Meilleures pratiques pour la conception de domaine Active Directory (AD) pour l’utilisation d’un nom de domaine enregistré en tant que nom d’un domaine AD. Les alternatives viables comprennent l’utilisation d’un suffixe d’DNS non public (. local ou . LAN, par exemple) dans le nom de domaine AD ou la création d’un sous-domaine de domaine AD dans le domaine enregistré (Corp.domain.com, par exemple).
Vous n’avez pas toujours le choix souhaité, mais vous pouvez être amené à prendre en charge un domaine AD qui a le même nom que le domaine enregistré de l’entreprise, et il se peut que la gestion ne souhaite pas modifier l’un de ces noms. C’est ce que l’on appelle un scénario split DNS (ou split-brain DNS), dans lequel il existe deux espaces de nommage DNS distincts : l’espace de nommage interne utilisé par Active Directory et l’espace de nommage externe utilisé par le registre de domaine public avec le même nom. Ce scénario peut présenter certains défis uniques. Cet article présente les problèmes courants liés à un environnement de DNS séparé, ainsi que les mesures à prendre pour les atténuer.
Dans tous les exemples ci-dessous, le domaine AD et le domaine enregistré sont tous deux nommés domain.com, et il existe un site Web de l’entreprise nommé www.domain.com.
Problème 1 : Le site Web de l’entreprise hébergée en externe est inaccessible à partir de l’intérieur du Bureau
C’est le problème le plus courant dans un environnement de DNS divisé : le site Web de l’entreprise, ou une autre ressource appartenant à une entreprise et connectée à Internet, n’est pas accessible depuis l’extérieur par des machines jointes au domaine AD, mais les machines en dehors du Bureau n’ont pas de problème pour accéder au site Web. Cela peut se produire en examinant ce qui se passe lorsqu’un utilisateur interne tente de parcourir le site Web de l’entreprise :
Le problème survient en raison du fait qu’un serveur DNS doté d’une zone de recherche particulière dans sa base de données : la zone domain.com dans cet exemple-n’envoie pas de requêtes pour les enregistrements de cette zone ailleurs. il renvoie simplement une réponse « introuvable » s’il n’y a aucun enregistrement correspondant à une requête donnée. Dans cet exemple, il existe un autre serveur DNS avec l’enregistrement approprié : le serveur DNS qui héberge la zone domain.com publique appartenant au registre des domaines, comme cela est évident par le fait que les machines en dehors du bureau peuvent accéder au site Web. Toutefois, les requêtes émanant d’ordinateurs internes ne sont jamais accessibles sur ce serveur.
La solution à ce problème est simple : créez un enregistrement d’hôte nommé www dans la zone domain.com sur le contrôleur de domaine et indiquez l’adresse IP du site Web. Les machines qui interrogent DNS Server reçoivent ensuite la bonne réponse et peuvent parcourir le site Web.
Problème 2 : Site Web public hébergé en interne et inaccessible à partir de l’intérieur du Bureau
Cela peut être considéré comme une variante du problème 1 ci-dessus. Dans ce cas, la différence est que le site Web est hébergé en interne, soit derrière un pare-feu sur le réseau interne de l’entreprise, soit dans une DMZ. Il est supposé être accessible aux utilisateurs internes et externes, mais les utilisateurs internes ne sont pas en mesure de les atteindre, tandis que les utilisateurs externes ne signalent pas de problèmes.
La raison de ce problème est similaire à celle du problème 1, mais les utilisateurs internes dans ce cas sont en mesure de résoudre correctement le nom du site Web sur son adresse IP publique. Cependant, ils ne peuvent toujours pas accéder au site Web en raison de la manière dont le pare-feu est configuré. Il s’attend à ce que les utilisateurs sur le réseau interne puissent accéder au site Web à l’aide de son adresse privée plutôt que de son adresse publique.
Là encore, il existe un correctif simple : créez un enregistrement d’hôte nommé www dans la zone domain.com sur le contrôleur de domaine, mais cette fois-ci, attribuez à l’enregistrement l’adresse IP privée du site Web. La fonctionnalité ordinateurs internes résout le nom du site Web sur cette adresse privée, tandis que les machines externes continuent de résoudre le nom sur l’adresse publique du site Web.
Problème 3 : Le site Web se charge inversement ou ne se charge pas après avoir apporté les modifications ci-dessus
. Cela peut se produire si le code du site web redirige les navigateurs de www.domain.com vers domain.com ou si les liens internes font référence au site en tant que domain.com plutôt que www.domain.com. Les mêmes symptômes sont observés sur les machines internes, que le site soit hébergé en interne ou en externe :
Dans ce cas, le problème est un peu plus complexe. Pour que les ordinateurs résolvent domain.com sur une adresse IP, il doit y avoir un enregistrement d’hôte vide dans la zone domain.com dans DNS. Le nom de cet enregistrement s’affiche sous la forme (identique à dossier parent) dans la console DNS Windows. Toutefois, il existe un problème dans ce cas : AD utilise des enregistrements d’hôte vides dans la zone domain.com pour représenter les DCS pour le domaine domain.com . Les membres du domaine utilisent ces enregistrements pour localiser un DC à des fins d’authentification, et s’il existe des enregistrements d’hôte vides dans la zone domain.com , des délais ou des problèmes d’authentification peuvent se produire.
Pour la raison précédente, ce problème ne peut pas être résolu dans DNS seul. La création d’un enregistrement d’hôte vide avec l’adresse IP du site Web résout par intermittence le problème d’accès au site Web pour les utilisateurs internes, car il existe déjà d’autres enregistrements d’hôte vides avec les adresses IP des contrôleurs de domaine dans le domaine, ce qui entraîne des problèmes d’authentification du domaine.
Le moyen le plus simple de résoudre ce problème consiste à modifier le code du site Web pour supprimer la redirection ou corriger les liens internes pour que tout se réfère au site en tant que www.domain.com plutôt qu’à domain.com. Si vous n’avez pas la possibilité de modifier le code, la seule option permettant de résoudre le problème est de renommer le domaine AD. Il peut s’agir d’une tâche complexe, en fonction de la taille et de la complexité de l’environnement.