Mettere in sicurezza un device Autopilot: BitLocker e LAPS

Un dispositivo che si configura da solo è metà del lavoro. L’altra metà è assicurarsi che, quando arriva sulla scrivania di qualcuno, sia cifrato, che la password dell’amministratore locale non sia la stessa su tutte le macchine, e che Intune sia in grado di dimostrare entrambe le cose.

Questo capitolo copre compliance, Windows LAPS e BitLocker su un Windows 11 Entra ID joined, senza nessun dominio on-premise. E dedica molto spazio a una policy che si è rifiutata di applicarsi senza dirlo, perché è lì che sta la parte interessante.

L’ordine conta

Prima la compliance, poi LAPS, BitLocker per ultimo.

La compliance è la più facile da azzeccare e ti dice se il dispositivo sta parlando con Intune. LAPS ti dà una via di rientro nella macchina se qualcosa va storto. BitLocker è quello che oppone resistenza, e conviene avere gli altri due funzionanti prima che cominci.

Policy di compliance

Una policy di compliance non configura niente. Valuta il dispositivo ed emette un verdetto, su cui più avanti l’accesso condizionale potrà agire.

Windows LAPS

Ogni macchina Windows ha un account amministratore locale. Se la password la imposti a mano, la imposti uguale ovunque, e resta quella per anni. Windows LAPS la fa ruotare, una diversa per dispositivo, e la conserva in Entra ID.

Intune → Sicurezza degli endpoint → Protezione account → Crea criterio → Local admin password solution (Windows LAPS).

Non gestire l’Administrator integrato

La scelta che viene spontanea è puntare LAPS sull’account Administrator predefinito. Non farlo.

Quell’account è RID 500: le ultime tre cifre del suo identificativo di sicurezza sono fisse e identiche su ogni installazione di Windows del pianeta. Rinominarlo cambia l’etichetta, non il RID, e qualunque strumento che tenti password lo cerca per RID. Oltretutto su un’installazione moderna è disabilitato: abilitarlo per gestirlo significa creare un bersaglio noto e sempre presente.

Usa invece l’Automatic Account Management: LAPS crea un account suo, con il nome che scegli tu e un suffisso casuale.

Impostazione	Valore
Backup Directory	Entra ID
Administrator Account Name	LocalAdmin
Automatic Account Management: Enabled	True
Automatic Account Management: Target	Automatic managed account
Password Age Days	30
Password Complexity	Maiuscole, minuscole, numeri, caratteri speciali
Password Length	20
Post Authentication Actions	Reset password and logoff the managed account

L’account che ne esce si chiama LocalAdmin####, con le cifre diverse su ogni dispositivo.

Recuperare la password

Interfaccia di amministrazione Entra → Dispositivi → Tutti i dispositivi → [dispositivo] → Ripristino password amministratore locale.

BitLocker, ovvero quello che oppone resistenza

L’obiettivo è la cifratura silenziosa: il disco si cifra da solo, senza interazione, senza PIN all’avvio, e la chiave di ripristino finisce in Entra ID.

Intune → Sicurezza degli endpoint → Crittografia dischi → Crea criterio → BitLocker. Le impostazioni che contano: metodo XTS-AES 256, tipo di cifratura del disco di sistema Full, TPM richiesto, nessun PIN, chiave di ripristino su Entra, e «Consenti agli utenti standard di abilitare la crittografia durante Autopilot» attivo — perché il profilo Autopilot crea un utente Standard, e senza quella voce la cifratura non parte proprio.

E poi non ha funzionato.

Cosa diceva manage-bde

Conversion Status:    Used Space Only Encrypted
Percentage Encrypted: 100.0%
Encryption Method:    XTS-AES 128      ← la policy chiedeva 256
Protection Status:    Protection Off
Key Protectors:       None Found

Protection Off con Key Protectors: None Found su un volume cifrato al 100% sembra una contraddizione. Non lo è. È il pre-provisioning: Windows cifra il volume durante l’installazione con una chiave in chiaro, e aspetta che una policy aggiunga il protettore TPM e la chiave di ripristino. Quella policy non è mai arrivata.

Prima causa: un conflitto di policy, e non lo dice nessuno

Anche la security baseline di Defender contiene impostazioni BitLocker. Quando una baseline e una policy dedicata configurano la stessa impostazione con valori diversi, Intune la mette in Conflict e non applica nessuna delle due. Il dispositivo ricade sul valore predefinito di Windows.

Non te lo dice niente. Nessun errore sul dispositivo, nessun fallimento nella pagina di stato della registrazione, nessuna riga rossa nel portale. L’impostazione semplicemente non esiste.

Per vederlo: Dispositivi → [dispositivo] → Configurazione dispositivo → [nome della policy]. Quella schermata mostra lo stato impostazione per impostazione, con i Source Profiles che se la contendono.

Impostazione in conflitto	Cosa ha ottenuto il dispositivo
Metodo di cifratura e livello del cifrario	XTS-AES 128
Tipo di cifratura sul disco di sistema	Used Space Only
Autenticazione aggiuntiva all’avvio	TPM/PIN non governati dalla policy

Da quell’esperienza è uscita una regola che vale la pena tenere: vince la policy dedicata, la baseline si sfoltisce. E se una baseline non permette di mettere una voce su Non configurato, il ripiego è allineare il suo valore a quello della policy dedicata, perché valori identici non generano conflitto.

Seconda causa: un messaggio d’errore che mente

Sciolto il conflitto, la cifratura continuava a non partire. Il registro eventi di BitLocker — Microsoft-Windows-BitLocker/BitLocker Management, evento 853 — diceva:

Failed to enable Silent Encryption. TPM is not available.

Error: BitLocker Drive Encryption detected bootable media (CD or DVD) in the
computer. Remove the media and restart the computer before configuring BitLocker.

La prima riga è falsa. Get-Tpm riportava TpmPresent: True e TpmReady: True.

La causa vera è la seconda riga: le ISO di Windows 11 e virtio-win erano ancora montate nei lettori CD virtuali della VM. BitLocker si rifiuta di partire in presenza di supporti avviabili, perché altererebbero la catena di avvio che il TPM misura.

Rimedio: Proxmox → VM → Hardware → ogni CD/DVD Drive → Do not use any media → riavvio.

Terza trappola: cercare nella chiave di registro sbagliata

Il posto ovvio dove controllare se una policy BitLocker è arrivata sul dispositivo è questo:

Get-ItemProperty "HKLM:\SOFTWARE\Microsoft\PolicyManager\current\device\BitLocker"

Le tre impostazioni contese lì non ci sono, perché sono ADMX-backed. Guardare lì e non trovare niente fa credere che la policy non sia mai arrivata. I valori veri stanno altrove:

Get-ItemProperty "HKLM:\SOFTWARE\Policies\Microsoft\FVE"

Valore	Significato
EncryptionMethodWithXtsOs	7 = XTS-AES 256 · 6 = XTS-AES 128
OSEncryptionType	1 = Full encryption · 2 = Used Space Only
UseTPM / UseTPMPIN	2 = richiesto / 0 = nessun PIN all’avvio (silenzioso)
EnableBDEWithNoTPM	0 = nessuna cifratura senza TPM

Il risultato, compresa la parte che non ha funzionato

Cifrario e tipo di cifratura si scelgono all’avvio della cifratura e non si cambiano in corsa. Cambiarli vuol dire decifrare e ricominciare:

manage-bde -off C:      # aspettare "Fully Decrypted"
# riavvio: la policy ricifra da zero
manage-bde -status

Stato finale:

Encryption Method:  XTS-AES 256               ✅ come configurato
Conversion Status:  Used Space Only           ❌ la policy chiedeva Full
Protection Status:  Protection On             ✅
Key Protectors:     TPM + Numerical Password  ✅

Il cifrario è cambiato. Il tipo di cifratura no, nonostante OSEncryptionType = 1 fosse correttamente presente nel registro.

Il motivo è di progetto: la cifratura silenziosa avviata da MDM usa sempre used-space-only. È pensata per dispositivi nuovi ed è ottimizzata per la velocità. L’impostazione ADMX che impone il tipo di cifratura governa le cifrature avviate a mano, non il percorso silenzioso.

Da sapere: ricifrare genera una nuova chiave di ripristino. Quella precedente in Entra diventa inutile, il che è bene sapere prima di averla archiviata da qualche parte.

Diagnostica da tenere sottomano

# la policy è arrivata sul dispositivo? (impostazioni non ADMX)
Get-ItemProperty "HKLM:\SOFTWARE\Microsoft\PolicyManager\current\device\BitLocker"

# quelle ADMX-backed
Get-ItemProperty "HKLM:\SOFTWARE\Policies\Microsoft\FVE"

# il TPM è utilizzabile?
Get-Tpm

# WinRE è attivo? (prerequisito della cifratura silenziosa)
reagentc /info

# il motivo esatto del fallimento
Get-WinEvent -LogName "Microsoft-Windows-BitLocker/BitLocker Management" -MaxEvents 15 |
  Format-List TimeCreated, Id, Message

Di cosa parla davvero questo capitolo

Tre problemi su quattro erano silenziosi. Una policy in conflitto che non applica niente e non dice niente. Un registro eventi che accusa il TPM per colpa di una ISO montata. Una chiave di registro che sembra vuota perché i valori stanno da un’altra parte.

Nessuno di questi produce un errore che qualcuno segnalerebbe. Il dispositivo funziona, la persona è contenta, e il disco è cifrato con una chiave in chiaro e senza protettore di ripristino: cioè non è protetto affatto.

L’abitudine da costruirsi è verificare lo stato finale sul dispositivo, non lo stato di distribuzione nel portale. manage-bde -status e un’occhiata alla chiave di ripristino in Entra costano trenta secondi e rispondono alla domanda a cui il cruscotto sembra soltanto rispondere.