Question Meilleures pratiques de dénomination de Windows Active Directory?


C'est un Question canonique sur la dénomination de domaine Active Directory.

Après avoir expérimenté des domaines et des contrôleurs de domaine Windows dans un environnement virtuel, je me suis rendu compte qu’avoir un domaine Active Directory portant le même nom qu’un domaine DNS n’était pas une bonne idée. example.com comme un nom Active Directory est pas bon quand nous avons le example.com nom de domaine enregistré pour être utilisé comme site Web).

Cette question connexe semble étayer cette conclusion, mais je ne suis toujours pas sûr des autres règles relatives à la dénomination des domaines Active Directory.

Existe-t-il des pratiques recommandées sur ce qu'un nom Active Directory devrait ou ne devrait pas être?


80
2017-10-21 13:10


origine




Réponses:


Cela a été un sujet de discussion amusant sur Server Fault. 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.

La chose la plus vile, à mon avis, utilise le nom de domaine Internet enregistré, mot pour mot, pour le nom de domaine Active Directory. Cela vous oblige à copier manuellement des enregistrements à partir du DNS Internet (comme www) dans la zone DNS Active Directory pour permettre la résolution de noms "externes". J'ai vu des choses complètement stupides comme IIS installé sur chaque contrôleur de domaine d'une organisation exploitant un site Web qui effectue une redirection telle que foo.com dans leur navigateur serait redirigé vers www.foo.com par ces installations IIS. Absurdité!

L'utilisation du nom de domaine Internet ne vous procure aucun avantage, mais crée "faire fonctionner" chaque fois que vous modifiez les adresses IP auxquelles font référence les noms d'hôte externes. (Essayez d’utiliser un DNS géographiquement équilibré en charge pour les hôtes externes et de l’intégrer à une telle situation de "split DNS" aussi! Ce serait amusant ...)

L'utilisation d'un tel sous-domaine n'a aucun effet sur des éléments tels que la remise de courrier électronique Exchange ou les suffixes UPN (User Principal Name), BTW. (Je vois souvent ces deux exemples cités comme des excuses pour utiliser le nom de domaine Internet en tant que nom de domaine AD.)

Je vois aussi l'excuse "beaucoup de grandes entreprises le font". Les grandes entreprises peuvent prendre des décisions décisives 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 qui la rend en quelque sorte une bonne décision.


94
2017-10-21 13:16



Mais alors le nom NetBIOS du domaine n'est pas ... bon, joli :) corp n'est pas aussi descriptif que foo. - Anton Gogolev
Vous pouvez cependant attribuer le nom NetBIOS de votre choix. Bon nombre de mes clients portent des noms tels que "ad.example.com", mais le nom NetBIOS est "EXEMPLE". DCPROMO vous demandera ce que vous souhaitez que le nom NetBIOS soit lors de la création du domaine. - Evan Anderson
Si vous faites cela, faites attention aux problèmes avec les domaines qui ont des caractères génériques. Lorsque vous avez * .foo.com, host.internal.foo.com lui correspond dans certaines situations - JamesRyan
Je ne connais aucun produit de serveur de messagerie qui vous oblige à utiliser le nom de domaine AD en tant que suffixe d'adresse électronique des utilisateurs. Échange a jamais toute corrélation entre le nom de domaine AD et les suffixes d’adresse électronique. - Evan Anderson
Office365 requiert uniquement que vos utilisateurs ouvrent une session avec leur UPN avec un suffixe correspondant à votre domaine de client hébergé. Étant donné que la stratégie d'adresse de boîte aux lettres Exchange par défaut peut être définie comme n'importe quoi, de même que votre suffixe UPN, il est simple. Nous avons EXAMPLE.COM comme nom de société (et locataire dans Office365), EXAMPLE.NET (également enregistré) comme forêt, CORP.EXAMPLE.NET comme domaine de compte principal (avec d’autres sous-domaines régionaux, par exemple EU.EXAMPLE. NET) avec EXAMPLE comme nom NetBIOS, tous les utilisateurs de l’organisation Exchange de la forêt utilisent Nom@EXAMPLE.COM pour UPN et pour le courrier électronique. Office365 est parfaitement satisfait de cela. - Ryan Fisher


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

  1. Un sous-domaine inutilisé d'un domaine que vous utilisez publiquement. Par exemple, si votre présence Web publique est example.com votre AD interne pourrait être nommé quelque chose comme ad.example.com ou internal.example.com.

  2. Un domaine de second niveau inutilisé que vous possédez et n'utilisez nulle part ailleurs. Par exemple, si votre présence Web publique est example.com votre AD pourrait être nommé 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é sur l'utilisation de .local et d'autres TLD composés, 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 ça n'a pas tout bénéficier sur les deux choix que j'ai proposés.

