Lacune di copertura di LAPS: audit e correzione

Sintesi: cosa sono le lacune di copertura di LAPS distribuito?

Le lacune di copertura di LAPS distribuito descrivono un ambiente Active Directory in cui esiste la gestione delle password dell’amministratore locale, ma la protezione non raggiunge tutte le macchine o identità importanti. Alcuni computer non ricevono mai i criteri previsti. Altri usano ancora l’archiviazione legacy in chiaro, concedono diritti di recupero troppo ampi o lasciano utilizzabile una password esposta finché la rotazione non riesce.

Windows Local Administrator Password Solution gestisce e salva la password di un account amministratore locale. Tra i suoi obiettivi rientra la riduzione dei movimenti laterali tramite credenziali locali riutilizzate. La panoramica di Windows LAPS di Microsoft descrive sia il backup in Active Directory sia la più recente implementazione nativa. Un oggetto criteri, una funzionalità installata o un attributo valorizzato sono elementi da esaminare; ciascuno risponde a una domanda diversa dal sapere se ogni dispositivo previsto sia protetto.

Questo articolo presuppone che LAPS con backup in AD sia già presente. La nostra guida a Windows LAPS non distribuito spiega il ciclo di vita mancante delle credenziali: password di amministratore locale non gestite, statiche o condivise, e come introdurne la rotazione. Il nostro articolo sull’igiene degli oggetti computer e sullo schema LAPS tratta il prerequisito più fondamentale di uno schema non esteso, insieme all’igiene di computer e controller di dominio. Qui lo schema esiste e la distribuzione è iniziata; occorre individuare dove questa distribuzione fallisce.

Funzionamento: quattro modi in cui LAPS distribuito perde protezione

1. Copertura parziale del dominio

Una distribuzione può riuscire in una OU pilota e tralasciare server membri, workstation appena predisposte o dispositivi spostati in un’altra OU. Si creano così due popolazioni dietro la stessa affermazione rassicurante: «usiamo LAPS». Esaminate separatamente l’inventario previsto e lo stato effettivo di workstation e server membri, senza lasciare che una vasta popolazione di workstation nasconda un parco server non gestito.

La copertura è anche diversa dal corretto funzionamento. Un attributo di scadenza può rimanere valorizzato mentre un dispositivo è offline o l’elaborazione dei criteri fallisce. Registrate se un computer presenta evidenze di Windows LAPS nativo, di LAPS legacy o di nessuno dei due, quindi verificate l’attività recente rispetto ai criteri di rotazione configurati. Esplicitate il trattamento degli oggetti computer disabilitati e dei controller di dominio nell’ambito dell’analisi; la gestione delle password DSRM è un caso d’uso distinto per i DC.

2. L’attributo legacy resta il percorso di recupero

Le generazioni usano attributi diversi. Il riferimento dello schema di Microsoft associa ms-Mcs-AdmPwdExpirationTime a msLAPS-PasswordExpirationTime e ms-Mcs-AdmPwd a msLAPS-Password. Il valore nativo msLAPS-Password contiene dati della password in chiaro in formato JSON; msLAPS-EncryptedPassword contiene dati cifrati. Il solo prefisso msLAPS- non dimostra quindi la cifratura.

Windows LAPS può applicare i vecchi criteri tramite la modalità di emulazione di Microsoft LAPS legacy. L’emulazione mantiene l’archiviazione AD in chiaro e non può fornire la cifratura nativa delle password. Individuare un attributo legacy deve portare a esaminare i criteri attivi e lo stato della migrazione, senza presumere che la vecchia estensione client sia necessariamente in esecuzione. I criteri nativi di Windows LAPS hanno precedenza su quelli legacy. L’emulazione richiede inoltre che l’estensione lato client di Microsoft LAPS legacy sia assente dal dispositivo gestito.

3. Il recupero delle password è delegato troppo ampiamente

La rotazione non compensa il recupero della password corrente da parte di un’entità di sicurezza non autorizzata. Verificate sia l’autorizzazione a recuperare i dati archiviati sia, quando si usa la cifratura, l’entità autorizzata a decifrarli. Sono controlli separati. Un gruppo di assistenza con una responsabilità di recupero approvata merita una verifica dei membri; non diventa sicuro soltanto perché il nome contiene «LAPS».

