Igiene degli Oggetti Computer Controller di Dominio Active Directory Schema LAPS: Sei Lacune Che un Audit Reale Continua a Trovare

Igiene degli Oggetti Computer Controller di Dominio Active Directory Schema LAPS: Cosa Copre Questo Audit

Igiene degli oggetti computer controller di dominio Active Directory schema LAPS: questo è ciò che un audit reale trova per primo, e nessuno di questi punti è di per sé eclatante: uno schema AD mai esteso per LAPS, controller di dominio posizionati fuori dalla loro OU, e oggetti computer che nessuno controlla da anni. Insieme, stanno alla base dei percorsi di attacco più discussi — Kerberoasting, DCSync, escalation ADCS — e determinano in silenzio se questi attacchi siano anche solo necessari. Un dominio in cui ogni oggetto computer è aggiornato, ogni controller di dominio è posizionato correttamente, e le password amministratore locali sono gestite in modo centralizzato è un dominio in cui un attaccante deve faticare per ottenere un punto d'appoggio. Un dominio in cui nulla di tutto ciò è vero regala scorciatoie.

Questo articolo copre sei lacune che un audit reale condotto su un ambiente AD reale trova sistematicamente insieme, nessuna delle quali compare in una tipica lista "top 10 delle configurazioni errate" perché nessuna è una vulnerabilità isolata e clamorosa:

1. L'estensione dello schema di Active Directory per LAPS non è mai stata applicata — non "LAPS è distribuito ma non ovunque", gli attributi di schema stessi non esistono.
2. Controller di dominio il cui oggetto computer si trova fuori dalla OU Domain Controllers.
3. Oggetti controller di dominio che hanno smesso di replicare e non sono mai stati ripuliti.
4. Oggetti computer obsoleti e inattivi, senza nessuno che li tenga d'occhio.
5. Computer senza BitLocker, inclusi controller di dominio che ospitano NTDS.dit.
6. Account computer la cui password macchina ha smesso di ruotare.

Ciascuna di queste, presa singolarmente, è poco eclatante. Insieme, descrivono un ambiente in cui il ciclo di vita degli oggetti non è compito di nessuno — ed è esattamente la condizione su cui contano gli attaccanti quando i controlli più vistosi sono già bloccati.

Perché uno Schema LAPS Non Esteso È la Lacuna Più Profonda

Local Administrator Password Solution esiste in due generazioni, e la distinzione qui conta. Il LAPS Microsoft legacy memorizzava la password gestita nell'attributo ms-Mcs-AdmPwd, aggiunto allo schema eseguendo Update-AdmPwdADSchema come membro di Schema Admins — vedi il riferimento ufficiale sugli attributi di Microsoft in MS-ADA2. Dall'aggiornamento cumulativo di aprile 2023, Windows LAPS viene distribuito come componente nativo del sistema operativo e utilizza un insieme di attributi distinto e cifrato (msLAPS-Password, msLAPS-EncryptedPassword, msLAPS-PasswordExpirationTime) — vedi il riferimento tecnico di Windows LAPS. Ciascuna generazione richiede la propria estensione di schema una tantum (Update-LapsADSchema per i nuovi attributi), a livello di dominio, eseguita da un membro di Schema Admins.

Questo passaggio è facile da saltare perché ometterlo non genera alcun errore. Le GPO possono essere collegate, il CSE di LAPS può essere distribuito su ogni endpoint, e non succederà nulla — non esiste alcun attributo in cui scrivere la password. Si tratta di una lacuna diversa e più profonda rispetto a "LAPS è configurato ma alcuni computer non sono nel perimetro", che è la lacuna Windows LAPS Non Distribuito trattata separatamente. Qui, lo schema stesso non è mai stato toccato, il che significa che tutte le password amministratore locali del dominio non sono gestite — spesso identiche su un'intera immagine di distribuzione, secondo l'analisi sulla distribuzione di LAPS di ADSecurity.org. Una singola credenziale amministratore locale basata su immagine, una volta craccata o estratta da un'unica workstation a basso valore, sblocca il movimento laterale verso tutte le macchine costruite a partire da quell'immagine.

DC Fuori dalla Loro OU e Metadati Mai Ripuliti

