Le choix d’un nom de domaine Active Directory (AD) est une étape très importante de la phase de planification. Cela est particulièrement vrai lorsque les administrateurs se trouvent dans une situation où un mauvais choix de nom a été fait et qu’ils envisagent maintenant de renommer le nom de domaine.
Il s’agit d’une très mauvaise situation, même si le changement de nom de domaine est pris en charge depuis AD 2003. En général, trois choix s’offrent à vous lorsque vous décidez du nom à utiliser :
Utiliser le même nom de domaine DNS interne et externe (interne/externe : company.com).
Utiliser un nom de domaine DNS interne et externe différent (interne : company.loc vs. externe : company.com).
Utiliser un sous-domaine du nom de domaine DNS externe pour l’espace de noms interne (interne : int.company.com vs. externe : company.com).
Pour cet article, nous allons supposer que vous avez choisi l’option 1. Personnellement, je trouve que la première option est la meilleure, même si elle est moins recommandée par Microsoft. La principale raison pour laquelle elle n’est pas recommandée est que si vous n’êtes pas très familier avec l’administration DNS, il est possible d’exposer vos enregistrements Active Directory à l’Internet.
Cependant, si vous concevez correctement l’infrastructure, vous fournirez de manière transparente des services à vos utilisateurs internes et externes accédant aux ressources en utilisant le même nom de domaine.
Paramètres du client DNS pour les contrôleurs de domaine
J’ai fait l’expérience directe de ce « gotcha » lors de ma première implémentation d’Active Directory utilisant le même nom interne et externe. Le problème était que les utilisateurs internes accédaient au site Web de l’entreprise en utilisant le même nom de domaine. Par exemple, disons que le nom de domaine est « widgets.com ».
Nos administrateurs DNS ont correctement séparé l’environnement DNS de sorte qu’une infrastructure DNS externe dédiée prenne en charge le trafic Internet externe, tandis que l’infrastructure DNS interne prend en charge l’infrastructure Active Directory. Cependant, lorsque les utilisateurs internes ouvrent un navigateur et tapent widgets.com, ils ne peuvent accéder à la page Web qu’un certain pourcentage du temps. La plupart du temps, les utilisateurs obtiennent simplement le message « Page non trouvée ».
En recherchant ce problème, j’ai remarqué que les contrôleurs de domaine du domaine widgets.com enregistraient un « enregistrement parent » vierge pour le nom de domaine avec l’adresse IP de chaque DC. C’est le comportement par défaut des contrôleurs de domaine Active Directory. Cet enregistrement est en fait appelé LdapIPAddress. Par conséquent, la zone DNS interne pour widgets.com avait les enregistrements suivants :
widgets.com 65.85.0.1 (IP publique pour le site Web, simplement un exemple)
widgets.com 192.168.0.1 (IP publique pour le site Web, à titre d’exemple)
widgets.com 192.168.0.2
widgets.com 192.168.0.3
www.widgets.com 65.85.0.1 (IP publique pour le site web)
Comme vous pouvez le remarquer dans cet exemple, les IP privées 192.168.0.1-3 appartiennent aux contrôleurs de domaine. Le 65.85.0.1 est l’IP publique du serveur web externe, créé par l’administrateur DNS. Dans ce scénario, lorsqu’une requête arrive sur le serveur DNS interne pour « widgets.com », le serveur DNS répond avec les 4 enregistrements.
Votre navigateur se connecterait alors à la première adresse IP à laquelle le nom a été résolu. Dans ce scénario hypothétique, il faut s’attendre à ce que seuls 25 % de vos utilisateurs internes puissent accéder au site Web (25 % à cause du DNS round robin).
Il existe plusieurs façons de gérer cette situation :
Apprenez à vos utilisateurs à accéder au site Web en utilisant l’enregistrement « www » au lieu du nom de domaine parent.
Installez IIS sur chaque contrôleur de domaine et redirigez les utilisateurs vers la page « www ».
Empêchez les DCs de mettre à jour l’adresse LdapIPAddress.
Sensibilisez vos utilisateurs
Il peut être difficile d’éduquer les utilisateurs. En outre, dans les grands environnements, cette tâche devient trop difficile à suivre en raison de la rotation des employés.
De plus, les utilisateurs non techniques ne comprennent pas vraiment la différence entre www.journaldufreenaute.fr et journaldufreenaute.fr, donc même si vous les éduquez, ils essaieront très probablement l’un ou l’autre enregistrement jusqu’à ce qu’une page s’affiche.
Installer IIS sur les DCs
La deuxième méthode, qui consiste à installer IIS sur les DC, permet d’atténuer facilement ce problème. En effet, si le client résout le nom de domaine vers les IP des DC, il accèdera aux services Web installés sur les DC.
Tout ce que vous devez faire est de rediriger l’utilisateur via les outils natifs de IIS ou de créer une page par défaut qui redirige l’utilisateur de manière programmatique.
Modification du registre
La troisième méthode peut très bien fonctionner dans les situations où les politiques de sécurité ne permettent pas d’installer IIS sur les contrôleurs de domaine. Empêcher l’enregistrement de LdapIPAddress dans le DNS peut être une solution facile.
Mais elle nécessite une entrée manuelle dans le registre de chaque contrôleur de domaine et une entrée manuelle dans le DNS pour les DCs qui sont également des serveurs de catalogue global. L’entrée dans le registre doit être créée avant le processus DCPROMO.
Pour empêcher un DC d’enregistrer le nom de domaine avec son adresse IP, créez un DWORD appelé RegisterDnsARecords à cet emplacement : HKLM\SYSTEM\CurrentControlSet\Services\Netlogon\Paramètres
Ce DWORD indique si le contrôleur de domaine enregistre les enregistrements A (adresses) du système de noms de domaine (DNS) pour le domaine. Si le contrôleur de domaine est une ressource de catalogue global, cette entrée détermine également si le contrôleur de domaine enregistre des enregistrements DNS A pour le catalogue global.
Une valeur de 0 ne permettra pas au DC d’enregistrer ces enregistrements (nom de domaine et enregistrement GC le cas échéant), et une valeur de 1 permettra au DC d’enregistrer les enregistrements.
Puisque cela empêche également le DC d’enregistrer l’enregistrement GC dans le DNS, vous devrez également créer cet enregistrement manuellement dans la zone AD DNS. Dans notre exemple, cet enregistrement sera nécessaire pour chaque DC sur lequel vous modifiez le registre. Nous supposerons que tous les DCs dans cet exemple sont également des serveurs Global Catalog.
gc._msdcs.widgets.com A 192.168.0.1 gc._msdcs.widgets.com A 192.168.0.2 gc._msdcs.widgets.com A 192.168.0.3
NOTE importante concernant LdapIPAdress
Si vous envisagez d’empêcher l’enregistrement de cet enregistrement dans le DNS, il y a certaines implications qui peuvent avoir un impact sur votre capacité à localiser certains services dans le domaine. Vous devez être pleinement conscient de la nature de ces implications et de la manière de les surmonter.
En savoir plus sur LdapIPAdress
AD DS : Ce contrôleur de domaine doit enregistrer ses enregistrements de ressources d’hôte DNS (A/AAAA) pour le domaine : technet.microsoft.com/en-us/library/dd378858(WS.10).aspx