Utilisation de l’attribut AdminCount pour trouver des comptes à privilèges

Les comptes Active Directory qui disposent de privilèges élevés présentent un risque majeur pour la sécurité : ils sont les cibles préférées des attaquants, car ils permettent d’obtenir un accès administrateur aux systèmes et aux données, et leurs propriétaires peuvent également en faire une utilisation malveillante, que ce soit de manière délibérée ou accidentelle. Il est donc essentiel pour les équipes informatiques d’effectuer un suivi strict des comptes qui disposent d’autorisations élevées.

Sélection de contenu connexe :

[Guide gratuit] Meilleures pratiques de gestion des accès privilégiés

Contrôler la valeur de l’attribut AdminCount constitue l’une des méthodes les plus courantes. Tous les objets Utilisateur, Groupe ou Ordinateur de l’Active Directory ont cet attribut. Par défaut, il affiche la valeur « <NOT SET> » (non défini). Cependant, lorsque l’objet est ajouté à certains groupes protégés (de manière directe ou transitive), sa valeur est mise à jour : elle est définie sur « 1 ». En conséquence, vérifier la valeur de cet attribut s’avère une stratégie efficace pour détecter les objets disposant de privilèges d’administrateur.

Ce n’est néanmoins pas aussi simple. Examinons plus en détail le fonctionnement de l’attribut AdminCount et découvrons ses limites en ce qui concerne le suivi des utilisateurs privilégiés.

L’attribut AdminCount et les objets protégés

Le tableau suivant dresse une liste de l’ensemble par défaut de comptes et de groupes protégés dans l’Active Directory, notamment les groupes susceptibles de provoquer une mise à jour de l’attribut AdminCount pour ses membres :

Vous aurez sans doute remarqué que je reste prudent : « susceptibles de provoquer une mise à jour de l’attribut AdminCount ». La raison est qu’il existe, dans un ensemble d’objets protégés, un grand nombre de variables qui peuvent avoir un impact sur l’appartenance à un groupe. Voici quelques explications :

1. L’ensemble par défaut de comptes et de groupes protégés varie en fonction du niveau fonctionnel Active Directory. Résultat : il existe des différences dans les groupes qui peuvent provoquer une mise à jour de l’attribut AdminCount pour leurs membres.
2. L’ensemble par défaut de comptes et de groupes protégés comprend quatre groupes qui peuvent être exclus manuellement de toute protection : les groupes Opérateurs de compte, Opérateurs de sauvegarde, Opérateurs d’impression et Opérateurs de serveur. Un correctif a introduit ce comportement pour Windows Server 2000 et Windows Server 2003, et a été conservé dans les versions suivantes (ce qui peut expliquer la relative complexité du processus). Le mécanisme qui permet de le contrôler se trouve dans l’attribut dsHeuristics de l’objet CN=Directory Service,CN=Windows NT,CN=Services,<FOREST ROOT DN>. L’attribut dsHeuristics est une chaîne Unicode dont chaque caractère contient une valeur pour un paramètre de configuration au niveau d’une forêt. En ce qui concerne cet article, le 16e caractère est celui qui nous intéresse : s’il existe, il représente le paramètre « dwAdminSDExMask ». Sa valeur se présente sous la forme d’un caractère hexadécimal, mais pour comprendre un peu plus facilement son comportement, il faut jeter un coup d’œil à son équivalent binaire. Chaque bit de la représentation binaire indique un groupe spécifique. Si le bit assigné à un groupe particulier ne prend pas la valeur 0, ce groupe sera exclu de l’ensemble d’objets protégés.