DC_NOT_IN_DC_OU sembra un dettaglio cosmetico finché non si verifica cosa Microsoft collega realmente all'OU Domain Controllers predefinita: la Default Domain Controllers Policy, che imposta le assegnazioni di diritti utente specifiche dei DC, la policy di controllo e le opzioni di sicurezza — la stessa catena di ereditarietà delle GPO che approfondiamo in Configurazioni Errate delle GPO: Come la Group Policy Diventa un Vettore di Attacco. Spostare l'oggetto computer di un controller di dominio in un'altra OU — anche una sotto-OU creata per ordine organizzativo — interrompe questa catena di ereditarietà, e Microsoft documenta questo da anni come configurazione non supportata, non come una preferenza stilistica; vedi l'articolo di Computerworld su questo errore e la guida alla sicurezza dei controller di dominio di Semperis. Un DC che ha silenziosamente perso la sua policy di controllo di base è un DC che genera log di sicurezza incompleti — esattamente il tipo di punto cieco su cui fa affidamento una tecnica di registrazione di un DC fraudolento come DCShadow; trattiamo questo abuso specifico in Attacco DCShadow: Registrazione di un Controller di Dominio Canaglia.

DC_INACTIVE è il problema gemello: un oggetto computer di un DC che ha smesso di replicare e non è mai stato dismesso formalmente. Le linee guida Microsoft affermano esplicitamente che un DC rimosso per un guasto hardware o una demotion forzata fallita lascia metadati di directory e DNS orfani — oggetti computer e NTDS Settings, connessioni di replica, record SRV/CNAME — che devono essere rimossi deliberatamente tramite una pulizia dei metadati, non lasciati in essere; vedi Pulire i metadati del server di un controller di dominio Active Directory. Lasciata così, questa identità di DC obsoleta produce risultati di localizzazione dei DC incoerenti e offre a un attaccante un oggetto plausibile e raramente controllato da impersonare o riutilizzare. Il posizionamento degli oggetti e lo stato di salute della replica sono la metà "igiene" della sicurezza dei DC; la metà rete/servizio — cifratura LDAPS debole, Print Spooler esposto, deriva dell'orologio oltre la tolleranza Kerberos — è una checklist distinta che abbiamo pubblicato in Audit DC: TLS Debole su LDAPS, Spooler di Stampa, Sincronizzazione Oraria.

Computer Obsoleti, BitLocker Assente, e Password Macchina Mai Ruotate

COMPUTER_STALE_INACTIVE è l'equivalente, per un oggetto computer, di un account utente obsoleto: una macchina che non si autentica da mesi ma resta un principal Kerberos pienamente valido, con un SID, appartenenze a gruppi e — se qualcuno le ha mai concesso diritti di delega o di scrittura su qualcosa di sensibile — una superficie di attacco che nessuno sorveglia. Questo stesso punto cieco riguarda anche gli account utente obsoleti, un problema trattato separatamente in Account Obsoleti e Sovraprivilegiati in AD. I rischi distinti e più profondi che si basano su un oggetto computer una volta che un attaccante lo controlla (delega senza vincoli, abuso di RBCD, diritti che abilitano DCSync) sono trattati separatamente in Superficie di Attacco degli Oggetti Computer in Active Directory; questa lacuna riguarda semplicemente il fatto che questi oggetti esistano, senza mai essere revisionati.

COMPUTER_NO_BITLOCKER conta soprattutto per le macchine che ospitano i dati più preziosi a riposo. Per un controller di dominio in particolare, si tratta di NTDS.dit — il database che contiene l'hash della password di ogni account. Le linee guida ufficiali Microsoft per l'hardening dei controller di dominio raccomandano BitLocker basato su TPM su tutti i volumi dei DC proprio perché protegge la directory anche se un disco fisico viene rimosso dal server (vedi il riferimento Securing Domain Controllers Against Attack). Quando BitLocker è abilitato con l'archiviazione della chiave basata su AD, la password di recupero viene depositata come oggetto figlio msFVE-RecoveryInformation sotto l'oggetto computer — vedi Storing BitLocker Recovery Keys in Active Directory — quindi la sua assenza è direttamente interrogabile, non qualcosa da dare per buono su un foglio di calcolo.

COMPUTER_PASSWORD_OLD segue un segnale più sottile. Per impostazione predefinita, "Membro di dominio: durata massima password account computer" è di 30 giorni — ogni computer aggiunto al dominio dovrebbe ruotare la propria password macchina con questa cadenza, un'impostazione documentata nel riferimento sulle policy di sicurezza di Microsoft e spiegata in dettaglio dal tutorial di ADSecurity.org sulla password dell'account macchina. Un account macchina con una password molto più vecchia di 30 giorni che continua ad autenticarsi attivamente segnala di solito un canale sicuro rotto, non un sistema irrobustito — e una password macchina statica dà a un attaccante che compromette l'account molto più tempo per forzarla via brute-force o rigiocarla prima che la rotazione imponga un reset.

