Si vous demandez à un administrateur système ce qu'est la « délégation » dans Active Directory, il pensera probablement à la délégation Kerberos. C'est le sujet le plus visible, le plus documenté. Mais la notion de délégation dans AD est beaucoup plus large — et beaucoup plus dangereuse — qu'on ne le pense.
Dans cet article, nous passons en revue les délégations de permissions (ACL) les plus critiques que nous rencontrons systématiquement dans nos audits, et qui constituent des chemins d'élévation de privilèges directs vers Domain Admin.
Comprendre les ACL Active Directory
Chaque objet dans Active Directory (utilisateur, groupe, ordinateur, OU, GPO) possède une liste de contrôle d'accès (ACL) qui définit qui peut faire quoi sur cet objet. Ces ACL sont composées d'entrées individuelles appelées ACE (Access Control Entries). Une ACE typique dit : « le groupe X a le droit Y sur l'objet Z ».
Le problème est que ces ACL sont rarement auditées après leur création. Au fil des années, des délégations s'accumulent : un prestataire qui avait besoin de créer des comptes dans une OU, un script d'automatisation qui nécessitait des droits d'écriture, un administrateur qui s'est donné des permissions « temporaires » il y a cinq ans. Personne ne nettoie.
1. GenericAll : le droit nucléaire
Le droit GenericAll accorde un contrôle total sur un objet. Si un utilisateur ou un groupe a GenericAll sur un compte Domain Admin, il peut réinitialiser son mot de passe, modifier ses attributs, le supprimer, le déplacer — tout.
Ce droit est parfois attribué involontairement. L'interface graphique d'Active Directory Users and Computers traduit GenericAll par « Contrôle total », et certains administrateurs cochent cette case par facilité quand ils veulent simplement accorder un droit de lecture.
Comment auditer
# Trouver les GenericAll sur les groupes privilégiés
$groups = @("Domain Admins","Enterprise Admins","Administrators")
foreach ($group in $groups) {
$dn = (Get-ADGroup $group).DistinguishedName
(Get-Acl "AD:$dn").Access | Where-Object {
$_.ActiveDirectoryRights -match "GenericAll" -and
$_.IdentityReference -notmatch "BUILTIN|NT AUTHORITY|S-1-5"
} | Select IdentityReference, ActiveDirectoryRights
}Impact
Un attaquant qui compromet un compte avec GenericAll sur Domain Admins peut s'ajouter lui-même au groupe. Temps d'exploitation : quelques secondes. Aucun outil sophistiqué nécessaire — une simple commande net group suffit.
2. WriteDACL : réécrire les règles du jeu
Le droit WriteDACL permet de modifier l'ACL d'un objet. En d'autres termes, un utilisateur avec WriteDACL peut s'accorder n'importe quel autre droit sur l'objet cible. C'est un méta-droit : il ne donne pas directement le contrôle, mais il permet de se l'attribuer.
Ce droit est particulièrement insidieux parce qu'il n'apparaît pas comme « Contrôle total » dans les outils d'administration. Un audit superficiel peut le rater. Et pourtant, WriteDACL sur un contrôleur de domaine ou sur le conteneur AdminSDHolder équivaut à un accès Domain Admin.
Comment auditer
# Chercher WriteDACL sur la racine du domaine
$rootDSE = (Get-ADDomain).DistinguishedName
(Get-Acl "AD:$rootDSE").Access | Where-Object {
$_.ActiveDirectoryRights -match "WriteDacl" -and
$_.IdentityReference -notmatch "BUILTIN|NT AUTHORITY|S-1-5|Domain Admins|Enterprise Admins"
} | Select IdentityReference, ActiveDirectoryRights, IsInherited3. WriteOwner : prendre la propriété
Le propriétaire d'un objet AD a implicitement le droit de modifier son ACL. Le droit WriteOwner permet de changer le propriétaire d'un objet. Donc : WriteOwner → changement de propriétaire → modification de l'ACL → GenericAll → compromission totale.
C'est un chemin d'attaque en trois étapes, mais chaque étape est triviale à exécuter. BloodHound visualise parfaitement ces chaînes, et les outils d'attaque comme PowerView automatisent l'exploitation.
4. ForceChangePassword : la porte d'entrée silencieuse
Le droit étendu User-Force-Change-Password (souvent abrégé ForceChangePassword dans les outils) permet de réinitialiser le mot de passe d'un utilisateur sans connaître l'ancien mot de passe. Si ce droit est accordé sur un compte à privilèges, c'est un chemin d'élévation direct.
Ce droit est souvent accordé aux équipes helpdesk pour gérer les réinitialisations de mots de passe des utilisateurs standards. Le problème survient quand la délégation est mal ciblée : au lieu de cibler uniquement l'OU des utilisateurs standards, elle cible la racine du domaine et s'hérite sur tous les comptes — y compris les Domain Admins.
Comment auditer
# Identifier les comptes avec ForceChangePassword sur les comptes privilégiés
Import-Module ActiveDirectory
$privUsers = Get-ADGroupMember "Domain Admins" -Recursive
foreach ($user in $privUsers) {
$acl = Get-Acl "AD:$($user.DistinguishedName)"
$acl.Access | Where-Object {
$_.ObjectType -eq "00299570-246d-11d0-a768-00aa006e0529" -and
$_.IdentityReference -notmatch "BUILTIN|NT AUTHORITY|S-1-5"
} | Select @{N='Target';E={$user.SamAccountName}}, IdentityReference
}5. Écriture sur msDS-KeyCredentialLink : Shadow Credentials
C'est une technique plus récente mais redoutable. Si un attaquant peut écrire sur l'attribut msDS-KeyCredentialLink d'un compte, il peut ajouter une clé d'authentification qui lui permet d'obtenir un TGT pour ce compte via PKINIT, sans connaître ni modifier le mot de passe.
L'avantage pour l'attaquant est que le mot de passe de la victime n'est pas modifié — l'attaque est donc silencieuse. Pas d'alerte « mot de passe réinitialisé », pas de ticket support de l'utilisateur qui ne peut plus se connecter.
Cette technique (connue sous le nom de « Shadow Credentials ») nécessite un droit d'écriture sur l'attribut spécifique ou un droit GenericWrite / GenericAll sur le compte cible. Elle nécessite également que l'infrastructure AD supporte PKINIT (ce qui est le cas par défaut avec les contrôleurs de domaine Windows Server 2016+).
6. La délégation Kerberos contrainte avec transition de protocole
La délégation Kerberos contrainte (msDS-AllowedToDelegateTo) est censée être la version « sécurisée » de la délégation non contrainte. Et c'est vrai — en théorie. Mais quand elle est configurée avec la transition de protocole activée (flag TRUSTED_TO_AUTH_FOR_DELEGATION), elle permet au service délégué d'obtenir un ticket pour n'importe quel utilisateur vers le service cible, sans que cet utilisateur ait besoin de s'authentifier.
En pratique, si un compte de service a une délégation contrainte avec transition de protocole vers le service LDAP d'un contrôleur de domaine, ce compte peut usurper l'identité de n'importe quel Domain Admin vers ce DC. C'est presque aussi dangereux que la délégation non contrainte, mais plus difficile à détecter car elle apparaît comme « contrainte » dans les outils.
Comment auditer
# Trouver les comptes avec délégation contrainte + transition de protocole
Get-ADObject -Filter {msDS-AllowedToDelegateTo -like "*"} -Properties `
msDS-AllowedToDelegateTo, userAccountControl, SamAccountName |
Where-Object {$_.userAccountControl -band 0x1000000} |
Select SamAccountName, @{N='DelegateTo';E={$_.'msDS-AllowedToDelegateTo'}}La remédiation systémique
Corriger ces délégations une par une est nécessaire mais insuffisant. Il faut mettre en place une gouvernance des ACL :
Documenter l'état de référence. Exporter les ACL de tous les objets critiques (AdminSDHolder, racine du domaine, OU des comptes privilégiés, conteneur des contrôleurs de domaine) et les stocker comme baseline. Tout écart doit déclencher une alerte.
Implémenter le modèle de tiering. Les comptes Tier 0 (administration AD) ne doivent jamais avoir de délégation vers des objets Tier 1 ou Tier 2, et inversement. Séparer les comptes d'administration par niveau empêche les chemins d'escalade inter-tiers.
Auditer régulièrement. Les ACL dérivent naturellement avec le temps. Un audit trimestriel des délégations sur les objets critiques permet de détecter les nouvelles configurations à risque avant qu'elles ne soient exploitées.
Utiliser le groupe Protected Users. Les comptes membres de ce groupe bénéficient de protections supplémentaires : pas de mise en cache des credentials, pas de délégation, pas de NTLM. Tous les comptes à hauts privilèges devraient y être.