Comptes privilégiés Active Directory : Protected Users, délégation et lacunes des comptes de service

Qu'est-ce que la protection des comptes privilégiés Active Directory (Protected Users et délégation)

Les comptes Domain Admins, Enterprise Admins et autres comptes Tier 0 sont ceux dont un attaquant a besoin pour compromettre entièrement un domaine. Pour les comptes privilégiés Active Directory, trois contrôles natifs et indépendants font l'essentiel du travail de protection : l'appartenance au groupe de sécurité Protected Users, l'indicateur de délégation « ce compte est sensible et ne peut pas être délégué », et la règle d'hygiène de base selon laquelle les comptes de service n'ont pas leur place dans les groupes privilégiés. En plus de cela, l'attribut SID History — conçu pour les migrations de domaine — peut accorder silencieusement un accès privilégié s'il n'est jamais audité.

Rien de tout cela n'est exotique. Ce sont des fonctionnalités AD natives, prêtes à l'emploi. La lacune couverte par cet article n'est pas un correctif manquant ni une faille zero-day — ce sont simplement ces contrôles qui ne sont pas activés pour les comptes qui en ont besoin, ce qui explique pourquoi ce point revient sans cesse en tête de liste des audits de sécurité Active Directory. Chaque lacune ci-dessous est exploitable indépendamment, et aucune ne nécessite d'outillage résident en mémoire ni d'injection de processus : ce sont des erreurs de configuration au niveau des attributs, visibles par quiconque interroge l'annuaire de la bonne façon.

Fonctionnement

Protected Users : conçu mais inutilisé

Le groupe de sécurité global Protected Users, introduit avec Windows Server 2012 R2, applique des protections non configurables à tout compte qui y est ajouté. Selon la documentation Microsoft sur Protected Users, les membres ne peuvent pas s'authentifier via NTLM, ne peuvent pas utiliser DES ou RC4 pour la pré-authentification Kerberos, ne peuvent pas être délégués via une délégation contrainte ou non contrainte, et se voient imposer une durée de vie de ticket TGT Kerberos strictement limitée à 4 heures, sans renouvellement. La simple appartenance au groupe suffit — il n'y a aucune politique à mal configurer une fois le compte ajouté.

Le problème, c'est que la plupart des environnements ne le peuplent jamais. Les comptes Domain Admins et autres comptes Tier 0 continuent de s'authentifier avec des protocoles obsolètes et de mettre en cache leurs identifiants dans LSASS exactement comme si le groupe n'existait pas, tout simplement parce que personne ne les y a ajoutés.

L'indicateur « sensible et ne peut pas être délégué »

Indépendamment de Protected Users, chaque compte AD possède un bit userAccountControl — NOT_DELEGATED (0x100000 / 1048576) — exposé dans l'interface graphique sous la forme « Ce compte est sensible et ne peut pas être délégué ». Lorsqu'il est activé, le ticket Kerberos du compte ne peut pas être transféré vers un service configuré pour la délégation, même si ce service est par ailleurs autorisé pour la délégation. Selon l'évaluation de sécurité de Microsoft Defender for Identity pour ce contrôle, laisser cet indicateur désactivé sur des comptes privilégiés signifie qu'un service compromis ou malveillant, autorisé pour la délégation, peut demander et réutiliser le ticket de ce compte pour l'usurper ailleurs sur le réseau — un chemin d'escalade indépendant du fait que le compte soit ou non dans Protected Users.

Exposition à la délégation sur le compte lui-même

Au-delà de l'indicateur sensible, un compte peut porter directement une configuration de délégation : TRUSTED_FOR_DELEGATION (non contrainte), msDS-AllowedToDelegateTo (contrainte), ou la délégation contrainte basée sur les ressources via msDS-AllowedToActOnBehalfOfOtherIdentity. L'une ou l'autre de ces configurations sur un compte Tier 0 signifie qu'un service compromis autorisé pour la délégation peut demander des tickets en tant que ce compte. Nous détaillons l'exploitation de ces mécanismes dans Attaques de délégation Kerberos : de la délégation non contrainte à l'abus RBCD — le propos de cet article est plus restreint : un compte sensible ne devrait jamais être une cible de délégation, quelle que soit la technique d'attaque utilisée contre lui.

