Cours Annuaire et identités — LDAP, Active Directory, Kerberos, Microsoft Entra ID, SSO et MFA

Objectifs d'apprentissage

À la fin de ce cours, l'apprenant peut :

1. décrire ce qu'un annuaire et une authentification centralisée font, et leurs avantages ;
2. situer LDAP (DN, entrées, schémas) et son usage en lecture ;
3. expliquer la structure d'Active Directory (domaines, forêts, unités d'organisation, groupes, GPO) et la sécurité de base ;
4. situer Kerberos (TGT, ST) et son rôle dans le réseau Windows ;
5. comparer Microsoft Entra ID (tenant, utilisateurs, groupes) avec AD ;
6. expliquer SSO par SAML et OpenID Connect ;
7. décrire MFA et Conditional Access en principe ;
8. situer les comptes de service et leurs risques ;
9. défendre contre pass-the-hash, énumération de comptes et accès privilégiés ;
10. lancer une requête LDAP en lecture sur un annuaire fictif ou une documentation.

Prérequis

• Savoir ouvrir Terminal et lire une commande avant de la valider (cours « Terminal macOS »).
• Notions de réseau : serveur, port, DNS (cours « Réseau »).
• Notions de chiffrement et de certificat (cours « Chiffrement et cryptographie »), utiles pour Kerberos et TLS.
• Aucun accès à un annuaire réel n'est requis pour ce cours ; les exemples sont fictifs.

Parcours et chapitres

1. Annuaires et centralisationdes identités : principes

Un annuaire stocke des informations sur les utilisateurs, les ordinateurs, les groupes et les ressources d'un réseau : noms, adresses de courrier, appartenance aux groupes, droits d'accès. Un service d'authentification centralisé permet à un utilisateur de se connecter une fois et d'accéder à de nombreuses ressources sans réenvoyer son mot de passe.

Avantages :

• un seul mot de passe pour tous les services ;
• gestion simplifiée : un administrateur crée un compte une fois et le propage partout ;
• audit : journalisation des connexions au même endroit ;
• sécurité : secrets stockés dans un coffre, pas sur chaque serveur ;
• révocation : supprimer un compte empêche aussitôt l'accès partout.

Coûts : complexité, dépendance à un serveur central (si l'annuaire est indisponible, plus personne ne peut se connecter à nouveau sans cache).

2. LDAP : le protocole d'annuaire

LDAP (Lightweight Directory Access Protocol) est défini par les RFC 4511, 4512, 4513 (juin 2006, Proposed Standard ; remplace RFC 2251). Il permet d'accéder à un annuaire en lecture et écriture via le réseau, sur le port 389 en clair ou 636 en TLS (LDAPS, non standardisé dans ces RFC : non vérifié).

Structure : le DN et l'arbre.

Une entrée dans un annuaire LDAP est identifiée par un DN (Distinguished Name) : une suite d'attributs de la racine à l'entrée. Exemple (syntaxe RFC 4514, juin 2006) :

cn=alice,ou=Personnes,dc=corp,dc=example,dc=test

Sens : utilisateur alice dans l'unité d'organisation Personnes du domaine corp.example.test. Les composants courants :

• cn : common name
• ou : organizational unit
• dc : domain component
• o : organization
• c : country

Schéma.

Un schéma définit les classes d'objets (types d'entrée : inetOrgPerson pour une personne, groupOfNames pour un groupe) et les attributs autorisés (nom, email, mot de passe haché, groupe de membres). Le schéma lui-même est stocké dans l'annuaire, consultable.

Opérations.

Les opérations LDAP courantes :

• Bind : s'identifier (fournir un DN et un mot de passe haché) ;
• Search : chercher des entrées (par filtre, par attribut) ;
• Modify : changer un attribut ;
• Add : ajouter une entrée ;
• Delete : supprimer ;
• Compare : vérifier un attribut.

Pour ce cours, seules les opérations en lecture (Search, Compare) sont envisagées.

Filtres.

