La requête derive acces privilegies active directory désigne ici un problème précis : la dérive des accès privilégiés Active Directory, c’est-à-dire l’écart entre le modèle de privilèges que l’organisation pense avoir et les droits effectifs qui existent réellement dans l’annuaire aujourd’hui. Cette dérive peut commencer par une appartenance temporaire à un groupe, une délégation helpdesk accordée pour débloquer une opération, un compte de service ajouté pendant un incident, ou une ACL que personne ne revisite après la fin d’un projet. Avec le temps, ces petits écarts peuvent recréer des chemins d’attaque qu’un audit précédent avait déjà supprimés.
Cet article se limite à Active Directory on-premises. Il ne présente pas Microsoft Entra Privileged Identity Management comme un contrôle de remplacement et ne réduit pas la dérive aux seuls comptes administrateurs obsolètes. Dans AD, les privilèges peuvent réapparaître via les groupes imbriqués, les ACL d’annuaire, les droits de réplication, les changements sur AdminSDHolder, la réutilisation du compte administrateur natif, les comptes de service et les exceptions d’urgence. La détection exige une corrélation entre le référentiel attendu, les droits effectifs, les changements récents et la télémétrie de sécurité.
Derive acces privilegies active directory : qu’est-ce que cela couvre ?
La dérive des accès privilégiés correspond à l’accumulation de droits administratifs effectifs qui ne correspondent plus au modèle prévu pour le domaine. Une revue d’accès propre peut conclure que seuls des groupes d’administration nommés contrôlent les actifs Tier 0. Quelques semaines plus tard, un opérateur peut ajouter temporairement un membre à Domain Admins, imbriquer un groupe support dans un groupe privilégié, déléguer WriteDACL sur une OU, ou accorder des droits de réplication à un compte de migration. Si le changement n’est pas retiré et remesuré, le résultat de la revue devient obsolète.
Le point important est que le privilège Active Directory n’est pas stocké dans un seul endroit. L’appartenance aux groupes est la couche visible, mais ce n’est qu’une partie du plan de contrôle. Un principal peut devenir dangereux parce qu’il est membre direct d’un groupe privilégié, parce qu’il y arrive par imbrication, parce qu’il peut modifier l’appartenance du groupe, parce qu’il peut réécrire le descripteur de sécurité d’un objet, parce qu’il possède des droits de réplication compatibles avec DCSync, ou parce qu’il peut influencer des comptes protégés par AdminSDHolder. C’est pourquoi un article sur les comptes privilégiés obsolètes est utile, mais insuffisant pour couvrir toute la dérive des accès privilégiés.
Une revue de dérive doit donc poser une question précise : qui peut agir sur les identités privilégiées, les groupes privilégiés, les contrôleurs de domaine, les permissions à la racine du domaine, les GPO, les services de certificats et les autres surfaces de contrôle Tier 0 aujourd’hui ? La réponse doit inclure les administrateurs directs, les administrateurs indirects, les opérateurs délégués, les comptes de service et les principals qui disposent de chemins ACL dangereux.
Pourquoi les revues d’accès annuelles ratent la dérive AD
Les revues annuelles ou trimestrielles sont des instantanés. Elles restent utiles pour la gouvernance, mais elles détectent mal un annuaire qui change chaque semaine. Les changements d’appartenance aux groupes Active Directory sont auditables, et Microsoft documente les événements de gestion des groupes de sécurité, notamment les ajouts et suppressions de membres dans les groupes globaux, locaux et universels. Les changements d’objets d’annuaire peuvent aussi être audités via les événements de changement du service d’annuaire, et l’accès aux objets peut exposer des opérations sensibles lorsque l’audit et les SACL sont configurés. Ces logs montrent qu’AD n’est pas statique.
Le problème pratique est que beaucoup de revues fonctionnent encore avec des exports. Une feuille de calcul des Domain Admins du mois dernier ne montre pas qu’un groupe imbriqué a été ajouté hier. Une liste d’utilisateurs privilégiés ne montre pas qu’un groupe helpdesk peut modifier l’appartenance d’un groupe admin. Une revue manuelle des comptes désactivés ne montre pas qu’un compte de service conserve encore DS-Replication-Get-Changes et DS-Replication-Get-Changes-All sur le contexte de nommage du domaine.
C’est aussi pour cela que les audits Active Directory récurrents comptent. Si les mêmes contrôles sont lancés une fois par an, l’organisation sait ce qui était faux à la date de l’audit. Si les contrôles sont relancés après les changements et les remédiations, elle peut voir si le modèle privilégié reste propre ou s’il dérive à nouveau.
Comment la dérive des accès privilégiés apparaît
Les appartenances temporaires deviennent permanentes
La réponse à incident, les migrations, la configuration des sauvegardes et le support applicatif urgent exigent parfois des droits élevés. Le risque n’est pas l’exception elle-même ; le risque est une exception sans propriétaire, sans date d’expiration et sans revalidation. Active Directory continuera d’honorer l’appartenance jusqu’à ce que quelqu’un la retire.
L’imbrication de groupes masque le privilège effectif
Un groupe peut paraître inoffensif isolément et devenir privilégié lorsqu’il est imbriqué dans Account Operators, Backup Operators, Domain Admins, Enterprise Admins ou un autre groupe sensible. L’accès imbriqué rend aussi les revues plus difficiles, car les membres effectifs ne sont pas visibles depuis le premier écran du groupe. Un groupe privilégié doit être revu par appartenance effective, pas seulement par membres directs.
La dérive ACL crée des chemins de contrôle
L’autorisation Active Directory dépend fortement des discretionary access control lists. GenericAll, WriteDACL, WriteOwner, AddMember, Self-Membership et des droits similaires peuvent transformer un principal non administrateur en administrateur pratique sur certains objets. Dans une revue de chemins d’attaque, la question n’est pas seulement de savoir qui est dans Domain Admins. Il faut savoir qui peut modifier un principal, un groupe, une GPO, un ordinateur, une OU ou une ACL qui mène au Tier 0. La même logique s’applique lors de la revue des abus d’ACL et chemins DCSync.
Les droits de réplication élargissent l’exposition des secrets
MITRE documente DCSync dans OS Credential Dumping, car un adversaire disposant de droits de réplication suffisants peut imiter le comportement de réplication d’un contrôleur de domaine pour obtenir du matériel d’identification. Les défenseurs doivent revoir les principals qui possèdent DS-Replication-Get-Changes et DS-Replication-Get-Changes-All, ainsi que les droits de réplication propres à l’environnement qui s’appliquent aux secrets protégés.
Les changements AdminSDHolder sont sensibles à la persistance
Les Microsoft Open Specifications décrivent AdminSDHolder comme l’objet utilisé par le système pour gérer les descripteurs de sécurité des objets administratifs protégés. Si le descripteur de sécurité AdminSDHolder est modifié, l’impact peut se propager aux comptes et groupes protégés via le mécanisme SDProp. AdminSDHolder doit donc être traité comme un objet sensible à la persistance, pas comme un conteneur administratif ordinaire.
Les comptes de service et le compte natif ajoutent un risque durable
Un compte de service dans un groupe privilégié peut être plus difficile à faire tourner, plus difficile à rattacher à un propriétaire humain et plus facile à oublier. Le compte Administrator natif avec RID 500 ne doit pas devenir l’identité utilisée pour l’administration quotidienne. S’il a été utilisé récemment, traitez-le comme une exception à expliquer, pas comme une preuve de compromission à lui seul.
Chemins d’attaque créés par la dérive des privilèges
La dérive des privilèges est importante parce qu’elle crée des chemins, pas seulement des listes d’accès désordonnées. Un compte admin supplémentaire est une cible d’identifiants. Un groupe support imbriqué peut devenir une route cachée vers Domain Admins. Une permission WriteDACL peut permettre à un principal de s’accorder des droits plus forts. Une permission WriteOwner peut permettre à un principal de prendre possession puis de changer l’ACL. Des droits AddMember sur un groupe privilégié peuvent suffire pour ajouter un compte contrôlé à ce groupe.
La dérive compatible DCSync est particulièrement sensible. Si un principal qui n’est pas un contrôleur de domaine dispose de droits de réplication permettant un comportement DCSync, les resets de mots de passe individuels ne suffisent pas. L’organisation doit retirer les droits de réplication, investiguer si du matériel d’identification a été exposé, puis faire tourner les secrets concernés selon le périmètre de réponse à incident.
La délégation et l’infrastructure d’identité peuvent élargir l’effet. Un compte ordinateur privilégié, un compte de service sur-délégué ou un chemin de délégation Kerberos mal géré peut relier la dérive des privilèges au mouvement latéral. C’est pourquoi l’analyse de dérive doit être corrélée avec les risques de délégation Kerberos, la gestion des mots de passe administrateur locaux comme Windows LAPS, et les chemins d’attaque AD CS lorsque les services de certificats sont dans le périmètre.
| Surface de dérive | Question pratique | Preuve de validation |
|---|---|---|
| Groupes privilégiés | Qui est membre direct ou imbriqué effectif ? | Propriétaire approuvé, ticket, expiration et appartenance effective actuelle |
| ACL d’annuaire | Qui peut modifier les objets privilégiés ou leurs descripteurs de sécurité ? | Diff ACL, revue du trustee, source d’héritage et propriétaire métier |
| Droits de réplication | Qui peut effectuer des opérations de réplication du domaine ? | Contrôleurs de domaine attendus et principals de réplication approuvés uniquement |
| AdminSDHolder | Qui peut influencer les objets administratifs protégés ? | Descripteur de sécurité attendu et absence d’ACE non autorisée |
Détection
Aucun événement Windows unique ne prouve une dérive des accès privilégiés. La détection doit combiner un référentiel des privilèges attendus, l’état actuel de l’annuaire, l’analyse des ACL et la télémétrie des changements récents.
Inventorier d’abord le privilège effectif
Commencez par un inventaire des accès privilégiés effectifs. Énumérez les appartenances directes et imbriquées des groupes privilégiés. Incluez les groupes privilégiés natifs, les groupes d’administration du domaine, les groupes qui administrent les contrôleurs de domaine, les groupes d’opérations sauvegarde ou serveur capables d’affecter des actifs Tier 0, et les groupes admin propres à l’organisation. Comparez le résultat à un référentiel approuvé avec propriétaires nommés.
Revoir les permissions hors appartenance aux groupes
Inspectez ensuite les permissions, pas seulement les appartenances. Revoyez les ACL à la racine du domaine, sur AdminSDHolder, les contrôleurs de domaine, les groupes privilégiés, les utilisateurs privilégiés, les OU sensibles, les GPO et les comptes de service à fort impact. Surveillez les droits qui permettent à un principal de modifier des appartenances ou des descripteurs de sécurité, notamment GenericAll, WriteDACL, WriteOwner, AddMember, Self-Membership, Write Property et Control Access. Pour la réplication, revoyez DS-Replication-Get-Changes et DS-Replication-Get-Changes-All sur le contexte de nommage du domaine.
Corréler les événements sans surinterpréter
Microsoft documente la catégorie Audit Security Group Management et les événements individuels utilisés pour les ajouts et suppressions de membres. Les événements 4728 et 4729 couvrent les changements de membres dans les groupes globaux de sécurité, 4732 et 4733 les groupes locaux de sécurité, et 4756 et 4757 les groupes universels de sécurité. Ces événements sont utiles lorsque le groupe privilégié ou le groupe imbriqué est dans le périmètre.
Pour les changements d’annuaire, l’événement 5136 enregistre les modifications d’objets du service d’annuaire lorsque l’audit approprié est activé. Il peut aider à identifier des attributs modifiés comme l’appartenance à un groupe ou les descripteurs de sécurité, selon ce qui est audité. L’événement 4662 peut aider sur les accès audités aux objets et les opérations sensibles d’annuaire, notamment les contextes Write Property, Control Access, WRITE_DAC et WRITE_OWNER lorsque les SACL sont configurées. Traitez ces événements comme des éléments de corrélation, pas comme des verdicts autonomes.
Enfin, reliez la télémétrie à l’intention. Un changement de groupe privilégié réalisé dans le cadre d’une demande d’accès documentée peut être attendu. Le même changement hors fenêtre de maintenance, effectué par un opérateur inhabituel ou suivi d’une nouvelle activité d’authentification sur des contrôleurs de domaine mérite investigation. Pour une cartographie plus large, utilisez un guide de supervision comme Supervision sécurité AD : les événements clés afin de garder les noms d’événements, les périmètres et les limites explicites.
Remediation et remédiation opérationnelle
La remédiation doit supprimer le chemin et corriger le processus qui lui a permis de revenir.
Supprimer les chemins de groupes et documenter les exceptions
Pour la dérive d’appartenance aux groupes, retirez les membres directs non approuvés et éliminez les imbrications dangereuses. Faites-le sur l’appartenance effective, pas seulement sur l’appartenance directe. Si un groupe imbriqué reste nécessaire, documentez le propriétaire, l’objectif, le chemin d’approbation et la cadence de revue. Évitez de laisser des principals larges comme Authenticated Users ou des groupes opérationnels trop vastes dans des groupes privilégiés.
Supprimer prudemment les ACL dangereuses
Pour la dérive ACL, ne supprimez pas les permissions à l’aveugle. Identifiez d’abord l’objet, le trustee, le droit, la source d’héritage et le propriétaire métier. Supprimez ensuite les droits qui créent un contrôle administratif sans objectif documenté. Priorisez GenericAll, WriteDACL, WriteOwner, AddMember, Self-Membership, les droits Write Property excessifs et les droits Control Access sur les objets Tier 0. Après suppression, vérifiez que la délégation opérationnelle fonctionne encore pour les tâches légitimes.
Révoquer les chemins de réplication et de persistance
Pour les principals compatibles DCSync, retirez les droits de réplication à tout compte ou groupe qui n’est pas explicitement approuvé pour ce rôle. Les contrôleurs de domaine ont besoin de réplication. Certains scénarios d’identité, de migration ou de sauvegarde peuvent nécessiter des droits soigneusement cadrés, mais ces exceptions doivent être rares, possédées, surveillées et revues. Si une capacité DCSync suspecte existait, traitez le nettoyage comme une question d’exposition d’identifiants, pas seulement comme un nettoyage d’ACL.
Pour la dérive AdminSDHolder, comparez le descripteur de sécurité au référentiel attendu et investiguez la manière dont il a changé. Comme AdminSDHolder affecte les objets administratifs protégés, traitez les permissions inattendues comme sensibles à la persistance. Supprimez les entrées non autorisées puis validez les permissions des comptes protégés après que SDProp a eu le temps de réappliquer le descripteur prévu.
Réduire l’exposition des identités privilégiées permanentes
Pour les identités privilégiées, réduisez l’accès permanent. Séparez les comptes utilisateurs quotidiens des comptes administratifs. Revoyez les comptes de service privilégiés et retirez-les des groupes admin lorsque c’est possible. Réservez le compte Administrator RID 500 aux scénarios break-glass ou d’urgence, et investiguez son utilisation routinière récente. Envisagez le groupe Protected Users pour les comptes humains privilégiés adaptés, mais testez d’abord la compatibilité, car Microsoft documente des changements de comportement d’authentification et des restrictions pour ses membres.
Pour la dérive de processus, imposez expiration et propriété pour les exceptions. Un AD propre après remédiation dérivera de nouveau si l’accès temporaire n’a pas de mécanisme de retrait. Le contrôle doit répondre à quatre questions : qui a approuvé le privilège, pourquoi il existe, quand il expire et quelle preuve démontre qu’il a été retiré.
Validation après nettoyage
La validation est l’endroit où beaucoup d’efforts de remédiation échouent. Retirer un membre visible de Domain Admins ne suffit pas si un groupe imbriqué, une ACL ou un droit de réplication demeure.
Recalculer l’appartenance effective
Après nettoyage, relancez l’inventaire d’appartenance effective. Confirmez que les groupes privilégiés ne contiennent que des membres directs et indirects approuvés. Confirmez qu’aucun principal large n’est présent dans un groupe privilégié. Confirmez que les comptes privilégiés créés récemment et les changements récents de groupes privilégiés correspondent à des tickets ou à des enregistrements d’incident approuvés.
Recontrôler les chemins ACL et réplication
Relancez ensuite la revue ACL. Confirmez que les droits GenericAll, WriteDACL, WriteOwner, AddMember, Self-Membership et les droits de réplication supprimés ne sont pas réapparus via l’héritage, l’imbrication de groupes ou un processus de template. Confirmez qu’AdminSDHolder ne contient plus d’entrées inattendues et que les objets protégés reflètent le descripteur de sécurité prévu.
Valider la télémétrie après remédiation
Enfin, validez la télémétrie. Recherchez les nouveaux changements d’appartenance aux groupes après nettoyage. Revoyez les modifications d’objets d’annuaire sur les objets sensibles. Confirmez que toute exception autorisée possède un propriétaire et une date de revue. Le but n’est pas de prouver qu’aucun changement futur ne peut arriver. Le but est de prouver que les droits effectifs actuels correspondent au référentiel et que les changements futurs seront visibles.
Si vous construisez un programme d’audit plus large, alignez cette validation avec la méthode d’audit de sécurité Active Directory afin de mesurer la dérive privilégiée aux côtés de l’authentification, de la délégation, d’AD CS, des GPO, des mots de passe et des contrôles de supervision.
Comment EtcSec détecte la dérive des accès privilégiés
EtcSec identifie et remesure les conditions de dérive des accès privilégiés dans la posture AD actuelle. Les contrôles catalogue pertinents couvrent les comptes privilégiés, les groupes, les ACL, les droits de réplication et AdminSDHolder, au lieu de traiter la dérive comme un symptôme unique.
Pour la dérive des comptes et de l’usage, EtcSec vérifie des conditions comme PRIVILEGED_ACCOUNT_STALE, ADMIN_NATIVE_RECENT_LOGON, EXCESSIVE_PRIVILEGED_ACCOUNTS et RECENT_PRIVILEGED_CREATION. Les seuils comme 90 jours pour les comptes privilégiés inactifs, 30 jours pour l’usage récent du compte Administrator natif, 10 jours pour les comptes privilégiés créés récemment, ou 7 jours pour les changements récents de groupes privilégiés sont des seuils de politique catalogue. Ils ne doivent pas être présentés comme des standards Microsoft.
Pour la dérive des groupes, EtcSec vérifie GROUP_EVERYONE_IN_PRIVILEGED, GROUP_AUTHENTICATED_USERS_PRIVILEGED, DANGEROUS_GROUP_NESTING et PRIVILEGED_GROUP_MEMBER_CHANGES. Ces findings aident à distinguer une liste d’appartenance directe apparemment propre d’un chemin de privilège effectif créé par des principals larges ou des groupes imbriqués.
Pour la dérive ACL et réplication, EtcSec vérifie DCSYNC_CAPABLE, ACL_GENERICALL, ACL_WRITEDACL, ACL_WRITEOWNER, ACL_SELF_MEMBERSHIP, ACL_ADD_MEMBER, ADMIN_SD_HOLDER_MODIFIED et ADMINSDHOLDER_BACKDOOR. Ces findings correspondent aux surfaces de contrôle que les défenseurs doivent remesurer après nettoyage : droits de réplication, droits de modification de groupes, contrôle des descripteurs de sécurité et persistance sur comptes administratifs protégés.
EtcSec ne remplace pas l’investigation SIEM ni la réponse à incident. Son rôle dans ce workflow est la mesure de posture : identifier la condition risquée, expliquer pourquoi elle compte, suivre la remédiation et mesurer si la condition revient après le prochain changement d’annuaire.
Contrôles associés
La dérive des accès privilégiés est plus facile à maîtriser lorsqu’elle est traitée comme un problème récurrent de posture. Une revue d’accès ponctuelle peut supprimer les comptes admin évidents ; un workflow récurrent peut détecter lorsque les mêmes droits reviennent.
Utilisez l’hygiène des comptes privilégiés pour réduire le nombre d’identités qui deviennent des cibles d’identifiants à forte valeur. Utilisez la revue des ACL et de DCSync pour repérer les chemins absents des rapports d’appartenance aux groupes. Utilisez les événements de supervision pour valider quand les changements ont eu lieu et qui les a effectués. Utilisez des contrôles de mots de passe administrateur locaux comme Windows LAPS pour réduire l’impact de la réutilisation d’identifiants admin locaux pendant que vous traitez les chemins de privilèges du domaine.
L’objectif opérationnel est simple : chaque chemin privilégié doit être intentionnel, possédé, minimal et revalidé. Tout le reste est de la dérive.
Références primaires
- Microsoft Learn: Audit Security Group Management
- Microsoft Learn: Event 4728 - A member was added to a security-enabled global group
- Microsoft Learn: Event 4729 - A member was removed from a security-enabled global group
- Microsoft Learn: Event 4732 - A member was added to a security-enabled local group
- Microsoft Learn: Event 4733 - A member was removed from a security-enabled local group
- Microsoft Learn: Event 4756 - A member was added to a security-enabled universal group
- Microsoft Learn: Event 4757 - A member was removed from a security-enabled universal group
- Microsoft Learn: Event 5136 - A directory service object was modified
- Microsoft Learn: Event 4662 - An operation was performed on an object
- Microsoft Open Specifications: AdminSDHolder
- Microsoft Learn: Protected Users security group
- MITRE ATT&CK: Account Manipulation T1098
- MITRE ATT&CK: DCSync T1003.006
- Catalogue local EtcSec : Active Directory vulnerability catalogue - docs/vulnerabilities/active-directory/AD_VULNERABILITY_CATALOG.md