Des comptes de service dans des groupes privilégiés

Un compte de service doté d'un SPN (Service Principal Name) est kerberoastable par conception — n'importe quel utilisateur du domaine authentifié peut demander un ticket de service pour ce compte et tenter de casser le ticket hors ligne (voir notre guide sur le Kerberoasting pour cette chaîne d'attaque). Ce risque est tolérable tant que le compte n'a accès qu'au service qu'il exécute. Il cesse de l'être dès que le compte est également membre de Domain Admins ou Enterprise Admins.

Les recommandations de Microsoft sur la réduction de l'appartenance aux groupes d'administration hautement privilégiés sont explicites : les groupes privilégiés doivent rester vides ou limités à un petit nombre d'administrateurs responsables, et les comptes de service doivent recevoir des permissions déléguées restreintes plutôt que des droits Domain Admin étendus. Un compte de service dans Domain Admins combine un mot de passe cassable et un privilège à l'échelle du domaine — quiconque peut interroger les SPN dispose déjà d'un chemin pour tenter une compromission complète du domaine.

SID History : la quatrième voie silencieuse

L'attribut sIDHistory existe pour préserver les accès lors des migrations inter-domaines — un utilisateur migré conserve le SID de son ancien compte, ajouté à son jeton, afin que les permissions existantes continuent de fonctionner. Selon MITRE ATT&CK T1134.005, un attaquant disposant de droits équivalents à Domain Admin (ou d'une capacité DCSync) peut insérer un SID privilégié récupéré ou bien connu — comme celui d'Enterprise Admins — dans le SID History d'un compte à faible privilège. Le jeton de ce compte porte alors les droits Enterprise Admin sans jamais apparaître comme membre du groupe Enterprise Admins, ce qui le rend précisément dangereux : une revue des appartenances aux groupes ne le détecte absolument pas.

Pourquoi les attaquants enchaînent ces lacunes

Aucune de ces quatre failles n'a besoin d'être isolée pour être utile à un attaquant, et en pratique, elles le sont rarement. Un compte privilégié sans l'indicateur sensible est une cible de délégation viable ; ce même compte hors de Protected Users peut toujours s'authentifier via NTLM, donc un attaquant disposant d'un hash relayé n'a même pas besoin de Kerberos. Si ce même environnement compte aussi un compte de service dans Domain Admins, un attaquant qui kerberoast et casse son mot de passe obtient une seconde voie, indépendante, vers le même niveau de privilège — sans avoir besoin d'abuser de la délégation. Et le SID History offre une option de persistance qui survit entièrement à une rotation d'identifiants sur le compte privilégié d'origine, puisque le SID injecté voyage sur une identité totalement différente et à faible privilège.

C'est également ce qui distingue cette lacune des comptes privilégiés obsolètes (des identifiants dormants que personne n'a désactivés — voir Comptes privilégiés obsolètes : un risque caché dans Active Directory) et de la dérive des accès privilégiés (des droits qui reviennent après un nettoyage — voir Dérive des accès privilégiés Active Directory). Ces deux cas concernent des comptes qui ne devraient plus avoir d'accès, ou des accès qui sont revenus discrètement. Ici, il s'agit de comptes correctement privilégiés aujourd'hui, mais dépourvus des protections au niveau des attributs qu'Active Directory propose déjà nativement pour les contenir.

Détection

Interrogez directement l'annuaire pour chaque lacune — aucun outillage tiers n'est nécessaire.

# Comptes privilégiés absents de Protected Users
$protected = (Get-ADGroupMember "Protected Users" -Recursive).SamAccountName
Get-ADGroupMember "Domain Admins" -Recursive |
    Where-Object { $_.SamAccountName -notin $protected } |
    Select-Object SamAccountName

