Active Directory & Entra ID : Sécuriser l'Identité en 2026

1. Pourquoi l'identité est devenue le nouveau périmètre

Pendant deux décennies, la sécurité des systèmes d'information s'est organisée autour d'un modèle centré sur le réseau : un périmètre clairement délimité, des flux contrôlés aux points d'entrée, une hypothèse implicite que ce qui est à l'intérieur est de confiance. Ce modèle n'a plus de pertinence opérationnelle. La généralisation du télétravail, des applications SaaS, des infrastructures hybrides et des accès partenaires a dissous le périmètre traditionnel. Ce qui reste invariant, dans tous ces contextes, c'est l'identité.

L'identité numérique, c'est-à-dire le compte utilisateur, le compte de service ou l'identité applicative, est l'objet qui détermine ce à quoi on peut accéder, depuis où et dans quelles conditions. Compromettre une identité suffisamment privilégiée revient, pour un attaquant, à opérer dans l'environnement cible avec une légitimité apparente. C'est précisément ce qui rend les attaques par compromission d'identité si difficiles à détecter : les journaux montrent un utilisateur connu qui se connecte, qui accède à des ressources, qui exécute des tâches. Rien d'anormal en surface.

La convergence vers des architectures hybrides (Active Directory on-premise synchronisé avec Microsoft Entra ID, applications SaaS fédérées via SAML ou OIDC, postes gérés via Intune) a considérablement élargi la surface exposée. Un attaquant qui compromet un compte synchronisé peut, selon la configuration du tenant, pivoter de l'environnement on-premise vers le cloud, ou inversement. Cette bidirectionnalité est souvent sous-estimée dans les modèles de risque.

1.1 L'identité dans la chaîne d'attaque

Les grandes étapes d'une intrusion avancée se déroulent quasi systématiquement autour de l'identité. L'accès initial exploite souvent un compte faiblement protégé, via phishing ciblé, password spray ou exploitation d'un service exposé. La phase de reconnaissance interne (LDAP queries, BloodHound, enum) vise à cartographier les chemins d'escalade de privilèges. La persistance passe par la création de comptes fantômes, la modification de délégations ou l'injection de credentials dans des objets AD. L'objectif final est presque toujours l'obtention d'un accès Domain Admin ou Global Admin pour exfiltrer les données ou déployer un ransomware.

Cette chaîne est bien documentée par l'ANSSI dans ses guides de durcissement AD (disponibles sur cert.ssi.gouv.fr) et reprise dans le référentiel MITRE ATT&CK sous les tactiques Credential Access, Privilege Escalation et Lateral Movement. La comprendre dans le détail conditionne la pertinence des mesures de durcissement à mettre en œuvre.

2. Les vecteurs d'attaque les plus exploités sur Active Directory

Avant de définir un plan de durcissement, le RSSI doit avoir une vision précise des techniques réellement utilisées par les attaquants contre les annuaires Active Directory. Certaines sont connues depuis plus de dix ans et restent largement exploitables, faute de mesures correctives déployées à l'échelle.

2.1 Kerberoasting

Le Kerberoasting consiste à demander, depuis n'importe quel compte authentifié du domaine, des tickets de service Kerberos (TGS) pour des comptes dont le SPN (Service Principal Name) est renseigné. Ces tickets sont chiffrés avec le mot de passe du compte de service concerné et peuvent être extraits puis soumis à une attaque par force brute hors ligne. La technique ne génère aucune alerte par défaut et n'exige aucun privilège particulier pour être exécutée.

Dans la pratique, les comptes de service avec SPN sont souvent associés à des mots de passe anciens, rarement renouvelés, parfois triviaux. Les audits BEAROPS révèlent régulièrement des comptes de service avec des mots de passe inchangés depuis plus de cinq ans, certains avec des droits d'administration délégués.

2.2 AS-REP Roasting

