Active Directory : IAM + ITDR, le duo gagnant pour sécuriser vos identités

Publié par RM3A • 10 octobre 2025

Active Directory en 2025 : combinez IAM (gouvernance, JML, MFA, PAM/JIT) et ITDR (détection Kerberoasting, Pass-the-Hash, DCSync) pour stopper les attaques d’identités.

Plan de l’article

1. Pourquoi l’identité est votre nouveau périmètre
2. IAM : gouverner l’accès, réduire la surface d’attaque
3. ITDR : voir les attaques d’identités arriver
4. Le duo IAM + ITDR en pratique : architecture cible
5. 10 détections ITDR haute valeur
6. 90 minutes pour réagir à une alerte
7. Plan d’action “30 jours”
8. Checklists pratiques
9. Cas d’usage : PME vs foyer avancé
10. Erreurs courantes à éliminer
11. FAQ

Pourquoi l’identité est votre nouveau périmètre (B2B & B2C)

Les attaquants ciblent d’abord l’identité : comptes à privilèges, comptes de service mal gérés, postes d’admin non cloisonnés. Dans les PME comme dans les groupes, Active Directory (AD) reste la colonne vertébrale de l’accès. Deux leviers complémentaires vous protègent réellement :

• IAM (Identity & Access Management) : gérer qui a accès à quoi, quand, et selon quelles règles (cycle JML : Joiner-Mover-Leaver, MFA, moindre privilège, PAM/JIT).
• ITDR (Identity Threat Detection & Response) : détecter et répondre aux menaces identitaires (Kerberoasting, AS-REP Roasting, Pass-the-Hash/Ticket, DCSync, DCShadow, Golden/Silver Ticket, abus des ACL).

Ensemble, IAM réduit l’attaque et ITDR capte le bruit résiduel pour vous alerter avant l’escalade de privilèges.

Mots-clés longue traîne : ITDR Active Directory, bloquer Kerberoasting AD, détecter DCSync, JIT PAM AD, zéro trust identité.

IAM : gouverner l’accès, réduire la surface d’attaque

1) Cycle de vie JML (Joiner–Mover–Leaver)

• Joiner : création nominative + appartenance à des groupes métiers (pas d’accès global).
• Mover : révision automatique des droits à chaque mobilité (droits retirés puis réattribués).
• Leaver : désactivation le jour J, rotation des secrets (clés API, gMSA si impacté), révocation des sessions.

2) Moindre privilège & segmentation

• Pas d’admin permanent : basculez vers PAM/JIT (droits élevés à la demande, expirants).
• Séparez comptes d’admin et comptes bureautiques (pas d’e-mail/web sur comptes admin).
• Tiering (Tier 0/1/2) : DC & identités critiques isolés (bastion, PAW).

3) MFA partout, surtout pour l’admin

• MFA obligatoire pour : VPN, consoles cloud, bastion, outils d’ITSM, accès RDP/PowerShell Remoting.
• Privilégiez FIDO2/clé matérielle pour l’admin et les accès sensibles.

4) Comptes de service & gMSA

• Remplacez les comptes de service “classiques” par des gMSA : rotation automatique, secrets protégés.
• Limitez leurs droits aux services concernés ; évitez l’admin de domaine “par confort”.

5) Hygiène AD

• Désactivez NTLMv1, forcez Kerberos AES, signez LDAP (LDAP signing), durcissez SMB.
• Nettoyez les ACL trop larges (WriteDACL, Replicating Directory Changes*) et révisez AdminSDHolder.
• Déployez LAPS pour les mots de passe locaux des postes/serveurs (version moderne : Windows LAPS).

ITDR : voir les attaques d’identités arriver (et y répondre)

L’ITDR complète votre IAM en mettant sous surveillance les comportements d’annuaires et de sessions. Trois axes :

1. Télémétrie identité : événements DC (logon/logoff, TGT/TGS), modifications d’ACL, réplication AD, création d’objets sensibles.
2. Détections spécialisées : Kerberoasting, AS-REP sans préauth, DCSync/DCShadow, KRBTGT modifié, anomalies TGT.
3. Réponse guidée : playbooks de containment (désactivation de compte, rotation secrets, reset KRBTGT, bascule RO/maintenance).

Mots-clés longue traîne : ITDR pour Active Directory PME, détection Pass-the-Hash, alertes DCSync SIEM, quels logs surveiller DC.

Le duo IAM + ITDR en pratique : architecture cible

Vue d’ensemble

• Bastion/PAM pour JIT : les admins demandent un rôle (ex. “DA 2h”).
• PAW dédiés pour l’admin (pas d’Internet, GPO durcies).
• SIEM/ITDR branché sur : contrôleurs de domaine (Security, Directory-Services, DNS), Bastion/PAM, Tier 0 (ADCS, ADFS, Azure AD Connect).
• MFA + politiques conditionnelles (réseau, appareil conforme).
• Honeytokens/honeyaccounts pour détecter vol de hash/Kerberos.

Flux quotidien

1. Un technicien demande une élévation JIT via le PAM.
2. Le bastion ouvre une fenêtre d’élévation MFA (2h), loguée.
3. L’ITDR corrèle : élévation + accès DC → normal ? Si anormal (heure, IP, pays), alerte.
4. En cas d’activité suspecte (TGS massifs/AS-REP), blocage, désactivation du compte, enquête.

10 détections ITDR “haute valeur” pour AD

1. Comptes sensibles sans préauth Kerberos (AS-REP possible).
2. Demandes massives de TGS (Kerberoasting probable).
3. DCSync détecté hors fenêtre de maintenance.
4. DCShadow : modifications répliquées par un hôte non DC.
5. Changement de KRBTGT non planifié.
6. Ajout à Domain Admins / modif AdminSDHolder.
7. Création d’un compte avec droits répli AD.
8. Connexion admin depuis poste non-PAW / hors zone Tier 0.
9. Accès LDAP non signé depuis hôtes externes.
10. Tentatives NTLMv1 / fallback NTLM anormal.

