Groupes Protégés AD & AdminSDHolder

Vous aurez peut-être remarqué en jouant avec les groupes de sécurité Active Directory, en ajoutant des ACLs sur des OUs ou autre que des permissions sautent toutes seules sur des comptes …

Je m’apprête à parler ici de l’objet AdminSDHolder dans Active Directory

Cas de figure simple
Dans votre infrastructure, vous disposez d’une hot-line dédiée à la gestion des comptes AD verrouillés, des mots de passe oubliés ou expirés etc …
Les comptes admins de base en charge de cette tâche peuvent, par exemple, avoir été regroupés dans un groupe de sécurité, lui-même positionné sur une ou plusieurs OUs.
Ce groupe de sécurité peut, par exemple, disposer de droits basiques (mot de passe, compte, …)  sur l’ensemble des comptes utilisateurs contenu dans l’OU.
Oui mais voilà, dans cette OU, vous avez de nombreux comptes utilisateurs standard mais aussi les comptes de quelques administrateurs avancés voire administrateurs du domaine.
Il est ainsi facile pour un hot-liner de changer le mot de passe de ce fameux compte admin du domaine et de faire ce que bon lui semble….  

L’objet AdminSDHolder est là pour contrôler ce type de phénomène pas forcement prévu et qui peut potentiellement créer une faille de sécurité.

Concrètement de quoi s’agit’il ?
Cet objet est stocké dans la partition Système d’Active Directory et dispose d’une ACL stricte :

Il se manifeste par un processus d’arrière plan qui tourne par défaut toutes les heures sur le DC qui héberge le rôle “PDC Emulator”. Ce processus est en charge de comparer l’ACL de l’objet AdminDSHolder avec celle de tout les comptes appartenant à des “groupes protégés”.
Si l’ACL est différente, elle est écrasée et remplacée par celle de l’objet AdminDSHolder.

Il est important de noter que cette ACL est très restrictive et qu’elle a pour effet secondaire de désactiver l’option d’héritage d’ACL qui proviendrait d’un niveau supérieur.
C’est de cette manière qu’il est possible d’observer que des permissions “sautent” périodiquement sur certains comptes.

Quels sont ces “groupes protégés” ?
Cette liste était composée de 4 groupes en Windows 2000 Server RTM. Elle a peu à peu évoluée jusqu’à en contenir 13 dans Windows 2008 R2 :

Quelle est cette ACL “restrictive” ?
Cette ACL est différente de celle appliquée au domaine.

On note que l’objectif de ce processus est de sécuriser des objets, il est donc normal que l’ACL en question soit plus restrictive qu’une autre. Celle du domaine par exemple.

Ces restrictions se manifestent par :
- L’héritage de permissions désactivé.
- Le propriétaire par défaut est positionné sur le groupe “Admins du domaine” à l’instar de la plupart des objets AD qui sont positionnés sur le groupe “Administrateurs”. Le propriétaire d’un objet est le seul à pouvoir prendre pleinement le contrôle et réinitialiser complètement ses permissions.
- Enfin, les groupes “Admins du domaine”, “Administrateurs” et “Admins de l’entreprise” sont les seuls à pouvoir modifier les attributs de l’objet “AdminDSHolder”. La plupart des objets/attributs AD nécessitent des privilèges moins élevés pour être modifiés.

Est-il possible de modifier la fréquence de détection ?
Par défaut, ce processus s’exécute toute les 60 minutes.
Il est possible de régler ce temps via la clé de registre :

AdminSDProtectFrequency (DWORD) en secondes

Dans le conteneur suivant :

Exemple de commande pour une exécution toutes les 10 minutes :

Est-il possible de modifier son comportement ?

Il est possible de modifier dans une certaines mesure toutefois les groupes protégés par AdminDSHolder. Ceci est possible grâce à une KB pour Windows 2000 et 2003 Server et nativement depuis Windows 2008 toutes versions.

Il est ainsi possible d’exclure du contrôle les groupes suivants :

Account Operators – Server Operators – Print Operators -Backup Operators

Cette information est contenue dans le dernier caractère de l’attribut “dsHeuristic” de la partition de Configuration du domaine. Cet attribut est partagé au sein d’une même forêt.

Ce caractère, codé en Hexadecimal, correspond au tableau suivant :

Une fois la valeur définie, il est possible de procéder à la mise à jour de l’attribut “dsHeuristic”. Suivre le KB817433.

ATTENTION - Ces modifications peuvent avoir des conséquences irrémédiables dans votre Organisation et doivent impérativement être réalisées en plateforme de test au préalable. D'une manière générale, sauf besoin explicite, il n'est pas conseillé de modifier le comportement de ce mécanisme.

Comment savoir si un compte est protégé par AdminSDHolder ?
La méthode la plus fiable pour savoir si un compte est protégé par ce processus est de regarder l’attribut Active Directory  ”adminCount”. Si ce dernier est positionné à “1″, l’objet a été modifié par AdminSDHolder.

La requête PowerShell/LDAP suivante permet de retourner la liste des utilisateurs concernés :

La requête PowerShell/LDAP suivante permet de retourner la liste des groupes concernés :

Qu’est ce que la notion d’objets AdminSDHolder Orphelins ?

Lorsqu’un utilisateur ne fait plus partie d’un groupe protégé, il est important de savoir que l’attribut “adminCount” reste positionné sur la valeur “1″. 

De plus, l’option d’héritage d’ACL parentes qui pouvait être cochée avant, ne sera pas re-cochée. L’objet ne recevra donc plus d’ACL et passera ainsi dans un mode dit “orphaned AdminSDHolder objects”.

Ces objets devront donc, après extraction d’un groupe protégé, être traités manuellement. Un script VB fourni par Microsoft permet d’aider à ré-activer cet héritage sur ces comptes. Suivre la KB817433.

Conclusion

J’espère que ces quelques lignes vous aurons permises de comprendre un peu mieux ce mécanisme de sécurité assez peu connu.
 

Pour aller plus loin :

https://technet.microsoft.com/en-us/magazine/2009.09.sdadminholder.aspx