Un filtre LDAP (RFC 4515, non relue : non vérifié) ressemble à (&(objectClass=inetOrgPerson)(uid=alice)) : cherche les personnes dont uid vaut alice. Opérateurs : & (ET), | (OU), ! (NON), comparaisons (=, ~=, >=, <=).

3. Active Directory : structure et sécurité

Active Directory Domain Services (AD DS) est la mise en œuvre Microsoft de la gestion d'identité sur les réseaux Windows. Consultée le 18 octobre 2026, la page Microsoft Learn « Active Directory Domain Services overview » décrit AD comme un annuaire hiérarchique, stocké et répliqué sur les contrôleurs de domaine.

Hiérarchie : domaines et forêts.

• Domaine : un groupe d'utilisateurs et d'ordinateurs administrés ensemble. Exemple : corp.example.test. Un domaine est servi par au moins un contrôleur de domaine (DC).
• Forêt : regroupement de domaines avec une relation de confiance ; un seul schéma et un seul catalogue global par forêt.
• Unité d'organisation (OU) : subdivision à fins de gestion et de politique de groupe (groupes de comptes, ordinateurs).

Objets courants.

• Utilisateur (classe user) : compte humain, avec mot de passe (haché).
• Ordinateur : compte machine (Windows, macOS sans Kerberos : non vérifié).
• Groupe : collection d'utilisateurs/ordinateurs pour les permissions (Domain Admins, Domain Users, etc.).
• Group Policy Object (GPO) : ensemble de paramètres appliqués à des utilisateurs ou des ordinateurs (logiciels à installer, pare-feu, mots de passe, etc.). Les pages Microsoft Learn mentionnent les GPO sans en détailler l'implémentation ici : non vérifié.

Sécurité : les trois réflexes.

Le document Microsoft « Best practices for securing Active Directory » (consulté le 18 octobre 2026) récapitule :

