What Is Windows LAPS non distribuito?
Windows LAPS non distribuito significa che l’ambiente non dispone ancora di un processo gestito per impostare, ruotare, salvare e recuperare la password dell’amministratore locale su workstation Windows e server. Windows Local Administrator Password Solution nasce per risolvere un problema molto concreto: l’account amministratore locale resta spesso presente per supporto, build o scenari di emergenza, ma se la sua password è statica o riutilizzata, la compromissione di una sola macchina può aprire lo stesso segreto a molti altri sistemi.
La raccomandazione attuale di Microsoft è usare Windows LAPS e non affidarsi a una rotazione manuale. Windows LAPS può eseguire il backup della password sia in Active Directory sia in Microsoft Entra ID, e offre criteri nativi, cmdlet PowerShell e audit. Se la funzione non è distribuita, ha uno scope sbagliato o non è mai stata implementata in modo coerente tramite GPO, Intune o CSP, il rischio resta reale anche se l’organizzazione ritiene che l’accesso admin locale sia usato raramente.
Per questo Windows LAPS non distribuito compare spesso insieme a Malfunzionamenti GPO come vettore di attacco e Account obsoleti e sovraprivilegiati in AD. In tutti questi casi il tema non è solo chi ha diritti amministrativi, ma se il ciclo di vita del segreto rimane controllabile dopo una compromissione.
How Windows LAPS non distribuito Works
Windows LAPS è integrato nelle versioni moderne di Windows e può gestire un account amministratore locale per dispositivo. Microsoft documenta due destinazioni di backup supportate:
- Windows Server Active Directory
- Microsoft Entra ID
Sul client si configurano account gestito, complessità della password, età massima, azioni post-autenticazione e directory di backup. Dal lato amministrativo si definisce chi può leggere la password, chi può forzare una rotazione e come la procedura di recupero viene auditata.
Per Entra ID, Microsoft indica anche prerequisiti precisi:
- il dispositivo deve essere Entra joined o hybrid joined
- i dispositivi solo registered non sono supportati
- LAPS deve essere abilitato lato tenant e la policy client deve impostare
BackupDirectorysu Entra ID
Per Active Directory, Windows LAPS si basa su estensione di schema e diritti delegati per archiviare e proteggere il segreto. Microsoft fornisce cmdlet dedicati per aggiornare lo schema, leggere le password, verificare chi può leggerle e resettare la rotazione.
| Area LAPS | Funzione fornita da Microsoft | Perché conta |
|---|---|---|
| Policy client | Impostazioni native Windows LAPS | Impone età, lunghezza, complessità e account gestito |
| Destinazione di backup | AD o Entra ID | Rende la password recuperabile senza fogli o note locali |
| Controllo accessi | Ruoli o deleghe | Evita che la comodità del supporto diventi esposizione ampia |
| Tooling PowerShell | Get-LapsADPassword, Get-LapsAADPassword, Find-LapsADExtendedRights, Reset-LapsPassword | Permette di misurare rollout e recupero |
Microsoft documenta inoltre il percorso di migrazione dal vecchio Microsoft LAPS. Questo punto è importante perché molte organizzazioni pensano di avere già LAPS, quando in realtà dispongono solo di una distribuzione storica, incompleta o mai normalizzata.
The Attack Chain
Passo 1 - Compromettere un host che usa ancora una password locale riutilizzabile
Gli attaccanti non hanno bisogno di partire con Domain Admin per sfruttare una cattiva igiene delle password locali. Basta un host in cui l’account amministratore locale sia ancora utilizzabile e la password possa essere indovinata, recuperata o catturata. Se quello stesso segreto funziona su più sistemi, la compromissione smette rapidamente di essere locale.
Passo 2 - Riutilizzare il segreto per movimento laterale
Quando la password o l’hash NTLM vale su più dispositivi, i canali di amministrazione remota diventano molto più utili per l’attaccante. Il problema centrale non è solo l’esistenza dell’account locale, ma il fatto che il segreto non sia unico per macchina e non ruoti abbastanza velocemente dopo un’esposizione.
# Verificare se un dispositivo registra attività recenti di Windows LAPS
Get-WinEvent -LogName 'Microsoft-Windows-LAPS/Operational' -MaxEvents 20 |
Select-Object TimeCreated, Id, LevelDisplayName, Message
Se questo log resta vuoto su sistemi che dovrebbero essere coperti, oppure non compaiono rotazioni e recuperi nel percorso atteso, il rollout è incompleto.
Passo 3 - Espandere l’accesso più velocemente di una rotazione manuale
Senza Windows LAPS, molte organizzazioni si affidano in incidente a script di emergenza, ticket o cambi manuali. Questo rallenta il contenimento e allunga il tempo in cui la stessa password locale può essere riutilizzata. Per questo il tema si collega direttamente a Percorsi di attacco AD verso Domain Admin: LAPS non elimina ogni escalation, ma la sua assenza offre un eccellente punto d’appoggio per il movimento laterale.
Perché un rollout parziale resta pericoloso
Lo scenario più ingannevole non è “LAPS assente ovunque”, ma “LAPS presente a metà”. Se le workstation standard sono coperte ma jump host, server più vecchi o postazioni amministrative restano fuori, il controllo perde una grande parte del suo valore. Gli attaccanti cercano proprio i sistemi in cui la password locale è ancora prevedibile o condivisa. Un rollout parziale crea quindi una falsa sensazione di sicurezza.
Per questo la revisione non deve fermarsi all’esistenza della policy. Bisogna verificare gruppi target, eccezioni, diritti di lettura e soprattutto quali macchine risultano davvero protette. Una GPO visibile in console non equivale a una password locale realmente ruotata e recuperabile.
Detection
La migliore rilevazione combina copertura delle policy, verifica del backup e review dei permessi.
| Indicatore | Fonte | Cosa verificare |
|---|---|---|
| Nessuna policy Windows LAPS efficace | GPO, Intune, CSP o policy locale | I dispositivi gestiti ricevono davvero configurazione LAPS? |
| Nessun backup recente in AD o Entra ID | Get-LapsADPassword o Get-LapsAADPassword | Le password vengono archiviate e ruotate come previsto? |
| Nessuna attività LAPS sull’endpoint | Microsoft-Windows-LAPS/Operational | Il client elabora correttamente la policy? |
| Letture troppo ampie del segreto | Find-LapsADExtendedRights o review dei ruoli Entra | Troppe identità possono leggere le password locali? |
# Verificare chi può leggere le password LAPS in AD
Find-LapsADExtendedRights -Identity 'OU=Workstations,DC=corp,DC=local'
# Validare il recupero di una password archiviata in AD
Get-LapsADPassword -Identity WS-001 -AsPlainText
Per i deployment con Entra ID, Microsoft documenta anche Get-LapsAADPassword e il recupero basato su ruoli. Una review seria deve quindi confermare entrambi gli aspetti: la password esiste davvero e solo i ruoli previsti possono recuperarla.
Remediation
💡 Quick Win: scegliete prima un modello di backup supportato. Un ambiente a metà strada tra gestione manuale, Microsoft LAPS legacy e Windows LAPS genera spesso più confusione che protezione.
Una sequenza pragmatica di remediation segue in genere questo ordine:
- Scegliere l’autorità di backup. Usate Active Directory o Microsoft Entra ID in base al modello di join e gestione.
- Preparare directory e permessi. Per AD aggiornate lo schema e rivedete diritti di lettura e reset. Per Entra abilitate LAPS nel tenant e verificate i ruoli di recupero.
- Configurare la policy client. Definite account gestito, complessità, età, destinazione di backup e azioni post-autenticazione.
- Validare l’elaborazione corretta. Usate il log di Windows LAPS e i cmdlet di recupero per confermare che le password ruotino e vengano archiviate.
- Rimuovere la deriva. Pulite script vecchi, password condivise e residui del precedente Microsoft LAPS.
- Auditare i diritti di recupero. Assicuratevi che solo i team corretti possano leggere o resettare le password.
# Esempio di rollout e validazione per Windows LAPS su AD
Update-LapsADSchema
Get-LapsADPassword -Identity WS-001
Reset-LapsPassword
Validate Before You Close the Finding
Un rollout non è completo perché esiste una policy. Lo è quando dispositivi rappresentativi ruotano davvero le password, il backend di backup contiene segreti recenti e il percorso di recupero è stato testato end-to-end dal ruolo autorizzato. La validazione minima dovrebbe coprire una workstation standard, una postazione amministrativa se presente, una classe di server rilevante e un test reale di recupero.
Questa validazione deve anche documentare chi può leggere le password e chi può avviare nuove rotazioni. In caso contrario, l’ambiente sostituisce semplicemente una password condivisa con una superficie di recupero troppo ampia.
Cosa validare separatamente nei deployment AD ed Entra ID
Molti progetti LAPS non falliscono per assenza di tecnologia, ma per modelli operativi mescolati. Microsoft separa chiaramente Windows LAPS per Active Directory e per Microsoft Entra ID. Nei deployment basati su AD non basta estendere lo schema; occorre anche verificare che i diritti delegati di lettura siano limitati alla OU o al gruppo corretto, che Get-LapsADPassword restituisca valori aggiornati su dispositivi rappresentativi e che Reset-LapsPassword provochi davvero una nuova rotazione. Solo così si dimostra che il percorso di recupero funzionerà durante un incidente e non soltanto nella documentazione.
Nei deployment con Entra ID i controlli critici sono altri. Microsoft supporta soltanto dispositivi Entra joined o hybrid joined; i dispositivi solo registered non sono supportati. Inoltre LAPS deve essere abilitato a livello tenant e la policy client deve impostare BackupDirectory su Microsoft Entra ID. Anche i diritti di recupero meritano una verifica separata, perché Microsoft distingue tra permessi per leggere la password e permessi per leggere i metadati della password. Un rollout è affidabile solo quando il team previsto testa entrambi i percorsi: backup corretto del segreto e recupero auditabile nel momento in cui serve davvero.
Un altro errore frequente è pensare che “un po’ di LAPS esiste già” e che basti così. Microsoft documenta un percorso esplicito di migrazione dal vecchio Microsoft LAPS. Per questo l’accettazione del rollout dovrebbe chiarire se vecchie GPO, script legacy o procedure parallele sono ancora attive. Finché convivono più modelli di gestione, si creano eccezioni, ownership duplicate e gap nel recovery. Un pilot serio valida separatamente AD ed Entra, conferma quali dispositivi sono realmente coperti e misura quanto rapidamente una nuova rotazione diventa visibile dopo un uso o un reset.
Conviene inoltre trattare admin workstation, jump host e server privilegiati come una wave specifica del pilot. Su questi sistemi è ancora più importante verificare le Post-Authentication-Actions e confermare che Windows LAPS gestisca solo l’account locale previsto per dispositivo, senza lasciare vecchi account fuori dal controllo di rotazione.
How EtcSec Detects This
EtcSec collega questo tema a LAPS_NOT_DEPLOYED e GPO_LAPS_NOT_DEPLOYED. La distinzione utile è capire se Windows LAPS manca del tutto o se l’organizzazione pensa di averlo distribuito mentre nessuna policy stabile raggiunge realmente gli endpoint giusti.
ℹ️ Note: EtcSec verifica automaticamente copertura LAPS assente o incoerente negli audit Active Directory, separando “funzionalità disponibile” da “funzionalità che protegge davvero gli endpoint”.
Official References
- Microsoft Learn: What is Windows LAPS?
- Microsoft Learn: Windows LAPS PowerShell Cmdlets Overview
- Microsoft Learn: Use Windows Local Administrator Password Solution with Microsoft Entra ID
- Microsoft Learn: Prepare for Windows LAPS deployment and migration
Related Reading
Per dare la giusta priorità al tema, rivedetelo insieme a Malfunzionamenti GPO come vettore di attacco, Account obsoleti e sovraprivilegiati in AD, Sicurezza password AD: configurazioni errate che contano, Come auditare la sicurezza di Active Directory: checklist pratica per i team interni e Monitoraggio sicurezza AD: Event ID e SIEM. Questi temi mostrano perché la rotazione di una password locale funziona solo quando scope, permessi e auditabilità sono allineati.
