Importare l'hash hardware Autopilot: gli errori che nessuno documenta

Ogni dispositivo Windows ha un hash hardware: un’impronta costruita a partire dalla scheda madre, dal TPM e da altri componenti. Autopilot la usa per riconoscere una macchina prima che quella macchina abbia una qualsiasi identità — nessun nome, nessun account, nessuna registrazione. Solo un computer che è stato acceso.

Portare quell’hash dentro Intune è documentato come un comando solo. Nella pratica è fallito tre volte di fila, ogni volta con un errore che indicava un punto diverso dalla causa.

Il metodo interattivo

Da eseguire sul dispositivo da registrare, in PowerShell come amministratore — oppure durante l’OOBE con Shift+F10:

Set-ExecutionPolicy -Scope Process -ExecutionPolicy RemoteSigned
Install-Script Get-WindowsAutopilotInfo -Force
Connect-MgGraph -UseDeviceAuthentication
Get-WindowsAutopilotInfo -Online

Carica l’hash direttamente nel tenant. Nessun file CSV da spostare, nessun passaggio di importazione nel portale.

Primo fallimento — PowerShell esce senza output

L’accesso è andato a buon fine. L’MFA pure. Poi la finestra è tornata al prompt senza stampare niente. Nessun errore, nessun hash, nessuna conferma.

Causa: la versione attuale di Get-WindowsAutopilotInfo usa il Graph SDK, e su Windows 11 l’autenticazione passa per impostazione predefinita dal broker WAM. Nel contesto dell’OOBE la sessione gira come defaultuser0, e lì il flusso interattivo di WAM non può proprio completarsi. Non fallisce rumorosamente: non restituisce nulla.

Rimedio: autenticarsi prima, con il codice dispositivo invece del broker:

Connect-MgGraph -UseDeviceAuthentication

Stampa un codice da inserire su microsoft.com/devicelogin da un altro dispositivo. Stabilita la sessione, Get-WindowsAutopilotInfo -Online la riutilizza.

Secondo fallimento — AADSTS530035

Con l’autenticazione a codice dispositivo, codice inserito, password accettata, MFA soddisfatto — e poi:

AADSTS530035: Access has been blocked by Conditional Access policies.

Vale la pena leggerlo con attenzione, perché il messaggio porta alla conclusione sbagliata. L’autenticazione è riuscita. L’identità è stata dimostrata. Quello che è stato rifiutato è il rilascio del token a quel flusso.

Causa: i Security Defaults, che Microsoft attiva sui tenant nuovi, bloccano del tutto il device code flow. Non conta quanto sia forte l’autenticazione: è quel flusso a non essere ammesso.

Confermato in Entra → Log di accesso, dove la voce riportava Policy: Security Defaults · Grant Controls: Block. È quel log a trasformare un’ipotesi in una diagnosi, ed è il primo posto da guardare ogni volta che compare un codice AADSTS.

Rimedio: Entra → Proprietà → Gestisci i valori predefiniti per la sicurezza → Disattivati.

Terzo fallimento — serialNumber is null

Terzo tentativo. Autenticazione pulita, script eseguito, e:

0 devices imported successfully
serialNumber is null

Causa: la macchina è virtuale, e le VM Proxmox non hanno un numero di serie SMBIOS. Autopilot ne pretende uno: l’hash da solo non basta a registrare un dispositivo.

Rimedio: spegnere la VM, poi Proxmox → Options → SMBIOS settings (type1) → Serial, e mettere qualcosa di sensato:

W11-AUTOPILOT-001

Riavviare e rilanciare l’import.

1 devices imported successfully

Il dispositivo compare in Intune sotto Dispositivi → Registrazione Windows → Dispositivi Autopilot, entra nel gruppo dinamico, e il profilo passa a Assigned.

Renderlo non interattivo

Il metodo interattivo costa sei passaggi per macchina: execution policy, installazione dello script, autenticazione a codice, aprire un secondo dispositivo, inserire il codice con MFA, caricare. Accettabile una volta. Pesante per dieci macchine.

Una App Registration lo riduce a un comando solo.

Configurazione, una tantum

Uso

Set-ExecutionPolicy -Scope Process -ExecutionPolicy RemoteSigned
Install-Script Get-WindowsAutopilotInfo -Force
Get-WindowsAutopilotInfo -Online -TenantId "<tenant>" -AppId "<appid>" -AppSecret "<valore>"

Output atteso: «Connected to Intune tenant … using app-based authentication». Nessun accesso, nessun codice dispositivo, nessun MFA.

Quanto costa quella comodità

Vale la pena dirlo chiaramente, perché quasi tutte le guide presentano l’App Registration semplicemente come il metodo migliore. Scambia sicurezza con automazione, e lo scambio è reale.

Rischio	Dettaglio
Il permesso è ampio	DeviceManagementServiceConfig.ReadWrite.All non copre solo il caricamento dell’hash. Consente lettura e scrittura su tutta la configurazione di registrazione: dispositivi Autopilot, profili di distribuzione, ESP, restrizioni
Scavalca l’accesso condizionale	Un token applicativo non passa dalle policy di accesso condizionale né dall’MFA. Applicarle alle identità del carico di lavoro richiede la licenza Entra Workload ID, a parte
Il segreto finisce nella cronologia	Tutto ciò che si digita a un prompt PowerShell viene scritto in chiaro in %APPDATA%\Microsoft\Windows\PowerShell\PSReadLine\ConsoleHost_history.txt
Scade in silenzio	Alla scadenza del segreto il comando fallisce con un errore di autenticazione poco leggibile, mesi dopo, senza niente che lo colleghi alla causa

Cosa farci

Il più utile dei quattro è il terzo, perché il rimedio è controintuitivo.

Le misure applicate davvero in laboratorio:

• L’app viene disabilitata fra un provisioning e l’altro — Entra → Applicazioni aziendali → Autopilot-HashUpload → Proprietà → Abilitata per l’accesso degli utenti → No — e riattivata solo quando serve.
• Il segreto è stato revocato dopo l’uso, lasciando un segnaposto nel file dello script.
• Cronologia ripulita su ogni macchina dove il comando è stato digitato:

  Remove-Item "$env:APPDATA\Microsoft\Windows\PowerShell\PSReadLine\ConsoleHost_history.txt" -Force

• Il comando sta in un file .ps1 su una chiavetta invece di essere digitato a mano.

Restano da fare, e vale la pena: un certificato al posto del segreto — non può essere copiato da una console perché non ci passa mai — e una scadenza breve con la rotazione segnata in agenda.

Quale metodo usare

Entrambi, in situazioni diverse.

Codice dispositivo per la macchina occasionale: non si conserva niente, non può trapelare niente, e i sei passaggi costano meno che gestire una credenziale.

App Registration quando si provisionano più macchine in una sessione: si abilita l’app, si esegue, si revoca, si disabilita.

Gli errori, in breve

Sintomo	Causa
PowerShell torna al prompt senza output	Broker WAM nel contesto OOBE defaultuser0 → usare -UseDeviceAuthentication
AADSTS530035 dopo un MFA riuscito	I Security Defaults bloccano il device code flow — blocco di flusso, non di identità
serialNumber is null · 0 devices imported	VM senza seriale SMBIOS → impostarlo in Proxmox, type1
«running scripts is disabled on this system»	Set-ExecutionPolicy -Scope Process valeva solo per la finestra precedente
Dispositivo Enabled: No in Entra	Normale — segnaposto Autopilot, si abilita da solo al join