VPN-inloggning avvisad: kontrollera bygget före registret
Ett saknat registervärde kan genomdriva sitt eget standardvärde efter en uppdatering. Läs först byggnivån, den effektiva principen och en matchande händelse.
Inloggningen avvisas på en dator där ingen har redigerat registret, och forumsvaret säger att du ska lägga till ett värde som inte finns där. Frånvaro är inte fyndet. Windows tillämpar standardvärden, ett standardvärde kan ändras med en installerad uppdatering, och därför kan den effektiva principen på enheten vara strängare än registret antyder.
Börja med felet som klienten faktiskt visade
Läs meddelandet, inte sammanfattningen som nådde dig på andra hand. En förfrågan som återvänder omedelbart, en timeout efter att tunneln bildats och ett fel som bara visas när anslutningen försöker återanvända det inloggade kontot är tre olika situationer. Bara den tredje handlar överhuvudtaget om enkel inloggning, och de två första åtgärdas inte av något i den här artikeln.
Lagret som fattade beslutet avgör vilken logg som svarar på det. Dessa fyra observationer pekar på fyra olika ägare:
| 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 |
Skriv den exakta texten, minuten och kontokontexten i ärendet. Om försöket var interaktivt eller automatiskt avgör vilken Windows-komponent som gjorde anropet, och en rapport som säger att VPN:en är trasig beskriver ofta en saknad intern webbplats i stället för avvisade inloggningsuppgifter.
Läs den effektiva principen, inte det saknade värdet
Fastställ först bygg- och uppdateringsnivån, eftersom standarden för generering av inloggningsuppgifter som härrör från NTLMv1 ändrades i de angivna utgåvorna av Windows 11 och Windows Server 2025. Med Credential Guard av och BlockNtlmv1SSO inte satt flyttar en uppdatering som släpptes den 13 oktober 2026 eller senare beteendet från Granskning till Tillämpning utan att någonsin skapa det värdet. Ingenting visas i registret, och enheten blir strängare än den senaste administratören avsåg. Det är hela anledningen till att en registersökning bevisar så lite här.
Håll gränserna åtskilda medan du läser utdata. LmCompatibilityLevel är svarsnivån för nätverksautentisering, som avgör vilken utmaning och vilket svar datorn skickar till en server; det är inte kontrollen som styr genereringen av inloggningsuppgifter för enkel inloggning, så att sänka den återställer inte inloggningen. Om enheten överhuvudtaget kommer att tala NTLMv1 som nätverksprotokoll är en tredje gräns, och de nuvarande utgåvorna av Windows 11 och Server 2025 har redan övergett det. Credential Guard, den fjärde, skyddar hemligheter på enheten.
Korrelera ett försök med en händelse
Återskapa felet en gång, notera minuten och hämta sedan de lokala bevisen i en enda sittning. Tre kommandon täcker bygget, det effektiva värdet och NTLM-driftloggen där en blockerad generering av inloggningsuppgifter för enkel inloggning registreras:
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, Message
En händelse vid samma tidpunkt som felet är bevis. En händelse från i går, från ett annat konto eller en logg utan någon post är det inte, och det tomma fallet är värt att registrera som tomt i stället för som saknat bevis. Microsofts vägledning om NTLMv1-ändringarna anger händelse-ID:t för blockerad generering av inloggningsuppgifter för enkel inloggning, så jämför Id med det i stället för att gissa från meddelandetexten.
Håll klientens eget meddelande och gatewayens syn på samma försök tillsammans. En lokal blockering av inloggningsuppgiftsgenerering, en avvisning av kontot på distans och en saknad privat rutt efter en lyckad inloggning har tre olika ägare, och bara den första är en Windows-principfråga. Rensa händelsen innan den lämnar teamet: en tidsstämpel och ett händelse-ID besvarar vanligtvis frågan utan kontouppgifterna.
Byt till en inloggningsmetod som stöds
Om den effektiva principen är blockeringen är svaret en autentiseringsväg som stöds och inte en tyst återgång till standarden. Certifikatbaserad autentisering är det vanliga målet där utrullningen stöder det, och den kräver registrering, distribution av förtroende och en gateway som accepterar certifikaten. Microsofts vägledning om de kommande NTLMv1-ändringarna är dokumentet som citeras när ärendet granskas.
Att stänga av Credential Guard som ett experiment tar bort skyddet utan att erbjuda en ersättningsinloggning, och de dokumenterade begränsningarna för återanvändbara inloggningsuppgifter är anledningen till att detta är ett designbeslut och inte ett diagnostiskt steg. Om ett tillfälligt undantag godkänns, ge det ett omfång, en ägare och ett slutdatum, och behåll en oberoende administrationsväg till datorn om ändringen låser dig ute från anslutningen du behöver. Acceptanstestet är den avsedda autentiseringen plus resursen bakom den, inte försvinnandet av en lokal felkod.