90 minutes pour réagir à une alerte identité (modèle)

T0–15 min : Containment

• Désactivez le compte suspect, isolez le poste source.
• Si privilèges élevés : planifier reset KRBTGT (double reset si compromis avéré).

T15–45 min : Enquête rapide

• Journaux DC (4624/4625, 4768–4771, 5136/5137), TGS massifs, groupes à privilèges.
• Vérifiez AdminSDHolder, ajouts Domain Admins, nouveaux SPN.

T45–90 min : Rémédiation

• Rotation mots de passe comptes à privilèges / gMSA impactés.
• Passage en PAW only pour l’admin, MFA renforcée.
• Planifiez reset KRBTGT si incident confirmé, communication & leçons apprises.

Plan d’action “30 jours” (priorités réalisables)

Semaine 1 — Fondations IAM

• Désactiver comptes obsolètes/inactifs, inventaire groupes privilégiés.
• Activer MFA pour tous les admins, séparer comptes admin/bureautiques.
• Déployer LAPS (Windows LAPS) pour mots de passe locaux.

Semaine 2 — Durcissement AD

• Forcer Kerberos AES, désactiver NTLMv1, activer LDAP signing.
• Mettre en place gMSA pour 1–2 services critiques.
• Démarrer le tiering (segmentation), PAW pilote pour l’équipe IT.

Semaine 3 — ITDR & détection

• Brancher les DC au SIEM/ITDR, créer 10 use cases (liste ci-dessus).
• Déployer un honeytoken (compte leurre DA), alerte si authentification.
• Journaliser les requêtes DCSync & modifications AdminSDHolder.

Semaine 4 — JIT/PAM & exercices

• Activer un bastion/JIT pour un rôle privilégié (ex. Server Admin 2h).
• Jeu de rôle : scénario Kerberoasting → détection → containment.
• Formaliser le runbook 90 min et la checklist mensuelle.

Checklists pratiques

Check express (5 minutes)

• Comptes admin distincts + MFA
• LAPS déployé
• NTLMv1 OFF, Kerberos AES
• LDAP signing activé
• DC branchés au SIEM/ITDR

Revue mensuelle (15 minutes)

• Droits Domain Admins revus (zéro “cadeau”)
• gMSA étendu aux services clés
• Alertes ITDR testées (DCSync/DCShadow/honeytoken)
• PAW et bastion utilisés pour l’admin
• Rapport JML : entrées, mobilités, sorties

Cas d’usage : PME vs foyer “power user”

PME (B2B)

• MFA + PAW pour l’admin, bastion/JIT.
• gMSA pour services, LAPS sur tout le parc.
• SIEM/ITDR avec détections Kerberoasting/DCSync.
• Tiering (DC isolés), zéro trust (appareil conforme).

Particulier avancé (B2C)

• Séparer compte admin local et compte usage.
• MFA pour services cloud, gestionnaire de mots de passe.
• Activer l’audit (journaux), surveiller connexions et services démarrés.
• Si homelab AD : LDAP signing, Kerberos AES, comptes de service minimaux.

Erreurs courantes à éliminer

• Compte Administrateur de domaine utilisé pour tout, tout le temps.
• Comptes de service statiques avec droits étendus, jamais renouvelés.
• Pas de MFA sur VPN/bastion/console cloud.
• ACL trop larges (WriteOwner/WriteDACL) laissées “provisoirement”.
• Journaux non collectés / alertes non surveillées.

FAQ

1) Quelle différence entre IAM et ITDR ?

IAM gouverne les accès (JML, moindre privilège, MFA, PAM/JIT). ITDR détecte et répond aux attaques d’identités (Kerberoasting, DCSync, Pass-the-Hash). L’un réduit la surface, l’autre surveille et stoppe l’escalade.

2) Le MFA suffit-il à bloquer les attaques sur AD ?

Non. Le MFA réduit le risque de vol d’identifiants mais ne couvre pas les abus d’ACL, Kerberoasting ou Pass-the-Hash. Il faut combiner IAM, ITDR et durcissement AD.

3) LAPS et gMSA sont-ils vraiment prioritaires ?

Oui. LAPS supprime les mots de passe locaux partagés. gMSA automatise et sécurise les comptes de service. Deux leviers à haut rendement.

4) Comment détecter un DCSync ?

Surveillez les événements de réplication AD et les droits Replicating Directory Changes All. Une requête depuis un hôte non DC ou hors fenêtre planifiée est une alerte critique.

5) On commence par quoi si on a peu de temps ?

MFA admin, LAPS, LDAP signing, Kerberos AES, collecte logs DC et 3 use cases ITDR (Kerberoasting, DCSync, AdminSDHolder), puis bastion/JIT.

Besoin d’un plan concret ? (Pack RM3A “IAM + ITDR”)

Sans tout refondre, obtenez un plan d’exécution pour sécuriser vos identités AD :

• Audit express AD (ACL, comptes à privilèges, gMSA/LAPS, NTLM/Kerberos, LDAP signing)
• Déploiement PAM/JIT et PAW avec procédures d’élévation
• Mise en place des détections ITDR clés (Kerberoasting, DCSync, DCShadow, honeytokens)
• Runbook 90 min + exercice de réponse (table-top)

Demander le diagnostic gratuit

Ou découvrez nos services : Sécurité des identités AD • ITDR & détection • PAM/JIT

Article rédigé par RM3A — rm3a.fr. Pour un accompagnement personnalisé, contactez-nous.