Una delega ampia sulla OU può interessare molti computer. Anche le autorizzazioni esplicite sui computer possono differire dalla configurazione di riferimento della OU. Esaminate insieme concessioni ereditate, eccezioni, appartenenze ai gruppi e popolazione autorizzata al recupero. Una concessione a un gruppo non equivale al conteggio delle singole persone che possono esercitarla.

4. L’esposizione della password persiste dopo la verifica degli accessi

Una modifica dell’ACL limita le future letture dalla directory. Non può ritirare una password già copiata in un ticket, una trascrizione, l’output di uno script o la sessione di un’altra persona. Si tratta di possibilità da esaminare nell’indagine su un incidente, non di prove che uno specifico ambiente abbia subito una fuga di dati.

Catena di attacco: dai diritti di recupero all’accesso locale

Una sequenza plausibile di guasti inizia con la compromissione di un’identità che dispone di diritti di recupero indebiti. Se tale entità può ottenere una password utilizzabile dell’amministratore locale, l’attaccante acquisisce una credenziale per il computer interessato. La portata risultante dipende dallo stato dell’account, dall’accesso di rete e dai controlli di autenticazione locali; un attributo leggibile non implica automaticamente la compromissione del dominio.

Un dispositivo non coperto offre un percorso diverso: la password locale resta al di fuori del ciclo di vita LAPS previsto. Un dispositivo che usa soltanto la generazione legacy può ruotare correttamente la password e continuare a esporre dati di recupero in chiaro a una popolazione di lettori troppo ampia. Queste condizioni possono coesistere, ma richiedono correzioni diverse. Ampliare l’ambito dei criteri non elimina i lettori eccessivi e attivare la cifratura non include un dispositivo escluso.

Per il triage degli incidenti, identificate il computer, la generazione della password archiviata, la popolazione autorizzata al recupero e la rotazione riuscita dopo il contenimento. Evitate di esportare password reali soltanto per dimostrare la debolezza. Metadati, evidenze delle ACL e log degli endpoint consentono generalmente una prima valutazione più sicura.

Misurare la copertura e le autorizzazioni di lettura

Individuare i computer con evidenze di scadenza nativa

Le indicazioni per la migrazione di Microsoft indicano un msLAPS-PasswordExpirationTime nuovo o aggiornato come uno dei modi per monitorare la transizione a Windows LAPS nativo. Il comando seguente adatta all’audit i parametri documentati del filtro LDAP e delle proprietà di Get-ADComputer, usando l’attributo documentato. Sostituite la OU di esempio con l’ambito di audit approvato. Il comando è fornito al lettore; non è stato eseguito su un dominio di produzione per questo articolo.

Get-ADComputer -SearchBase 'OU=Workstations,DC=corp,DC=example' -LDAPFilter '(msLAPS-PasswordExpirationTime=*)' -Properties 'msLAPS-PasswordExpirationTime',OperatingSystem,Enabled

Il risultato è un elenco di computer con evidenze di scadenza nativa, non una percentuale né la prova che ogni risultato funzioni correttamente. Confrontatelo con l’inventario atteso dei dispositivi per individuare i computer mancanti. Un valore di scadenza legacy su un computer mancante può indicare una distribuzione precedente. Verificate lo stato disabilitato, la directory di backup prevista e la configurazione effettiva dell’endpoint prima di attribuire una lacuna di copertura. Un dispositivo con backup in Entra non deve essere valutato in base all’assenza di un attributo di backup AD.

Per un calcolo della copertura difendibile, riconciliate lo stesso inventario di workstation e server membri abilitati e inclusi nell’ambito con le evidenze di distribuzione nativa o legacy. Dichiarate quali generazioni sono considerate coperte. Mantenete separata la vista di migrazione al nativo dalla vista di distribuzione di qualsiasi generazione. Poi esaminate quanto sia recente la scadenza e la riuscita della rotazione; la sola presenza dell’attributo non può accertare nessuna delle due.

Enumerare le entità di recupero

Il riferimento di Find-LapsADExtendedRights documenta la query sulla OU e l’opzione -IncludeComputers. Questo esempio sostituisce una OU di audit e include le autorizzazioni a livello di computer:

Find-LapsADExtendedRights -Identity 'OU=Workstations,DC=corp,DC=example' -IncludeComputers

Confrontate le entità restituite con un elenco di recupero approvato ed esaminate le appartenenze pertinenti e le autorizzazioni ereditate o esplicite. Consideratela un’enumerazione delle autorizzazioni, non la prova di una lettura di password completata o una ricostruzione esaustiva dell’accesso effettivo. Conservate gli identificatori degli oggetti e dei destinatari delle autorizzazioni nelle evidenze di audit senza archiviare i valori delle password.

Per una verifica autorizzata del recupero su un computer, il riferimento di Get-LapsADPassword di Microsoft documenta il modello seguente, con un nome di computer di esempio sostituito. Recupera dati delle credenziali; non è una query limitata ai metadati e non è stata eseguita su un dominio di produzione per questo articolo.

Get-LapsADPassword -Identity 'WS-001'

Senza -AsPlainText, le password restituite sono racchiuse in SecureString. Esaminate Source, DecryptionStatus e AuthorizedDecryptor per distinguere gli esiti di archiviazione e decifratura. Il cmdlet recupera anche le password legacy ms-Mcs-AdmPwd, ma i risultati legacy non includono Account e PasswordUpdateTime; una data di aggiornamento vuota in quel caso non è prova di una rotazione fallita.

Rilevamento: leggere il log operativo LAPS del client

Microsoft documenta questi segnali nel riferimento del log degli eventi Windows LAPS:

Raccogliete questi eventi da Microsoft-Windows-LAPS/Operational sui client gestiti. Il canale corrispondente su un controller di dominio riguarda la sua gestione DSRM, non l’attività dei client aggiunti al dominio. Un ciclo di elaborazione riuscito non deve necessariamente includere la rotazione se non era previsto un aggiornamento della password.

Correlate gli eventi per dispositivo e ciclo di elaborazione. Usate i criteri configurati per decidere quando avrebbe dovuto verificarsi un aggiornamento. Questi eventi operativi accertano gli esiti dell’elaborazione e degli aggiornamenti; non accertano chi abbia recuperato la password archiviata. Anche l’assenza di eventi richiede una verifica del corretto funzionamento della raccolta prima di essere interpretata come assenza di attività LAPS.

Correzione: risolvere separatamente ogni problema (Remediation)

1. Riparare l’ambito dei criteri e le autorizzazioni di scrittura

Assegnate un responsabile a ogni computer non coperto. Verificate la directory di backup prevista e il targeting dei criteri, quindi correggete la causa effettiva: collocazione nella OU, filtri, precedenza dei criteri o delega di scrittura. La procedura di distribuzione AD di Microsoft documenta il comando seguente, con una OU di esempio sostituita:

Set-LapsADComputerSelfPermission -Identity 'OU=Workstations,DC=corp,DC=example'

Concede autorizzazioni di aggiornamento autonomo per gli attributi nativi di Windows LAPS; non configura i criteri e non dimostra la riuscita del backup. Per distribuzioni legacy o di emulazione, usate gli strumenti ACL legacy descritti nelle indicazioni di emulazione di Microsoft, senza presumere che questo cmdlet nativo ripari le autorizzazioni legacy. Ricontrollate l’elenco dei candidati e le evidenze di aggiornamento degli endpoint dopo la correzione.

2. Limitare il recupero e la decifratura

Rimuovete le concessioni indebite alla loro origine effettiva, comprese le autorizzazioni ereditate, quindi delegate il recupero alla popolazione approvata. Aggiungere una concessione limitata non revoca una concessione ampia esistente. Ripetete la query dei diritti dopo la verifica delle ACL e provate il recupero approvato senza inserire credenziali nell’output generale dell’audit.

Per la cifratura AD nativa, il riferimento delle impostazioni dei criteri di Microsoft richiede un livello funzionale di dominio 2016 o successivo. Esaminate ADPasswordEncryptionEnabled e ADPasswordEncryptionPrincipal; quest’ultimo identifica l’entità autorizzata a decifrare e deve essere risolvibile sul dispositivo. Non equiparate i diritti di recupero dalla directory all’autorità di decifratura.

