KB5127648 e NTLMv1: perché PEAP-MSCHAPv2 Wi-Fi, LAN e VPN hanno smesso di connettersi e come risolvere il problema definitivamente

La risposta breve

A partire da KB5127648, l'aggiornamento cumulativo di ottobre 2026 per Windows 11 24H2, 25H2 e 26H2, Windows blocca per impostazione predefinita le credenziali derivate da NTLMv1 per il single sign-on. Windows Server 2025 riceve la stessa modifica con il suo aggiornamento di ottobre 2026. Sui dispositivi privi di Credential Guard, le connessioni Wi-Fi, Ethernet (802.1X cablato) e VPN che utilizzano PEAP-MSCHAPv2 o EAP-MSCHAPv2 con credenziali Windows non si connettono più automaticamente.

Impostare il valore di registro BlockNtlmv1SSO a 0 ripristina il comportamento precedente per il momento. Il fix definitivo raccomandato da Microsoft è l'autenticazione basata su certificati con EAP-TLS.

TL;DR

• Cosa è cambiato: Windows applica ora BlockNtlmv1SSO su ogni dispositivo in cui un amministratore non lo ha configurato esplicitamente. Microsoft ha annunciato questo cambiamento nel post MC1508562 del Message Center e lo documenta in KB5066470.
• Chi è colpito: I dispositivi privi di Credential Guard che utilizzano il single sign-on basato su MS-CHAPv2, tipicamente client Windows aggiunti al dominio.
• Soluzione temporanea: Impostare BlockNtlmv1SSO a 0. Microsoft stessa afferma che questa impostazione non dovrebbe essere usata a lungo termine.
• Fix definitivo: Migrare a EAP-TLS. Con SCEPman puoi farlo senza costruire una PKI on-premises.

Cosa è cambiato con KB5127648

Microsoft sta eliminando NTLM gradualmente, passo dopo passo. L'ultimo passaggio colpisce un protocollo su cui molte reti fanno ancora affidamento ogni giorno: MS-CHAPv2. Si basa su credenziali derivate da NTLMv1, e Windows non le fornisce più per il single sign-on.

Microsoft ha annunciato l'applicazione forzata nel post MC1508562 del Message Center, "Take action: NTLMv1 hardening changes might affect network connections on devices without Credential Guard". Il contesto tecnico è in KB5066470.

Microsoft definisce questa modifica come un cambiamento pianificato di security hardening, non un problema noto dell'aggiornamento. In altre parole, è qui per restare.

Sei interessato?

Probabilmente sei interessato se si verificano tutte le seguenti condizioni:

• I tuoi dispositivi eseguono Windows 11 24H2 o versioni successive, oppure Windows Server 2025, con l'aggiornamento di ottobre 2026 (KB5127648 su Windows 11) installato.
• Credential Guard è disabilitato su quei dispositivi.
• Il tuo Wi-Fi, Ethernet (802.1X cablato) o VPN utilizza PEAP-MSCHAPv2 o EAP-MSCHAPv2 con single sign-on. Si tratta tipicamente di un dispositivo aggiunto al dominio con l'opzione "Usa automaticamente il nome e la password di accesso Windows" abilitata.
• Il valore di registro BlockNtlmv1SSO non è mai stato impostato.

Non sei interessato da questo cambiamento se i tuoi dispositivi utilizzano già l'autenticazione basata su certificati (EAP-TLS). I dispositivi con Credential Guard abilitato bloccavano già questo comportamento, quindi l'SSO basato su password era già non funzionante su di essi. Il cambiamento riguarda Windows, pertanto i client macOS, iOS, Android e Linux non sono interessati.

Come si manifesta

• I dispositivi non si connettono più automaticamente e agli utenti viene mostrata una richiesta di credenziali.
• Inserire la password manualmente funziona ancora, ma Windows non riesce a salvarla per la volta successiva.
• I flussi di lavoro che si connettevano senza interazione dell'utente smettono di funzionare, ad esempio dispositivi condivisi o kiosk e profili VPN che si connettono automaticamente.
• Il client registra l'Event ID 4025 ("blocked") in Microsoft-Windows-NTLM/Operational. In modalità Audit registra invece l'Event ID 4024.

Il problema si verifica sul client, quindi i log di RADIUS o NPS potrebbero non mostrare nulla o quasi. Inizia la risoluzione dei problemi sull'endpoint.

Come verificare un dispositivo

# BlockNtlmv1SSO è configurato? (nessun valore = Windows usa il nuovo default Enforce)
reg query "HKLM\SYSTEM\CurrentControlSet\Control\Lsa\MSV1_0" /v BlockNtlmv1SSO

# Windows ha auditato (4024) o bloccato (4025) le credenziali derivate da NTLMv1?
Get-WinEvent -LogName 'Microsoft-Windows-NTLM/Operational' -FilterXPath '*[System[(EventID=4024 or EventID=4025)]]' -MaxEvents 50

La soluzione temporanea: imposta BlockNtlmv1SSO a 0

Puoi riportare i dispositivi interessati in modalità Audit. Windows consente di nuovo le credenziali derivate da NTLMv1 e registra ogni utilizzo con l'Event ID 4024.

Riga di comando

reg add "HKLM\SYSTEM\CurrentControlSet\Control\Lsa\MSV1_0" /v BlockNtlmv1SSO /t REG_DWORD /d 0 /f

Remediation con Intune (eseguire nel contesto di sistema)