L'AS-REP Roasting cible les comptes pour lesquels la pré-authentification Kerberos est désactivée (attribut DONT_REQ_PREAUTH). Dans ce cas, n'importe qui peut demander un AS-REP pour ce compte sans s'authentifier, obtenir une réponse partiellement chiffrée avec le hash du mot de passe et tenter une attaque hors ligne. Cette configuration est parfois positionnée intentionnellement pour des raisons de compatibilité applicative et oubliée.

2.3 Pass-the-Hash et Pass-the-Ticket

Les techniques de Pass-the-Hash (réutilisation d'un hash NTLM sans connaître le mot de passe en clair) et de Pass-the-Ticket (réutilisation d'un ticket Kerberos volé) permettent un mouvement latéral rapide dès qu'un attaquant dispose d'un accès avec des droits d'administration locale sur un poste. La présence de comptes d'administration partagés (même mot de passe sur tous les postes, comptes génériques de type admin_local) multiplie mécaniquement la portée de ces techniques.

2.4 DCSync et Golden/Silver Ticket

Une fois des droits de réplication obtenus sur le domaine (droits DS-Replication-Get-Changes-All), un attaquant peut exécuter une attaque DCSync : simuler le comportement d'un contrôleur de domaine secondaire pour extraire l'ensemble des hashes NTLM du domaine, y compris celui du compte krbtgt. La possession du hash krbtgt permet de forger des tickets Kerberos arbitraires (Golden Ticket), valides pour n'importe quel compte du domaine, avec n'importe quel niveau de privilège, pour une durée pouvant atteindre dix ans.

2.5 Abus des ACL et délégations

Les listes de contrôle d'accès (ACL) sur les objets Active Directory constituent un vecteur d'escalade de privilèges souvent invisible dans les audits classiques. Un compte qui dispose d'un droit GenericAll, WriteDACL ou ForceChangePassword sur un compte à privilèges peut l'exploiter pour élever ses propres droits sans aucune action visible dans les journaux d'événements standard. L'outil BloodHound visualise ces chemins d'attaque et montre régulièrement des chemins courts (2 à 3 arêtes) entre un compte utilisateur ordinaire et Domain Admin.

2.6 Abus du protocole NTLM

NTLM, bien que deprecated par Microsoft, reste activé par défaut dans la quasi-totalité des environnements AD pour assurer la rétrocompatibilité. Les attaques NTLM Relay permettent à un attaquant positionné en homme du milieu d'intercepter et de rejouer des authentifications NTLM vers des cibles non protégées (SMB, LDAP sans signature obligatoire). Cette technique est l'une des plus fréquentes dans les premières phases d'intrusion.

3. Surface d'attaque hybride : AD et Entra ID

La grande majorité des organisations qui utilisent Active Directory ont aujourd'hui connecté leur annuaire à Microsoft Entra ID via Microsoft Entra Connect (anciennement Azure AD Connect). Cette synchronisation offre des bénéfices opérationnels réels (SSO, accès conditionnel, MFA cloud) mais crée simultanément une surface d'attaque bidirectionnelle que beaucoup de RSSI n'ont pas encore pleinement cartographiée.

3.1 Le serveur Entra Connect comme cible privilégiée

Le serveur qui exécute Microsoft Entra Connect dispose de droits très étendus sur les deux environnements. Le compte de synchronisation AD dispose au minimum de droits de lecture sur l'ensemble de l'annuaire, et souvent de droits d'écriture sur certains attributs. Le compte utilisé côté Entra ID dispose, dans les configurations par défaut, du rôle Directory Synchronization Accounts qui permet de modifier les mots de passe des utilisateurs synchronisés. Un attaquant qui compromet le serveur Entra Connect peut donc potentiellement extraire les credentials des deux environnements et modifier les comptes cloud.

3.2 Comptes synchronisés et politiques de mots de passe

Les comptes synchronisés héritent de la politique de mots de passe on-premise, qui est souvent moins stricte que les exigences d'un tenant Entra ID moderne. Si un compte synchronisé dispose de rôles administrateurs dans Entra ID (Global Admin, Privileged Role Administrator), une compromission on-premise suffit à obtenir un accès cloud complet. Cette situation est plus fréquente qu'on ne le croit : selon les audits BEAROPS, environ 30 % des organisations qui synchronisent leur AD ont au moins un compte avec un rôle admin cloud synchronisé depuis l'on-premise.