1. Moindre privilège : un compte n'a que les droits indispensables pour son travail. Les groupes à risque (Domain Admins, Enterprise Admins, Administrators) sont protégés, les compte quotidiens ne sont pas administrateurs.
2. Comptes de service sécurisés : un service tournant sous un compte AD doit avoir un mot de passe long et complexe, une portée réduite (pas d'administrateur), et être auditée. Local Administrator Password Solution (LAPS) aide à gérer les mots de passe locaux.
3. Défense contre pass-the-hash : un attaquant ayant volé le haché d'un compte peut le rejouer pour se faire passer pour lui, sans connaître le mot de passe. Protections : Kerberos plutôt que NTLMv1/v2, comptes protégés dans des groupes (Protected Users), authentification à multiples facteurs.

Renvoi vers Azure et chiffrement. Le cours « Chiffrement et cryptographie » couvre les certificats X.509 utilisés par TLS et LDAPS. Le cours « Azure » couvre Microsoft Entra ID (l'équivalent cloud d'AD DS).

4. Kerberos en principe

Kerberos est un protocole d'authentification réseau (RFC 4120, juillet 2005, Proposed Standard) basé sur le chiffrement symétrique et des clés de session courtes. Il évite au client de renvoyer un mot de passe au serveur.

Principes. Kerberos demande à un centre de distribution de clés (KDC) de prouver l'identité d'un client. Le client reçoit un Ticket-Granting Ticket (TGT) (valable quelques heures, souvent 10 heures dans les déploiements Windows), puis demande des service tickets (ST) auprès du KDC pour accéder à chaque serveur sans montrer de mot de passe.

Détails : l'échange TGT/ST, la preuve d'identité par chiffrage, le rôle du KDC et les keytabs (fichiers de clés) ne sont pas entièrement spécifiés ici (non vérifié). Le point à retenir : Kerberos évite le mot de passe sur le réseau.

Intégration Windows. Sur un réseau Active Directory, les utilisateurs obtiennent un TGT au ouverture de session ; les ressources (serveurs de fichiers, bases de données) les acceptent sans nouveau mot de passe.

5. Microsoft Entra ID

Microsoft Entra ID (anciennement Azure AD) est la version cloud de l'authentification. La page Microsoft Learn « What is Microsoft Entra? » (consultée le 18 octobre 2026) la décrit comme un service SaaS d'identité et d'accès.

Concepts clés.

• Tenant : instance isolée pour une organisation (comparable à un domaine, mais dans le cloud) ; identifié par un ID unique.
• Utilisateurs et groupes : créés dans le tenant, synchronisés depuis AD DS par l'outil Azure AD Connect (non vérifié : cas hybride).
• Groupe : collection pour autorisation ; intégré aux applications SaaS (Microsoft 365, Salesforce, etc.).
• Accès conditionnel : politiques « si... alors... » basées sur le contexte : localisation, appareil, risque de connexion, application.

Avantages sur AD DS : accès depuis n'importe quel appareil, intégration cloud, gestion des identités externes (clients, partenaires).

6. Single Sign-On (SSO) : SAML et OpenID Connect

SSO permet à un utilisateur de se connecter une fois auprès d'un fournisseur d'identité (IdP) et d'accéder à de nombreuses applications (fournisseurs de service, SP) sans réentrer ses identifiants.

SAML 2.0 (OASIS, SAML V2.0 Technical Overview, mars 2008, non entièrement relue : non vérifié) : un fournisseur de service redirige l'utilisateur vers l'IdP, qui le vérifie et retourne une assertion (document XML signé prouvant l'identité). Flux : navigateur ← → SP ← → IdP.

OpenID Connect (OIDC) (OpenID Connect Core 1.0 avec erratum 2, 15 décembre 2023) : couche de protocole au-dessus d'OAuth 2.0, apportant l'identité (jeton id_token JWT avec claims iss, sub, aud, exp, iat, nonce). Un client peut aussi demander des attributs utilisateur via le endpoint userinfo.

Choix : SAML est courant en entreprise (complet, XML) ; OIDC est moderne (compact, JSON, facilement intégrable aux frameworks). Microsoft Entra ID supporte les deux.

7. Authentification multifacteur (MFA) et Conditional Access

MFA demande au moins deux preuves d'identité : mot de passe + jeton (SMS, app de génération de codes, clé physique FIDO2). Résiste mieux au vol de mot de passe.

Conditional Access (Microsoft Entra Conditional Access, page consultée le 18 octobre 2026, mise à jour du 28 avril 2026) : politiques d'accès conditionnelles basées sur :

• Signaux : identité, appareil, localisation (pays/région, adresse IP), risque (détection anormale, comptes compromis) ;
• Décisions : bloquer, autoriser, nécessiter MFA, demander conformité de l'appareil, etc. ;
• Rapport (report-only) : surveiller avant d'appliquer.

Exemple : « Si connexion depuis un endroit inconnu, exiger MFA ». Nécessite une licence Microsoft Entra ID P1.

8. Comptes de service et moindre privilège

Un compte de service est un compte non interactif pour un logiciel (application, script planifié). Risques :

• mot de passe codé en dur dans une configuration : le dépôt Git, un fichier de configuration, un secret enregistré sans chiffrement.
• trop de droits : un compte de service qui a Domain Admins expose l'annuaire entier si le mot de passe est volé.
• pas de revue : les comptes de service oubliés restent dangereux.

Défenses :

• mot de passe fort et unique, stocké en Trousseau ou en coffre (pas en dur) ;
• scope réduit : droits sur une application, une base de données, pas l'annuaire entier ;
• rotation : changer le mot de passe régulièrement ;
• audit : journaliser les actions du compte ;
• LAPS (Local Administrator Password Solution) : gérer les mots de passe locaux des comptes administrateur machines, avec rotation automatique ;
• Managed Service Identities (MSI) en cloud : Azure gérer l'authentification de l'application ; pas de mot de passe à gérer.

Comptes spécialisés Windows : gMSA (group Managed Service Account), standalone MSA ; détails non vérifiés ici.

9. Défense contre les attaques courantes

Pass-the-hash (PTH). Un attaquant capture le haché du mot de passe d'un compte (non le mot de passe lui-même) et s'en sert pour s'authentifier auprès du serveur qui accepte le hachage. Défense :

• Kerberos plutôt que NTLM : Kerberos n'utilise pas le haché directement sur le réseau ;
• Protected Users : groupe AD qui limite l'utilisation de hachés ;
• MFA : même avec le haché, un second facteur est exigé ;
• NTLMv2 au minimum (jamais NTLMv1) ; non vérifié : le détail du hachage.

Énumération de comptes et spray de mot de passe. Un attaquant essaie de nombreuses combinaisons user/password. Défense :

• limitation d'essais : après N tentatives échouées, verrouiller le compte temporairement ;
• MFA : ralentit l'automatisation ;
• mot de passe fort : moins de risques qu'on le trouve par force brute.

Accès privilégié non contrôlé. Les comptes administrateurs sont cibles de choix. Défense :

• comptes administrateurs séparés : ne pas utiliser le même compte pour l'administrateur et pour le travail quotidien ;
• bastion ou PAM (Privileged Access Workstation, Privileged Access Management) : machine isolée pour les tâches d'administration ;
• audit : tracer chaque utilisation.

10. Lecture LDAP : commandes

Cet exercice utilise un annuaire fictif ou la documentation de commande. Aucune exécution sur un annuaire réel.

Bind (authentification LDAP) :

ldapsearch -x -H ldap://ldap.example.test:389 -D "cn=admin,dc=corp,dc=example,dc=test" -w '<MOT-DE-PASSE-FACTICE>'

• Contexte : Terminal ; LDAP sur port 389, annuaire synthétique.
• Droits : utilisateur normal (une vraie machine demande le paquet ldap-utils non installé par défaut).
• Effet : aucune exécution. Décrit à titre éducatif la ligne de commande.
• Vérification : repérer ldapsearch (requête), -x (simple bind, pas SASL), -H ldap:// (schéma et serveur), -D (DN à authentifier), -w (mot de passe).
• Retour arrière : sans objet.

Recherche (si l'annuaire était accessible) :

ldapsearch -x -H ldap://ldap.example.test:389 -D "cn=admin,dc=corp,dc=example,dc=test" -w '<MOT-DE-PASSE-FACTICE>' -b "dc=corp,dc=example,dc=test" "(&(objectClass=inetOrgPerson)(uid=alice))"

• Contexte : Terminal ; annuaire fictif.
• Droits : utilisateur normal.
• Effet : aucune exécution. -b : base DN (racine de la recherche), filtre entre guillemets.
• Vérification : repérer le filtre (&(objectClass=inetOrgPerson)(uid=alice)) qui cherche une personne d'ID alice.
• Retour arrière : sans objet.

Exercices et vérifications de fin de cours

Tous sur papier ou en lecture sur documentation, jamais sur un annuaire réel.

1. Hiérarchie. Tracer l'arborescence DNS → Domaine → OU → Utilisateur pour corp.example.test, OU Equipes, utilisateur alice.
2. DN LDAP. Écrire le DN de alice dans l'OU Personnes du domaine corp.example.test.
3. Kerberos. Énumérer les trois acteurs (client, KDC, serveur) et dire pourquoi Kerberos n'envoie pas le mot de passe sur le réseau.
4. Annuaires. Comparer AD DS (sur site) et Entra ID (cloud) : trois avantages chacun.
5. SSO. Décrire le flux OIDC : client, SP, IdP, jeton id_token.
6. MFA. Citer deux facteurs et dire lequel résiste aux mots de passe compromis.
7. Moindre privilège. Concevoir un compte de service pour une application de rapports : droits sur une base seule, mot de passe robuste, audit.
8. PTH. Expliquer comment un haché de mot de passe est utile sans connaître le mot de passe, et citer une défense.
9. Conditional Access. Écrire une politique : « bloc la connexion depuis pays X, sauf si MFA ».
10. Requête LDAP. Écrire un filtre pour trouver tous les utilisateurs d'un groupe app-lecture.

Critères de réussite

• Distinguer domaine, OU, compte dans la hiérarchie AD.
• Lire et écrire un DN LDAP.
• Situer Kerberos, SAML, OIDC et leur rôle.
• Appliquer moindre privilège à un compte de service.
• Dire ce qui n'a pas été vérifié (voir plus bas).