LmCompatibilityLevel è un criterio di Windows, non una correzione per la VPN

Qualcuno non raggiunge una condivisione file tramite VPN, legge che abbassare LmCompatibilityLevel risolve i problemi NTLM e lo modifica su un server condiviso. La mattina dopo altre applicazioni falliscono, e il problema originale è ancora lì. Questa impostazione non è mai stata un interruttore per singolo tunnel; è una dichiarazione a livello di macchina su quali risposte di autenticazione questo sistema invierà e accetterà. Modificarla per riparare un solo accesso riscrive le regole per ogni accesso che la macchina esegue.

Leggere i livelli documentati è il modo più rapido per smettere di trattare un valore di criterio come un numero magico.

Tre livelli, tre promesse diverse

Il livello 1 fa inviare al client risposte LM e NTLM, usando la sicurezza di sessione NTLMv2 quando la negoziazione lo consente. Il livello 3 fa inviare al client solo risposte NTLMv2, che non è lo stesso che rifiutare ogni risposta legacy sul lato ricevente. Il livello 5 mantiene il client su NTLMv2 e aggiunge il rifiuto documentato di LM e NTLMv1 da parte del controller di dominio. Tre numeri, e la differenza tra loro è una decisione di criterio e non una preferenza.

Queste differenze spiegano perché copiare un valore da un caso funzionante non è affidabile. Spostare un client mal configurato dal livello 1 alla linea di base approvata può essere corretto. Spostare una distribuzione rafforzata dal livello 5 al 3 solo perché un thread di forum citava 3 allenta un confine che qualcuno ha scelto deliberatamente, e lo fa per ogni servizio con cui la macchina parla.

Leggi il criterio effettivo, non un valore del registro

Uno sguardo in sola lettura al valore locale è un punto di partenza ragionevole: Get-ItemProperty -LiteralPath 'HKLM:\System\CurrentControlSet\Control\Lsa' -Name LmCompatibilityLevel. L'assenza di un valore non significa che il criterio effettivo sia zero, perché un criterio di dominio o di sicurezza locale può impostarlo altrove, e il ruolo della macchina cambia ciò che fa con il numero.

Controlla il criterio gestito, il ruolo del sistema e la build reale prima di concludere qualcosa. Una workstation e un controller di dominio con lo stesso valore si comportano diversamente all'estremo superiore, ed è la parte che le persone dimenticano quando confrontano due macchine.

Individua quale autenticazione è realmente fallita

Problemi di ticket Kerberos, rifiuti NTLM e fallimenti di ammissione VPN richiedono prove diverse. Tieni insieme il servizio di destinazione, l'account e l'errore esatto in un'unica nota, poi guarda ciò che il servizio ha richiesto e non ciò che preferisce il client. Quella singola nota evita la svolta sbagliata più comune, cioè cambiare un valore lato client per rispondere a un rifiuto lato server.

Abbassare un criterio ripetutamente finché un errore di accesso generico scompare non è diagnosi; è una modifica che nasconde la prova. Se l'applicazione usa Kerberos, il livello di compatibilità NTLM non è nemmeno il controllo pertinente, e hai allentato un confine per nulla.

Alcuni supporti di protocollo non possono essere ripristinati

Windows 11 24H2 e Windows Server 2025 non includono più affatto l'autenticazione di rete NTLMv1. Nessun numero di compatibilità riporta un protocollo che la build non implementa più, quindi un downgrade che sembrava aiutare su una versione precedente fallirà semplicemente su una più recente. Microsoft documenta quella rimozione separatamente dall'impostazione del criterio, e confondere le due cose produce consigli che non possono funzionare.

Una restrizione correlata ma distinta si applica alle credenziali derivate da NTLMv1 usate dall'accesso singolo basato su MSCHAPv2. È una questione di credenziali derivate, non del protocollo di rete stesso, e non di questo valore del registro. Trattare i tre come lo stesso argomento è il modo in cui le organizzazioni finiscono per indebolire un controllo mentre ne cercano di riparare un altro.

Modificalo tramite il proprietario, poi prova entrambe le direzioni

Se una correzione è davvero necessaria, falla passare dal proprietario del criterio così che la linea di base resti coerente, e annota perché. Poi prova un'applicazione autorizzata con la nuova impostazione e un caso di autenticazione volutamente vietato, perché una modifica che ripara una condivisione e permette silenziosamente risposte legacy altrove non è un successo. Una connessione VPN funzionante dimostra che l'ammissione è riuscita. Non convalida il criterio di autenticazione della macchina, e di certo non dimostra che ogni servizio dietro di essa si comporti ancora come progettato.

Se il servizio che fallisce è basato su Kerberos, smetti del tutto di guardare questa impostazione. Se è un dispositivo legacy che davvero non può fare meglio, documenta quell'eccezione e limitane l'ambito, perché l'alternativa è una linea di base indebolita in silenzio che nessuno ricorda di aver approvato.