Cas Pratique : Résoudre un conflit DNS « Split-Brain » entre Active Directory et Site Web Public

Avez-vous déjà eu un site web parfaitement accessible depuis la maison, mais qui joue à la roulette russe quand vous essayez d’y accéder depuis le bureau ? C’est l’histoire d’un classique de l’administration système : le conflit de nommage, ou « Split-Brain DNS ».

Le Symptôme : « Ça marche, ça marche pas… »

Tout commence par un ticket utilisateur : « Le site institutionnel ((societe.com) ne charge pas quand je suis au bureau. Une fois sur deux, j’ai une erreur. »

Un rapide diagnostic avec nslookup révèle l’anomalie :

C:\> nslookup societe.com
Réponse ne faisant pas autorité :Nom :    socite.com
Addresses:  
10.10.0.XX      <-- IP Interne (Privée)            
10.10.0.XX      <-- IP Interne (Privée)            
194.254.x.x     <-- IP Publique (Web)

Le problème est flagrant : Le client DNS reçoit trois adresses pour le même nom. C’est la roulette russe réseau : 1 chance sur 3 de tomber sur le site Web, 2 chances sur 3 d’avoir une erreur.

  1. S’il choisit l’IP publique (194...), le site s’affiche.
  2. S’il choisit une IP privée (10...), il essaie de contacter un serveur interne (Contrôleur de Domaine) sur le port 443 (HTTPS). Or, un Contrôleur de Domaine n’est pas un serveur web… Résultat : « La connexion a échoué ».

L’Explication pour les Néophytes : Le « Pizzaiolo et le Comptable »

Pour comprendre ce qui se passe, imaginez que dans votre ville, il y a deux « Mario ».

  • Mario le Pizzaiolo (Public) : Il fait les meilleures Margarita de la ville. C’est votre site Web.
  • Mario le Comptable (Privé) : Il travaille au 3ème étage de votre bureau. Il gère les fiches de paie et les badges d’accès (votre Active Directory). Il est très sérieux et ne sait pas faire de pizza.

Quand vous êtes chez vous, vous cherchez « Mario » dans l’annuaire, vous tombez sur le Pizzaiolo. Miam.

Mais quand vous êtes au bureau, l’annuaire interne liste aussi Mario le Comptable. Si vous criez « MARIO ! » dans le couloir :

  • Une chance sur deux que le Comptable lève la tête.
  • Vous lui demandez « Une Reine supplément champignons s’il te plait ».
  • Il vous regarde avec des yeux ronds, vous tend une feuille Excel et retourne travailler. Error 404 : Pizza Not Found.

C’est le Split-Brain DNS : Avoir donné le même nom (societe.com) à votre service d’identité interne et à votre vitrine publique.

Le Dilemme Technique

La solution naïve serait de dire : « Supprimons les IP privées du DNS pour societe.com ! ». ⛔ Interdit ! Microsoft Active Directory a besoin que le nom du domaine racine (societe.com) pointe vers les Contrôleurs de Domaine. C’est vital pour l’authentification des sessions, l’application des GPO (stratégies) et le bon fonctionnement du réseau.

On ne peut donc pas « réparer » le DNS. On doit contourner le trafic.

Le « Péché Originel » de l’Architecture (Pourquoi c’est comme ça ?)

« Mais pourquoi on a appelé le domaine interne pareil que le site web ? » Pas si vite. Il faut remettre les choses dans leur contexte historique.

1. Le poids de l’histoire (La mode d’il y a 15 ans)

Il y a 10-15 ans, c’était la grande mode (et même une recommandation de certains consultants) de nommer son domaine Active Directory exactement comme son domaine public : societe.com.

L’objectif était l’élégance : On voulait que les utilisateurs se loguent sur leur PC avec leur adresse email : [email protected]. C’était propre, simple, facile à retenir. À l’époque, utiliser [email protected] ou pire, [email protected], semblait « moche » et techniquement lourd.

Le revers de la médaille : Le problème, c’est la contrainte technique absolue de Microsoft Active Directory :

La Règle d’Or AD : Pour qu’un domaine Active Directory fonctionne, le nom du domaine racine (societe.com) DOIT obligatoirement résoudre vers les adresses IP des Contrôleurs de Domaine.

C’est non-négociable. C’est comme ça que vos PC trouvent le serveur pour ouvrir votre session Windows, télécharger les GPO, et synchroniser l’horloge. Si votre domaine s’appelle societe.com, alors ping societe.com doit répondre l’IP du serveur interne. Si vous supprimez ça, plus personne ne peut se loguer au bureau. Tout le réseau s’effondre.

2. Le raccourci « facile » (Le Split-Brain Zone)

L’autre scénario (celui que l’on rencontre souvent quand l’AD est bien nommé, type societe.prod) est le besoin de résoudre des noms internes. L’admin veut que intranet.societe.com fonctionne en interne, alors il crée une zone DNS manuelle societe.com sur ses serveurs Windows.

L’erreur fatale : Avoir hébergé cette zone directement SUR les Contrôleurs de Domaine. En étant hébergée sur un DC, la zone hérite de ses comportements : la racine @ est capturée par le DC. Si cette zone avait été sur un petit serveur DNS Linux à côté, on aurait pu faire pointer la racine vers le Web sans aucun conflit. C’est donc souvent une économie de bout de chandelle (un serveur DNS en moins) qui cause le souci des années plus tard.

La Vision Moderne (« Best Practice »)

Aujourd’hui, on a appris de nos erreurs. L’architecture recommandée par Microsoft et les experts sécurité est stricte : Séparation totale.

On utilise un sous-domaine d’un domaine public que l’on possède.

  • Web Public = societe.com
  • Active Directory = ad.societe.com, corp.societe.com ou int.societe.com.

Pourquoi pas .local ou .prod ?

  • .local : À proscrire absolument ! Il est réservé pour le protocole mDNS (Bonjour/Avahi) utilisé par les Macs et les objets connectés. Appeler son AD societe.local garantit des lenteurs et des bugs bizarres avec les produits Apple.
  • .prod, .corp, .internal : C’est mieux, mais attention. Certaines de ces extensions (comme .prod géré par Google) sont devenues de vraies extensions Internet. Si un jour quelqu’un achète votre nom de domaine sur Internet avec cette extension, vous aurez un nouveau conflit.
  • Le Gold Standard : En utilisant ad.societe.com, comme vous êtes propriétaire de societe.com, vous avez la garantie mathématique que personne d’autre au monde ne pourra utiliser ce nom. C’est la sécurité absolue.

Résultat : Zéro conflit. Les Marios ne s’appellent plus pareil.

  • L’AD gère sa petite bulle corp.societe.com.
  • Le DNS public gère tout le reste.

Mais migrer un domaine existant (renommer tout l’AD de societe.com à corp.societe.com) est un projet titanesque, risqué et coûteux. Alors, plutôt que de tout casser, on triche avec notre ami IIS.

La Solution de Contournement : Former le Comptable à la Réception

Puisqu’on est « coincés » avec cette architecture héritée, nous allons transformer nos Contrôleurs de Domaine (les comptables) en réceptionnistes.

L’objectif :

  1. L’utilisateur demande https://societe.com.
  2. Le DNS l’envoie vers le Contrôleur de Domaine (DC ou le comptable dans notre scénario)
  3. Le DC (via IIS) répond : « Je ne suis pas le site web, mais le vrai site est à l’adresse https://www.societe.com« . Pour les néophytes, le comptable (IIS) a reçu une nouvelle consigne : « Si quelqu’un te demande une pizza (page web), ne dis rien, montre lui juste le panneau vers www.societe.com. »
  4. L’ordinateur de l’utilisateur va automatiquement sur www.societe.com (qui lui, est hébergé sur le serveur Web public).

Mise en œuvre Technique

Voici les étapes que nous avons suivies pour corriger cela sans casser l’Active Directory.

1. Installation de IIS sur les Contrôleurs de Domaine

C’est souvent contre-intuitif d’installer un rôle Web sur un serveur critique comme un DC, mais c’est ici nécessaire pour gérer la requête HTTP. Nous installons uniquement le strict minimum.

Commandes PowerShell (à exécuter sur chaque DC) :

Install-WindowsFeature Web-Server, Web-Http-Redirect

Note : Cela n’installe pas de base de données ou de moteur PHP complexe, juste de quoi répondre à une requête Web simple.

2. Configuration de la Redirection

Dans la console IIS (ou via script), nous configurons le « Site Web par défaut » pour qu’il ne serve aucune page, mais renvoie une instruction de redirection (Code 301 – Permanent).

Import-Module WebAdministration
# Activer la redirection vers le sous-domaine 'www'
Set-WebConfigurationProperty -PSPath 'IIS:\Sites\Default Web Site' -Filter /system.webServer/httpRedirect -Name destination -Value 'https://www.societe.com'
Set-WebConfigurationProperty -PSPath 'IIS:\Sites\Default Web Site' -Filter /system.webServer/httpRedirect -Name httpResponseStatus -Value 'Permanent'

3. Le défi du SSL (HTTPS)

C’est le point critique souvent oublié. Si la redirection n’est active que sur le port 80 (HTTP), l’utilisateur qui tape https://societe.com aura une erreur de certificat avant d’être redirigé.

Analogie : C’est comme si le Comptable verrouillait sa porte. Vos collègues ne peuvent même pas entrer pour lui demander où est le Pizzaiolo. (Les gens de l’extérieur, eux, vont directement chez le Pizzaiolo, donc ils ne voient jamais le Comptable).

Il faut donc :

  1. Générer un fichier .PFX contenant le certificat wildcard (*.societe.com) ou le certificat racine.
  2. L’importer sur les Contrôleurs de Domaine.
  3. Lier ce certificat au port 443 dans IIS.

Analogie : Ainsi, le Comptable ouvre la porte, sourit, et redirige vos collègues poliment.

4. Nettoyage DNS final

Une fois la redirection en place sur TOUS les contrôleurs de domaine, on peut (et on doit) supprimer l’enregistrement A de l’IP publique (194.x.x.x) dans la zone DNS interne. Désormais, 100% du trafic interne pour societe.com ira vers les DC -> Redirection -> www.societe.com.

5. Le détail qui tue (Le Pare-feu)

N’oubliez pas un détail physique bête et méchant : jusqu’à présent, vos utilisateurs n’avaient pas de raison d’aller sur le port 80 ou 443 de vos Contrôleurs de Domaine. Vérifiez vos ACLs / Pare-feux ! Assurez-vous que le flux réseau LAN Utilisateurs -> Contrôleurs de Domaine est bien autorisé sur les ports TCP 80 et 443. Sinon, vos utilisateurs s’écraseront sur le pare-feu avant même de recevoir la redirection.

Résultat

Le problème est résolu de manière transparente :

  • L’Active Directory continue de fonctionner normalement sur societe.com.
  • Les utilisateurs accèdent au site web sans erreur via la redirection automatique vers www.
  • L’expérience utilisateur est unifiée entre l’interne et l’externe.

Étiquettes

Publications similaires