Triage adminCount ordinateur AD : DC protégés ou hôtes membres

Qu'est-ce que le triage adminCount ordinateur AD ?

Le triage adminCount ordinateur AD consiste à expliquer pourquoi un objet de l'annuaire lié à une machine porte adminCount=1 avant de décider si une modification est nécessaire. Un contrôleur de domaine, un compte de service et un serveur membre ordinaire peuvent figurer dans la même liste de candidats tout en exigeant des décisions très différentes. Le résultat utile est une classification étayée par des preuves d'identité, d'appartenance et de permissions.

La référence du schéma Admin-Count de Microsoft décrit un attribut associé à la protection des ACL à la suite d'une appartenance directe ou transitive à un groupe administratif. Le marqueur seul ne démontre ni privilège actuel, ni chemin d'attaque, ni ACL obsolète. Considérez-le comme une raison d'examiner l'objet, plutôt que comme une instruction d'effacer une valeur.

Ce processus produit une fiche pour chaque SID : protégé, exception justifiée, résidu plausible ou indéterminé. Il complète notre procédure de nettoyage des valeurs adminCount obsolètes des comptes utilisateur, qui demande explicitement de classer séparément les ordinateurs et les groupes. Ses commandes de nettoyage des utilisateurs ne doivent pas devenir une recette de maintenance en masse des machines.

Effets de la protection sur les DC, les RODC et les autres objets

L'annexe C : comptes et groupes protégés de Microsoft inclut Domain Controllers et Read-only Domain Controllers dans la liste protégée. AdminSDHolder fournit les permissions du modèle, et SDProp compare les permissions des objets protégés avec ce modèle. L'héritage est désactivé sur les objets protégés ; déplacer un objet dans une autre OU ne supprime pas sa protection.

Un DC ou RODC vérifié peut donc avoir une explication légitime à sa protection. Établissez son rôle réel et ses appartenances au lieu de traiter chaque marqueur de machine comme un accès administratif accidentel. Pour un poste membre ou un serveur applicatif, examinez les chemins d'appartenance actuels et leur justification métier. Ni le nom d'hôte ni l'emplacement dans une OU ne suffisent à prouver son rôle.

La recherche d'ordinateurs du collecteur compte également : elle utilise (objectClass=computer). À la révision examinée, le parseur reconnaît explicitement msDS-GroupManagedServiceAccount dans cette population. Un gMSA peut donc apparaître comme un constat Computer sans être un hôte ordinaire. Confirmez la classe structurelle renvoyée et le responsable du service ; ne lui accordez pas d'exception générale au seul motif qu'il s'agit d'un compte de service.

L'explication historique d'AdminSDHolder et de SDProp de Microsoft documente les marqueurs résiduels et l'héritage désactivé après qu'un utilisateur quitte une appartenance protégée. Cela explique pourquoi l'hypothèse d'un résidu mérite d'être testée. Cela ne démontre pas qu'un ordinateur particulier est orphelin, et son ancienne liste de groupes protégés ne doit pas remplacer l'annexe C actuelle. Le même article décrit la protection par des groupes de sécurité ou de distribution imbriqués ; l'examen des appartenances doit donc conserver ces chemins.

Détection : recueillir l'identité et des preuves indépendantes de l'annuaire

Commencez par Get-ADComputer, dont les paramètres documentés comprennent -LDAPFilter, -SearchBase, -Server et -Properties. Cette adaptation demande les attributs nécessaires à l'examen des ordinateurs candidats :

Get-ADComputer -LDAPFilter "(adminCount=1)" -SearchBase "DC=corp,DC=example" -Server "dc01.corp.example" -Properties adminCount,memberOf,primaryGroupID,PrimaryGroup,nTSecurityDescriptor,Enabled,SID,ObjectClass,userAccountControl

Cette requête indépendante conserve délibérément les résultats activés et désactivés pour les classer. Le contrôle EtcSec présenté plus bas sélectionne uniquement les entrées Computer activées. Consignez explicitement l'état d'activation lors du rapprochement des deux populations ; une différence de périmètre n'est pas nécessairement une divergence du marqueur.