3.3 Applications d'entreprise et consentements OAuth

Chaque application enregistrée dans un tenant Entra ID dispose de permissions sur le Microsoft Graph et potentiellement sur d'autres services. Une application avec des permissions Mail.ReadWrite, Directory.ReadWrite.All ou RoleManagement.ReadWrite.Directory est une porte d'entrée de fait sur l'environnement cloud. Les attaques de type Illicit Consent Grant exploitent la propension des utilisateurs à consentir à des applications tierces : une application malveillante qui obtient le consentement d'un administrateur dispose d'un accès permanent, sans MFA, au tenant.

3.4 Protocoles d'authentification hérités

Les protocoles dits « hérités » (Basic Auth, POP3, IMAP, SMTP Auth, ActiveSync sans MFA) contournent par définition les politiques d'accès conditionnel et la MFA. Leur présence dans un tenant Entra ID constitue un vecteur de password spray particulièrement efficace : l'attaquant essaie un volume de comptes avec quelques mots de passe courants, sans déclencher de verrouillage de compte AD classique. Microsoft indique que plus de 99 % des attaques par compromission de compte exploitent l'absence de MFA, souvent via ces protocoles hérités.

4. Durcissement de l'Active Directory : priorités opérationnelles

Le durcissement d'un Active Directory en production est un projet de longue haleine. Les organisations qui tentent de tout traiter simultanément échouent ou créent des ruptures de service. L'approche pragmatique consiste à prioriser selon l'impact sur la réduction du risque et la faisabilité opérationnelle.

4.1 Mettre en place le Tiering Model

Le Tiering Model (ou modèle à trois niveaux) est la mesure structurelle la plus importante pour limiter le mouvement latéral dans un Active Directory. Son principe est simple : séparer les comptes et les ressources en niveaux d'isolation étanches, de façon à ce qu'une compromission à un niveau ne permette pas d'accéder aux niveaux supérieurs.

Le déploiement du Tiering Model commence invariablement par l'identification des comptes qui violent déjà les frontières, notamment les comptes Domain Admin utilisés pour des tâches quotidiennes ou pour administrer des postes utilisateurs. Cette phase d'inventaire est souvent la plus révélatrice.

4.2 Déployer LAPS sur tous les postes

LAPS (Local Administrator Password Solution), dans sa version Microsoft LAPS intégrée à Windows depuis 2023, gère automatiquement les mots de passe des comptes administrateurs locaux et les stocke dans l'attribut AD correspondant. Chaque poste dispose ainsi d'un mot de passe unique, renouvelé périodiquement. Cette mesure seule élimine la majorité des attaques Pass-the-Hash sur les postes de travail, car la réutilisation du même mot de passe admin local sur l'ensemble du parc n'est plus possible.

4.3 Éliminer les protocoles d'authentification hérités

NTLM doit être désactivé progressivement. La démarche recommandée par l'ANSSI consiste à activer l'audit NTLM pour identifier les flux résiduels, traiter les dépendances applicatives une par une, puis bloquer NTLM en commençant par les contrôleurs de domaine. L'objectif à terme est Kerberos exclusif, avec NTLMv2 maintenu uniquement pour les cas de compatibilité documentés et justifiés.

De même, la pré-authentification Kerberos doit être obligatoire pour tous les comptes. Un audit régulier des comptes avec l'attribut DONT_REQ_PREAUTH doit être intégré dans les processus de revue de l'annuaire.

4.4 Sécuriser les comptes de service avec gMSA

Les Group Managed Service Accounts (gMSA) sont la réponse de Microsoft au problème des comptes de service avec des mots de passe statiques. Le mot de passe d'un gMSA est généré et renouvelé automatiquement par l'Active Directory (par défaut toutes les 30 jours), sans aucune intervention manuelle. Les services compatibles gMSA n'ont plus de SPN exploitable par Kerberoasting, puisque le mot de passe n'est jamais connu et ne peut pas être craqué hors ligne.

