Comptes AD désactivés, expirés, verrouillés groupes privilégiés : pourquoi les droits admin persistent

Comptes AD désactivés, expirés, verrouillés groupes privilégiés est exactement l'angle mort que couvre cet article : un compte dont l'état propre — désactivé, expiré ou verrouillé — indique qu'il ne devrait plus avoir d'accès, alors qu'il est encore formellement membre de Domain Admins, Enterprise Admins, ou d'un autre groupe Tier 0. Un compte admin désactivé est presque toujours une étape d'offboarding oubliée. Un compte expiré est un accès accordé pour une durée limitée que personne n'a retiré du groupe une fois l'échéance passée. Un compte verrouillé peut n'être qu'un simple ticket de helpdesk — ou bien la fin d'une attaque de password spraying encore en cours. Cet article couvre ces trois états, ainsi que leur proche cousin, le flag adminCount orphelin, et explique comment les détecter et les corriger.

Comptes AD désactivés, expirés, verrouillés groupes privilégiés : les quatre états

Chacune de ces quatre situations a une définition précise au niveau de l'attribut, et chacune a sa propre façon de finir discrètement dans un groupe privilégié sans que personne ne l'ait décidé.

Le compte désactivé

Le bit ACCOUNTDISABLE (0x2) est positionné dans userAccountControl ; le compte ne peut plus se connecter de manière interactive. (Microsoft Learn : UserAccountControl property flags) Les comptes désactivés s'accumulent parce que les checklists d'offboarding s'arrêtent généralement à « désactiver le compte ». Cela bloque la connexion, mais ne change rien à l'appartenance aux groupes — le SID reste dans Domain Admins. Tout outil de cartographie de chemins d'attaque qui détermine « qui pourrait devenir admin du domaine » — BloodHound, PingCastle ou EtcSec inclus — le compte quand même, car ces graphes sont construits sur l'appartenance aux groupes, pas sur userAccountControl. Si le compte est un jour réactivé — par erreur, via un ticket ITSM en retard, ou par un attaquant ayant obtenu le droit de basculer un seul bit — son ancien privilège redevient effectif immédiatement, sans aucune autre action nécessaire.

Le compte expiré

accountExpires contient une valeur différente de 0 ou de la sentinelle « n'expire jamais » 9223372036854775807, et cette valeur (un FILETIME Windows) est dans le passé. (Microsoft Learn : Account-Expires attribute) Cet attribut est fréquemment utilisé pour des comptes de prestataires ou d'élévation temporaire avec une date de fin planifiée. Le KDC refuse d'émettre un ticket-granting ticket au-delà de cette date, donc le compte cesse de fonctionner pour une connexion interactive ou réseau — mais accountExpires ne touche pas non plus à l'appartenance aux groupes. Si l'intention réelle était « l'accès admin de cette personne se termine à cette date », fixer une date d'expiration sans retirer également l'appartenance au groupe ne verrouille que la porte d'entrée.

Le compte verrouillé

lockoutTime est non nul et la durée de verrouillage du compte n'est pas encore écoulée. Windows ne positionne jamais de bit UF_LOCKOUT dans la valeur stockée de userAccountControl elle-même ; l'état verrouillé/déverrouillé en direct est exposé via l'attribut construit msDS-User-Account-Control-Computed. (MS-ADLS : lockoutTime, MS-ADTS : msDS-User-Account-Control-Computed) Contrairement à la désactivation ou à l'expiration, le verrouillage n'est pas une décision administrative — c'est un effet de bord des tentatives de connexion échouées qui atteignent la politique de verrouillage de compte. Un compte privilégié peut être verrouillé parce que quelqu'un a réellement mal saisi son mot de passe, ou parce qu'il est actuellement ciblé : une campagne de password spraying ou de brute-force qui atteint un compte privilégié et est sur le point de réussir peut produire exactement la même signature juste avant l'authentification.

Le flag adminCount orphelin

adminCount=1 marque les membres des groupes protégés par AdminSDHolder, mais un compte peut le porter alors qu'il n'appartient plus à aucun groupe protégé — le cas inverse : non pas un privilège vivant sur un compte mort, mais un marqueur mort laissé par un privilège déjà retiré. Le mécanisme derrière cela est le processus SDProp, qui s'exécute sur le contrôleur de domaine détenant le rôle PDC Emulator (par défaut environ une fois par heure), parcourt l'appartenance des groupes protégés, positionne adminCount=1 sur chaque membre, copie l'ACL AdminSDHolder sur l'objet, et désactive l'héritage des ACL. (Microsoft Community Hub : Five common questions about AdminSDHolder and SDProp) Lorsque le compte est ensuite retiré du groupe protégé, SDProp cesse simplement d'y toucher — il ne réinitialise pas adminCount à 0 et ne restaure pas l'héritage. Le flag et l'ACL déconnectée restent en place comme un marqueur silencieux, d'apparence permanente, d'un privilège que le compte ne possède plus.

Détection

Attributs et requêtes PowerShell

Des requêtes directes sur l'appartenance via le module PowerShell AD révèlent rapidement les quatre situations :