L’ensemble par défaut de comptes et de groupes protégés comprend deux objets : l’objet Administrateur et l’objet krbtgt. Ils sont tous les deux protégés, mais ne peuvent pas déclencher de mise à jour de l’attribut AdminCount sur d’autres objets, car un utilisateur, un groupe ou un ordinateur ne peuvent pas être membres d’un objet utilisateur.
L’ensemble par défaut de comptes et de groupes protégés comprend deux groupes qui n’accordent pas à leurs membres la protection dont ils disposent : les contrôleurs de domaine et les contrôleurs de domaine en lecture seule. Même si la commande DCPROMO ajoute l’objet Ordinateur associé à un contrôleur de domaine au groupe de contrôleur de domaine adéquat lorsqu’un hôte est promu au rang de contrôleur de domaine, l’objet ne sera pas ajouté à l’ensemble d’objets protégés.
Les membres de l’ensemble par défaut de comptes et de groupes protégés sont identifiés grâce à leur attribut ObjectSID. Bien qu’un grand nombre d’entre eux soient configurés à l’aide d’un indicateur système qui empêche leur renommage ou leur déplacement, l’Active Directory est basé sur les valeurs de l’attribut objectSID qui permet d’identifier ces objets correctement et systématiquement.

Pour faire simple, il existe un grand nombre de comportements qui ne facilitent pas la tâche pour comprendre quels groupes appartenant à un domaine spécifique peuvent provoquer une mise à jour de l’attribut AdminCount.

AdminSDHolder et SDPROP

Intéressons-nous maintenant au mécanisme de contrôle du comportement de l’attribut AdminCount.

L’objet AdminSDHolder

Chaque objet AD comprend un descripteur de sécurité qui contient des informations sur son propriétaire, son groupe principal, les utilisateurs et les groupes autorisés ou non à y accéder (liste de contrôle d’accès discrétionnaire ou DACL), ainsi que les événements vérifiables qui permettent de créer une entrée dans le journal des événements de sécurité (liste de contrôle d’accès système ou SACL). Des bits de contrôle sont également inclus et peuvent modifier le comportement du descripteur de sécurité.

Afin de renforcer la sécurité des objets disposant de privilèges administratifs, l’Active Directory applique un descripteur de sécurité restreinte spécifique (Authoritative Security Descriptor) à tous les membres d’un ensemble d’objets protégés d’un domaine particulier. Ce descripteur de sécurité est défini dans l’objet AdminSDHolder qui se trouve dans le conteneur système de chaque contexte de nommage par défaut du domaine Active Directory (par ex., CN=AdminSDHolder,CN=System,<DOMAIN DN>).

Le descripteur de sécurité restreinte permet de sécuriser les objets protégés en :

Limitant la DACL d’un objet à un ensemble restreint d’entrées de contrôle d’accès (ACE). Seuls les comptes NT AUTHORITY\System ainsi que les membres des groupes Administrateurs, Administrateurs de domaine et Administrateurs de l’entreprise sont autorisés à modifier les objets protégés.

Activant les bits de contrôle du descripteur de sécurité de l’objet SE_DACL_PROTECTED. Les objets parents d’un objet protégé contiennent des ACE héritables qui peuvent modifier sa DACL : les bits de contrôle permettent de désactiver l’héritage de sécurité ainsi que toute modification de la DACL d’un objet protégé.

En limitant la propriété d’un objet protégé au groupe Administrateurs de domaine. Il est ainsi pratiquement impossible pour un compte d’utilisateur sans privilège de contrôler un objet protégé, ce qui lui permettrait de modifier ses autorisations et d’en prendre le contrôle total.

Pour appliquer ce comportement, il est nécessaire que l’Active Directory puisse vérifier que le descripteur de sécurité de chaque membre d’un ensemble d’objets protégés corresponde au descripteur de sécurité restreinte, et que cette correspondance soit conservée dans le temps. L’Active Directory doit également veiller à ce que le descripteur de sécurité restreinte soit appliqué aux objets lorsqu’ils deviennent membres de l’ensemble par défaut de comptes et de groupes protégés (de manière directe ou transitive).

Tâche de propagation du descripteur de sécurité (SDProp)

Pour répondre à ces exigences, l’Active Directory utilise le processus appelé SDProp (propagateur de descripteurs de sécurité). Par défaut, le service LSASS (Local Security Authority Subsystem Service) exécute cette tâche toutes les 60 minutes sur les contrôleurs de domaine qui hébergent le rôle FSMO d’émulateur PDC. Cet intervalle de temps permet de limiter la durée pendant laquelle une modification, malveillante ou accidentelle, du descripteur de sécurité d’un objet peut être conservée. Il prend également en compte les capacités de calcul plutôt élevées que requiert l’exécution du processus SDProp.

