Triage adminCount computer AD: DC protetti o host membri

Che cos'è il triage adminCount computer AD?

Il triage adminCount computer AD è il processo che spiega perché un oggetto della directory legato a una macchina presenta adminCount=1, prima di decidere se sia necessario modificare qualcosa. Un controller di dominio, un account di servizio e un normale server membro possono comparire nello stesso elenco di candidati pur richiedendo decisioni molto diverse. Il risultato utile è una classificazione sostenuta da evidenze di identità, appartenenza e autorizzazioni.

Il riferimento dello schema Admin-Count di Microsoft descrive un attributo associato alla protezione delle ACL in seguito all'appartenenza diretta o transitiva a gruppi amministrativi. Il solo marcatore non dimostra privilegi attuali, un percorso di attacco o un'ACL obsoleta. Consideratelo un motivo per esaminare l'oggetto, anziché un'istruzione per cancellare un valore.

Questo procedimento produce una scheda per ogni SID: protetto, eccezione giustificata, residuo plausibile o indeterminato. Integra il nostro procedimento di pulizia dei valori adminCount obsoleti degli account utente, che chiede esplicitamente di classificare computer e gruppi separatamente. I suoi comandi di pulizia degli utenti non devono diventare una ricetta di manutenzione in massa delle macchine.

Effetti della protezione su DC, RODC e altri oggetti

L'appendice C: account e gruppi protetti di Microsoft include sia Domain Controllers sia Read-only Domain Controllers nell'elenco protetto. AdminSDHolder fornisce le autorizzazioni del modello e SDProp confronta le autorizzazioni degli oggetti protetti con quel modello. Gli oggetti protetti hanno l'ereditarietà disabilitata; spostarne uno in un'altra OU non ne elimina la protezione.

Un DC o RODC verificato può quindi avere una spiegazione legittima della protezione. Accertatene il ruolo effettivo e le appartenenze, anziché trattare ogni marcatore di macchina come un accesso amministrativo accidentale. Per una workstation membro o un server applicativo, esaminate gli attuali percorsi di appartenenza ai gruppi e la loro finalità aziendale. Né il nome host né la posizione in una OU costituiscono evidenze sufficienti del ruolo.

Conta anche la ricerca dei computer del collector: utilizza (objectClass=computer). Alla revisione esaminata, il parser riconosce esplicitamente msDS-GroupManagedServiceAccount all'interno di questa popolazione. Un gMSA può quindi comparire come segnalazione Computer senza essere un normale host. Confermate la classe strutturale restituita e il responsabile del servizio; non concedete un'eccezione generalizzata solo perché si tratta di un account di servizio.

La spiegazione storica di AdminSDHolder e SDProp di Microsoft documenta marcatori residui ed ereditarietà disabilitata dopo che un utente lascia un'appartenenza protetta. Questo spiega perché il residuo sia un'ipotesi da verificare. Non dimostra che uno specifico computer sia orfano e il suo vecchio elenco di gruppi protetti non deve sostituire l'appendice C attuale. Lo stesso articolo descrive la protezione tramite gruppi di sicurezza o di distribuzione annidati: l'indagine sulle appartenenze deve quindi conservare questi percorsi.

Rilevamento: raccogliere identità ed evidenze indipendenti dalla directory

Iniziate con Get-ADComputer, i cui parametri documentati comprendono -LDAPFilter, -SearchBase, -Server e -Properties. Questo adattamento richiede gli attributi necessari per esaminare i computer candidati:

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

Questa query indipendente conserva deliberatamente i risultati abilitati e disabilitati per la classificazione. Il controllo EtcSec descritto più avanti seleziona solo le voci Computer abilitate. Registrate esplicitamente lo stato di abilitazione quando riconciliate le due popolazioni; una differenza di ambito non implica necessariamente una discrepanza nel marcatore.

