I. Présentation

Dans ce tutoriel, nous allons étudier le fonctionnement de l'attribut adminCount de l'Active Directory ainsi que l'AdminSDHolder puisque ce sont deux éléments liés. Il s'agit d'une notion importante lorsque l'on s'intéresse à la sécurité de l'Active Directory et à la gestion des comptes à privilèges (utilisateurs, groupes).

Chaque objet "utilisateur" de l'Active Directory contient un ensemble d'attributs, dont celui nommé "adminCount" qui peut être "non défini" (ou "0") ou avoir la valeur "1". Mais, à quoi sert-il ? Qu'est-ce que signifie cette valeur ? Quel est le lien avec l'AdminSDHolder ? C'est ce que nous allons voir dans cet article.

II. AdminSDHolder

Sur chaque domaine Active Directory, le conteneur "System" contient un conteneur nommé "AdminSDHolder". Celui-ci est visible en mode affichage avancé avec la console "Utilisateurs et ordinateurs Active Directory". Ce conteneur spécifique contient une liste de permissions (ACL) qui est le reflet de ce que doivent être les permissions sur les comptes à privilèges du domaine Active Directory.

CN=AdminSDHolder,CN=System,DC=it-connect,DC=local

Ainsi les ACLs définies sur le conteneur "AdminSDHolder" seront définies sur les groupes et utilisateurs à privilèges de votre domaine Active Directory, tel un modèle. Il s'agit d'ACLs restrictives qui vont notamment éliminer la notion d'héritage (ce qui est très important quand il s'agit de protéger les objets avec des privilèges élevés).

L'Active Directory, par l'intermédiaire du contrôleur de domaine qui dispose du rôle FSMO "Emulateur PDC" va redéfinir les permissions sur tous les comptes à privilèges de façon automatique, toutes les 60 minutes. L'objectif est de s'assurer que les permissions des comptes à privilèges ne soient pas altérées (notamment par une délégation mal placée). Ce processus s'appelle SDProp (Security Descriptor Propagator).

Note : même si ce n'est pas recommandé (attention à la surcharge du serveur, notamment le CPU), il est possible d'exécuter le processus SDProp plus ou moins fréquemment. En effet, bien que ce soit 60 minutes par défaut, la valeur peut être comprise entre 60 secondes et 7200 secondes, soit deux heures. Cette modification s'effectue dans le Registre avec la valeur DWORD "AdminSDProtectFrequency" dans "HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\NTDS\Parameters".

Désormais, nous allons voir en quoi le conteneur AdminSDHolder est lié à l'attribut adminCount.

III. adminCount = 1, quelle est la signification ?

Dans mon annuaire Active Directory, si je regarde la valeur de l'attribut "adminCount" sur un compte administrateur et un compte utilisateur standard, je peux constater une valeur différente.

• Sur le compte "Administrateur", adminCount est égal à 1
• Sur le compte "Utilisateur", adminCount est "<non défini>"

L'attribut "adminCount" sert de repère pour le processus SDProp évoqué précédemment : si l'attribut "adminCount = 1" sur un objet, alors les permissions de l'AdminSDHolder doivent être répliquées. Autrement dit, cet objet est protégé par le processus de propagation des ACLs "AdminSDHolder". À l'inverse, si la valeur est sur "non défini" ou sur "0" alors l'objet n'est pas protégé.

