Pulizia adminCount Active Directory: una procedura sicura

Pulizia adminCount Active Directory: che cosa si corregge

L’obiettivo operativo della pulizia adminCount Active Directory è rimuovere un indicatore amministrativo residuo e ripristinare l’ereditarietà dei permessi prevista sugli account che hanno realmente lasciato i gruppi protetti. Si tratta di manutenzione ordinaria dopo cambi di ruolo e cessazioni dei rapporti di lavoro. La nostra guida alle backdoor AdminSDHolder e SDProp riguarda uno scenario diverso: un’ACE non autorizzata nel modello può propagarsi agli oggetti protetti. Qui la decisione parte dalle appartenenze attuali e dall’ACL dell’account, senza presumere il coinvolgimento di un attaccante.

Controllare gli annidamenti, cancellare l’indicatore e abilitare l’ereditarietà sono solo una parte di questa procedura. Una registrazione di manutenzione sicura deve identificare i gruppi protetti tramite SID, risolvere separatamente il gruppo primario, esaminare l’OU padre, approvare ogni account individualmente e verificare il risultato dopo un ciclo SDProp successivo. Un inventario adminCount=1 più ridotto è utile, ma non dimostra che i permessi effettivi siano corretti.

Come funziona SDProp e perché l’indicatore persiste

AdminSDHolder fornisce i permessi del modello per gli oggetti protetti. SDProp confronta i loro permessi con quel modello sull’emulatore PDC (PDCE) di ogni dominio, ogni 60 minuti per impostazione predefinita, e ripristina le differenze. Gli oggetti protetti hanno l’ereditarietà disabilitata; spostarli in un’altra OU non rimuove la protezione. Microsoft lo documenta nell’Appendice C: account e gruppi protetti. La specifica del protocollo AdminSDHolder spiega la protezione periodica dei descrittori di sicurezza.

Il riferimento allo schema Admin-Count di Microsoft descrive l’attributo come registrazione di un’ACL rafforzata dopo un’appartenenza amministrativa diretta o transitiva. Non è un inventario completo dei privilegi attuali. L’articolo storico di Microsoft su AdminSDHolder e SDProp spiega che, dopo la rimozione dell’appartenenza protetta, rimangono adminCount=1 e l’ereditarietà disabilitata. L’ex membro smette di ricevere l’ACL del modello, ma continua a non ereditare dall’oggetto padre.

Usare l’elenco attuale dell’Appendice C anziché quello precedente dell’articolo storico:

Administrator e Krbtgt sono account, non gruppi di appartenenza. Registrare ogni configurazione di dominio o eccezione di foresta applicabile; non modificare dSHeuristics per semplificare la pulizia. Il gruppo Protected Users è un controllo di autenticazione separato; non è esso stesso protetto da AdminSDHolder.

Insidia 1: una rimozione diretta lascia un percorso annidato

L’articolo storico di Microsoft descrive la protezione transitiva, compresi i percorsi attraverso gruppi di distribuzione. Un utente rimosso da Domain Admins può ancora raggiungere un gruppo protetto tramite un altro gruppo. Se quel percorso rimane, cancellare un attributo non rimuove la protezione e SDProp può annullare l’abilitazione dell’ereditarietà. Non promettere che la sola cancellazione dell’indicatore ne provochi necessariamente la reimpostazione in un momento preciso del ciclo successivo; la conclusione supportata è che l’appartenenza restante rende ancora protetto l’oggetto.

Insidia 2: l’indicatore scompare, ma l’ACL rimane errata

Per un ex membro confermato, cancellare adminCount lascia invariata l’ereditarietà. La delega sull’OU padre potrebbe quindi continuare a non raggiungere l’account. Questo non dimostra che l’ACL esistente dell’account sia più permissiva: potrebbero invece mancare i diritti di gestione previsti. Viceversa, abilitare l’ereditarietà sotto un’OU con deleghe eccessive può aggiungere permessi indesiderati. Anche le ACE esplicite richiedono un esame separato; abilitare l’ereditarietà non le rimuove di per sé.

Rilevamento: creare un inventario dei candidati

Iniziare con un inventario in sola lettura. Get-ADObject documenta -LDAPFilter, -Properties e -Server; questo adattamento richiede l’indicatore e lo stato necessari per l’indagine:

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

I risultati possono includere gruppi e computer. Classificarli separatamente, invece di applicare la procedura degli account utente a ogni oggetto restituito. Per la popolazione di utenti trattata dai due controlli EtcSec, usare i parametri documentati di Get-ADUser:

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

Un valore memberOf vuoto o apparentemente ordinario è una pista da approfondire, non la prova di un account orfano. La pagina dello schema MemberOf descrive i DN dei gruppi; questa proprietà da sola non fornisce l’analisi completa della protezione richiesta di seguito.

Questa procedura rileva una condizione dello stato della directory tramite query ed esame delle ACL. Non richiede un ID evento inventato e non considera una rimozione storica da un gruppo come prova che sia attualmente sicuro modificare l’account.

Correzione: verificare, poi modificare un account (Remediation)

Passo 1 — Conservare lo stato dell’account e del padre

Per ogni candidato, registrare DN, SID, stato abilitato, gruppi diretti, RID del gruppo primario, responsabile aziendale, ACL completa e stato dell’ereditarietà. Registrare il DC e l’ora di acquisizione. Tenere disponibile un metodo approvato di ripristino delle ACL; salvare l’output testuale fornisce evidenze utili, ma non consente di dichiarare l’esistenza di un backup AD ripristinabile.

Il riferimento Microsoft Dsacls documenta la visualizzazione delle voci di accesso senza modificarle. L’output predefinito omette le informazioni su proprietà e auditing; /A include questi dettagli durante la raccolta del registro completo di sicurezza. Eseguire ogni lettura separatamente:

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

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

Esaminare il padre prima di consentire l’ereditarietà. Identificare quali diritti ereditati devono comparire e quali ACE esplicite dell’account devono rimanere o essere esaminate separatamente. Un’ACL sospetta sposta l’account nell’ambito dell’indagine, invece di avviare una pulizia automatica.

Passo 2 — Risolvere i gruppi protetti tramite SID

Usare il riferimento SID di Microsoft per distinguere l’identificatore di dominio dal RID. Risolvere ogni gruppo protetto nel dominio pertinente; i gruppi di foresta richiedono una copertura adeguata del dominio radice della foresta. I nomi dei gruppi rinominati o localizzati non sono una verifica sufficiente dell’identità.

Get-ADGroup accetta un SID per -Identity. Il SID specifico del dominio riportato di seguito è un valore illustrativo, non un gruppo individuato. È mostrato anche il SID del gruppo incorporato Administrators, con un server esplicito per stabilire il contesto del dominio:

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"

Documentare il SID e il DN risolti per ogni voce dell’elenco protetto. Una ricerca non riuscita lascia una lacuna di copertura. Non equivale a confermare che il gruppo non contenga membri pertinenti.

Passo 3 — Controllare l’appartenenza ricorsiva e il gruppo primario

La documentazione di Get-ADGroupMember include un esempio di appartenenza ricorsiva. Adattarlo a ogni SID verificato di gruppo protetto e confrontare i SID degli utenti restituiti con quello del candidato:

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

Ripetere per l’intero elenco protetto e i domini pertinenti. Includere i percorsi attraverso gruppi di distribuzione. -Recursive restituisce i membri della gerarchia privi di oggetti figli; non è un elenco completo delle relazioni intermedie tra gruppi. Microsoft documenta anche una limitazione relativa ad altre foreste quando la foresta non dispone di Active Directory Web Service. Un’enumerazione non riuscita o incompleta deve lasciare il verdetto indeterminato.

Controllare separatamente il gruppo primario. Il riferimento Primary-Group-ID di Microsoft definisce il valore come RID del gruppo primario dell’utente. Il riferimento del protocollo primaryGroupID conferma che memberOf dell’utente e l’attributo member del gruppo primario omettono questa appartenenza. Il collector esaminato costruisce il SID del gruppo primario dal SID di dominio e da quel RID. Risolvere il SID completo con Get-ADGroup; non dedurre la risposta da un nome descrittivo del gruppo.

Determinare quindi se il gruppo primario è direttamente protetto o raggiunge un gruppo protetto tramite annidamento. Questo adattamento documentato di Get-ADGroup legge il successivo insieme di gruppi padre:

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

Continuare a esaminare ogni padre gestendo i cicli e coprendo i domini coinvolti. L’esempio è una singola lettura, non un programma di attraversamento completo e validato. L’assenza di un candidato nell’output dei membri ricorsivi non elimina la necessità di controllare il gruppo primario. Membri esterni non risolti, domini non interrogati o cicli non risolti impediscono l’approvazione di una scrittura.

Passo 4 — Registrare la decisione prima di scrivere

Gli account incorporati Administrator e Krbtgt rimangono protetti anche in assenza di un’appartenenza diretta che lo spieghi. Il collector esaminato li identifica tramite RID 500 e 502, anche dopo la ridenominazione. Un account disabilitato che rimane protetto appartiene alla prima riga, non a quella degli orfani. Per un orfano disabilitato confermato, decidere tra manutenzione e dismissione secondo la politica di conservazione; questa procedura non lo riabilita automaticamente.

