[AD DS Sécurité] L’objet « AdminSDHolder»

Dans un domaine Active Directory il existe un objet particulier qui sert de référence pour protéger les informations de sécurité de certains comptes à fort privilège. L'objet en question est « AdminSDHolder » et il est présent dans chaque domaine dans le conteneur « System ».

L'objet « AdminSDHolder » permet de protéger les informations de sécurité des comptes membres des groupes suivants :

  • Opérateurs de compte, Opérateurs de sauvegarde, Operateur de serveur, Opérateurs d'impression (conteneur « Builtin »)
  • Administrateurs, sur les contrôleurs de domaine (conteneur « Builtin »)
  • Admins du domaine, Administrateurs de l'entreprise, Administrateurs du schéma (Conteneur « Users »)-
  • Contrôleurs de domaine en lecture seule , Contrôleurs de domaine (Conteneur « Users »)

Les éléments ci-dessous restent valables même si un utilisateur n'est pas directement membre d'un groupe de privilège du moment qu'il hérite de ce groupe. Par exemple si « admin1 » est membre de « SG-Administrateurs » et « SG-Administrateurs » est membre de « Admins du domaine » alors les comptes membres de « SG-Administrateurs » seront également protégés.

 

Il protège également le compte « Administrateur » et le compte « KrbTGT » existant par défaut dans un domaine Active Directory.

Les informations de sécurité de cet objet seront comparées aux informations de sécurités des comptes membres des groupes protégés.

Il existe un processus « SDProp » qui s'exécute par défaut toutes les heures sur le contrôleur de domaine qui dispose du rôle « Emulateur PDC ». Ce processus va désactiver l'héritage de droits sur les objets membre des groupes protégés et il leurs appliquera les informations de sécurité de l'objet « AdminSDHolder ». Cela évite que des comptes à fort privilège se retrouvent en danger par exemple si une délégation de droit a été configurée sur leur conteneur.

Dans l'exemple ci-dessous, le contrôle total pour un compte utilisateur a été ajouté sur le compte « Adm-PB », membre de « Admins du domaine ». Le compte utilisateur en question est maintenant en mesure d'obtenir tous les droits sur le domaine.

Après un délai pouvant aller jusqu'à une heure, les ACL sur le compte « Adm-pb » ont été réinitialisé.

L'héritage des droits sur le compte a également été désactivé.

Le processus « SDProp », modifie également l'attribut « AdminCount » de l'objet protégé. Par défaut cet attribut n'est pas renseigné. Si le traitement « SDProp » détecte un compte membre d'un groupe protégé, l'attribut passe à 1 pour ce compte.

Si l'utilisateur n'est plus membre d'un groupe protégé, ces ACL ne seront pas remises à mises à jour, l'héritage sera toujours désactivé et l'attribut « AdminCount » restera à 1.

Si vous souhaitez rétablir les éléments, il vous faudrait effacer l'attribut « AdminCount », rétablir les l'héritage des informations de sécurité et supprimer les ACLs qui n'ont pas lieu d'être. Dans le principe oui, mais il est déconseillé de le faire !!!

La bonne démarche serait de supprimer le compte et d'en refaire un nouveau. En effet même si vous réinitialisez ces éléments, l'utilisateur concerné a peut-être obtenu d'autres droits dans votre environnement par ces privilèges. Peut-être est-il maintenant administrateur d'un serveur applicatif ? Il serait fastidieux et délicat de faire l'inventaire de toutes les ACL sur l'ensemble des postes et serveurs du domaine.

Il est préférable de refaire un compte avec un nouvel identifiant de sécurité.

Le processus « SDProp « s'exécute par défaut toutes les heures. Il est possible de modifier la fréquence à l'aide de la valeur « AdminSDProtectFrequency » dans le registre. Dans l'exemple ci-dessous la fréquence a été modifié sur 600 secondes (10 minutes).

La commande ci-dessous permet de modifier la fréquence à 20 minutes par exemple.

REG ADD HKLM\SYSTEM\CurrentControlSet\Services\NTDS\Parameters /V AdminSDProtectFrequency /T REG_DWORD /F /D 1200

Néanmoins il n'est pas recommandé de diminuer la fréquence définit par défaut, afin d'éviter des problèmes de performances sur le contrôleur de domaine.

Il est possible d'obtenir la liste des comptes dont l'attribut « AdminCount » a été modifié avec la requête PowerShell suivante :

Get-ADUser -LDAPFilter "(objectcategory=person)(samaccountname=*)(admincount=1)"

 

Si vous êtes dans une forêt multi domaine vous devez exécuter la commande dans chaque domaine de votre forêt. L'attribut n'est pas répliqué dans le catalogue global.

 

 

  • Ne modifier pas les informations de sécurité de l'objet AdminSDHolder
  • Isoler les comptes d'administrations dans une OU distinct des comptes utilisateurs
  • Si l'attribut « AdminCount » d'un compte utilisateur est à 1, il est préférable de supprimer et de refaire le compte. En effet ce compte peut disposer de privilège spécifique à différents niveaux et il sera difficile de les identifier sans outils tiers ( administrateurs d'un serveur applicatif, délégation de permission AD, permission NTFS, permission SharePoint, …)
  • Ne modifier pas la fréquence du processus « SDProp » dans un environnement de production. Si vous réduisez le délai cela peut impacter les performances du contrôleur de domaine qui dispose du rôle FSMO « Emulateur PDC ».

 

 

Quelques suggestions de lecture supplémentaire :

https://docs.microsoft.com/en-us/openspecs/windows_protocols/ms-adts/dd3d29f3-8e1e-4e8c-a210-9eaef3abd628

https://docs.microsoft.com/en-us/windows/desktop/adschema/a-admincount

https://blogs.technet.microsoft.com/askds/2009/05/07/five-common-questions-about-adminsdholder-and-sdprop/

Theme: 

Systeme: 

Annee: