Nettoyer adminCount Active Directory : une procédure sûre

Nettoyer adminCount Active Directory : ce que vous corrigez

L’objectif opérationnel de nettoyer adminCount Active Directory est de supprimer un marqueur administratif résiduel et de rétablir l’héritage des autorisations prévu sur les comptes qui ont réellement quitté les groupes protégés. Il s’agit d’une maintenance courante après un changement de rôle ou un départ. Notre guide des portes dérobées AdminSDHolder et SDProp traite d’un autre scénario : une ACE non autorisée sur le modèle peut se propager aux objets protégés. Ici, la décision part des appartenances actuelles et de l’ACL du compte, sans présumer l’intervention d’un attaquant.

Vérifier les imbrications, effacer le marqueur et activer l’héritage ne constituent qu’une partie de cette procédure. Un dossier de maintenance sûr doit identifier les groupes protégés par leur SID, résoudre séparément le groupe primaire, examiner l’OU parente, approuver chaque compte individuellement et vérifier le résultat après un cycle SDProp ultérieur. Un inventaire adminCount=1 plus réduit est utile, mais ne démontre pas que les autorisations effectives sont correctes.

Fonctionnement de SDProp et persistance du marqueur

AdminSDHolder fournit les autorisations modèles des objets protégés. SDProp compare leurs autorisations à ce modèle sur l’émulateur PDC (PDCE) de chaque domaine, toutes les 60 minutes par défaut, et réinitialise les différences. L’héritage est désactivé sur les objets protégés ; les déplacer dans une autre OU ne supprime pas leur protection. Microsoft le documente dans l’annexe C : comptes et groupes protégés. La spécification du protocole AdminSDHolder explique la protection périodique des descripteurs de sécurité.

La référence de schéma Admin-Count de Microsoft décrit cet attribut comme la trace d’une ACL renforcée après une appartenance administrative directe ou transitive. Il ne constitue pas un inventaire complet des privilèges actuels. L’article historique de Microsoft sur AdminSDHolder et SDProp explique qu’après la suppression des appartenances protégées, adminCount=1 et l’héritage désactivé subsistent. L’ancien membre cesse de recevoir l’ACL du modèle, mais reste privé de l’héritage du parent.

Utilisez la liste actuelle de l’annexe C plutôt que l’ancienne liste de l’article historique :

Administrator et Krbtgt sont des comptes, pas des groupes d’appartenance. Consignez toute configuration de domaine ou exception de forêt applicable ; ne modifiez pas dSHeuristics pour simplifier le nettoyage. Le groupe Protected Users est un contrôle d’authentification distinct ; il n’est pas lui-même protégé par AdminSDHolder.

Piège 1 : un retrait direct laisse subsister un chemin imbriqué

L’article historique de Microsoft décrit la protection transitive, y compris les chemins passant par des groupes de distribution. Un utilisateur retiré de Domain Admins peut encore atteindre un groupe protégé par l’intermédiaire d’un autre groupe. Si ce chemin subsiste, effacer un attribut ne supprime pas la protection et SDProp peut annuler l’activation de l’héritage. Ne promettez pas que le seul effacement du marqueur entraîne nécessairement sa réapplication au prochain cycle à un instant précis ; la conclusion étayée est que l’appartenance restante rend toujours l’objet protégé.

Piège 2 : le marqueur disparaît, mais l’ACL reste incorrecte

Pour un ancien membre confirmé, effacer adminCount laisse l’héritage inchangé. La délégation sur l’OU parente peut donc toujours ne pas s’appliquer au compte. Cela ne prouve pas que l’ACL existante du compte est plus permissive : elle peut au contraire manquer des droits de gestion prévus. À l’inverse, activer l’héritage sous une OU excessivement déléguée peut ajouter des autorisations indésirables. Les ACE explicites nécessitent aussi leur propre examen ; activer l’héritage ne les supprime pas en soi.

