Accesso VPN rifiutato: controllate la build prima del registro
Un valore mancante nel registro può imporre il proprio valore predefinito dopo un aggiornamento. Leggete prima il livello di build, il criterio effettivo e un evento corrispondente.
L’accesso viene rifiutato su una macchina in cui nessuno ha modificato il registro, e la risposta del forum dice di aggiungere un valore che non c’è. L’assenza non è il risultato. Windows applica valori predefiniti, un valore predefinito può cambiare con un aggiornamento installato, e quindi il criterio effettivo sul dispositivo può essere più severo di quanto suggerisca il registro.
Partite dall’errore che il client ha realmente mostrato
Leggete il messaggio, non il riepilogo che vi è arrivato di seconda mano. Una richiesta che torna subito, un timeout dopo la formazione del tunnel e un errore che compare solo quando la connessione prova a riutilizzare l’account connesso sono tre situazioni diverse. Solo la terza riguarda l’accesso singolo, e le prime due non saranno risolte da nulla in questo articolo.
Lo strato che ha preso la decisione determina quale registro gli risponde. Queste quattro osservazioni indicano quattro proprietari diversi:
| What you observe | Where the decision was made | Who owns the fix |
|---|---|---|
| The prompt returns before the tunnel forms | Local credential handling on the client | Device policy or the installed build |
| Authentication succeeds, no internal site loads | Routing or access control after login | The gateway or network owner |
| Fails only when the logged-on account is reused | SSO credential generation | The policy boundary this page covers |
| Every user on one build fails | Update level or vendor regression | Patch management |
Scrivete nel ticket il testo esatto, il minuto e il contesto dell’account. Se il tentativo è stato interattivo o automatico determina quale componente di Windows ha fatto la chiamata, e un rapporto che dice che la VPN è rotta spesso descrive un sito interno mancante invece di credenziali rifiutate.
Leggete il criterio effettivo, non il valore mancante
Stabilite prima il livello di build e di aggiornamento, perché il valore predefinito per la generazione di credenziali derivate da NTLMv1 è cambiato nelle versioni elencate di Windows 11 e Windows Server 2025. Con Credential Guard disattivato e BlockNtlmv1SSO non impostato, un aggiornamento pubblicato il 13 ottobre 2026 o dopo sposta il comportamento da Audit a Applicazione senza mai creare quel valore. Nel registro non compare nulla, e il dispositivo diventa più severo di quanto intendesse l’ultimo amministratore. È tutta la ragione per cui una ricerca nel registro dimostra così poco qui.
Tenete separate le frontiere mentre leggete l’output. LmCompatibilityLevel è il livello di risposta dell’autenticazione di rete, che decide quale sfida e quale risposta la macchina invierà a un server; non è il controllo che governa la generazione delle credenziali per l’accesso singolo, quindi abbassarlo non ripristina l’accesso. Se il dispositivo parlerà mai NTLMv1 come protocollo di rete è una terza frontiera, e le versioni attuali di Windows 11 e Server 2025 l’hanno già abbandonato. Credential Guard, la quarta, protegge i segreti sul dispositivo.
Correlate un tentativo con un evento
Riproducete il guasto una volta, annotate il minuto e poi raccogliete le prove locali in una sola sessione. Tre comandi coprono la build, il valore effettivo e il registro operativo NTLM dove viene registrata una generazione bloccata di credenziali per l’accesso singolo:
Get-ComputerInfo | Select-Object WindowsProductName, OsBuildNumber, OsVersion
reg query "HKLM\SYSTEM\CurrentControlSet\Control\Lsa" /v LmCompatibilityLevel
Get-WinEvent -LogName "Microsoft-Windows-NTLM/Operational" -MaxEvents 30 | Select-Object TimeCreated, Id, MessageUn evento nello stesso momento del guasto è una prova. Un evento di ieri, di un altro account o un registro senza alcuna voce non lo è, e il caso vuoto merita di essere annotato come vuoto e non come prova assente. Le indicazioni Microsoft sui cambiamenti di NTLMv1 nominano l’identificatore di evento per la generazione bloccata di credenziali per l’accesso singolo, quindi confrontate l’Id con quello invece di indovinare dal testo del messaggio.
Tenete insieme il messaggio del client e la visione del gateway dello stesso tentativo. Un blocco locale della generazione di credenziali, un rifiuto remoto dell’account e una rotta privata mancante dopo un accesso riuscito hanno tre proprietari diversi, e solo il primo è una questione di criterio di Windows. Ripulite l’evento prima che esca dal team: una marca temporale e un Id di evento di solito rispondono alla domanda senza i dettagli dell’account.
Passate a un metodo di accesso supportato
Se il criterio effettivo è il blocco, la risposta è un percorso di autenticazione supportato e non un silenzioso ritorno al valore predefinito. L’autenticazione basata su certificati è la destinazione abituale dove la distribuzione la supporta, e richiede iscrizione, distribuzione della fiducia e un gateway che accetti i certificati. Le indicazioni Microsoft sui prossimi cambiamenti di NTLMv1 sono il documento da citare quando il caso viene riesaminato.
Disattivare Credential Guard come esperimento rimuove la protezione senza fornire un accesso sostitutivo, e le restrizioni documentate sulle credenziali riutilizzabili sono la ragione per cui si tratta di una decisione di progettazione e non di un passo diagnostico. Se viene autorizzata un’eccezione temporanea, datele un perimetro, un responsabile e una data di dismissione, e mantenete un percorso di amministrazione indipendente verso la macchina nel caso la modifica vi chiuda fuori dalla connessione che vi serve. Il test di accettazione è l’autenticazione prevista più la risorsa dietro di essa, non la scomparsa di un codice di errore locale.