AdminSDHolder et SDProp : comprendre, auditer et nettoyer les comptes protégés

Comment fonctionne le mécanisme

L'objet CN=AdminSDHolder,CN=System de chaque domaine porte un descripteur de sécurité de référence. Un processus appelé SDProp, exécuté par le contrôleur de domaine détenteur du rôle d'émulateur PDC (toutes les 60 minutes par défaut), compare ce modèle aux ACL des comptes et groupes protégés. En cas d'écart, il écrase l'ACL de l'objet protégé, désactive l'héritage et positionne l'attribut adminCount à 1.

Les groupes protégés incluent notamment Administrateurs, Admins du domaine, Administrateurs de l'entreprise, Administrateurs du schéma, Opérateurs de compte, Opérateurs de sauvegarde, Opérateurs de serveur, Opérateurs d'impression, Réplicateur, Contrôleurs de domaine et Key Admins, ainsi que les comptes Administrateur et krbtgt. Leurs membres, directs ou imbriqués, sont eux aussi protégés.

Les adminCount orphelins

Lorsqu'un compte quitte un groupe protégé, SDProp ne le « déprotège » pas. L'attribut adminCount reste à 1 et l'héritage reste désactivé. Conséquences : les délégations appliquées à l'OU ne s'appliquent plus à ce compte, ce qui peut casser le support, et le compte continue d'apparaître comme sensible dans les outils. Surtout, ces comptes signalent souvent d'anciens administrateurs dont les droits ont été retirés sans nettoyage.

Get-ADUser -Filter 'adminCount -eq 1' -Properties adminCount, MemberOf, Enabled |
    Select-Object SamAccountName, Enabled, @{n='Groupes';e={$_.MemberOf.Count}}

Il faut ensuite comparer cette liste à l'appartenance effective, imbrications comprises, aux groupes protégés.

AdminSDHolder comme outil de persistance

Un attaquant qui a obtenu des droits élevés peut ajouter une entrée de contrôle d'accès sur AdminSDHolder, par exemple un contrôle total pour un compte discret. En moins d'une heure, SDProp propage cette entrée sur tous les comptes et groupes protégés. Même si l'on retire l'ACE directement sur les Admins du domaine, elle réapparaît au cycle suivant. C'est une technique de persistance simple et efficace.

Auditer l'ACL

Import-Module ActiveDirectory
$dn = "CN=AdminSDHolder,CN=System," + (Get-ADDomain).DistinguishedName
(Get-Acl "AD:$dn").Access |
    Select-Object IdentityReference, ActiveDirectoryRights, AccessControlType, ObjectType

Pour la détection, activez l'audit des modifications du service d'annuaire et une SACL sur AdminSDHolder : l'événement 5136 signale alors toute modification de son descripteur de sécurité.

Nettoyer proprement

1. Vérifier que le compte n'appartient plus, même indirectement, à aucun groupe protégé.
2. Remettre adminCount à vide.
3. Réactiver l'héritage des permissions sur l'objet, puis contrôler l'ACL obtenue.
4. Documenter l'opération et vérifier au cycle SDProp suivant que le compte n'est pas reprotégé.

Ce qu'un audit vérifie

• les entrées non standard dans l'ACL d'AdminSDHolder ;
• les comptes avec adminCount=1 qui ne sont plus membres de groupes protégés ;
• la valeur de dsHeuristics si des groupes d'opérateurs ont été exclus de la protection ;
• la présence d'un audit des modifications sur l'objet.