(La période d’exécution par défaut du processus SDProp peut être remplacée au niveau du domaine en ajoutant l’entrée AdminSDProtectFrequency à la clé de registre HKEY_LOCAL_MACHINESYSTEMCurrentControlSetServicesNTDSParameters sur le contrôleur de domaine qui héberge le rôle FSMO d’émulateur PDC du domaine. La valeur de l’entrée de registre AdminSDProtectFrequency peut être comprise entre 60 secondes et 7200 secondes. Toutefois, il n’est pas recommandé de remplacer la valeur par défaut. D’un côté, augmenter la fréquence d’exécution est susceptible de provoquer une augmentation de l’utilisation du processeur et de la charge de l’émulateur PDC. De l’autre, la diminuer allonge la période pendant laquelle une modification du descripteur de sécurité d’un objet protégé peut être conservée.)

Lorsque le processus SDProp est en cours d’exécution, il identifie l’ensemble par défaut de comptes et de groupes protégés du domaine et parcourt ensuite de manière récursive l’arborescence de tous les objets protégés pour identifier leurs appartenances. Le processus SDProp compare le descripteur de sécurité de chaque objet à celui de l’objet AdminSDHolder : si les valeurs ne correspondent pas, les autorisations du compte ou du groupe protégé sont remplacées par celles de l’objet AdminSDHolder, et la valeur de l’attribut AdminCount est définie sur 1.

La création d’une tâche dédiée pour effectuer ces vérifications peut sembler inutile, mais elle n’est en réalité pas vraiment configurée pour contrôler ce comportement. Lorsque le descripteur de sécurité d’un objet ou son nom unique est mis à jour, l’Active Directory applique presque immédiatement toute modification de la liste de contrôle d’accès héritable associée (à moins que le nouveau parent de l’objet et le conteneur Objets supprimés du domaine ne deviennent identiques en raison du changement de nom unique). En revanche, les modifications d’appartenance aux groupes ne déclenchent pas ce processus. Cela signifie que l’ajout d’un objet à un groupe protégé ne déclenche donc pas ce processus et que le descripteur de sécurité de l’objet AdminSDHolder ne peut pas être appliqué aux objets concernés par la mise à jour de l’appartenance aux groupes.

Limitations de l’attribut AdminCount

Examinons les principales limitations de l’attribut AdminCount et les malentendus qu’elles peuvent engendrer.

L’exécution du processus SDProp est planifiée.

Comme nous l’avons vu plus haut, la tâche SDProp est programmée pour être exécutée chaque heure. Par conséquent, il faut parfois jusqu’à une heure pour que SDProp détecte un compte ajouté à un groupe protégé et l’identifie comme membre de l’ensemble de comptes et de groupes protégés. Il est donc possible d’ajouter un objet à un compte ou un groupe protégé (de manière directe ou transitive) et de supprimer cette appartenance avant que le processus SDProp ne soit exécuté : l’objet en question ne sera pas reconnu comme un objet protégé et la valeur de son attribut AdminCount restera la même.

Le processus SDProp met à jour l’attribut AdminCount lorsqu’il modifie le descripteur de sécurité d’un objet.

Quel est le problème ? SDProp n’accorde pas d’importance à la valeur de l’attribut AdminCount d’un objet. S’il met à jour le descripteur de sécurité d’un objet protégé, la valeur de cet attribut sera définie sur 1. Si le descripteur de sécurité de l’objet protégé correspond à celui de l’objet AdminSDHolder, le processus SDProp laissera l’attribut AdminCount de l’objet protégé inchangé, peu importe sa valeur. En conséquence, changer ou supprimer la valeur de l’attribut AdminCount d’un objet protégé peut en réalité masquer les objets protégés lors d’un simple reporting.

Le processus SDProp analyse uniquement les membres actifs de l’ensemble de comptes et de groupes protégés.

