Meilleures pratiques de nommage Windows Active Directory?
Il s'agit d'une question canonique sur la dénomination de domaine Active Directory.
Après avoir expérimenté avec des domaines Windows et des contrôleurs de domaine dans un environnement virtuel, je me suis rendu compte qu'avoir un domaine Active Directory nommé de manière identique à un domaine DNS est une mauvaise idée (ce qui signifie qu'avoir example.com comme nom Active Directory n'est pas bon lorsque nous avons le example.com nom de domaine enregistré comme site Web).
Cette question connexe semble étayer cette conclusion , mais je ne suis toujours pas sûr des autres règles concernant la dénomination des domaines Active Directory.
Existe-t-il des meilleures pratiques sur ce qu'un nom Active Directory devrait ou ne devrait pas être?
Cela a été un sujet amusant de discussion sur la défaillance du serveur. Il semble y avoir différentes "opinions religieuses" sur le sujet.
Je suis d'accord avec la recommandation de Microsoft : utilisez un sous-domaine du nom de domaine Internet déjà enregistré de la société.
Donc, si vous possédez foo.com, utilisation ad.foo.com ou quelque chose comme ça.
À mon avis, la chose la plus ignoble consiste à utiliser le nom de domaine Internet enregistré, textuellement, pour le nom de domaine Active Directory. Cela vous oblige à copier manuellement les enregistrements du DNS Internet (comme www) dans la zone DNS Active Directory pour permettre la résolution des noms "externes". J'ai vu des choses complètement stupides comme IIS installé sur tous les DC dans une organisation exécutant un site Web qui fait une redirection telle que quelqu'un entrant foo.com dans leur navigateur serait redirigé vers www.foo.com par ces installations IIS. Idiot!
L'utilisation du nom de domaine Internet ne vous procure aucun avantage, mais crée un "travail" à chaque fois que vous modifiez les adresses IP auxquelles les noms d'hôte externes font référence. (Essayez d'utiliser un DNS géographiquement équilibré en charge pour les hôtes externes et d'intégrer cela à une telle situation de "DNS partagé" aussi! Gee-- ce serait amusant ...)
L'utilisation d'un tel sous-domaine n'a aucun effet sur des éléments tels que la remise des e-mails Exchange ou les suffixes UPN (User Principal Name), BTW. (Je vois souvent les deux cités comme excuses pour utiliser le nom de domaine Internet comme nom de domaine AD.)
Je vois aussi l'excuse "beaucoup de grandes entreprises le font". Les grandes entreprises peuvent prendre des décisions impitoyables aussi facilement (sinon plus) que les petites entreprises. Je n'achète pas cela simplement parce qu'une grande entreprise prend une mauvaise décision, ce qui en fait en quelque sorte une bonne décision.
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 Web publique est
example.comvotre AD interne pourrait s'appeler quelque chose commead.example.comouinternal.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 Web publique est
example.comvotre annonce peut être nomméeexample.nettant que vous êtes inscritexample.netet 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é sur l'utilisation de .local et d'autres TLD constitués comme .lan et .corp . Vous ne devez en aucun cas le faire.
Ce n'est pas plus sûr. Ce ne sont pas des "meilleures pratiques" comme certains le prétendent. Et il n'a pas n'importe quoi avantage sur les deux choix que j'ai proposés.
Mais je veux lui donner le même nom que l'URL de mon site Web public afin que mes utilisateurs soient example\user au lieu de ad\user
Il s'agit d'une préoccupation valide mais erronée. Lorsque vous faites la promotion du premier DC 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 qu'il soit ad.example.com, vous pouvez configurer le nom NetBIOS du domaine sur example pour que vos utilisateurs se connectent en tant que example\user.
Dans 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 @ example.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 jamais 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 qui auront besoin de travailler avec le nom de domaine complet sont les administrateurs système qui travaillent avec Active Directory.
Supposez également que vous utilisez un espace de noms DNS à horizon divisé, ce qui signifie que votre nom AD est le même que votre site Web public. Vos utilisateurs ne peuvent plus accéder à example.com en interne sauf si vous en avez un préfixe www. dans leur navigateur ou vous exécutez IIS sur tous vos contrôleurs de domaine (c'est mauvais). Vous devez également organiser deux zones DNS non identiques qui partagent 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'ils ont également une configuration DNS à horizon partagé avec leur AD et leur présence externe. Vous avez une liaison fibre privée entre les deux et vous devez créer une approbation. Maintenant, tout votre trafic vers l'un de leurs sites publics doit traverser le lien privé au lieu de simplement sortir sur Internet. Il crée également toutes sortes de maux de tête pour les administrateurs réseau des deux côtés. Évitez ça. 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. Tout autre moyen comporte des écueils. Je ne vous dis pas de vous précipiter pour changer votre nom de domaine s'il fonctionne et est en place, mais si vous créez un nouvel AD, faites l'une des deux choses que j'ai recommandées ci-dessus.
Pour aider la réponse de MDMarra:
Vous ne devez JAMAIS utiliser un nom DNS à étiquette unique pour votre nom de domaine. C'était/est disponible avant Windows 2008 R2. Les raisons/explications peuvent être trouvées ici: Déploiement et fonctionnement des domaines Active Directory configurés à l'aide de noms DNS en une seule partie | Support Microsoft
N'oubliez pas de NE PAS utiliser de mots réservés (un tableau est inclus dans le lien "Conventions de nommage" au bas de cet article), comme SYSTEM ou MONDE ou RESTREINT.
Je suis également d'accord avec Microsoft en ce que vous devez suivre deux règles supplémentaires (qui ne sont pas figées, mais quand même):
- Vous ne devez PAS nommer votre domaine en fonction de quelque chose qui changera ou deviendra obsolète. Les exemples incluent l'attribution d'un nom à votre domaine après une ligne de produits, un système d'exploitation ou tout autre élément susceptible de changer au fil du temps. Restez fidèle à quelque chose de géographique ou de concret pour avoir un sens 5 ou même 10 ans plus tard.
- Restez avec des noms courts de 15 caractères ou moins, cela permettra au nom NETBIOS d'être facilement le même que le nom de domaine.
Enfin, je recommanderais que vous pensiez à long terme autant que possible. Les entreprises passent par des fusions et acquisitions, même de petites entreprises. Pensez également à obtenir une aide/consultation extérieure. Utilisez les noms de domaine, la structure AD, etc. qui seront explicables aux consultants ou aux personnes ici sur SF sans trop d'effort.
Liens de connaissances:
http://technet.Microsoft.com/en-us/library/cc731265%28v=ws.10%29.aspx
http://support.Microsoft.com/kb/909264
http://support.Microsoft.com/kb/300684/en-us
page de recommandation actuelle de Microsoft (W2k12) pour le nom de domaine de la forêt racine
Je ne suis pas d'accord avec l'utilisation de:
- example.com - pour des raisons déjà mentionnées dans d'autres réponses
Je pourrais accepter d'utiliser:
- ad.example.com - - pour des raisons déjà mentionnées dans d'autres réponses
Mais je ne le ferais pas moi-même ou ne le recommanderais pas. Lors de la reprise de l'entreprise, le rebranding de tous les enfers se déchaîne, en particulier lorsque la direction souhaite à ce stade que les choses changent immédiatement. Renommer les migrations, les changements sont très difficiles ou coûteux.
La meilleure façon que je recommanderais est d'acheter un domaine non pertinent pour le nom de l'entreprise et non pertinent pour la marque de l'entreprise. SIMPLE.CLOUD ou similaire devrait très bien faire tant que vous pouvez le posséder.
J'ai vu de grandes entreprises avec 150 000 utilisateurs utiliser AD qui fait toujours référence à une ancienne entreprise qu'ils ont achetée il y a des années, ou des entreprises qui ont changé de nom et même si cela n'a pas d'importance à long terme que vous utilisez\login (si vous ne pouvez pas utilisez UPN), cela semble toujours mauvais devant la direction qui ne comprend pas pourquoi il n'est pas trivial de la changer.