Détection : constituer un inventaire des candidats

Commencez par un inventaire en lecture seule. Get-ADObject documente -LDAPFilter, -Properties et -Server ; cette adaptation demande le marqueur et l’état nécessaires à l’investigation :

Get-ADObject -LDAPFilter "(adminCount=1)" -Properties adminCount,memberOf,objectSid,primaryGroupID,nTSecurityDescriptor -Server "dc-pdce.corp.example"

Les résultats peuvent inclure des groupes et des ordinateurs. Classez-les séparément au lieu d’appliquer la procédure des comptes utilisateurs à chaque objet retourné. Pour la population d’utilisateurs couverte par les deux contrôles EtcSec, utilisez les paramètres Get-ADUser documentés :

Get-ADUser -LDAPFilter "(adminCount=1)" -Properties adminCount,memberOf,Enabled,SID,primaryGroupID -Server "dc-pdce.corp.example"

Une valeur memberOf vide ou apparemment ordinaire est une piste d’investigation, pas la preuve d’un compte orphelin. La page de schéma MemberOf décrit les DN des groupes ; cette propriété seule ne fournit pas l’analyse complète de la protection requise ci-dessous.

Cette procédure détecte un état de l’annuaire par des requêtes et un examen des ACL. Elle n’exige pas d’identifiant d’événement inventé et ne considère pas un retrait historique d’un groupe comme la preuve que le compte peut actuellement être modifié sans risque.

Remédiation : vérifier, puis modifier un compte (Remediation)

Étape 1 — Préserver l’état du compte et de son parent

Pour chaque candidat, consignez son DN, son SID, son état activé, ses groupes directs, le RID de son groupe primaire, son responsable métier, son ACL complète et son état d’héritage. Consignez le DC et l’heure de capture. Gardez une méthode approuvée de restauration des ACL disponible ; enregistrer une sortie texte fournit une preuve utile, mais ne permet pas de revendiquer une sauvegarde AD restaurable.

La référence Microsoft Dsacls documente l’affichage des entrées d’accès sans les modifier. La sortie par défaut omet les informations de propriétaire et d’audit ; /A inclut ces détails lors de la collecte du dossier de sécurité complet. Exécutez chaque lecture séparément :

dsacls "\\dc-pdce.corp.example\CN=FormerAdmin,OU=Staff,DC=corp,DC=example"

dsacls "\\dc-pdce.corp.example\OU=Staff,DC=corp,DC=example"

Examinez le parent avant d’autoriser l’héritage. Identifiez les droits hérités qui doivent apparaître et les ACE explicites du compte qui doivent être conservées ou examinées séparément. Une ACL suspecte fait passer le compte en investigation, au lieu de déclencher un nettoyage automatique.

Étape 2 — Résoudre les groupes protégés par SID

Utilisez la référence SID de Microsoft pour distinguer l’identifiant de domaine du RID. Résolvez chaque groupe protégé dans le domaine concerné ; les groupes de forêt nécessitent une couverture appropriée du domaine racine de la forêt. Les noms de groupes renommés ou localisés ne suffisent pas à vérifier leur identité.

Get-ADGroup accepte un SID pour -Identity. Le SID propre au domaine ci-dessous est une valeur illustrative, pas un groupe découvert. Le SID du groupe intégré Administrators est également présenté, avec un serveur explicite pour établir le contexte du domaine :

Get-ADGroup -Identity "S-1-5-21-111111111-222222222-333333333-512" -Properties memberOf,groupType -Server "dc-pdce.corp.example"

Get-ADGroup -Identity "S-1-5-32-544" -Properties memberOf,groupType -Server "dc-pdce.corp.example"

Documentez le SID et le DN résolus pour chaque entrée de la liste protégée. Un échec de recherche laisse une lacune de couverture. Il n’équivaut pas à confirmer que le groupe ne contient aucun membre pertinent.

Étape 3 — Vérifier les appartenances récursives et le groupe primaire