SDProp commence par analyser les membres de l’ensemble par défaut de comptes et de groupes protégés et répète ensuite ce comportement en analysant leurs appartenances. Toutefois, SDProp ignore les objets hautement privilégiés qui ne sont pas membres de l’ensemble par défaut de comptes et de groupes protégés et la valeur de leur attribut AdminCount demeure <NON DÉFINI>. Résultat : on ne peut pas s’appuyer sur l’attribut AdminCount pour identifier tous les objets hautement privilégiés d’un domaine.

Par ailleurs, une fois qu’un objet protégé n’appartient plus aux groupes dont il a hérité le statut « protégé », il est ignoré ultérieurement par le processus SDProp tout en continuant à ressembler parfaitement à un objet protégé. Pourquoi ? Parce qu’Active Directory ne dispose pas d’un mécanisme lui permettant d’annuler les modifications apportées par SDProp lorsqu’un objet devient membre de l’ensemble de comptes et de groupes protégés : la valeur de son attribut AdminCount reste définie sur 1 (ou toute autre valeur antérieure au changement d’appartenance aux groupes). Plus important encore, le descripteur de sécurité de l’objet en question demeure également inchangé et continue de bloquer l’héritage de sécurité des objets parents.

Le processus SDProp ne fait pas de distinction entre les différents types de groupes.

Il existe deux types de groupes Active Directory : les groupes de sécurité et les groupes de distribution. Les membres d’un groupe de sécurité héritent de ses privilèges, contrairement à ceux d’un groupe de distribution. Même s’il peut sembler étrange de protéger, à l’aide d’un groupe de distribution (les privilèges ne sont donc pas hérités), des objets dont l’appartenance à l’ensemble par défaut de comptes et de groupes protégés est transitive, la catégorie d’un groupe, elle, peut être modifiée. La possibilité d’accorder des privilèges aux membres d’un groupe peut se voir affectée lorsque le type de groupe est modifié. Pour empêcher tout usage malveillant de ce comportement, le processus SDProp ignore donc complètement les catégories de groupe.

Résumé

Au bout du compte, l’attribut AdminCount est juste un indicateur. Pour comprendre de quelle manière il peut vous aider, il est également nécessaire de connaître ses limitations.

L’exécution de la commande suivante semble retourner une liste des objets protégés par le processus SDProp :

Get-ADObject -LDAPFilter « (adminCount=1) »

En réalité, ce que cette commande retourne est une liste des objets qui ont un attribut AdminCount dont la valeur est définie sur 1.

La seule manière fiable d’identifier avec précision les objets protégés est de reproduire exactement ce que fait le processus SDProp : identifier d’abord l’ensemble par défaut de comptes et de groupes protégés du domaine et parcourir ensuite l’arborescence de tous les objets protégés pour identifier leurs appartenances.

Comment Netwrix peut vous aider ?

Sécurisez votre Active Directory de bout en bout grâce à la solution de Sécurité Active Directory de Netwrix. Elle vous permettra de :

Découvrir les risques de sécurité dans l’Active Directory et d’établir des priorités en matière de mesures d’atténuation.
Renforcer la configuration de la sécurité de votre infrastructure informatique.
Détecter et de contenir rapidement les menaces, y compris les plus avancées, notamment les attaques DCSync et les attaques Golden Ticket (« tickets d’or »).
Réagir instantanément aux menaces connues grâce aux options de réponse automatisée.
Réduire les interruptions de vos activités grâce à la restauration rapide de l’Active Directory.

FAQ

Qu’est-ce que l’attribut AdminCount dans l’Active Directory ?

L’attribut AdminCount permet de voir si les paramètres de la liste de contrôle d’accès (ACL) d’un objet ont été modifiés par le système en raison de son appartenance à l’un des groupes d’administration.

Lorsque je supprime un utilisateur d’un groupe protégé, pourquoi la valeur de l’attribut AdminCount n’est-elle pas définie sur 0 ou « non défini » ?

Très tôt dans le développement de Windows 2000, un sondage d’utilisateurs a révélé qu’ils préféraient supprimer un compte d’utilisateur une fois que ses privilèges élevés avaient été retirés. En effet, le compte en question peut avoir ouvert des portes dérobées de manière explicite avant que ses privilèges ne soient supprimés. Étant donné que le compte sera donc résilié ou désactivé, le contrôleur de domaine ne supprime pas l’attribut AdminCount.