Active Directory – Les enregistrements DNS indispensables
Sommaire
I. Présentation
L'importance du protocole DNS n'est plus à prouver, nous l'utilisons chaque jour des dizaines de fois, à chaque fois que l'on communique avec un serveur ou que l'on navigue sur internet, pour ne citer que ces deux cas de figures.
Il en est de même pour l'Active Directory qui est très friand de DNS... D'ailleurs, sans le DNS l'Active Directory ne fonctionnera pas.
Dans cet article, nous allons nous intéresser aux enregistrements DNS liés à l'Active Directory et en particuliers ceux qui lui sont indispensables, ceux sans lesquels il ne peut fonctionner.
II. Listing des enregistrements
Commençons par lister les enregistrements DNS importants dans un tableau, avant de passer au cas par cas. Ces enregistrements peuvent être de type A, CNAME ou SRV, selon l’enregistrement concerné.
| Rôle | Enregistrement DNS | Type | Requis |
| PDC | _ldap._tcp.pdc._msdcs. | SRV | Uniquement un par domaine |
| GC | _ldap._tcp.gc._msdcs. | SRV | Au moins un par forêt |
| KDC | _kerberos._tcp.dc._msdcs. | SRV | Au moins un par domaine |
| DC | _ldap._tcp.dc._msdcs. | SRV | Au moins un par domaine |
| FQDN | <FQDN-Contrôleur-de-domaine> | A | Un enregistrement par contrôleur de domaine |
| Adresse IP du GC | gc._msdcs.<Nom-DNS-Forêt> | A | Au moins un par forêt |
| GUID via CNAME | <DC-GUID>._msdcs.<Nom-DNS-Forêt> | CNAME | Un enregistrement par contrôleur de domaine |
III. Les propriétés d’un enregistrement
Lorsque l’on va s’attaquer au cas par cas, nous irons voir les propriétés des enregistrements. Pour cela il est nécessaire de comprendre l’utilité des différents champs qui sont les suivants :
- Priorité : Un indice de priorité du serveur, les clients tentent de joindre en priorité celui qui a la valeur la plus basse.
- Poids : Un mécanisme d'équilibrage de charge qui est utilisé lors de la sélection d'un hôte cible à partir de ceux qui ont la même priorité. Les clients choisissent aléatoirement parmi les enregistrements SRV correspondant, notamment dans le cas d’un environnement multi-contrôleurs.
- Numéro du port : Le port sur lequel le serveur écoute pour ce service
- Hôte offrant ce service : Le nom complet (FQDN) de l’hôte correspondant pour l’enregistrement.
IV. Les enregistrements
Passons désormais au cas par cas, en reprenant l’ensemble des enregistrements indiqués dans le tableau.
A. Enregistrement PDC
Cet enregistrement permet à vos clients de localiser le PDC (Primary Domain Controller). Le serveur enregistré derrière cet enregistrement est celui qui détient le rôle FSMO « Émulateur PDC ».
Pour vérifier la valeur de cet enregistrement, et même de tous les enregistrements, plusieurs méthodes existent :
- Via l’interface graphique
- Via PowerShell notamment avec Get-DnsServerResourceRecord
- Via l’utilitaire nslookup
Par exemple, sur votre serveur DNS, via le Gestionnaire DNS vous pouvez le retrouver à l’emplacement suivant :
Zones de recherche directes > _msdcs.it-connect.fr > pdc > _tcp
Pour ma part, il s’agit du contrôleur de domaine « dc2.it-connect.fr » qui est l’émulateur PDC. On peut également le vérifier avec une requête dans l’Active Directory directement (via PowerShell – Remplacez « it-connect.fr » avec le nom de votre domaine) :
(Get-ADDomain it-connect.fr).PDCEmulator
D’ailleurs, en PowerShell, pour vérifier dans le DNS on utilisera (Remplacez « it-connect.fr ») :
(Get-DnsServerResourceRecord -Name _ldap._tcp.pdc -ZoneName _msdcs.it-connect.fr).RecordData.DomainName
Ces deux commandes retournent un résultat sensiblement équivalent :
La seule différence est la présence d’un point à la fin du résultat concernant la requête DNS. Ceci est typique dans un enregistrement DNS afin d’indiquer au serveur que c’est la fin de l’enregistrement et qu’il n’est pas nécessaire d’ajout le nom de domaine à la suite.
Ces deux commandes et ces deux résultats permettent une chose : Comparer les deux valeurs afin de voir si l’enregistrement DNS concernant le PDC est cohérent avec le PDC déclaré dans l’Active Directory.
Pour cela, on peut utiliser ce petit script réalisé par mes soins :
# Récupérer la valeur complète enregistrée dans le DNS
$DnsPdc = (Get-DnsServerResourceRecord -Name _ldap._tcp.pdc -ZoneName _msdcs.it-connect.fr).RecordData.DomainName
# Retrait du point en fin de ligne dû au DNS – Nécessaire pour la comparaison
$DnsPdc = $DnsPdc.Substring(0,$DnsPdc.Length-1)
# Récupérer la valeur complète dans l'annuaire
$AdPdc = (Get-ADDomain it-connect.fr).PDCEmulator
# Comparaison des deux valeurs et conclusion
if ($DnsPdc -eq $AdPdc){
Write-Host "Le PDC enregistré dans l'annuaire est cohérent avec la valeur de l'annuaire"
}else{
Write-Host "Le PDC enregistré dans le DNS n'est pas le même que celui de l'annuaire"
}
Ce type de script peut facilement être réalisé pour l’ensemble des enregistrements, il suffit d’adapter à chaque fois.
L’importance de ce contrôleur de domaine, notamment utilisé pour la synchronisation de l’horloge via w32time ou une partie de la réplication inter-contrôleurs, implique que l’on s’assure de la validité de l’enregistrement DNS le concernant.
B. Enregistrement GC
Passons désormais au GC, c’est-à-dire au Catalogue Global. Il contient une copie de tous les objets de la forêt entière dont il fait partie.
Il peut y avoir un ou plusieurs Catalogue Global, ce qui est même recommandé d’en avoir plusieurs pour une question de redondance.
Voici la commande PowerShell pour vérifier qu’il existe au moins un GC d’enregistré dans le DNS (Remplacez « it-connect.fr ») :
Get-DnsServerResourceRecord -Name _ldap._tcp.gc -ZoneName _msdcs.it-connect.fr
Concernant la méthode graphique, parcourez l’arborescence de cette façon :
Zones de recherche directes > _msdcs.it-connect.fr > gc > _tcp
C. Enregistrement KDC
Cet enregistrement permet à un client de localiser un contrôleur de domaine qui fonctionne avec le service Kerberos, pour le domaine ciblé. Tous les contrôleurs de domaine basés sur Windows créent un enregistrement SRV dans le DNS pour le service Kerberos (KDC).
La commande PowerShell à utiliser sera la suivante :
Get-DnsServerResourceRecord -Name _kerberos._tcp.dc -ZoneName _msdcs.it-connect.fr
Pour les amoureux de l’interface graphique, voici toujours la correspondance :
Zones de recherche directes > _msdcs.it-connect.fr > dc > _tcp
D. Enregistrement DC
Ce type d’enregistrement permet aux clients de localiser le ou les contrôleur(s) de domaine disponibles pour le domaine concerné. Vous pouvez vérifier la cohérence des DCs enregistrés en interrogeant votre serveur DNS comme ceci :
Get-DnsServerResourceRecord -Name _ldap._tcp.dc -ZoneName _msdcs.it-connect.
Situé au même niveau que les enregistrements KDC, ils sont visibles via l’interface graphique à cet endroit :
Zones de recherche directes > _msdcs.it-connect.fr > dc > _tcp
E. Enregistrement FQDN
Ces enregistrements de type A permettent d’enregistrer l’adresse IP des différents contrôleurs de domaine. Le type « A » permet l’enregistrement d’une adresse IPv4, concernant l’IPv6 il est nécessaire d’utiliser le type « AAAA ».
Ces enregistrements sont très importants puisqu’ils permettent de résoudre en adresse IP les noms FQDN utilisés dans les autres enregistrements vus précédemment.
Pour cela, on listera les enregistrements de la zone principale correspondante à notre domaine, où le type d’enregistrement (RecordType) est « A ».
Get-DnsServerResourceRecord -ZoneName it-connect.fr | Where{$_.RecordType -eq "A"}
Pour obtenir l’adresse IP de tous les contrôleurs de domaine pour le domaine concerné, on peut utiliser nslookup qui est très appréciable dans ce cas :
nslookup it-connect.fr
Des enregistrements accessibles également en mode graphique :
Zones de recherche directes > it-connect.fr
F. Adresse IP du GC
Cet enregistrement et le suivant concerne plus particulièrement les clients appelés « non-SRV-Aware », c’est-à-dire qui ne supportent pas les enregistrements de type SRV. Pour ceux-là, il faudra prévoir un enregistrement basique de type « A » pour qu’ils trouvent malgré tout l’information recherchée.
Pour récupérer ces enregistrements concernant la localisation du Catalogue Global, on se positionne uniquement sur « gc » dans l’arborescence DNS. Ce qui donnera la commande :
Get-DnsServerResourceRecord -Name gc -ZoneName _msdcs.it-connect.fr
Cela est valable également via le Gestionnaire DNS où il suffit de rester positionné sur « gc » dans l’arborescence. Ensuite, sur la droite apparaîtrons les enregistrements « A » dédiés pour le ou les GC.
G. L’enregistrement du GUID via CNAME
Permet à un client de localiser un contrôleur de domaine dans une forêt en regardant un enregistrement spécifique.
Toutefois, les seules informations contenues et connues via cet enregistrement concernant le DC, sont le GUID de l'objet dans l'annuaire et le nom de la forêt dans laquelle le contrôleur de domaine est situé.
Si le GUID du contrôleur est « d46d1617-7665-48c1-8042-22a4c89059bb » on pourra grâce à nslookup et à l’alias CNAME retrouver l’adresse IP du serveur :
nslookup d46d1617-7665-48c1-8042-22a4c89059bb._msdcs.it-connect.fr
V. Contrôler les enregistrements
Il est envisageable de contrôler les enregistrements DNS en utilisant différents utilitaires, ou même, en développant différents scripts de contrôle en PowerShell comme celui que nous avons vu précédemment. On peut ensuite adapter ces scripts pour les intégrer à une solution de supervision afin de retourner un code retour compréhensible et interprétable par une telle solution.
Voici une liste d’utilitaire pratique pour le contrôle du DNS :
- nslookup : interroger le DNS
- dcdiag /test:dns : Tester le DNS
- ipconfig /flushdns : Vider le cache DNS
- dnslint : Diagnostiquer les problèmes de résolution DNS
VI. Conclusion
Bien entendu, pour un fonctionnement optimal d’un environnement Active Directory, il est nécessaire d’avoir un serveur DNS à jour et contenant l’ensemble des enregistrements nécessaires au fonctionnement de vos différents services.
S’assurer que les enregistrements cités dans cet article soient présents et cohérents me semble astucieux, et, c’est toujours bien de savoir comment fonctionne le DNS avec un Active Directory. Surtout lorsque l’on se retrouve face à une panne, on a déjà quelques notions en main pour vérifier le DNS et trouver une éventuelle erreur.
