Active Directory — LDAP, DNS et Kerberos
Trois protocoles font fonctionner Active Directory : LDAP pour accéder à l'annuaire, DNS pour localiser les contrôleurs, Kerberos pour authentifier. Si l'un tombe, l'annuaire ne fonctionne plus.
1. LDAP
LDAP (Lightweight Directory Access Protocol) est le protocole d'accès et d'administration des annuaires. Il permet de rechercher, ajouter, supprimer et modifier des entrées.
Active Directory l'utilise pour toutes les interactions avec sa base : c'est LDAP qui circule quand une application interroge l'annuaire pour valider un compte ou récupérer une liste d'utilisateurs.
| Variante | Port | Apport |
|---|---|---|
| LDAP | TCP/389 | Accès standard, en clair |
| LDAPS | TCP/636 | LDAP sur SSL/TLS : confidentialité et intégrité. Nécessite un certificat |
| LDAP Signing | TCP/389 | Signature numérique des requêtes : authenticité et intégrité, via SASL Bind |
Distinction régulièrement demandée : LDAP Signing protège contre l'altération des requêtes et les attaques de type man-in-the-middle ; LDAPS protège la confidentialité par chiffrement. Ce ne sont pas des alternatives mais des protections complémentaires, et Microsoft recommande d'activer les deux.
La structure de l'annuaire
Un annuaire LDAP est un ensemble d'entrées, chacune composée d'attributs (nom, type, valeur). Les entrées s'organisent hiérarchiquement dans des unités d'organisation.
2. DNS
Active Directory ne fonctionne pas sans DNS. C'est la dépendance la plus souvent sous-estimée, et la première cause de panne d'un domaine.
Pour joindre gameon.local, un poste n'interroge pas une adresse IP connue d'avance : il effectue
une requête DNS pour trouver le contrôleur de domaine.
| Enregistrement | Rôle |
|---|---|
| A | Associe le nom d'un contrôleur à son adresse IP |
| SRV | Localise les services : contrôleurs de domaine, KDC Kerberos, catalogue global, PDC Emulator |
| CNAME | Alias, notamment pour identifier les DC par leur GUID dans la forêt |
Les enregistrements SRV sont le cœur du mécanisme : ils répondent à la question
« quel serveur rend ce service dans ce domaine ? ». Ils sont créés automatiquement à la promotion du
contrôleur, dans les zones _msdcs, _sites, _tcp et _udp.
En pratique
- Le serveur DNS est intégré au contrôleur de domaine dans la plupart des déploiements, ce que propose l'assistant d'installation par défaut.
- Les contrôleurs doivent pouvoir écrire dynamiquement dans la zone.
- Tous les ordinateurs du domaine peuvent s'y enregistrer :
pc-01.gameon.local. - Les clients doivent avoir le DC comme serveur DNS principal. Pointer vers une box ou vers un DNS public est l'erreur la plus fréquente : la jonction au domaine échoue alors sans message clair.
Vérifications utiles depuis un poste client :
nslookup gameon.local
nslookup -type=SRV _ldap._tcp.dc._msdcs.gameon.local
ipconfig /all # contrôler le serveur DNS attribué
ipconfig /registerdns # forcer l'enregistrement du poste3. Kerberos
Kerberos v5 est le protocole principal d'authentification d'un domaine AD. Il n'intervient ni dans l'annuaire, ni dans la résolution de noms : il ne fait qu'authentifier.
| Composant | Rôle |
|---|---|
| KDC (Key Distribution Center) | Présent sur chaque DC, il regroupe les deux services suivants |
| AS (Authentication Service) | Délivre un TGT (Ticket-Granting Ticket) |
| TGS (Ticket-Granting Service) | Délivre un ticket de service pour une ressource précise |
Le déroulé
- L'utilisateur ouvre sa session : le poste contacte l'AS du KDC.
- L'AS vérifie l'identité et délivre un TGT, valable environ 10 heures, renouvelable.
- Pour accéder à un partage, le poste présente son TGT au TGS.
- Le TGS délivre un ticket de service propre à cette ressource.
- Le poste présente ce ticket au serveur de fichiers, qui accorde ou refuse l'accès.
Le TGT évite de se réauthentifier en permanence : c'est ce qui rend l'authentification unique possible. Les tickets de service sont réutilisables tant qu'ils sont valides. Le chiffrement symétrique (AES) protège contre le rejeu et l'interception.
Un ticket contient l'identité de l'utilisateur ou du service, une clé de session, une durée de validité, et pour un ticket de service l'identité de la ressource autorisée — ce qui empêche sa réutilisation frauduleuse ailleurs.
Si le KDC est indisponible, plus aucune authentification n'est possible : nouvelle justification des deux contrôleurs de domaine. Une bascule vers NTLM reste techniquement possible, mais ce protocole est nettement moins sûr et doit être limité, voire désactivé.
Kerberos est sensible à l'heure : un décalage de plus de 5 minutes entre le poste et le contrôleur fait échouer l'authentification, par protection contre le rejeu. D'où l'importance de la synchronisation NTP, assurée par le DC porteur du rôle PDC Emulator.
4. Les ports à connaître
| Service | Port |
|---|---|
| LDAP | TCP/389 |
| LDAPS | TCP/636 |
| Kerberos | TCP et UDP/88 |
| DNS | TCP et UDP/53 |
| Catalogue global | TCP/3268 — 3269 en SSL |
| SMB (partages, SYSVOL) | TCP/445 |
| NTP (synchronisation horaire) | UDP/123 |
| Changement de mot de passe Kerberos | TCP et UDP/464 |
Ces ports sont à ouvrir entre les postes et les contrôleurs lorsqu'un pare-feu sépare les deux — cas courant quand les serveurs sont dans un VLAN dédié. Voir la fiche Pare-feu, DMZ et filtrage.
5. Les identifiants d'objet
| Attribut | Format | Unique dans | Change ? |
|---|---|---|---|
| DistinguishedName (DN) | CN=Alice,OU=Compta,DC=gameon,DC=local |
L'annuaire | Oui : en cas de déplacement ou de renommage d'une OU |
| ObjectGUID | 128 bits générés automatiquement | La forêt | Jamais : il suit l'objet de sa création à sa suppression |
| ObjectSID | Identifiant de sécurité attribué par le DC | Le domaine | Jamais dans la même forêt |
| sAMAccountName | alice ou GAMEON\alice |
Le domaine | Modifiable |
| UserPrincipalName (UPN) | alice@gameon.local |
La forêt | Modifiable |
Le DN représente le chemin LDAP complet : domaine + OU + objet. Il se lit de droite à gauche,
du plus général au plus précis. Deux objets ne peuvent pas porter le même CN dans une même OU.
Point essentiel pour la sécurité : les permissions référencent l'ObjectSID, pas le nom. C'est pourquoi renommer un compte ne casse aucun droit, et pourquoi recréer un compte supprimé portant le même nom ne lui rend pas ses anciennes permissions — le nouveau SID est différent. Sur un partage, les anciennes permissions apparaissent alors comme un SID non résolu.
Le sAMAccountName est l'identifiant court hérité de Windows 2000, limité à 20 caractères ; l'UPN, au format e-mail, est plus moderne et recommandé pour l'ouverture de session.
Pour afficher le DN d'un objet dans ADUC : activer Affichage > Fonctionnalités avancées,
puis ouvrir les propriétés de l'objet et consulter l'onglet Éditeur d'attributs, attribut
distinguishedName.
À retenir
- LDAP accède à l'annuaire | DNS localise les DC | Kerberos authentifie
- LDAP 389 | LDAPS 636 | Kerberos 88 | DNS 53 | SMB 445
- LDAP Signing = authenticité | LDAPS = confidentialité
- AD ne fonctionne pas sans DNS : les DC se trouvent par enregistrements SRV
- Les clients doivent avoir le DC comme DNS principal — erreur la plus fréquente
- Kerberos : AS → TGT (~10 h), puis TGS → ticket de service
- Décalage horaire > 5 minutes → authentification Kerberos refusée
- KDC indisponible → plus aucune authentification
- ObjectGUID et ObjectSID ne changent jamais | le DN change
- Les permissions référencent le SID → recréer un compte homonyme ne rend pas les droits
- DN se lit de droite à gauche :
CN=…,OU=…,DC=…