4.5 Sécuriser la signature SMB et LDAP

La signature SMB et la signature LDAP sont les mesures les plus efficaces contre les attaques NTLM Relay. Leur activation force les clients à signer cryptographiquement les échanges, rendant les attaques de relais inutilisables. Sur les contrôleurs de domaine, la signature LDAP doit être requise (pas seulement négociée). Sur les serveurs, la signature SMB doit être obligatoire. Ces paramètres sont déployables via les stratégies de groupe (GPO) et ne génèrent pas de rupture de service dans les environnements correctement à jour.

5. Sécuriser Microsoft Entra ID en environnement hybride

La sécurisation d'Entra ID suit une logique différente de celle de l'Active Directory on-premise. L'annuaire cloud est géré par Microsoft et dispose de contrôles natifs (accès conditionnel, Protection des identités Entra, Privileged Identity Management) qui sont d'une efficacité réelle à condition d'être correctement configurés. Trop d'organisations activent ces fonctionnalités sans définir de politiques cohérentes.

5.1 Accès conditionnel : sortir des configurations par défaut

L'accès conditionnel Entra ID permet de définir des politiques qui évaluent, au moment de chaque authentification, un ensemble de signaux (utilisateur, localisation, état du terminal, application cible, niveau de risque) et décident de l'autoriser, de la bloquer ou d'exiger une vérification supplémentaire. Les politiques Microsoft par défaut couvrent les cas de base (MFA pour les administrateurs, blocage des pays à risque) mais sont insuffisantes pour une protection efficace.

Une configuration mature inclut des politiques qui exigent des terminaux conformes (Intune Compliance) pour accéder aux applications sensibles, qui bloquent explicitement les protocoles d'authentification hérités, et qui renforcent les exigences d'authentification en fonction du niveau de risque calculé par Entra ID Protection.

5.2 Privileged Identity Management (PIM)

Le Privileged Identity Management est la brique fondamentale pour la gestion des comptes à privilèges dans Entra ID. Il permet de passer d'une attribution permanente des rôles administrateurs à une attribution à la demande, avec une durée limitée, une justification obligatoire et une approbation optionnelle. En pratique, aucun compte ne devrait détenir en permanence un rôle Global Admin, Privileged Role Administrator ou Security Administrator. Ces rôles sont activés ponctuellement, pour la durée strictement nécessaire.

5.3 Comptes break-glass et stratégie d'accès d'urgence

Un point souvent négligé : la définition d'au moins deux comptes d'accès d'urgence (break-glass accounts), exclus des politiques d'accès conditionnel, associés à des mots de passe très forts stockés hors ligne et réservés aux situations où les mécanismes d'authentification normaux sont inopérants. Ces comptes doivent être monitorés en permanence : toute connexion sur l'un d'eux doit déclencher une alerte immédiate.

5.4 Audit des applications et des consentements

Toutes les applications enregistrées dans le tenant doivent faire l'objet d'une revue régulière. Les points à vérifier : permissions accordées versus permissions réellement utilisées, applications orphelines (plus d'owner actif), applications avec des permissions d'écriture non justifiées, et consentements utilisateurs sur des applications tierces non approuvées. La stratégie de consentement doit être définie explicitement : consentement utilisateur désactivé ou limité aux applications vérifiées, approbation admin requise pour toute nouvelle application tierce.

6. Supervision et détection : ce que les journaux ne disent pas

Une des caractéristiques des attaques sur Active Directory est leur faible signature initiale. Un attaquant qui exécute BloodHound génère un volume de requêtes LDAP légèrement supérieur à la normale. Un Kerberoasting cible un ou plusieurs comptes de service via des demandes TGS tout à fait légitimes en apparence. La détection par signature simple est insuffisante pour ces vecteurs.

6.1 Les événements à monitorer en priorité

Certains événements Windows sont des indicateurs fiables d'activité malveillante sur l'annuaire, à condition d'être collectés et corrélés. Les plus importants sur les contrôleurs de domaine incluent : Event ID 4768/4769 (demandes de ticket Kerberos TGT et TGS, à analyser pour détecter les schémas de Kerberoasting), Event ID 4771 (échec de pré-authentification Kerberos, indicateur d'AS-REP Roasting ou de password spray), Event ID 4624/4625 (authentifications réussies et échouées, à corréler par compte et par source), Event ID 4728/4732/4756 (ajout de membres dans des groupes sensibles) et Event ID 4670 (modification de permissions sur des objets AD).