# Comptes désactivés toujours membres d'un groupe privilégié
Get-ADGroupMember -Identity "Domain Admins" -Recursive |
    Get-ADUser -Properties Enabled, userAccountControl |
    Where-Object { -not $_.Enabled }

# Comptes expirés (accountExpires renseigné et dans le passé — 0 et la
# sentinelle max int64 signifient tous deux « n'expire jamais »)
Get-ADGroupMember -Identity "Domain Admins" -Recursive |
    Get-ADUser -Properties accountExpires |
    Where-Object {
        $_.accountExpires -gt 0 -and
        $_.accountExpires -lt 9223372036854775807 -and
        [datetime]::FromFileTime($_.accountExpires) -lt (Get-Date)
    }

# Comptes actuellement verrouillés, croisés avec les groupes privilégiés
Search-ADAccount -LockedOut -UsersOnly |
    Where-Object { (Get-ADPrincipalGroupMembership $_.SamAccountName).Name -contains "Domain Admins" }

# adminCount=1 sans appartenance actuelle à un groupe protégé (flag orphelin)
Get-ADUser -LDAPFilter "(adminCount=1)" -Properties adminCount, memberOf, Enabled

Filtre LDAP pour les outils en bind brut

Pour les outils qui ne passent pas par le module PowerShell AD, la vérification du bit de désactivation utilise l'OID LDAP_MATCHING_RULE_BIT_AND sur userAccountControl :

(&(objectCategory=person)(objectClass=user)(userAccountControl:1.2.840.113556.1.4.803:=2))

Cela correspond à la sémantique de ET binaire propre à AD : la clause n'est satisfaite que si le second bit (0x2, ACCOUNTDISABLE) est positionné sur la valeur stockée. (MS-ADTS : LDAP_MATCHING_RULE_BIT_AND)

Event IDs Windows à corréler

Ces événements sont journalisés sur les contrôleurs de domaine sous l'audit Account Management — voir la référence complète des Event IDs de supervision Active Directory pour la configuration de journalisation plus large :

Sources : Event ID 4725, Event ID 4740, Event ID 4767, Event ID 4738, Event ID 4728, Event ID 4756.

Remediation

Pour les comptes désactivés et expirés

1. Rendez le contrôle récurrent, pas seulement une étape d'offboarding. Un processus de départ qui désactive le compte quand quelqu'un quitte l'entreprise ne détectera pas une date d'expiration déjà dépassée depuis six mois. Planifiez l'exécution régulière des requêtes ci-dessus, ou d'une règle SIEM/EASM équivalente.
2. Liez l'offboarding au retrait du groupe, pas seulement à la désactivation du compte. La désactivation bloque la connexion ; elle ne révoque pas l'appartenance au groupe que les graphes de chemins d'attaque, les droits délégués, et certaines logiques d'autorisation applicative continuent de lire. Quand l'accès doit prendre fin, retirez explicitement le compte du groupe privilégié.
3. Traitez les dates d'expiration comme un déclencheur de revue d'appartenance, pas comme un substitut. Si un compte a été intégré à un groupe privilégié pour une durée limitée, fixez un rappel correspondant pour retirer l'appartenance à la date d'expiration ou avant — ne comptez pas uniquement sur accountExpires pour représenter « cette personne n'est plus admin ».

Pour les comptes privilégiés verrouillés

Comme déverrouiller un compte est une opération peu coûteuse, rapide et délégable — une permission AD distincte de la réinitialisation du mot de passe — un compte Tier 0 verrouillé n'est qu'à un déverrouillage d'être à nouveau pleinement utilisable. Routez l'Event ID 4740 sur les membres des groupes protégés vers son propre chemin d'alerte, distinct du bruit habituel de déverrouillage helpdesk, et confirmez que le déverrouillage (Event ID 4767) provient bien d'un administrateur attendu avant de considérer l'incident comme clos.

Pour les flags adminCount orphelins

Pour chaque compte avec adminCount=1 mais sans appartenance actuelle à un groupe protégé, confirmez qu'il n'est réellement plus privilégié — vérifiez les appartenances imbriquées, pas seulement directes, car un retrait d'un groupe assigné directement peut laisser un privilège indirect en place. Une fois la vérification confirmée, réinitialisez adminCount et réactivez l'héritage des ACL plutôt que de laisser le flag obsolète et l'ACL déconnectée en place ; les laisser brouille chaque futur audit de permissions sur cet objet.

Comment EtcSec détecte cela

EtcSec vérifie ces quatre situations à chaque audit Active Directory : DISABLED_ACCOUNT_IN_ADMIN_GROUP et EXPIRED_ACCOUNT_IN_ADMIN_GROUP signalent les membres de groupes privilégiés dont l'état du compte aurait déjà dû bloquer leur accès, LOCKED_ACCOUNT_ADMIN fait remonter les comptes privilégiés actuellement verrouillés pour le scénario de password spraying décrit ci-dessus, et ADMIN_COUNT_ORPHANED capture le cas inverse — le marqueur résiduel adminCount=1 laissé après le retrait d'une appartenance protégée.