KB5127648 og NTLMv1: Hvorfor PEAP-MSCHAPv2 Wi-Fi, LAN og VPN stoppede med at forbinde, og hvordan du løser det permanent
KB5127648 blokerer NTLMv1 SSO som standard. Hvorfor PEAP-MSCHAPv2 Wi-Fi, LAN og VPN fejler, BlockNtlmv1SSO-workaround og den permanente løsning: EAP-TLS.

Det korte svar
Siden KB5127648, den kumulative opdatering fra oktober 2026 til Windows 11 24H2, 25H2 og 26H2, blokerer Windows NTLMv1-afledte legitimationsoplysninger til single sign-on som standard. Windows Server 2025 får den samme ændring med sin oktober 2026-opdatering. På enheder uden Credential Guard forbinder Wi-Fi, Ethernet (kabelbaseret 802.1X) og VPN-forbindelser, der bruger PEAP-MSCHAPv2 eller EAP-MSCHAPv2 med Windows-legitimationsoplysninger, ikke længere automatisk.
Hvis du sætter registreringsværdien BlockNtlmv1SSO til 0, gendannes den tidligere adfærd midlertidigt. Den permanente løsning, som Microsoft anbefaler, er certifikatbaseret godkendelse med EAP-TLS.
TL;DR
- Hvad ændrede sig: Windows håndhæver nu BlockNtlmv1SSO på alle enheder, hvor en administrator ikke har konfigureret det. Microsoft annoncerede dette i Message Center-opslaget MC1508562 og dokumenterer det i KB5066470.
- Hvem rammes: Enheder uden Credential Guard, der bruger MS-CHAPv2-baseret single sign-on, typisk domænetilsluttede Windows-klienter.
- Hurtig workaround: Sæt BlockNtlmv1SSO til 0. Microsoft understreger selv, at indstillingen ikke bør bruges på lang sigt.
- Permanent løsning: Skift til EAP-TLS. Med SCEPman kan du gøre det uden at bygge en on-premises PKI.
Hvad ændrede sig med KB5127648
Microsoft har udfaset NTLM trin for trin. Det seneste trin rammer en protokol, som mange netværk stadig er afhængige af i dagligdagen: MS-CHAPv2. Den er bygget på NTLMv1-afledte legitimationsoplysninger, og Windows udleverer dem ikke længere til single sign-on.
| Hvornår | Hvad skete der |
|---|---|
| Ultimo august 2025 | Windows 11 24H2 og nyere begynder at auditere brug af NTLMv1-afledte legitimationsoplysninger (Event ID 4024). |
| November 2025 | Udrulning af auditering begynder på Windows Server 2025. |
| 13. oktober 2026 | KB5127648 (Windows 11 24H2, 25H2, 26H2) skifter standarden fra Audit til Enforce på enheder, hvor BlockNtlmv1SSO ikke er konfigureret. Windows Server 2025 følger med sin oktober 2026-opdatering. |
Microsoft annoncerede håndhævelsen i Message Center-opslaget MC1508562, "Take action: NTLMv1 hardening changes might affect network connections on devices without Credential Guard". Den tekniske baggrund findes i KB5066470.
Microsoft betegner dette som en planlagt sikkerhedshærdende ændring, ikke et kendt problem med opdateringen. Den er med andre ord kommet for at blive.
Er du påvirket?
Du er sandsynligvis påvirket, hvis alle følgende gælder:
- Dine enheder kører Windows 11 24H2 eller nyere, eller Windows Server 2025, med oktober 2026-opdateringen (KB5127648 på Windows 11) installeret.
- Credential Guard er deaktiveret på disse enheder.
- Dit Wi-Fi, Ethernet (kabelbaseret 802.1X) eller VPN bruger PEAP-MSCHAPv2 eller EAP-MSCHAPv2 med single sign-on. Dette er typisk en domænetilsluttet enhed med "Brug automatisk mit Windows-logonnavn og -adgangskode" aktiveret.
- Registreringsværdien BlockNtlmv1SSO er aldrig blevet sat.
Du er ikke påvirket af denne ændring, hvis dine enheder allerede bruger certifikatbaseret godkendelse (EAP-TLS). Enheder med Credential Guard aktiveret blokerede allerede denne adfærd, så adgangskodebaseret SSO var allerede ikke-fungerende der. Ændringen er i Windows, så macOS-, iOS-, Android- og Linux-klienter er ikke påvirket.
Sådan ser det ud
- Enheder forbinder ikke længere automatisk, og brugerne får en legitimationsprompt.
- Det virker stadig at skrive adgangskoden manuelt, men Windows kan ikke gemme den til næste gang.
- Arbejdsgange, der tidligere forbandt uden brugerinteraktion, holder op med at fungere, for eksempel delte enheder eller kiosk-enheder og VPN-profiler, der forbinder automatisk.
- Klienten logger Event ID 4025 ("blokeret") i Microsoft-Windows-NTLM/Operational. I Audit-tilstand logges Event ID 4024 i stedet.
Fejlen opstår på klienten, så dine RADIUS- eller NPS-logs viser måske lidt eller ingenting. Begynd fejlfinding på endpointet.
Sådan undersøger du en enhed
# Er BlockNtlmv1SSO konfigureret? (ingen værdi = Windows bruger den nye Enforce-standard)
reg query "HKLM\SYSTEM\CurrentControlSet\Control\Lsa\MSV1_0" /v BlockNtlmv1SSO
# Har Windows auditeret (4024) eller blokeret (4025) NTLMv1-afledte legitimationsoplysninger?
Get-WinEvent -LogName 'Microsoft-Windows-NTLM/Operational' -FilterXPath '*[System[(EventID=4024 or EventID=4025)]]' -MaxEvents 50
Den hurtige workaround: sæt BlockNtlmv1SSO til 0
Du kan sætte påvirkede enheder tilbage i Audit-tilstand. Windows tillader da NTLMv1-afledte legitimationsoplysninger igen og logger hvert enkelt tilfælde med Event ID 4024.
| Indstilling | Værdi |
|---|---|
| Nøgle | HKEY_LOCAL_MACHINE\ |
| Værdinavn | BlockNtlmv1SSO |
| Type | REG_DWORD |
| Data | 0 = Audit (tilladt, Event ID 4024), 1 = Enforce (blokeret, Event ID 4025) |
Kommandolinje
reg add "HKLM\SYSTEM\CurrentControlSet\Control\Lsa\MSV1_0" /v BlockNtlmv1SSO /t REG_DWORD /d 0 /f
Intune remediation (kør i systemkontekst)
# Detection script: compliant only if BlockNtlmv1SSO is explicitly set to 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 }
# Remediation script
New-ItemProperty -Path 'HKLM:\SYSTEM\CurrentControlSet\Control\Lsa\MSV1_0' -Name 'BlockNtlmv1SSO' -PropertyType DWord -Value 0 -Force | Out-Null
Til domænetilsluttede enheder bruger du et Group Policy Preferences-registreringselement med samme nøgle, værdinavn, type og data.
Hvorfor det kun er en workaround
- Det genåbner en svag vej. Microsoft siger, at MS-CHAPv2-baserede endpoints "er udsat for risici svarende til dem, der påvirker NTLMv1", og råder til, at denne indstilling "bør evalueres nøje og ikke bruges på lang sigt."
- Det hjælper ikke enheder med Credential Guard. De blokerer MS-CHAPv2 SSO uanset denne indstilling.
- Offline-enheder kan ikke modtage politikker. Enheder, der allerede har mistet netværksadgang, kan have brug for et kabelbaseret netværk eller et gæstenetværk for at modtage indstillingen.
- Afinstallation af opdateringen er ikke et alternativ. Det efterlader dine enheder uden månedens sikkerhedsrettelser.
Brug workarounden til at købe tid, giv den en dokumenteret slutdato, og brug den tid på at migrere.
Den permanente løsning: EAP-TLS i stedet for adgangskoder
Microsoft anbefaler at fjerne afhængigheden af MS-CHAPv2 og flytte Wi-Fi- og VPN-forbindelser til certifikatbaseret godkendelse med EAP-TLS. Enheden eller brugeren beviser da sin identitet med et certifikat og en privat nøgle i stedet for en adgangskode, og den private nøgle kan beskyttes af TPM'en.
| PEAP-MSCHAPv2 | EAP-TLS | |
|---|---|---|
| Klientlegitimation | Adgangskode (NT-hash-baseret) | X.509-certifikat og privat nøgle |
| Afhænger af NTLM-ærens kryptografi | Ja | Nej |
| Påvirket af KB5127648 og Credential Guard | Ja | Nej |
| Adgangskodeskift kan bryde forbindelsen | Ja | Nej |
| Udsat for opfangning af legitimationsoplysninger og offline-crackning | Ja | Ingen adgangskode at stjæle |
| Knytter adgang til en administreret enhed | Nej | Ja |
| Microsofts anbefaling | Migrer væk | Anbefalet |
Ud over at løse nedbruddet får du en bedre brugeroplevelse og en stærkere sikkerhedsprofil.
Hvorfor så mange netværk stadig kører på adgangskoder
Protokollen er ikke det svære. PKI'en er. Den klassiske opsætning inkluderer AD CS, NDES, Intune Certificate Connector, en application proxy, CRL-publicering, høj tilgængelighed og patching. Det er mange bevægelige dele bare for at lægge et certifikat på en laptop, og det er årsagen til, at mange teams har udskudt skiftet i årevis. Læs mere om det i Microsoft ADCS Alternatives in 2026.
Hvordan SCEPman tager PKI'en ud af ligningen
SCEPman er en Azure-native certifikatmyndighed, der kører udelukkende i din egen Azure-tenant med nøgler i Azure Key Vault.
- Hurtig opstart: Deployment via Azure Marketplace, ARM-skabelon eller Terraform. De fleste teams udsteder deres første certifikat på under en time.
- Administrerede enheder: Microsoft Intune, Jamf Pro og andre MDM'er udsteder og fornyer enheds- og brugercertifikater automatisk via SCEP.
- Realtidsvalidering: Certifikater er bundet til bruger- eller enhedsobjektet og kontrolleres via OCSP. Når en identitet ændres, tilbagekaldes adgangen automatisk.
- Virker med dit netværk: SCEPman understøtter Cisco og Meraki, HPE Aruba, Fortinet, Juniper og andre, og fungerer med din eksisterende RADIUS-server.
- Ingen RADIUS-servere nødvendige: Kombineret med RADIUSaaS får du en komplet cloud-native løsning til certifikatbaseret Wi-Fi-, LAN- og VPN-adgang.
Din migrationssti i seks trin
- Lav en opgørelse. Find ud af, hvilke SSID'er, kabelbaserede 802.1X-politikker og VPN-profiler der stadig bruger MS-CHAPv2. Event ID 4024 og 4025 viser dig, hvilke enheder der er afhængige af det.
- Køb tid, hvor det er nødvendigt. Sæt BlockNtlmv1SSO til 0 på kritiske enheder, men dokumentér det og giv det en slutdato.
- Deploy SCEPman og distribuer dets root CA-certifikat, enten via en Intune-profil for betroede certifikater eller via Group Policy.
- Rul certifikater ud. Udsted enhedscertifikater (og brugercertifikater, hvor det er nødvendigt) via Intune, Jamf Pro eller andre MDM SCEP-profiler.
- Skift gradvist. Aktivér EAP-TLS på din RADIUS-server (NPS, din eksisterende RADIUS eller RADIUSaaS) side om side med PEAP. Flyt derefter dine Wi-Fi-, 802.1X- og VPN-profiler til EAP-TLS én gruppe ad gangen.
- Ryd op. Fjern MS-CHAPv2-politikkerne, og sæt derefter BlockNtlmv1SSO tilbage til 1, eller slet værdien, så Windows bruger den sikre standard igen:
reg delete "HKLM\SYSTEM\CurrentControlSet\Control\Lsa\MSV1_0" /v BlockNtlmv1SSO /f
Bundlinjen
Microsoft har truffet beslutningen: adgangskodebaseret netværks-SSO via MS-CHAPv2 har ingen fremtid på Windows. Du kan lappe rundt om KB5127648 i et par uger, eller du kan bruge dette øjeblik til at skifte til certifikatbaseret adgang for bestandigt.
Kedelig PKI. Pålidelige certifikater.
FAQ
Hvorfor beder mit Wi-Fi om en adgangskode efter installation af KB5127648?
KB5127648 får Windows til at blokere NTLMv1-afledte legitimationsoplysninger til single sign-on som standard. PEAP-MSCHAPv2 har netop brug for disse legitimationsoplysninger til automatisk at logge ind med dit Windows-logon, så Windows falder tilbage til en legitimationsprompt.
Bør jeg afinstallere KB5127648?
Nej. Ændringen er et planlagt hærднingstrin, ikke en fejl, og afinstallation af opdateringen efterlader enheder uden månedens sikkerhedsrettelser. Brug BlockNtlmv1SSO-workarounden midlertidigt og migrer til EAP-TLS.
Hjælper registry-workarounden på enheder med Credential Guard?
Nej. Credential Guard blokerer MS-CHAPv2 single sign-on uanset BlockNtlmv1SSO. Disse enheder har brug for certifikatbaseret godkendelse.
Er macOS-, iOS-, Android- eller Linux-enheder påvirket?
Nej. Ændringen er i Windows. Ikke-Windows-klienter, der bruger PEAP-MSCHAPv2, fortsætter med at virke, selvom protokollens svagheder stadig gælder for dem.
Hvorfor viser mine RADIUS- eller NPS-logs ingen fejl?
Windows blokerer legitimationsoplysningerne på klienten, inden godkendelsen gennemføres. Tjek i stedet Event ID 4025 i Microsoft-Windows-NTLM/Operational på enheden.
Har jeg brug for AD CS eller en on-premises PKI til EAP-TLS?
Nej. SCEPman kører som certifikatmyndighed i din egen Azure-tenant og udsteder enheds- og brugercertifikater via Intune, Jamf Pro og andre MDM'er, uden AD CS eller NDES.