La documentation Get-ADGroupMember inclut un exemple d’appartenance récursive. Adaptez-le à chaque SID de groupe protégé vérifié et comparez les SID des utilisateurs retournés à celui du candidat :

Get-ADGroupMember -Identity "S-1-5-21-111111111-222222222-333333333-512" -Recursive -Server "dc-pdce.corp.example"

Répétez cette vérification sur toute la liste protégée et les domaines concernés. Incluez les chemins passant par des groupes de distribution. -Recursive retourne les membres de la hiérarchie sans objets enfants ; il ne fournit pas une liste complète des relations intermédiaires entre groupes. Microsoft documente aussi une limitation pour une autre forêt lorsqu’elle ne dispose pas d’Active Directory Web Service. Une énumération échouée ou incomplète doit laisser le verdict indéterminé.

Vérifiez séparément le groupe primaire. La référence Primary-Group-ID de Microsoft définit cette valeur comme le RID du groupe primaire de l’utilisateur. La référence de protocole primaryGroupID confirme que memberOf de l’utilisateur et l’attribut member du groupe primaire omettent cette appartenance. Le collecteur examiné construit le SID du groupe primaire à partir du SID de domaine et de ce RID. Résolvez ce SID complet avec Get-ADGroup ; ne déduisez pas la réponse d’un nom de groupe lisible.

Déterminez ensuite si le groupe primaire est directement protégé ou atteint un groupe protégé par imbrication. Cette adaptation documentée de Get-ADGroup lit l’ensemble suivant de parents :

Get-ADGroup -Identity "CN=PrimaryGroup,OU=Groups,DC=corp,DC=example" -Properties memberOf -Server "dc-pdce.corp.example"

Continuez à examiner chaque parent avec gestion des cycles et couverture des domaines concernés. L’exemple représente une seule lecture, pas un programme de parcours complet et validé. L’absence d’un candidat dans la sortie des membres récursifs ne dispense pas de vérifier le groupe primaire. Des membres étrangers non résolus, des domaines non interrogés ou des cycles non résolus empêchent l’approbation d’une écriture.

Étape 4 — Consigner la décision avant toute écriture

Les comptes intégrés Administrator et Krbtgt restent protégés même sans appartenance directe explicative. Le collecteur examiné les identifie par les RID 500 et 502, y compris après renommage. Un compte désactivé qui reste protégé appartient à la première ligne, pas à celle des orphelins. Pour un orphelin désactivé confirmé, choisissez entre maintenance et retrait selon la politique de conservation ; cette procédure ne le réactive pas automatiquement.

Étape 5 — Effacer uniquement l’attribut résiduel confirmé

Set-ADObject documente -Clear avec le nom d’affichage LDAP, ainsi que -WhatIf et -Confirm. Commencez par prévisualiser la modification individuelle :

Set-ADObject -Identity "CN=FormerAdmin,OU=Staff,DC=corp,DC=example" -Clear adminCount -Server "dc-pdce.corp.example" -WhatIf

Seulement après la décision et l’examen, exécutez l’écriture confirmée distincte :

Set-ADObject -Identity "CN=FormerAdmin,OU=Staff,DC=corp,DC=example" -Clear adminCount -Server "dc-pdce.corp.example" -Confirm

-Clear supprime la valeur ; il n’écrit pas le nombre zéro. La commande ne supprime pas d’appartenance, ne modifie pas les ACE explicites et n’active pas l’héritage. Une prévisualisation réussie ne dit pas non plus si le candidat est réellement orphelin.

Étape 6 — Activer l’héritage et examiner l’ACL résultante

La référence Dsacls définit /P:N comme l’autorisation donnée à l’objet d’hériter des autorisations du parent. Appliquez-le uniquement à l’objet approuvé, après l’examen du parent :

dsacls "\\dc-pdce.corp.example\CN=FormerAdmin,OU=Staff,DC=corp,DC=example" /P:N

