Annuaire LDAP, Active Directory et Kerberos

Un annuaire est une base centrale qui recense les comptes, les groupes et les machines d'une organisation, et que les applications interrogent pour authentifier les utilisateurs et connaître leurs droits. LDAP est le protocole standard pour interroger un annuaire ; Active Directory est l'annuaire de Microsoft, qui utilise LDAP pour la consultation et Kerberos pour l'authentification. Kerberos permet à un utilisateur de prouver son identité une seule fois à l'ouverture de session, puis d'accéder aux services du domaine grâce à des tickets, sans retaper son mot de passe.

Pourquoi un annuaire

Sans annuaire, chaque serveur a ses comptes locaux : Chloé Lambert a un compte sur le serveur de fichiers, un autre sur l'imprimante, un troisième sur l'outil de tickets, avec des mots de passe différents qui ne suivent pas la même politique. Le jour de son départ, il faut penser à tous. L'annuaire centralise les identités (comptes utilisateurs et ordinateurs), les groupes, les attributs (service, fonction, téléphone) et, pour Active Directory, les politiques appliquées aux postes. Une identité, un mot de passe, une politique, un point de désactivation.

LDAP : le protocole des annuaires

LDAP (Lightweight Directory Access Protocol, version 3, RFC 4511) est le protocole qui permet de chercher, lire et modifier les entrées d'un annuaire.

L'annuaire est un arbre (le DIT, Directory Information Tree). Chaque entrée a un nom distinctif (DN, Distinguished Name) qui décrit son chemin, de la feuille vers la racine :

CN=Chloé Lambert,OU=Informatique,OU=Utilisateurs,DC=ad,DC=sorbier,DC=example

Chaque entrée appartient à des classes d'objets (user, group, computer, inetOrgPerson…) qui définissent ses attributs : sAMAccountName (l'identifiant court, clambert), userPrincipalName (clambert@ad.sorbier.example), mail, memberOf (ses groupes), department.

Une recherche LDAP en ligne de commande, depuis un serveur Linux :

# Chercher Chloé dans l'annuaire, en LDAPS, avec un compte de service en lecture seule
ldapsearch -H ldaps://dc1.ad.sorbier.example -D "svc-ldap-lecture@ad.sorbier.example" -W \
  -b "OU=Utilisateurs,DC=ad,DC=sorbier,DC=example" \
  "(&(objectClass=user)(sAMAccountName=clambert))" cn mail memberOf

Le filtre (&(objectClass=user)(sAMAccountName=clambert)) se lit « les objets qui sont des utilisateurs et dont l'identifiant est clambert ». & signifie ET, | OU, ! NON.

Active Directory : les briques à connaître

Active Directory Domain Services (AD DS) est l'annuaire des réseaux Windows. Ses briques, que tu manipules en SISR :

Les groupes ont une étendue qui dit où ils peuvent être utilisés. La bonne pratique pour donner des droits sur une ressource s'appelle AGDLP :

