VPN-innlogging avvist: sjekk bygget før registeret
En manglende registerverdi kan håndheve sin egen standardverdi etter en oppdatering. Les byggenivået, den effektive policyen og én samsvarende hendelse først.
Innloggingen avvises på en maskin der ingen har redigert registeret, og forumsvaret sier at du skal legge til en verdi som ikke finnes der. Fravær er ikke funnet. Windows bruker standardverdier, en standardverdi kan endres med en installert oppdatering, og derfor kan den effektive policyen på enheten være strengere enn registeret antyder.
Start med feilen klienten faktisk viste
Les meldingen i stedet for sammendraget som nådde deg på andre hånd. En forespørsel som kommer umiddelbart tilbake, en tidsavbrudd etter at tunnelen er dannet, og en feil som bare vises når tilkoblingen prøver å gjenbruke den påloggede kontoen, er tre forskjellige situasjoner. Bare den tredje handler i det hele tatt om enkel pålogging, og de to første blir ikke rettet av noe i denne artikkelen.
Laget som tok avgjørelsen bestemmer hvilken logg som svarer på den. Disse fire observasjonene peker på fire forskjellige eiere:
| 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 nøyaktige teksten, minuttet og kontokonteksten i saken. Om forsøket var interaktivt eller automatisk avgjør hvilken Windows-komponent som gjorde kallet, og en rapport som sier at VPN-en er ødelagt, beskriver ofte et manglende internt nettsted i stedet for avviste påloggingsdata.
Les den effektive policyen, ikke den manglende verdien
Fastslå bygge- og oppdateringsnivået først, fordi standarden for generering av påloggingsdata avledet fra NTLMv1 ble endret i de oppførte utgivelsene av Windows 11 og Windows Server 2025. Med Credential Guard av og BlockNtlmv1SSO ikke satt flytter en oppdatering utgitt 13. oktober 2026 eller senere atferden fra Revisjon til Håndhevelse uten noen gang å opprette den verdien. Ingenting vises i registeret, og enheten blir strengere enn den siste administratoren hadde tenkt. Det er hele grunnen til at et registersøk beviser så lite her.
Hold grensene atskilt mens du leser utdataene. LmCompatibilityLevel er svarnivået for nettverksautentisering, som bestemmer hvilken utfordring og respons maskinen sender til en server; det er ikke kontrollen som styrer generering av påloggingsdata for enkel pålogging, så å senke det gjenoppretter ikke påloggingen. Om enheten i det hele tatt vil snakke NTLMv1 som nettverksprotokoll, er en tredje grense, og de gjeldende utgivelsene av Windows 11 og Server 2025 har allerede droppet den. Credential Guard, den fjerde, beskytter hemmeligheter på enheten.
Korrelér ett forsøk med én hendelse
Gjenskap feilen én gang, noter minuttet, og hent deretter de lokale bevisene i én økt. Tre kommandoer dekker bygget, den effektive verdien og NTLM-driftsloggen der en blokkert generering av påloggingsdata for enkel pålogging registreres:
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, MessageEn hendelse på samme tidspunkt som feilen er bevis. En hendelse fra i går, fra en annen konto eller en logg uten noen oppføring er det ikke, og det tomme tilfellet er verdt å registrere som tomt i stedet for som manglende bevis. Microsofts veiledning om NTLMv1-endringene navngir hendelses-ID-en for blokkert generering av påloggingsdata for enkel pålogging, så sammenlign Id med den i stedet for å gjette ut fra meldingsteksten.
Hold klientens egen melding og gatewayens syn på samme forsøk sammen. En lokal blokkering av påloggingsdatagenerering, en ekstern kontoforvisning og en manglende privat rute etter vellykket pålogging har tre forskjellige eiere, og bare den første er et Windows-policyspørsmål. Rens hendelsen før den forlater teamet: et tidsstempel og en hendelses-ID svarer vanligvis på spørsmålet uten kontodetaljene.
Bytt til en støttet påloggingsmetode
Hvis den effektive policyen er blokkeringen, er svaret en støttet autentiseringsvei og ikke en stille tilbakeføring av standarden. Sertifikatbasert autentisering er det vanlige målet der utrullingen støtter det, og den krever registrering, distribusjon av tillit og en gateway som godtar sertifikatene. Microsofts veiledning om de kommende NTLMv1-endringene er dokumentet som siteres når saken gjennomgås.
Å slå av Credential Guard som et eksperiment fjerner beskyttelsen uten å levere en erstatningspålogging, og de dokumenterte begrensningene på gjenbrukbare påloggingsdata er grunnen til at dette er en designbeslutning og ikke et diagnostisk trinn. Hvis en midlertidig unntak godkjennes, gi den et omfang, en eier og en sluttdato, og behold en uavhengig administrasjonsvei til maskinen i tilfelle endringen låser deg ute fra tilkoblingen du trenger. Aksepttesten er den tiltenkte autentiseringen pluss ressursen bak den, ikke forsvinningen av én lokal feilkode.