Mais je veux le nommer de la même façon que l'URL de mon site Web public afin que mes utilisateurs soient example\user au lieu de ad\user
C’est une préoccupation valable 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 pour qu'il soit 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 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 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. Maintenant, vos utilisateurs ne peuvent pas arriver à example.com en interne, sauf si vous les avez préfixe www. dans leur navigateur ou vous exécutez IIS sur tous vos contrôleurs de domaine (ce qui est mauvais). Vous devez aussi organiser deux zones 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 solution comporte 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.


87
2018-01-29 16:18



Un petit point - on peut utiliser quelque chose de beaucoup plus petit, plus rapide et sécurisé que IIS pour servir la redirection. Même haproxy ou nginx sont probablement excessifs - encore moins un serveur complet comme apache2. - OrangeDog
C’est vrai, mais tout de cela est bâclée et inutile. - MDMarra
Uuuuw ouais, c'était si douloureux quand quelqu'un a soudainement enregistré le nom de domaine local.net et que tous les imprimeurs qui avaient silencieusement NXDOMAIN avant cette date ne répondaient plus du tout. C'était une enquête amusante ... - Johannes
Puis-je simplement noter que .local n’est pas "constitué", il est en fait réservé; mais pas pour ce type d'utilisation: en.wikipedia.org/wiki/.local - mikebabcock
Au moment où cela a été écrit, ce n'était pas réservé. - MDMarra


Pour aider la réponse de MDMarra:

Vous devriez NE JAMAIS utiliser un nom DNS en une seule étiquette pour votre nom de domaine non plus. C'était / est disponible avant Windows 2008 R2. Les raisons / explications peuvent être trouvées ici: Déploiement et exploitation de domaines Active Directory configurés à l'aide de noms DNS en une seule étiquette | Support Microsoft

N'oubliez pas de NE PAS utiliser de mots réservés (un tableau est inclus dans le lien "Conventions de désignation" au bas de cet article), tel que SYSTEM ou WORLD ou RESTRICTED.

Je suis également d'accord avec Microsoft dans le sens où vous devriez suivre deux règles supplémentaires (qui ne sont pas figées dans la pierre, mais quand même):

  1. Vous ne devez PAS nommer votre domaine en fonction de quelque chose qui va changer ou devenir obsolète. Les exemples incluent l'attribution d'un nom de domaine à une ligne de produit, à un système d'exploitation ou à tout autre élément susceptible de changer au fil du temps. Tenez-vous-en avec quelque chose qui soit suffisamment géographique ou concret pour avoir un sens dans 5 ou 10 ans.
  2. Utilisez des noms courts de 15 caractères ou moins pour que le nom NETBIOS soit facilement identique au nom de domaine.

Enfin, je vous recommanderais de penser à long terme autant que possible. Les entreprises passent par des fusions et des acquisitions, même des petites entreprises. Pensez également à obtenir une aide / une consultation extérieure. Utilisez des noms de domaine, une structure AD, etc. qui pourront être expliqués aux consultants ou aux utilisateurs de SF sans 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 (W2k12) de Microsoft pour le nom de domaine de la forêt racine


33
2018-01-29 16:35





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 le recommanderais. Lors de la prise de contrôle de l'entreprise, tout le monde se rebiffe, surtout lorsque la direction souhaite alors que les choses changent immédiatement. En renommant les migrations, les modifications sont très difficiles ou coûteuses.

Le meilleur moyen que je recommande est d’acheter un domaine qui n’est pas pertinent pour le nom de la société ni pour la marque de la société. SIMPLE.CLOUD ou similaire devrait faire l'affaire aussi longtemps que vous pouvez le posséder. 

J'ai vu de grandes entreprises avec 150 000 utilisateurs utilisant AD qui font toujours référence à une ancienne entreprise 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 utilisiez \ login (si vous ne le pouvez pas utiliser UPN), ça a toujours l'air mauvais devant la direction qui ne comprend pas pourquoi ce n'est pas anodin de le changer.


1
2017-10-27 15:33





je 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 bien savoir que web1.mydomain.local résoudra à l'adresse IP interne d'un serveur Web, tandis que web1.mydomain.com va résoudre à l'IP externe.


-14
2017-09-23 20:03



FWIW, .local requêtes marteau sur le serveur L racine - ~ 800 / sec quand j'ai regardé. - jscott
dot.Local, AKA dot.Fail - PnP
L'utilisation d'un TLD (ou d'un domaine non enregistré) non valide n'est pas une bonne pratique, c'est une pire pratique, pour toutes les raisons mentionnées ci-dessus. J'admettrai que j'ai utilisé .local, mais c'était avant que je sache mieux. - Jonathan J