6.2 Détection comportementale et UEBA

Les solutions de détection comportementale (UEBA, User and Entity Behavior Analytics) apportent une couche de détection complémentaire en établissant un profil comportemental de référence pour chaque compte et en alertant sur les déviations significatives : première connexion depuis une nouvelle géolocalisation, escalade de privilèges inhabituelle, accès massif à des ressources jamais consultées, demandes TGS sur un volume de comptes de service anormalement élevé. Microsoft Entra ID Protection fournit une analyse de risque native pour les comptes cloud. Pour l'environnement on-premise, des solutions dédiées à la surveillance des annuaires (Tenable Identity Exposure, Quest Change Auditor, ou BEAREYE pour les environnements hybrides) offrent cette couverture.

6.3 Le problème de la visibilité sur les délégations

Les délégations Kerberos non contraintes (Unconstrained Delegation) constituent un risque majeur : tout service configuré avec cette délégation reçoit et met en cache le ticket TGT de chaque utilisateur qui s'y connecte. Un attaquant qui compromet ce serveur dispose des tickets de tous les utilisateurs qui s'y sont authentifiés, y compris potentiellement des Domain Admins. L'énumération des objets avec délégation non contrainte est une des premières étapes d'une mission de test d'intrusion interne. Elle devrait l'être également dans les processus de revue régulière de l'annuaire.

7. Exigences réglementaires NIS2, DORA et conformité

La directive NIS2, transposée en droit français, impose aux entités essentielles et importantes des mesures techniques et organisationnelles proportionnées aux risques. Sur le périmètre de l'identité, plusieurs articles ont une implication directe sur la gestion de l'Active Directory et des accès à privilèges.

7.1 NIS2 et gestion des accès à privilèges

L'article 21 de la directive NIS2 mentionne explicitement les politiques de contrôle d'accès et la gestion des actifs. Sur le plan de l'identité, les obligations concrètes pour les RSSI incluent la tenue d'un inventaire des comptes à privilèges, la mise en œuvre d'une politique de gestion des droits d'accès, la journalisation des accès à privilèges avec conservation suffisante, et la capacité à détecter et à répondre à une compromission d'identité dans des délais compatibles avec les obligations de notification (72 heures pour les incidents significatifs).

7.2 DORA et les infrastructures de gestion des identités

Le règlement DORA, applicable depuis janvier 2025 aux entités financières, inclut les infrastructures de gestion des identités dans son périmètre de résilience opérationnelle numérique. Les exigences portent sur la gestion des accès (principe du moindre privilège, revue périodique, traçabilité), les tests de résilience des composants critiques (dont les annuaires d'entreprise) et la gestion du risque lié aux tiers, qui inclut les fournisseurs d'identité cloud.

7.3 Souveraineté numérique et identité cloud

La question de la souveraineté numérique se pose avec une acuité particulière pour les organisations qui externalisent leur référentiel d'identité vers des fournisseurs cloud non européens. Les données d'authentification, les journaux de connexion et les configurations d'accès conditionnel stockés dans un tenant Microsoft sont soumis au droit américain via le CLOUD Act. Pour les organisations qui traitent des données sensibles (défense, santé, services essentiels), cela implique une réflexion sur la localisation des données d'identité et sur les alternatives souveraines.

BEAREYE, hébergé en France et opéré par des équipes BEAROPS, intègre la supervision des environnements AD/Entra ID sans transfert de données sensibles hors du territoire national. Cette architecture répond aux exigences de souveraineté des organisations soumises à des contraintes réglementaires sectorielles.