Vérifiez le résultat d’exécution et répétez immédiatement la lecture de l’ACL de l’étape 1. Comparez les droits hérités à la référence approuvée du parent et examinez indépendamment les entrées explicites. /P:N modifie la protection de l’objet contre l’héritage ; il ne modifie pas la capacité d’une ACE à être héritée. Ne lui substituez pas /S ou /S /T : /S restaure la sécurité par défaut du schéma de l’objet, et /T étend cette restauration à l’arborescence uniquement lorsqu’il est utilisé avec /S.

Validation après le prochain cycle SDProp

Relisez le compte sur le serveur consigné, avec les paramètres Get-ADUser documentés ci-dessus :

Get-ADUser -Identity "CN=FormerAdmin,OU=Staff,DC=corp,DC=example" -Properties adminCount,memberOf,primaryGroupID,Enabled -Server "dc-pdce.corp.example"

Lisez séparément son ACL :

dsacls "\\dc-pdce.corp.example\CN=FormerAdmin,OU=Staff,DC=corp,DC=example"

Répétez également la résolution des appartenances : elles peuvent changer entre l’inventaire et la maintenance. Attendez un passage SDProp ultérieur selon l’intervalle réellement configuré et tenez compte de la réplication avant de comparer les DC. Consignez l’heure et les serveurs du contrôle, l’absence du marqueur résiduel, l’héritage attendu, l’examen des ACE explicites et un test réel de la délégation prévue. N’affirmez « validé après le cycle » que lorsque cette observation existe.

Si la protection revient, examinez un chemin de groupe restant, un ajout récent ou une collecte incomplète. Effacer l’attribut de façon répétée ne résout pas le problème. L’annexe C de Microsoft fournit une méthode facultative de laboratoire utilisant Ldp.exe sur le PDCE avec le rootDSE RunProtectAdminGroupsTask=1. Privilégiez le cycle normal pour cette maintenance en production et laissez sa fréquence inchangée. L’opération FixUpInheritance de l’article historique ne doit pas être substituée automatiquement à cette tâche.

Notre guide de la dérive des accès privilégiés explique pourquoi les exceptions de groupes et d’ACL nécessitent des responsables et une revalidation par rapport aux droits effectifs. Appliquez ce principe ici : nettoyer le marqueur avec succès constitue un résultat de maintenance, tandis que prouver que les autorisations du compte correspondent à son rôle prévu nécessite l’examen plus large des droits.

Comment EtcSec détecte cette situation

Les deux contrôles etc-collector examinés partagent le même prédicat d’orphelin fondé sur l’appartenance directe ou primaire, appliqué à des populations de comptes différentes :

Les blocs de sélection normalisés diffèrent uniquement par if u.Disabled contre if !u.Disabled ; les titres, la sévérité et les recommandations diffèrent aussi. Ce sont deux branches du même contrôle selon l’état du compte, pas des mécanismes indépendants à additionner comme preuve d’un risque accru.

Les appartenances imbriquées ne sont pas résolues. Aucun des deux contrôles ne développe un groupe imbriqué dans un groupe protégé, y compris un groupe primaire lui-même imbriqué. Ces comptes peuvent encore être protégés et produire un faux candidat orphelin. La fonction auxiliaire résout les DN des groupes protégés à partir des suffixes de SID dans l’index collecté, puis compare les DN directs ; des données de groupes ou de SID manquantes peuvent aussi laisser un candidat inexpliqué.

Aucune des méthodes Detect() ne lit l’ACL du compte ni son état d’héritage. Un résultat ne démontre donc pas des droits résiduels dangereux, ne prouve pas l’absence de protection SDProp et n’autorise pas l’effacement de l’attribut. Confirmez-le par la procédure d’appartenances et d’ACL avant toute modification. Après la maintenance et la validation dans l’annuaire, relancez l’audit pour comparer les résultats candidats au résultat consigné.