Quelques règles simples pour faire d’Active Directory votre meilleur allié !

AD a besoin d’une infrastructure DNS – c’est-à-dire, d’un ensemble de serveurs DNS dans votre intranet d’entreprise qui contient des enregistrements DNS décrivant (au minimum) vos DC et serveurs membres, et aussi peut-être quelques informations sur vos stations de travail. Les réseaux d’ordinateurs utilisent DNS depuis deux décennies, bien plus longtemps qu’ils n’ont utilisé AD, donc il devrait être simple de construire une fondation DNS pour AD. Toutefois, la plupart des infrastructures DNS sont destinées à être visibles sur l’interface publique et vous ne voulez certainement pas que vos données DNS à propos d’AD soient visibles par tous sur Internet. C’est pourquoi les structures DNS de la plupart des implémentations d’AD sont déconnectées de l’Internet public selon un modèle appelé « split-brain DNS », une configuration qui s’accompagne d’exigences qui échappent à une installation DNS banale.
La plus forte de ces exigences est que chaque serveur DNS à l’intérieur de l’intranet est une copie locale de l’information DNS (en jargon DNS, le « fichier de zone DNS ») pour chaque domaine de votre forêt. Supposons que je ne veuille qu’un domaine local, que nous appellerons bigfirm.biz. Mais comme je prévois la croissance de mon entreprise, je préfère anticiper en créant non pas un mais deux domaines : bigfirm. biz et un domaine racine de forêt vide que j’appelle root.local. Chaque instance d’AD a besoin d’une zone DNS, donc il me faudra des zones DNS nommées root.local et bigfirm. biz.

Premièrement, je veux créer le domaine root.local parce que c’est le domaine racine de la forêt. Pour m’y préparer, j’établis la zone DNS root.local en mettant en place DNS sur une machine Windows 2003 Server ou Windows 2000 et en créant une zone nommée root.local sur ce serveur. Comme le domaine root.local a très peu de machines et de comptes utilisateur, il n’est pas déraisonnable d’avoir un serveur jouant le double rôle de serveur DNS et de DC pour root.local. J’établis ce premier serveur comme le serveur DNS primaire pour une zone dynamique nommée root.local, j’ordonne au système de s’utiliser lui-même comme le serveur DNS préféré, et j’exécute Dcpromo pour créer le domaine d’AD nommé root.local.

Ensuite, j’établis un second serveur comme serveur DNS secondaire pour root.local, en ordonnant à nouveau à ce serveur de s’utiliser lui-même comme serveur DNS préféré. Je le configure pour qu’il aille au premier serveur DNS pour obtenir des copies actualisées de la zone root.local. Ensuite, j’utilise Dcpromo pour en faire non seulement un second serveur DNS pour le domaine racine mais aussi un second DC, parce que n’avoir qu’un DC pour un domaine – aussi mineur soit-il – est une très mauvaise chose.

Avec deux serveurs DNS/DC en place pour root.local, j’ai bien instauré le domaine racine de la forêt. Cela ne veut pas dire dans mon esprit que tous les DC devraient être des serveurs DNS. Dans un domaine de plus de deux serveurs, n’hésitez pas à faire de certains serveurs des DC et d’autres des serveurs DNS, si vous le préférez. Supposons que j’aie plutôt décidé de faire de root.local un grand domaine dans une forêt à un seul domaine. Il me suffirait de configurer tous les serveurs DNS suivants comme secondaires sur le domaine root.local et de tirer leur copie de la zone root.local à partir du premier serveur DNS de root.local, qui agit comme le serveur DNS primaire de root.local. Il me faudrait aussi être certain que les machines que je voulais être membres du domaine root.local pointaient vers un serveur DNS qui est soit le primaire, soit l’un des secondaires pour root.local.

Jusqu’ici tout va bien et aucun problème de configuration ne s’est manifesté. Je m’attaque donc ensuite à mon second domaine, bigfirm.biz. Comme avec root.local, j’établis un serveur avec DNS et crée une zone dynamique nommée bigfirm.biz, je la pointe vers elle-même comme un serveur DNS préféré et j’exécute Dcpromo. Mais Dcpromo échouera parce que le service DNS sur le premier (et seul) serveur DNS de bigfirm.biz ne peut pas trouver la zone root.local. Le seul moyen pour un serveur DNS de trouver une zone DNS donnée est soit d’avoir une copie de cette zone localement sur le disque dur du serveur DNS, soit de rechercher dans l’Internet public un serveur avec cette zone. Le premier serveur DNS de bigfirm.biz n’a pas une copie de la zone localement et – par nature – il ne trouvera jamais un serveur DNS avec la zone root.local sur l’Internet public. C’était délibéré : je ne voulais pas que le monde extérieur puisse trouver mon fichier de zones.

Je pourrais bien sûr faire du premier serveur DNS de bigfirm. biz un serveur secondaire pour root.local, et Dcpromo fonctionnerait parfaitement. Malheureusement, les domaines de ma forêt ne se trouveraient pas entre eux. Les systèmes pointant vers les serveurs DNS qui sont aussi des DC dans root.local seraient incapables de trouver les DC de bigfirm. biz parce que les serveurs de root.local seraient dépourvus d’une copie locale de la zone bigfirm.biz. Pis encore, je pourrais créer davantage de serveurs DNS sur des systèmes dans la zone bigfirm.biz et me souvenir de les rendre secondaires sur bigfirm. biz, mais oublier de les rendre secondaires sur root.local. Ce serait grave, parce que les enregistrements DNS qui identifient les serveurs GC très importants d’un domaine n’apparaissent que dans la zone DNS pour le domaine racine de la forêt. Les éventuels systèmes d’un domaine autre que la racine de forêt seraient par conséquent incapables de trouver un GC et une pluie de problèmes s’abattrait sur moi. Pour régler cette difficulté, il me faut mettre une zone bigfirm.biz et root.local sur chaque serveur DNS dans l’intranet.

Morale de cette histoire: Chaque serveur DNS dans votre intranet doit être un serveur DNS primaire ou secondaire pour chaque domaine de votre forêt.