En PowerShell, on peut lister tous les objets pour lesquels "adminCount = 1" avec cette commande (à exécuter dans chaque domaine d'une forêt) :

Get-ADObject -LDAPFilter "(adminCount=1)"

Ce qui donne la liste ci-dessous sur mon environnement de test, où l'on peut voir des utilisateurs et des groupes. On retrouve des objets natifs intégrés à l'AD et que l'on retrouve dans les conteneurs "Users" et "Builtin" : Admins du domaine, Administrateurs, Contrôleurs de domaine, Administrateurs clés, etc. Ainsi que deux utilisateurs natifs : Administrateur et krbtgt.

Puisqu'il y a une notion de groupes protégés par l'AdminSDHolder, cela implique qu'un utilisateur membre d'un groupe protégé sera aussi protégé. Partons de ce constat, on peut affirmer que le processus SDProp définit "adminCount = 1" sur les comptes ajoutés aux groupes avec des privilèges élevés comme "Admins du domaine". Ce n'est pas l'administrateur système qui doit configurer "adminCount = 1", c'est le processus SDProp qui s'en charge.

• Microsoft Learn - adminCount

IV. La persistance de adminCount = 1

Lorsqu'un compte utilisateur devient membre d'un groupe à privilèges, l'attribut adminCount est défini sur la valeur "1" par le processus SDProp. Mais, que se passe-t-il si ce compte redevient un utilisateur standard et qu'il n'est plus membre du groupe en question, par exemple "Admins du domaine" ? Dans ce cas, adminCount sera toujours égal à 1 !

En soi, ce n'est pas une mauvaise nouvelle, mais plutôt une bonne nouvelle pour la traçabilité ! En effet, si un compte à l'attribut "adminCount = 1", cela signifie qu'il a été un moment donné associé à un groupe donnant des privilèges élevés. Le compte utilisateur en question a pu être membre du groupe Admins du domaine même s'il ne l'est plus maintenant !

Pendant cette période, une personne a pu utiliser ce compte pour se créer un autre compte Administrateur sur le domaine, pour se donner des droits d'administration sur un serveur, etc... Potentiellement, ce compte est à l'origine d'activités suspectes !

Que faire lorsque ce scénario se produit ? La préconisation de Microsoft est "simple" : il faut supprimer le compte, et le recréer s'il y a besoin de continuer à l'utiliser. Le nouveau compte, même s'il a le même nom, va bénéficier d'un nouveau SID unique. En fait, on considère que l'on a perdu le contrôle de ce compte et on ne sait pas exactement sur quelles applications ou quels serveurs il pourrait avoir des droits, au-delà de ce qui est visible dans l'annuaire. Toutefois, dans la pratique, ce n'est pas si simple de supprimer le compte pour le recréer, même si c'est l'idéal. Tout dépend quel est le compte en question...

Si, malgré tout, vous souhaitez définir l'attribut adminCount à 0, car vous êtes sûr que ce compte n'a pas été utilisé pour effectuer d'autres actions, sachez que ce n'est pas si simple. Vous ne devez pas seulement changer la valeur de l'attribut, car le processus "AdminSDHolder" est déjà passé sur le compte pour configurer ces ACLs (et désactiver l'héritage). Au-delà de définir "adminCount = 0" (ou plutôt en "<non défini>"), vous devez aussi redéfinir les ACLs de ce compte (activer l'héritage).

V. Conclusion

Le mécanisme associé au conteneur AdminSDHolder est très important pour protéger les objets donnant des privilèges élevés et pour lutter contre les erreurs ou les actes malveillants liés à la délégation de contrôle Active Directory.

Par exemple, un utilisateur se retrouve avec des droits sur un compte administrateur, telle que la possibilité de réinitialiser le mot de passe, à cause d'une délégation de contrôle mal configurée. Potentiellement, ce compte peut devenir administrateur du domaine puisqu'il est en mesure de prendre le contrôle du compte sur lequel il a les droits (en changeant le mot de passe). Grâce au processus SDProp, les droits seront "réinitialisés" et les permissions ajoutées (par erreur ou par un attaquant) seront supprimées (sous une heure maximum).

Même si je pense que c'est moins évident, si un attaquant parvient à ajouter un compte compromis à la liste des ACL du conteneur "AdminSDHolder", alors il peut prendre le contrôle de votre domaine Active Directory. On peut affirmer qu'il s'agisse d'une technique de persistance (ou de porte dérobée) au niveau d'un annuaire AD.

Sur un annuaire Active Directory qui a plusieurs années et où il y a eu beaucoup de mouvements, et peut-être même plusieurs prestataires, il est fort possible de retrouver de nombreux comptes avec l'attribut "adminCount = 1".

À vous de jouer !

The post Sécurité Active Directory : le principe d’AdminSDHolder et l’attribut adminCount first appeared on IT-Connect.