Utilisez le SID et le DN pour faire correspondre le constat à l'objet de l'annuaire. Conservez également son GUID comme identifiant, sa classe, le domaine et le serveur interrogés, l'heure de capture et les lectures échouées. Gardez les preuves brutes des attributs plutôt qu'une simple liste mise en forme à l'écran. Un résultat vide sur une base de recherche plus étroite ne résout pas un constat collecté ailleurs.

Pour un candidat soupçonné d'être un gMSA, effectuez une lecture du DN exact sans restriction de classe. Get-ADObject documente l'identification par DN et les propriétés supplémentaires :

Get-ADObject -Identity "CN=svcInventory,CN=Managed Service Accounts,DC=corp,DC=example" -Server "dc01.corp.example" -Properties objectClass,objectSid,adminCount,memberOf,primaryGroupID,nTSecurityDescriptor,userAccountControl

Comparez cette identité avec le constat avant de choisir la voie d'examen d'un hôte ou d'un compte de service. L'échec d'une recherche spécifique aux ordinateurs ne doit pas écarter silencieusement un objet renvoyé par le filtre de classe plus large du collecteur.

Remédiation : classer chaque objet avant d'approuver des changements (Remediation)

Étape 1 — Établir la référence des groupes protégés

Résolvez les groupes applicables de l'annexe C dans les domaines concernés et à la racine de la forêt, en consignant leurs SID et DN. Les noms peuvent être renommés ou localisés. La référence des SID de Microsoft explique les identifiants de domaine et les identifiants relatifs ; utilisez des identités de groupe vérifiées plutôt qu'une comparaison fondée uniquement sur les noms.

Get-ADGroup accepte un SID pour -Identity et prend en charge des propriétés supplémentaires. Cette adaptation documentée lit le groupe intégré Administrators dans un contexte de domaine explicite :

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

Répétez l'opération pour les groupes protégés applicables à partir de leurs SID vérifiés. Cet exemple est une recherche unique, pas un inventaire complet des groupes protégés. Distinguez les comptes directement protégés des groupes d'appartenance, et consignez les exceptions pertinentes de configuration du domaine. Un groupe de référence non résolu laisse l'examen incomplet.

Étape 2 — Résoudre les appartenances au-delà de la première vue

Get-ADPrincipalGroupMembership prend en charge les ordinateurs, les groupes et les comptes de service. Le SID d'exemple est une valeur à remplacer par le SID vérifié du candidat :

Get-ADPrincipalGroupMembership -Identity "S-1-5-21-111111111-222222222-333333333-1101" -Server "dc01.corp.example"

Microsoft indique que la recherche de groupes nécessite un catalogue global et que les groupes locaux d'un autre domaine nécessitent le contexte de ressource approprié. Consignez les erreurs non bloquantes comme des échecs de résolution des appartenances, au lieu de considérer une sortie partielle comme un résultat sans anomalie. Interrogez les domaines de ressources concernés lorsque l'objet y possède des appartenances.

Utilisez les groupes renvoyés et les preuves memberOf de l'objet comme points de départ. Pour chaque groupe, lisez ses parents avec Get-ADGroup -Properties memberOf,groupType et poursuivez jusqu'à ce que les chemins se terminent ou atteignent l'ensemble protégé vérifié. Conservez les identités intermédiaires, gérez les cycles et couvrez les domaines concernés. Une seule invocation de cmdlet n'est pas présentée ici comme un parcours transitif complet et validé.

Étape 3 — Résoudre séparément le groupe principal

La référence de protocole primaryGroupID de Microsoft explique que l'appartenance principale est omise de memberOf sur l'objet et de la liste member ordinaire du groupe. La documentation Get-ADComputer montre également PrimaryGroup et primaryGroupID dans sa sortie pour les ordinateurs.

Relisez un ordinateur vérifié et résolvez indépendamment le DN de son groupe principal :

$machine = Get-ADComputer -Identity "CN=APP01,OU=Servers,DC=corp,DC=example" -Server "dc01.corp.example" -Properties PrimaryGroup,primaryGroupID,memberOf,adminCount,nTSecurityDescriptor

Get-ADGroup -Identity $machine.PrimaryGroup -Server "dc01.corp.example" -Properties memberOf,groupType