3. Completare la migrazione dalla generazione legacy

Seguite la procedura di migrazione di Microsoft per una transizione immediata o una coesistenza temporanea. Durante la coesistenza, le due implementazioni devono gestire account locali diversi. Verificate i criteri nativi, gli attributi nativi aggiornati e l’attività riuscita degli endpoint prima di rimuovere il software legacy. Esaminate anche l’accesso ai dati residui delle password legacy; una distribuzione nativa riuscita non accerta che tutti i vecchi percorsi di recupero siano stati ripuliti.

4. Eseguire la rotazione dopo un’esposizione credibile

Dopo aver contenuto l’accesso non autorizzato, coordinate la rotazione sull’endpoint interessato. Microsoft documenta Reset-LapsPassword per situazioni eccezionali che richiedono un cambiamento immediato, inclusa una compromissione della sicurezza della macchina:

Reset-LapsPassword

Eseguitelo localmente sul dispositivo gestito interessato con i privilegi necessari. Il cmdlet non restituisce informazioni dettagliate sull’esito; verificate gli eventi risultanti. Una richiesta di reimpostazione inviata non è una prova sufficiente che la credenziale esposta abbia smesso di funzionare. Esaminate le identità e gli endpoint coinvolti nell’incidente insieme alla rotazione, senza chiuderlo soltanto perché l’ACL dei lettori è cambiata.

Come EtcSec rileva questi problemi

Il catalogo accetta questi quattro identificatori. Le descrizioni seguenti riflettono le implementazioni di Detect() esaminate per questo articolo, senza affermare che sia stato eseguito un audit sul vostro dominio:

• LAPS_DOMAIN_COVERAGE_LOW valuta la copertura dei computer abilitati che non sono DC, contando la presenza di LAPS legacy o nativo. Separa i dati di workstation e server e riporta una metrica a livello di dominio. Nel Detect() esaminato, una copertura inferiore al 95% produce un rilievo: alta (High) sotto l’80%, altrimenti media (Medium) sotto il 95%. Sono soglie di controllo EtcSec, non raccomandazioni Microsoft. Fonte: etc-collector public/internal/audit/detectors/ad/advanced/laps/laps-domain-coverage.go, righe 78–86, commit f51fad0b69c0c7fbda2fcc3c43bd6f6b4da4bee4, esaminato il 3 ottobre 2026. Il controllo misura le evidenze di distribuzione, non quanto sia recente la rotazione o la qualità della cifratura.
• LAPS_LEGACY_ATTRIBUTE identifica computer con evidenze di LAPS legacy e senza evidenze di Windows LAPS nativo. Non identifica l’implementazione client in esecuzione e non dimostra una lettura non autorizzata.
• LAPS_PASSWORD_READABLE esamina le ACE di concessione con CONTROL_ACCESS che puntano al GUID dello schema ms-Mcs-AdmPwd risolto nella foresta reale. Esclude i destinatari riconosciuti come amministratori incorporati e il SID del computer stesso. Il suo ambito è questo segnale di autorizzazione legacy, non una valutazione generale dei diritti di decifratura delle password native cifrate.
• LAPS_PASSWORD_LEAKED usa lo stesso segnale delle ACE di concessione legacy con CONTROL_ACCESS e segnala più di un destinatario di lettura distinto su un computer dopo le stesse esclusioni degli amministratori incorporati e del SID del computer. Qui, «non amministratore» significa non riconosciuto da quel filtro; il rilevatore non accerta il ruolo amministrativo effettivo di ogni destinatario. Segnala una potenziale esposizione dovuta a permessi eccessivi, non un’esfiltrazione osservata, e non espande i gruppi per contare le persone. Verificate separatamente l’accesso effettivo: questo predicato conta le concessioni corrispondenti senza risolvere rispetto a esse le ACE di negazione.

Usate i rilievi di etc-collector per dare priorità all’indagine, poi verificate separatamente copertura, diritti effettivi, generazione dei criteri e rotazione degli endpoint. Un rilievo di distribuzione può essere risolto mentre permane un problema di autorizzazioni. Chiudete la verifica soltanto quando sia l’inventario previsto sia il percorso di recupero approvato corrispondono alle evidenze.