• Accounts : les comptes des utilisateurs…
• … vont dans des groupes Globaux qui représentent une fonction (GG_Comptabilite) ;
• ces groupes globaux vont dans des groupes de Domaine Local qui représentent un droit sur une ressource (DL_Partage_Compta_Modification) ;
• et c'est au groupe de domaine local que l'on donne la Permission (sur le dossier, l'imprimante).

Quand Paul Martin arrive à la comptabilité, on l'ajoute à GG_Comptabilite : il obtient d'un coup tous les droits de sa fonction. Personne ne touche aux ACL des dossiers. Cette organisation est la traduction technique de la matrice d'habilitations (chapitre 11).

# Créer le compte de Paul Martin dans la bonne OU, désactivé tant que son arrivée n'est pas confirmée
New-ADUser -Name "Paul Martin" -SamAccountName "pmartin" `
  -UserPrincipalName "pmartin@ad.sorbier.example" `
  -Path "OU=Comptabilite,OU=Utilisateurs,DC=ad,DC=sorbier,DC=example" `
  -AccountPassword (Read-Host -AsSecureString "Mot de passe initial") `
  -ChangePasswordAtLogon $true -Enabled $false

# Lui donner les droits de sa fonction
Add-ADGroupMember -Identity "GG_Comptabilite" -Members "pmartin"

# Le jour de l'arrivée
Enable-ADAccount -Identity "pmartin"

Le cours Windows Server détaille l'installation d'un contrôleur de domaine, les OU et les GPO. Sous Linux, les équivalents libres sont OpenLDAP (annuaire seul), Samba en mode contrôleur de domaine (compatible Active Directory) et FreeIPA (annuaire, Kerberos et gestion des droits).

Kerberos : s'authentifier une fois, accéder à tout le domaine

Kerberos (version 5) est le protocole d'authentification d'Active Directory. Son idée : l'utilisateur prouve son identité une seule fois à un tiers de confiance, le KDC (Key Distribution Center, qui tourne sur chaque contrôleur de domaine), et reçoit en échange des tickets chiffrés qu'il présente ensuite aux services. Son mot de passe ne circule jamais sur le réseau.

Les étapes, avec leur nom :

1. AS-REQ : à l'ouverture de session, le poste demande au service d'authentification (AS) un ticket. Il prouve qu'il connaît le mot de passe en chiffrant l'heure courante avec une clé dérivée de ce mot de passe (la pré-authentification).
2. AS-REP : le KDC vérifie et renvoie un TGT (Ticket Granting Ticket), chiffré avec la clé du compte spécial krbtgt, que seul le KDC connaît.
3. TGS-REQ : pour accéder au serveur de fichiers, le poste présente son TGT au service d'émission de tickets (TGS).
4. TGS-REP : le TGS renvoie un ticket de service pour ce serveur, chiffré avec la clé du compte du serveur.
5. AP-REQ : le poste présente le ticket de service au serveur, qui le déchiffre avec sa propre clé, y lit l'identité de Chloé et ses groupes, et applique les droits.

Les valeurs par défaut d'une stratégie Kerberos d'Active Directory, à connaître :

NTLM, l'ancien protocole à abandonner

Avant Kerberos, Windows utilisait NTLM, un protocole défi-réponse. Il reste utilisé quand Kerberos n'est pas possible (accès par adresse IP au lieu du nom, machine hors domaine). Il est plus faible : pas d'authentification mutuelle, exposition aux attaques par relais et au pass-the-hash. Microsoft a déclaré toutes les versions de NTLM obsolètes et a supprimé NTLMv1 de Windows 11 24H2 et de Windows Server 2025. La consigne : appeler l'authentification par Negotiate, qui tente Kerberos d'abord, auditer l'usage de NTLM, puis le restreindre.

Les attaques contre l'annuaire, en bref

Active Directory est la cible principale des attaques par rançongiciel : qui contrôle le domaine contrôle toutes les machines. Quatre attaques à savoir nommer et parer :

L'ANSSI publie des recommandations dédiées à l'administration sécurisée des systèmes d'information reposant sur Active Directory, organisées autour du cloisonnement des comptes d'administration en niveaux (chapitre 10).

Côté SLAM : authentifier les utilisateurs d'une application par l'annuaire

Une application interne peut éviter de gérer ses propres mots de passe en les faisant vérifier par l'annuaire : elle cherche le DN de l'utilisateur avec un compte de service, puis tente un bind avec ce DN et le mot de passe saisi. Si le bind réussit, le mot de passe est bon.

<?php
function authentifierParAnnuaire(string $identifiant, string $motDePasse): ?array {
    // Un mot de passe vide ferait un bind anonyme qui RÉUSSIT : on le refuse d'emblée
    if ($identifiant === '' || $motDePasse === '') {
        return null;
    }
    $ldap = ldap_connect('ldaps://dc1.ad.sorbier.example');
    ldap_set_option($ldap, LDAP_OPT_PROTOCOL_VERSION, 3);
    ldap_set_option($ldap, LDAP_OPT_REFERRALS, 0);

    // 1. Bind du compte de service, en lecture seule (secret lu hors du code source)
    if (!ldap_bind($ldap, 'svc-ldap-lecture@ad.sorbier.example', getenv('LDAP_SVC_MDP'))) {
        return null;
    }
    // 2. Recherche du DN : la saisie est échappée avant d'entrer dans le filtre
    $filtre = sprintf('(&(objectClass=user)(sAMAccountName=%s))',
                      ldap_escape($identifiant, '', LDAP_ESCAPE_FILTER));
    $resultat = ldap_search($ldap, 'OU=Utilisateurs,DC=ad,DC=sorbier,DC=example',
                            $filtre, ['dn', 'cn', 'memberof']);
    $entrees = ldap_get_entries($ldap, $resultat);
    if ($entrees['count'] !== 1) {
        return null;
    }
    // 3. Bind avec le DN trouvé et le mot de passe saisi : c'est la vérification
    if (!@ldap_bind($ldap, $entrees[0]['dn'], $motDePasse)) {
        return null;
    }
    return ['dn' => $entrees[0]['dn'], 'groupes' => $entrees[0]['memberof'] ?? []];
}

Deux pièges que ce code évite :

• l'injection LDAP : sans ldap_escape(), un identifiant comme *)(sAMAccountName=* modifie le filtre, comme une injection SQL modifie une requête (cours SQL) ;
• le bind non authentifié : avec un DN valide et un mot de passe vide, beaucoup d'annuaires acceptent le bind comme anonyme, et l'application croit le mot de passe correct.

Aujourd'hui, une application web récente passe plutôt par un fournisseur d'identité OpenID Connect relié à l'annuaire (chapitre 6) : elle ne voit plus du tout les mots de passe.

Comment l'E7 l'interroge

• SISR : expliquer le rôle d'un contrôleur de domaine et l'intérêt d'en avoir deux ; proposer une organisation des groupes (AGDLP) ; diagnostiquer un échec d'authentification dû à l'heure ; justifier LDAPS plutôt que LDAP ; proposer une parade au pass-the-hash ou au kerberoasting ; analyser des journaux de connexion d'un contrôleur de domaine.
• SLAM : repérer une injection LDAP ; expliquer pourquoi déléguer l'authentification à l'annuaire évite de stocker des mots de passe ; justifier un compte de service en lecture seule.
• Tronc commun : expliquer l'intérêt d'un annuaire centralisé pour la gestion des arrivées et des départs.

Exercices