Rilevamento

# 1. Confermare che l'estensione di schema LAPS esista (entrambe le generazioni)
Get-ADObject -SearchBase (Get-ADRootDSE).schemaNamingContext `
    -Filter {name -eq "ms-Mcs-AdmPwd" -or name -eq "msLAPS-Password"}

# 2. Controller di dominio il cui oggetto computer si trova fuori dalla OU DC predefinita
Get-ADDomainController -Filter * | ForEach-Object {
    $dn = (Get-ADComputer $_.Name).DistinguishedName
    if ($dn -notmatch "OU=Domain Controllers") { "$($_.Name) -> $dn" }
}

# 3. Oggetti computer obsoleti — nessuna autenticazione da 90+ giorni
Get-ADComputer -Filter * -Properties lastLogonTimestamp |
    Where-Object { [DateTime]::FromFileTime($_.lastLogonTimestamp) -lt (Get-Date).AddDays(-90) } |
    Select-Object Name, @{N='LastLogon';E={[DateTime]::FromFileTime($_.lastLogonTimestamp)}}

# 4. Computer senza informazioni di recupero BitLocker archiviate in AD
Get-ADComputer -Filter * | ForEach-Object {
    $recovery = Get-ADObject -Filter {objectClass -eq "msFVE-RecoveryInformation"} -SearchBase $_.DistinguishedName
    if (-not $recovery) { $_.Name }
}

# 5. Password account macchina più vecchia della policy di 30 giorni
Get-ADComputer -Filter * -Properties PasswordLastSet |
    Where-Object { $_.PasswordLastSet -lt (Get-Date).AddDays(-30) } |
    Select-Object Name, PasswordLastSet

Rimedio

1. Estendere lo Schema LAPS, Una Volta, a Livello di Dominio

Eseguite Update-LapsADSchema (Windows LAPS) — oppure Update-AdmPwdADSchema se l'organizzazione rimane deliberatamente su LAPS legacy — come membro di Schema Admins, quindi delegate il permesso di scrittura SELF sui nuovi attributi con Set-LapsADComputerSelfPermission prima di distribuire la GPO.

2. Riportare gli Oggetti DC Mal Posizionati in Domain Controllers

Usate Move-ADObject o ADUC per riposizionare l'oggetto computer, quindi confermate che la Default Domain Controllers Policy si riapplichi con gpresult /r sul DC interessato.

3. Risolvere o Dismettere Deliberatamente i DC Inattivi

Se repadmin /showrepl mostra un guasto di replica reale, correggetelo. Se il DC è effettivamente scomparso, eseguite una pulizia dei metadati adeguata invece di lasciare in essere l'oggetto orfano e i record DNS.

4. Disabilitare, Poi Eliminare, i Computer Obsoleti Secondo un Calendario Fisso

Ad esempio, disabilitare dopo 90 giorni di inattività ed eliminare dopo 180 — la stessa disciplina già applicata agli account utente obsoleti.

5. Abilitare BitLocker con TPM e Archiviazione della Chiave in AD

Date priorità prima ai controller di dominio, tramite l'impostazione GPO "Archivia le informazioni di ripristino di BitLocker in Active Directory Domain Services", in modo che msFVE-RecoveryInformation si popoli e diventi verificabile.

6. Lasciare Invariata la Policy dei 30 Giorni per la Password Macchina

Indagate, invece di ignorare, qualsiasi macchina attiva il cui PasswordLastSet si sia allontanato ben oltre questo limite — di solito Test-ComputerSecureChannel -Repair risolve un canale sicuro rotto che blocca silenziosamente la rotazione.

Come EtcSec Rileva Questo

L'audit Active Directory di EtcSec verifica direttamente queste sei condizioni sul dominio: COMPUTER_NO_LAPS per un'estensione di schema mancante, DC_NOT_IN_DC_OU e DC_INACTIVE per il posizionamento e lo stato di salute della replica dei controller di dominio, COMPUTER_STALE_INACTIVE per le macchine inattive mai revisionate, COMPUTER_NO_BITLOCKER per la cifratura del disco non archiviata, e COMPUTER_PASSWORD_OLD per la rotazione della password macchina ferma.