# Comptes privilégiés sans l'indicateur « sensible, ne peut pas être délégué » (bit 0x100000)
Get-ADGroupMember "Domain Admins" -Recursive |
    Get-ADUser -Properties userAccountControl |
    Where-Object { -not ($_.userAccountControl -band 1048576) } |
    Select-Object SamAccountName

# Comptes toujours autorisés pour la délégation non contrainte/contrainte
Get-ADUser -Filter 'TrustedForDelegation -eq $true -or msDS-AllowedToDelegateTo -like "*"' `
    -Properties TrustedForDelegation, msDS-AllowedToDelegateTo

# Comptes de service (SPN défini) dans des groupes privilégiés
Get-ADGroupMember "Domain Admins","Enterprise Admins" -Recursive |
    Get-ADUser -Properties ServicePrincipalNames |
    Where-Object { $_.ServicePrincipalNames.Count -gt 0 }

# Tout compte portant un SID History
Get-ADUser -Filter * -Properties SIDHistory |
    Where-Object { $_.SIDHistory.Count -gt 0 } |
    Select-Object SamAccountName, SIDHistory

Pour une vue plus large des ID d'événements pertinents sur le reste de votre parc AD, consultez Supervision Active Directory : les ID d'événements de sécurité qui comptent.

Remédiation

1. Peuplez Protected Users uniquement avec les comptes Tier 0 humains. Testez d'abord sur un groupe pilote — Protected Users casse les applications dépendantes de NTLM, la connexion hors ligne/en cache, et tout flux reposant sur le renouvellement de ticket Kerberos au-delà de 4 heures. N'y ajoutez jamais de comptes de service ou d'ordinateur.
2. Activez l'indicateur sensible sur chaque compte privilégié humain :

   Get-ADUser -Identity "jdoe" | Set-ADAccountControl -AccountNotDelegated:$true
   

   Faites-le même pour les comptes déjà dans Protected Users — le blocage de la délégation par Protected Users s'applique au moment de l'authentification, mais un indicateur sensible explicite apporte une défense en profondeur et compte immédiatement pour tout compte pas encore entièrement migré dans le groupe.
3. Retirez la confiance de délégation des comptes Tier 0. Effacez TrustedForDelegation et msDS-AllowedToDelegateTo sur tout compte privilégié ; les comptes privilégiés ne devraient jamais être des cibles de délégation. Consultez notre guide Attaques de délégation Kerberos pour savoir comment auditer la configuration de délégation à l'échelle du domaine avant de commencer à la retirer.
4. Sortez les comptes de service des groupes privilégiés. Remplacez l'appartenance à Domain Admin par un compte de service géré de groupe (gMSA) associé à des permissions déléguées restreintes sur l'UO ou la ressource dont le service a réellement besoin. Si le service a réellement besoin de droits à l'échelle du domaine, c'est le signe qu'il faut repenser le service, pas laisser un compte kerberoastable avec un privilège de domaine complet.
5. Auditez et purgez le SID History obsolète. Exécutez la requête de détection ci-dessus ; toute valeur sIDHistory non rattachée à une migration de domaine documentée et toujours pertinente doit être examinée puis supprimée avec Set-ADUser -Clear sIDHistory après avoir confirmé qu'aucun accès légitime n'en dépend. Pour les approbations (trusts) inter-forêts et externes, activez le filtrage de SID (mise en quarantaine) afin que les SID injectés de l'autre côté de l'approbation soient supprimés avant d'atteindre votre domaine — voir Attaques sur les approbations Active Directory : du domaine enfant à la racine de la forêt pour comprendre comment les lacunes de filtrage de SID sont exploitées à travers les approbations.

Comment EtcSec détecte cela

L'audit Active Directory d'EtcSec vérifie ces quatre lacunes à chaque scan : NOT_IN_PROTECTED_USERS signale les comptes privilégiés absents du groupe Protected Users, SENSITIVE_DELEGATION détecte les comptes privilégiés sans l'indicateur « ne peut pas être délégué », SERVICE_ACCOUNT_PRIVILEGED identifie les comptes porteurs d'un SPN au sein de Domain Admins/Enterprise Admins, et SID_HISTORY fait remonter tout compte portant un sIDHistory non vide pour examen.