Usate SID e DN per associare la segnalazione all'oggetto della directory. Conservate anche il GUID come ulteriore identificatore, la classe, il dominio e il server interrogati, l'ora di acquisizione e le eventuali letture fallite. Mantenete le evidenze grezze degli attributi, anziché solo un elenco formattato a schermo. Un risultato vuoto ottenuto da una base di ricerca più ristretta non risolve una segnalazione raccolta altrove.

Per un candidato che si sospetta sia un gMSA, leggete il DN esatto senza limitare la classe. Get-ADObject documenta l'identificazione tramite DN e le proprietà aggiuntive:

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

Confrontate questa identità con la segnalazione prima di scegliere il percorso di revisione dell'host o dell'account di servizio. Una ricerca specifica per computer fallita non deve scartare silenziosamente un oggetto restituito dal filtro di classe più ampio del collector.

Correzione: classificare ogni oggetto prima di approvare modifiche (Remediation)

Passaggio 1 — Stabilire il riferimento dei gruppi protetti

Risolvete i gruppi applicabili dell'appendice C nei domini interessati e nella radice della foresta, registrandone SID e DN. I nomi possono essere rinominati o localizzati. Il riferimento dei SID di Microsoft spiega gli identificatori di dominio e quelli relativi; usate identità di gruppo verificate anziché un confronto basato solo sul nome.

Get-ADGroup accetta un SID per -Identity e supporta proprietà aggiuntive. Questo adattamento documentato legge il gruppo predefinito Administrators in un contesto di dominio esplicito:

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

Ripetete l'operazione per i gruppi protetti applicabili usando i loro SID verificati. Questo esempio è una singola ricerca, non un inventario completo dei gruppi protetti. Separate gli account direttamente protetti dai gruppi di appartenenza e registrate le eccezioni pertinenti alla configurazione del dominio. Un gruppo di riferimento irrisolto lascia l'indagine incompleta.

Passaggio 2 — Risolvere le appartenenze oltre la prima vista

Get-ADPrincipalGroupMembership supporta computer, gruppi e account di servizio. Il SID di esempio è un segnaposto per il SID verificato del candidato:

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

Microsoft documenta che la ricerca dei gruppi richiede un catalogo globale e che i gruppi locali in un altro dominio richiedono il contesto di risorsa appropriato. Registrate gli errori non terminanti come fallimenti nella risoluzione delle appartenenze, anziché accettare un output parziale come un risultato privo di problemi. Interrogate i domini delle risorse interessati quando l'oggetto vi ha delle appartenenze.

Usate i gruppi restituiti e le evidenze memberOf dell'oggetto come punti di partenza. Per ogni gruppo, leggetene i gruppi superiori con Get-ADGroup -Properties memberOf,groupType e proseguite finché i percorsi terminano o raggiungono l'insieme protetto verificato. Conservate le identità intermedie, gestite i cicli e coprite i domini interessati. Una singola invocazione di cmdlet non viene presentata qui come un attraversamento transitivo completo e validato.

Passaggio 3 — Risolvere separatamente il gruppo primario

Il riferimento di protocollo primaryGroupID di Microsoft spiega che l'appartenenza primaria è omessa da memberOf sull'oggetto e dall'elenco member ordinario del gruppo. La documentazione di Get-ADComputer mostra anche PrimaryGroup e primaryGroupID nell'output dei computer.

Rileggete un computer verificato e risolvete in modo indipendente il DN del suo gruppo primario:

$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

Eseguite la seconda lettura solo se PrimaryGroup è stato risolto correttamente. Se è disponibile solo il RID, costruite il SID del gruppo primario a partire dal SID verificato del dominio dell'account e da quel RID, quindi risolvete il SID completo. Non sostituite il SID completo del computer e non presumete un gruppo primario atteso in base al ruolo della macchina. Esaminate anche i percorsi dei gruppi superiori del gruppo primario. Evidenze mancanti o contrastanti mantengono il caso indeterminato.