# Script di rilevamento: conforme solo se BlockNtlmv1SSO è esplicitamente impostato a 0
$v = (Get-ItemProperty -Path 'HKLM:\SYSTEM\CurrentControlSet\Control\Lsa\MSV1_0' -Name 'BlockNtlmv1SSO' -ErrorAction SilentlyContinue).BlockNtlmv1SSO
if ($v -eq 0) { exit 0 } else { exit 1 }

# Script di correzione
New-ItemProperty -Path 'HKLM:\SYSTEM\CurrentControlSet\Control\Lsa\MSV1_0' -Name 'BlockNtlmv1SSO' -PropertyType DWord -Value 0 -Force | Out-Null

Per i dispositivi aggiunti al dominio, utilizza un elemento del registro di Group Policy Preferences con la stessa chiave, nome del valore, tipo e dati.

Perché si tratta solo di una soluzione temporanea

• Riapre un percorso debole. Microsoft afferma che gli endpoint basati su MS-CHAPv2 "sono soggetti a rischi simili a quelli che interessano NTLMv1" e consiglia che questa impostazione "debba essere valutata attentamente e non usata a lungo termine".
• Non aiuta i dispositivi con Credential Guard. Questi bloccano l'SSO con MS-CHAPv2 indipendentemente da questa impostazione.
• I dispositivi offline non possono ricevere la policy. I dispositivi che hanno già perso l'accesso alla rete potrebbero aver bisogno di una rete cablata o guest per ricevere l'impostazione.
• Disinstallare l'aggiornamento non è un'alternativa. Lascerebbe i tuoi dispositivi senza le patch di sicurezza del mese.

Usa la soluzione temporanea per guadagnare tempo, assegnale una data di scadenza documentata e utilizza quel tempo per migrare.

Il fix definitivo: EAP-TLS al posto delle password

Microsoft raccomanda di eliminare la dipendenza da MS-CHAPv2 e di spostare le connessioni Wi-Fi e VPN all'autenticazione basata su certificati con EAP-TLS. Il dispositivo o l'utente dimostra la propria identità con un certificato e una chiave privata invece di una password, e la chiave privata può essere protetta dal TPM.

Oltre a risolvere l'interruzione, si ottiene una migliore esperienza utente e una postura di sicurezza più solida.

Perché così tante reti funzionano ancora con le password

Il protocollo non è la parte difficile. Lo è la PKI. La configurazione classica include AD CS, NDES, l'Intune Certificate Connector, un application proxy, la pubblicazione della CRL, l'alta disponibilità e il patching. Sono molti componenti solo per mettere un certificato su un laptop, ed è per questo che molti team hanno rimandato la migrazione per anni. Approfondisci nel post Microsoft ADCS Alternatives in 2026.

Come SCEPman elimina la complessità della PKI

SCEPman è un'autorità di certificazione nativa di Azure che gira interamente nel tuo tenant Azure, con le chiavi in Azure Key Vault.

• Avvio rapido: Distribuisci tramite Azure Marketplace, template ARM o Terraform. La maggior parte dei team emette il primo certificato in meno di un'ora.
• Dispositivi gestiti: Microsoft Intune, Jamf Pro e altri MDM emettono e rinnovano automaticamente i certificati di dispositivi e utenti tramite SCEP.
• Validazione in tempo reale: I certificati sono associati all'oggetto utente o dispositivo e verificati tramite OCSP. Quando un'identità cambia, l'accesso viene revocato automaticamente.
• Compatibile con la tua rete: SCEPman supporta Cisco e Meraki, HPE Aruba, Fortinet, Juniper e altri, e funziona con il tuo server RADIUS esistente.
• Nessun server RADIUS necessario: Combinato con RADIUSaaS, ottieni una soluzione completamente cloud-native per l'accesso Wi-Fi, LAN e VPN basato su certificati.

Il percorso di migrazione in sei passi

1. Fai un inventario. Individua quali SSID, policy 802.1X cablate e profili VPN usano ancora MS-CHAPv2. Gli Event ID 4024 e 4025 mostrano quali dispositivi ne dipendono.
2. Guadagna tempo dove necessario. Imposta BlockNtlmv1SSO a 0 sui dispositivi critici, ma documentalo e assegna una data di scadenza.
3. Distribuisci SCEPman e distribuisci il suo certificato CA radice, tramite un profilo di certificato attendibile di Intune o tramite Group Policy.
4. Distribuisci i certificati. Emetti certificati di dispositivo (e certificati utente dove necessario) tramite Intune, Jamf Pro o altri profili SCEP MDM.
5. Passa gradualmente. Abilita EAP-TLS sul tuo server RADIUS (NPS, il tuo RADIUS esistente o RADIUSaaS) insieme a PEAP. Poi sposta i tuoi profili Wi-Fi, 802.1X e VPN a EAP-TLS un gruppo alla volta.
6. Fai pulizia. Rimuovi le policy MS-CHAPv2, poi reimposta BlockNtlmv1SSO a 1 o elimina il valore in modo che Windows utilizzi di nuovo il default sicuro:

reg delete "HKLM\SYSTEM\CurrentControlSet\Control\Lsa\MSV1_0" /v BlockNtlmv1SSO /f

Conclusione

Microsoft ha preso la decisione: l'SSO di rete basato su password tramite MS-CHAPv2 non ha futuro su Windows. Puoi tamponare con una patch attorno a KB5127648 per qualche settimana, oppure puoi cogliere questo momento per passare definitivamente all'accesso basato su certificati.

PKI senza complicazioni. Certificati affidabili.

Prova SCEPman gratuitamente

FAQ