Windows LAPS non distribuito: perché le password locali di amministratore condivise restano un rischio

Cos'è 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 entrambi i casi il tema non è solo chi ha diritti amministrativi, ma se il ciclo di vita del segreto rimane controllabile dopo una compromissione.

Come funziona

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 BackupDirectory su 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.

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.

La catena di attacco

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.

Per questo il tema compare spesso nella stessa review di Sicurezza delle password in Active Directory: errori critici. L'errore di fondo è identico: un segreto che dovrebbe essere unico e controllato risulta in realtà facile da riutilizzare.

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 percorso esatto varia in base all'ambiente, ma la logica resta la stessa: la password non è mai stata randomizzata per dispositivo né ruotata abbastanza in fretta 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

I cambi manuali di password non scalano bene durante un incidente. Un ambiente senza Windows LAPS finisce spesso per affidarsi a script di emergenza, ticket o reset ad hoc. Questo rallenta il contenimento e allunga la finestra in cui l'attaccante può continuare a riutilizzare lo stesso accesso locale su altri sistemi.

Per questo il tema si collega direttamente a Percorsi di attacco AD verso Domain Admin. LAPS da solo non elimina ogni escalation, ma la sua assenza offre agli attaccanti un punto d'appoggio affidabile per il movimento laterale, che spesso si collega ad abusi più ampi di AD.

Rilevamento

La migliore rilevazione combina copertura delle policy, verifica del backup e review dei permessi.

# 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.

Vale anche la pena correlare il rollout di LAPS con Monitoraggio sicurezza AD: Event ID e SIEM. Se manca il controllo sulla password admin locale, il team di monitoraggio in genere non ha nemmeno una visibilità chiara su quali sistemi restano fuori dalla baseline prevista.

Remediation

Una sequenza pragmatica di remediation segue in genere questo ordine:

1. Scegliere l'autorità di backup. Usate Active Directory o Microsoft Entra ID in base al modello di join e gestione.
2. 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.
3. Configurare la policy client. Definite account gestito, complessità, età, destinazione di backup e azioni post-autenticazione.
4. Validare l'elaborazione corretta. Usate il log di Windows LAPS e i cmdlet di recupero per confermare che le password ruotino e vengano archiviate.
5. Rimuovere la deriva. Pulite script vecchi, password condivise e residui del precedente Microsoft LAPS.
6. 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

Per i deployment basati su Microsoft Entra, Microsoft consiglia anche di proteggere il recupero delle password con l'accesso condizionale sui ruoli che possono recuperare credenziali admin locali. È un utile promemoria: distribuire LAPS non è solo un compito di igiene degli endpoint, è anche un problema di controllo degli accessi.

Convalidare il rollout prima di chiudere il rilievo

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. Per questo Windows LAPS non distribuito e una delega troppo ampia andrebbero spesso rivisti insieme nello stesso audit.

Come EtcSec rileva questo problema

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.

Riferimenti ufficiali

• Microsoft Learn: Windows LAPS Overview
• 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

Approfondimenti correlati

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.