Passaggio 4 — Esaminare le autorizzazioni dell'oggetto e del contenitore padre

Conservate il descrittore di sicurezza ed esaminate ereditarietà, proprietà e ACE esplicite. Confrontate l'oggetto con il ruolo previsto e con il riferimento del contenitore padre. La protezione delle autorizzazioni può essere legittima; viceversa, un marcatore noto non spiega una concessione esplicita sospetta.

Il riferimento Dsacls di Microsoft documenta la visualizzazione dell'ACL e l'uso di /A per aggiungere informazioni di proprietà e auditing. Si tratta di operazioni di lettura separate:

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 errore di accesso indica che le evidenze richieste non sono disponibili. Un'acquisizione testuale è un artefatto d'indagine, non la garanzia di un backup ripristinabile. Stabilite il metodo di ripristino approvato prima di qualsiasi successiva manutenzione delle ACL.

La nostra revisione di diritti, delega e gruppi pericolosi degli oggetti computer spiega la superficie di attacco più ampia delle macchine. Queste esposizioni richiedono evidenze proprie: adminCount=1 da solo non ne dimostra alcuna. Tenete distinte l'ACL dell'oggetto, le sue appartenenze e i diritti che detiene altrove nella scheda di revisione.

Passaggio 5 — Registrare la decisione e validare il risultato previsto

Un'eccezione giustificata è una decisione aziendale; non rende non protetto un oggetto protetto. Un residuo plausibile è una classificazione d'indagine, non un'autorizzazione alla pulizia. Sottoponete qualsiasi modifica proposta di appartenenza o ACL al responsabile della macchina o del servizio, con il riferimento acquisito e le autorizzazioni finali attese.

Dopo la manutenzione approvata, ripetete le letture di identità, appartenenza e ACL sui server registrati. Tenete conto della replica della directory e, dove si applica la protezione, osservate il successivo risultato di SDProp secondo la pianificazione configurata. Registrate l'esito positivo o negativo e verificate il comportamento amministrativo o del servizio previsto. Non cancellate ripetutamente un marcatore per sopprimere un risultato inspiegato.

Come EtcSec rileva questo caso

Alla revisione del collector 9f698083354a1cb7f625df5cb490a515823c3257, il controllo COMPUTER_ADMIN_COUNT esaminato scorre le voci Computer raccolte, salta quelle disabilitate e seleziona quelle il cui booleano AdminCount è vero. Emette una segnalazione Info con il conteggio selezionato; i dettagli delle entità interessate sono inclusi solo quando sono stati richiesti e sono presenti candidati.

Il parser LDAP imposta quel booleano a vero solo quando il valore adminCount restituito è uguale a 1. Un valore assente o diverso da 1 diventa falso in questa rappresentazione. Il controllo non esclude DC, RODC o gMSA, non risolve appartenenze dirette, transitive o al gruppo primario e non esamina le ACL. Fornisce quindi candidati da classificare, anziché un verdetto di protezione obsoleta o privilegi pericolosi.

Il provider dei computer non richiede primaryGroupID o nTSecurityDescriptor nel proprio elenco predefinito di attributi. La loro assenza da questa raccolta non deve essere interpretata come assenza di gruppi o diritti. BaseDN e MaxComputers limitano la popolazione raccolta; un errore GetComputers interrompe la raccolta. Il rilevatore restituisce comunque una segnalazione Info con conteggio zero quando non ha candidati selezionati, quindi la sola presenza del tipo di segnalazione non dimostra una corrispondenza.

Riconciliate l'ambito dell'audit e le identità dei candidati con le letture indipendenti descritte sopra. Usate la scheda di classificazione per spiegare la protezione legittima, segnalare agli interlocutori competenti gli host irrisolti e conservare l'incertezza. Ripetere l'audit permette di confrontare l'elenco dei candidati nell'ambito con questa scheda, ma non sostituisce la risoluzione delle appartenenze o la validazione delle autorizzazioni.