Les meilleures pratiques en matière de dénomination de Windows Active Directory ?

Il n'y a que deux réponses correctes à cette question.

1. Un sous-domaine inutilisé d'un domaine que vous utilisez publiquement. Par exemple, si votre présence publique sur le web est example.com votre AD interne pourrait être nommé comme suit ad.example.com o internal.example.com .

2. Un domaine de second niveau inutilisé que vous possédez et ne pas utiliser ailleurs. Par exemple, si votre présence publique sur le web est example.com votre AD pourrait s'appeler example.net pour autant que vous vous soyez inscrit example.net et ne l'utilisez pas ailleurs !

Ce sont vos deux seuls choix. Si tu fais autre chose, tu t'exposes à beaucoup de douleur et de souffrance.

Mais tout le monde utilise .local !
Cela n'a pas d'importance. Tu ne devrais pas. J'ai écrit un blog sur l'utilisation de .local et d'autres TLD inventés comme .lan et .corp. . En aucun cas, vous ne devez faire cela.

Ce n'est pas plus sûr. Ce ne sont pas des "meilleures pratiques" comme certains le prétendent. Et ça n'a pas cualquier par rapport aux 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 valable, mais erronée. Lorsque vous promouvez le premier DC d'un domaine, vous pouvez définir le nom NetBIOS du domaine comme vous le souhaitez. Si vous suivez mon conseil et configurez votre domaine pour qu'il soit ad.example.com vous pouvez configurer le nom NetBIOS du domaine pour qu'il soit example afin que vos utilisateurs se connectent en tant que example\user .

Dans les forêts et les trusts 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 primaire pour tous les comptes de votre domaine. Si vous combinez cela avec la recommandation NetBIOS précédente, aucun utilisateur final ne verra jamais que le FQDN de votre domaine est ad.example.com . Tout ce qu'ils voient sera example\ o @example.com . Les seules personnes qui auront besoin de travailler avec le FQDN sont les administrateurs système qui travaillent avec Active Directory.

Supposons également que vous utilisez un espace de noms DNS à horizon partagé, ce qui signifie que votre nom AD est le même que celui de votre site Web public. Maintenant, vos utilisateurs ne peuvent pas accéder à example.com en interne, sauf si vous les avez préfixés www. dans leur navigateur ou vous exécutez IIS sur tous vos contrôleurs de domaine (ce qui est mauvais). Vous devez également gérer deux des zones DNS non identiques qui partagent un espace de noms disjoint. C'est vraiment plus de tracas que cela n'en vaut la peine. Imaginez maintenant que vous ayez un partenariat avec une autre entreprise et qu'elle ait également une configuration DNS à horizon partagé avec son AD et sa présence externe. Vous avez un lien privé en fibre optique entre les deux et vous devez créer une confiance. Désormais, tout votre trafic vers l'un de leurs sites publics doit traverser la liaison privée au lieu de passer par l'Internet. Cela crée également toutes sortes de maux de tête pour les administrateurs de réseau des deux côtés. Evitez cela. Faites-moi confiance.

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 méthode comporte des pièges. 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 je vous ai recommandées ci-dessus.

Pour aider la réponse de MDMarra :

Vous devez N'utilisez JAMAIS un nom DNS à étiquette unique. pour votre nom de domaine non plus. Ceci était/est disponible avant Windows 2008 R2. Les raisons/explications peuvent être trouvées ici : Déploiement et fonctionnement des domaines Active Directory qui sont configurés en utilisant des noms DNS à étiquette unique | Support Microsoft

N'oubliez pas de NE PAS utiliser les mots réservés (un tableau est inclus dans le lien "Conventions de nommage" en bas de cet article), comme SYSTEM ou WORLD ou RESTRICTED.

Je suis également d'accord avec Microsoft pour dire que vous devriez suivre deux règles supplémentaires (qui ne sont pas gravées dans la pierre, mais tout de même) :

1. Vous ne devez PAS nommer votre domaine en fonction de quelque chose qui va changer ou devenir obsolète. Par exemple, vous pouvez nommer votre domaine d'après une gamme de produits, un système d'exploitation ou tout autre élément susceptible de changer au fil du temps. Choisissez plutôt quelque chose de géographique ou de concret qui aura un sens dans 5, voire 10 ans.
2. Privilégiez les noms courts de 15 caractères ou moins, ce qui permettra au nom NETBIOS d'être facilement identique au nom de domaine.

Enfin, je vous recommande de penser à long terme autant que possible. Les entreprises passent par des fusions et des acquisitions, même les petites entreprises. Pensez également à obtenir une aide/consultation extérieure. Utilisez des noms de domaine, une structure AD, etc. qui pourront être expliqués aux consultants ou aux personnes présentes sur SF sans trop d'efforts.

Liens de connaissance :

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 :

• example.com - pour des raisons déjà évoquées dans d'autres réponses

Je pourrais accepter d'utiliser :

• ad.example.com - - pour des raisons déjà évoquées dans d'autres réponses

Mais je ne le ferais pas moi-même et je ne le recommanderais pas. Lors d'un rachat d'entreprise ou d'un changement de marque, tout peut arriver, surtout si la direction veut que les choses changent immédiatement. Les migrations et les changements de nom sont très difficiles ou coûteux.

Le meilleur moyen que je recommande est d'acheter un domaine qui n'a rien à voir avec le nom de l'entreprise ni avec sa marque. SIMPLE.CLOUD ou similaire devrait faire l'affaire aussi longtemps que vous pouvez le posséder.

J'ai vu de grandes entreprises de 150 000 utilisateurs utiliser AD qui se réfère toujours à une ancienne société 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 utiliser l'UPN), cela fait toujours mauvais effet devant la direction qui ne comprend pas pourquoi il n'est pas trivial de le changer.

Je le fais toujours mydomain.local .

local n'est pas un TLD valide, il n'entre donc jamais en concurrence avec une entrée DNS publique réelle.

Par exemple, j'aime être capable de savoir que web1.mydomain.local se résoudra à l'IP interne d'un serveur web, tandis que web1.mydomain.com sera résolu vers l'IP externe.