Passo 5 — Cancellare solo l’attributo residuo confermato

Set-ADObject documenta -Clear con il nome visualizzato LDAP, insieme a -WhatIf e -Confirm. Visualizzare prima l’anteprima della modifica individuale:

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

Solo dopo la decisione e l’esame, eseguire la scrittura confermata separata:

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

-Clear rimuove il valore; non scrive il numero zero. Il comando non rimuove appartenenze, non modifica ACE esplicite e non abilita l’ereditarietà. Un’anteprima riuscita non dimostra neppure che il candidato sia realmente orfano.

Passo 6 — Abilitare l’ereditarietà ed esaminare l’ACL risultante

Il riferimento Dsacls definisce /P:N come l’autorizzazione per l’oggetto a ereditare i permessi del padre. Applicarlo solo all’oggetto approvato, dopo l’esame del padre:

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

Controllare il risultato dell’esecuzione e ripetere immediatamente la lettura dell’ACL del passo 1. Confrontare i diritti ereditati con la configurazione di riferimento approvata del padre ed esaminare le voci esplicite indipendentemente. /P:N modifica la protezione dell’oggetto rispetto all’ereditarietà; non modifica la possibilità di ereditare un’ACE. Non sostituirlo con /S o /S /T: /S ripristina la sicurezza predefinita dello schema dell’oggetto, e /T estende quel ripristino all’albero solo quando viene usato con /S.

Validazione dopo il prossimo ciclo SDProp

Rileggere l’account sul server registrato, usando i parametri Get-ADUser documentati sopra:

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

Leggere separatamente la sua ACL:

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

Ripetere anche la risoluzione delle appartenenze: possono cambiare tra inventario e manutenzione. Attendere un passaggio SDProp successivo secondo l’intervallo effettivamente configurato e tenere conto della replica prima di confrontare i DC. Registrare l’ora del controllo e i server, l’assenza dell’indicatore residuo, l’ereditarietà prevista, l’esame delle ACE esplicite e una prova reale della delega desiderata. Dichiarare «validato dopo il ciclo» solo quando esiste tale osservazione.

Se la protezione ritorna, indagare un percorso di gruppo restante, un’aggiunta recente o una raccolta incompleta. Cancellare ripetutamente l’attributo non è una soluzione. L’Appendice C di Microsoft fornisce un metodo facoltativo di laboratorio usando Ldp.exe sul PDCE con il rootDSE RunProtectAdminGroupsTask=1. Preferire il ciclo normale per questa procedura di manutenzione in produzione e lasciare invariata la frequenza. L’operazione FixUpInheritance dell’articolo storico non deve essere usata automaticamente al posto di tale attività.

La nostra guida alla deriva degli accessi privilegiati spiega perché le eccezioni relative a gruppi e ACL richiedono responsabili e una nuova validazione rispetto ai diritti effettivi. Applicare qui quel principio: la pulizia riuscita dell’indicatore è un risultato di manutenzione, mentre dimostrare che i permessi dell’account corrispondano al ruolo previsto richiede l’esame più ampio dei diritti.

Come EtcSec rileva questa situazione

I due controlli etc-collector esaminati condividono lo stesso predicato di account orfano basato sull’appartenenza diretta o primaria, applicato a popolazioni diverse di account:

I blocchi di selezione normalizzati differiscono solo per if u.Disabled rispetto a if !u.Disabled; anche titoli, gravità e raccomandazioni differiscono. Sono due rami dello stesso controllo in base allo stato dell’account, non meccanismi indipendenti da sommare come prova di un rischio maggiore.

Le appartenenze annidate non vengono risolte. Nessuno dei due controlli espande un gruppo annidato in un gruppo protetto, incluso un gruppo primario a sua volta annidato. Tali account possono ancora essere protetti e produrre un falso candidato orfano. La funzione ausiliaria risolve i DN dei gruppi protetti dai suffissi SID nell’indice raccolto, quindi confronta i DN diretti; dati mancanti sui gruppi o sui SID possono anch’essi lasciare un candidato senza spiegazione.

Nessun metodo Detect() legge l’ACL dell’account o lo stato dell’ereditarietà. Un rilievo quindi non dimostra diritti residui pericolosi, non prova l’assenza di protezione SDProp e non autorizza a cancellare l’attributo. Confermarlo con la procedura di appartenenze e ACL prima di apportare modifiche. Dopo la manutenzione e la validazione della directory, rieseguire l’audit per confrontare i rilievi candidati con il risultato registrato.