N'exécutez la seconde lecture que si PrimaryGroup a été résolu avec succès. Si seul le RID est disponible, construisez le SID du groupe principal à partir du SID vérifié du domaine du compte et de ce RID, puis résolvez le SID complet. Ne substituez pas le SID complet de l'ordinateur et ne présumez pas d'un groupe principal attendu d'après le rôle de la machine. Examinez également les chemins des parents du groupe principal. Des preuves manquantes ou contradictoires maintiennent le cas indéterminé.

Étape 4 — Examiner les permissions de l'objet et de son parent

Conservez le descripteur de sécurité et examinez l'héritage, le propriétaire et les ACE explicites. Comparez l'objet à son rôle prévu et à la référence de son parent. La protection des permissions peut être légitime ; inversement, un marqueur familier n'explique pas une autorisation explicite suspecte.

La référence Dsacls de Microsoft documente l'affichage de l'ACL et l'utilisation de /A pour ajouter les informations de propriété et d'audit. Ce sont des opérations de lecture distinctes :

dsacls "\\dc01.corp.example\CN=APP01,OU=Servers,DC=corp,DC=example" /A

dsacls "\\dc01.corp.example\OU=Servers,DC=corp,DC=example" /A

Un échec d'accès signifie que les preuves demandées sont indisponibles. Une capture textuelle est un artefact d'investigation, pas la garantie d'une sauvegarde restaurable. Établissez la méthode de restauration approuvée avant toute maintenance ultérieure des ACL.

Notre examen des droits, de la délégation et des groupes dangereux des objets ordinateur explique la surface d'attaque plus large des machines. Ces expositions exigent leurs propres preuves : adminCount=1 seul n'en démontre aucune. Distinguez l'ACL de l'objet, ses appartenances et les droits qu'il détient ailleurs dans la fiche d'examen.

Étape 5 — Consigner la décision et valider le résultat attendu

Une exception justifiée est une décision métier ; elle ne rend pas un objet protégé non protégé. Un résidu plausible est une classification d'investigation, pas une autorisation de nettoyage. Soumettez toute modification proposée d'appartenance ou d'ACL au responsable de la machine ou du service, avec la référence capturée et les permissions finales attendues.

Après une maintenance approuvée, répétez les lectures d'identité, d'appartenance et d'ACL sur les serveurs consignés. Tenez compte de la réplication de l'annuaire et, lorsque la protection s'applique, observez le résultat SDProp ultérieur selon la planification configurée. Consignez la réussite ou l'échec et testez le comportement d'administration ou de service attendu. N'effacez pas un marqueur de manière répétée pour masquer un résultat inexpliqué.

Comment EtcSec détecte ce cas

À la révision du collecteur 9f698083354a1cb7f625df5cb490a515823c3257, le contrôle COMPUTER_ADMIN_COUNT examiné parcourt les entrées Computer collectées, ignore les entrées désactivées et sélectionne celles dont le booléen AdminCount vaut vrai. Il émet un constat Info avec le nombre sélectionné ; les détails des entités affectées ne sont inclus que si les détails ont été demandés et qu'il existe des candidats.

Le parseur LDAP ne positionne ce booléen à vrai que si la valeur adminCount renvoyée est égale à 1. Une valeur absente ou différente de 1 devient fausse dans cette représentation. Le contrôle n'exclut pas les DC, RODC ou gMSA, ne résout pas les appartenances directes, transitives ou au groupe principal, et n'examine pas les ACL. Il fournit donc des candidats à classer plutôt qu'un verdict de protection obsolète ou de privilège dangereux.

Le fournisseur d'ordinateurs ne demande ni primaryGroupID ni nTSecurityDescriptor dans sa liste d'attributs par défaut. Leur absence de cette collecte ne doit pas être interprétée comme une absence de groupes ou de droits. BaseDN et MaxComputers limitent la population collectée ; une erreur GetComputers arrête la collecte. Le détecteur renvoie tout de même un constat Info avec un compte de zéro lorsqu'aucun candidat n'est sélectionné : la présence du seul type de constat ne prouve donc pas qu'un objet a été trouvé.

Rapprochez le périmètre de l'audit et les identités des candidats des lectures indépendantes ci-dessus. Utilisez la fiche de classification pour expliquer la protection légitime, faire remonter les hôtes non résolus et préserver l'incertitude. Relancer l'audit permet de comparer la liste des candidats dans le périmètre avec cette fiche, mais ne remplace ni la résolution des appartenances ni la validation des permissions.