Il n'y a que deux bonnes réponses à cette question.
Un sous-domaine inutilisé d'un domaine que vous utilisez publiquement. Par exemple, si votre présence sur le Web est publique, example.com
votre AD interne peut porter le nom ad.example.com
ou internal.example.com
.
Un domaine de second niveau inutilisé que vous possédez et que vous n'utilisez nulle part ailleurs. Par exemple, si votre présence sur le Web est publique, example.com
votre AD peut être nommée example.net
tant que vous vous êtes inscrit example.net
et ne l'utilisez nulle part ailleurs!
Ce sont vos deux seuls choix. Si vous faites autre chose, vous vous exposez à beaucoup de douleur et de souffrance.
Mais tout le monde utilise .local!
Peu importe Tu ne devrais pas. J'ai blogué à propos de l'utilisation de .local et d'autres TLD tels que .lan et .corp . En aucun cas, vous ne devriez faire cela.
Ce n'est pas plus sécurisé. Ce ne sont pas des "meilleures pratiques" comme le prétendent certaines personnes. Et les deux choix que j'ai proposés ne présentent aucun avantage.
Mais je veux lui donner le même nom que l'URL de mon site Web public, de sorte que mes utilisateurs soient example\user
remplacés parad\user
Ceci est une préoccupation valide, mais erronée. Lorsque vous promouvez le premier contrôleur de domaine dans un domaine, vous pouvez définir le nom NetBIOS du domaine comme vous le souhaitez. Si vous suivez mes conseils et configurez votre domaine pour être ad.example.com
, vous pouvez configurer le nom NetBIOS du domaine example
afin que vos utilisateurs se connectent en tant que example\user
.
Dans les forêts et approbations Active Directory, vous pouvez également créer des suffixes UPN supplémentaires. Rien ne vous empêche de créer et de définir @ exemple.com comme suffixe UPN principal pour tous les comptes de votre domaine. Lorsque vous combinez cela avec la recommandation NetBIOS précédente, aucun utilisateur final ne verra que le nom de domaine complet de votre domaine est ad.example.com
. Tout ce qu'ils verront sera example\
ou @example.com
. Les seules personnes devant utiliser le nom de domaine complet sont les administrateurs système qui travaillent avec Active Directory.
En outre, supposons que vous utilisiez un espace de noms DNS à horizon divisé, ce qui signifie que votre nom AD est identique à votre site Web destiné au public. Désormais, vos utilisateurs ne peuvent pas accéder à l’ example.com
interne à moins d’avoir leur préfixe www.
dans leur navigateur ou d’exécuter IIS sur tous vos contrôleurs de domaine (ce qui est mauvais). Vous devez également organiser deuxzones DNS non identiques partageant un espace de noms disjoint. C'est vraiment plus compliqué que ça en vaut la peine. Imaginez maintenant que vous avez un partenariat avec une autre entreprise et qu’elles ont également une configuration DNS à horizon divisé avec leur AD et leur présence externe. Vous avez un lien de fibre privé entre les deux et vous devez créer une confiance. Maintenant, tout votre trafic sur l'un de leurs sites publics doit traverser le lien privé au lieu de simplement sortir par Internet. Cela crée également toutes sortes de maux de tête pour les administrateurs réseau des deux côtés. Évitez cela. Croyez-moi.
Mais mais mais ...
Sérieusement, il n'y a aucune raison de ne pas utiliser l'une des deux choses que j'ai suggérées. Toute autre manière a des pièges. Je ne vous dis pas de vous précipiter pour changer votre nom de domaine s'il fonctionne et qu'il est en place, mais si vous créez une nouvelle AD, effectuez l'une des deux choses que j'ai recommandées ci-dessus.
corp
n’est pas aussi descriptif quefoo
.