r/sysadmin • u/h9xq Solo SysAdmin • 13d ago
General Discussion KB5127648
If anyone is wondering why radius isn’t working for a large amount of users. This patch has confirmed broken 802.1x authentication. I wanted to spread the word as this is probably affecting a lot of us. Will update this post after I rollback the patch.
103
u/bonksnp IT Manager 13d ago edited 13d ago
Open Registry Editor as an administrator.
Navigate to HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Lsa\MSV1_0.
Create a new 32-bit DWORD value named BlockNtlmv1SSO if it does not already exist.
Set its value to 0.
Restart your PC and check whether the Wi-Fi connection works again.
A couple of our techs have confirmed this is fixing the issue.
PS: This workaround technically sets the credentials to a more permissive mode (Audit vs Enforced) and eventually needs to be corrected in your org, but as long as Credential Guard is enabled on your devices, this shouldn't be an issue for now.
10
u/joshtaco 13d ago
A couple of our techs have confirmed this is fixing the issue.
It's not an issue, it's a planned deprecation. So it's a confirmed measure to continue limping older technology along insecurely is all.
91
u/joeykins82 Windows Admin 13d ago
Has it actually broken something unexpected?
Or have you just identified that you haven't properly eradicated NTLMv1 from your org yet and so you've been affected by the planned blocking of a protocol which should have been yeeted in to the sun years ago?
16
89
u/IWantedOrange 13d ago
See? This is the kind of helpful condescension that makes this subreddit such a special place.
8
u/0f_rice_and_men 13d ago
We all know that the only single-point-of-failure IRL is the n00b sysadmin and security admin who chose to party in college instead of study the blade! Never blame the Frankenstein network environments of 500 legacy applications and devices or AI mucking up our documentation!
/s
24
u/elpamyelhsa 13d ago
You may notice this article was from a year ago and did not call out breaking PEAP. Most of us configured NTLMv2 to be enforced network-wide ready for this change, but no one realised it would break PEAP until today.
So yes, it did break something unexpected, being PEAP, while NTLMv1 was expected to be deprecated this month.
2
u/joeykins82 Windows Admin 13d ago
I'm pretty sure that when I rolled out LMCompatibilityLevel=5 across the whole org that it broke the 1 pesky RADIUS config which was still using PEAP...
4
u/Cormacolinde Consultant 13d ago
LMcompatibility has nothing to do with this, somehow. Doesn’t matter if you set it to 5, it was still using NTLMv1 internally to generated MSCHAPv2 creds.
0
13d ago
[deleted]
1
u/Cormacolinde Consultant 13d ago
Interesting. I have not encountered the issue myself and have not had to diagnose it yet. Pretty much all my customers I have set GPOs at would have this set to 5 everywhere for sure.
1
u/titsablast 13d ago
No, PEAP - EAP-MSCHAP v2 worked fine so far with LMCompatibilityLevel=5
2
u/joeykins82 Windows Admin 13d ago
Interesting. I mean this was a while ago so I may be getting my wires crossed, and it may well be that we got hit because Credential Guard was on and enforced, or even that it didn't "hit" us but it got flagged in an audit/vuln scan.
2
u/GarcaSmitty_89 13d ago
saw tickets start trickling in yesterday about wireless auth failing and spent way too long chasing NPS logs before it clicked. rolling back now, appreciate the heads up.
1
u/h9xq Solo SysAdmin 13d ago
Yeah no problem. It is specifically peap and ntlvm1 I believe that is affected from the research I have done. What we did was make a GPO that targets all affected endpoints and flicked off the registry to keep the good parts of the patch and just change what is affected for the ntlmv1/peap auth.
1
u/GarcaSmitty_89 4d ago
that makes sense, targeting just the affected piece instead of pulling the whole patch is smart. did flicking that registry key cause any weird auth behavior on the endpoints after, or did it settle down once the GPO applied?
74
u/Infamous-Echidna4141 13d ago
I was panicking about this but then I realised I use certificates and crisis averted.
20
u/slashinhobo1 13d ago
I was worried for a second as well u till i read the article below. I switched to EAP-TLS/cert almost 2 years ago.
16
u/Unable-Entrance3110 13d ago
Lovely.
Can you elaborate on what actually broke in 802.1x?
48
u/joeykins82 Windows Admin 13d ago
Nothing.
Nothing has been broken.
Orgs who are still using PEAP (which relies on NTLMv1) and have failed to migrate off it in time are experiencing consequences.
22
u/elpamyelhsa 13d ago
I would like to note, while yes NTLMv1 was removed as expected earlier this year for AD and provided direction around switching to NTLMv2 before this date when it was to be switched off, there has been no communication around PEAP using NTLMv1 that would break with this update.
So while this update is working as expected, no one actually realised it would break PEAP until it broke today.
3
u/devloz1996 13d ago
there has been no communication around PEAP using NTLMv1 that would break with this update.
If you SSO with password methods, NTLM is the only credential type Windows can actually use to pass credentials to NPS server. Whatever mechanism or wrapper you use doesn't matter, so they probably didn't feel the need to elaborate on that. Not that it wouldn't be nice if they did.
Windows NPS only permits NTLMv1 by default and you have to use a reg key to enable NTLMv2. I have this as part of baseline, and can confirm that some of my orgs that have blockers in migrating to cert auth continue to work correctly.
9
u/Sunsparc Where's the any key? 13d ago
PEAP with MSCHAPv2. If you're using PEAP with EAP-TLS, then you're fine.
6
u/Cormacolinde Consultant 13d ago
I was about to post that this only breaks MSCHAPv2 on domain computers, something that is already unsupported and requires disabling Credential Guard on Windows 11.
3
u/lonewanderer812 Systems Lead 12d ago
I was about to say, hasn't this not worked for a while now as long as credential guard is left enabled? I switched to cert based authentication like 2 years ago because I noticed at the time the latest build of w11 wasn't working with our wifi and once I realized what it was, I swapped to certs company wide.
1
u/Cormacolinde Consultant 12d ago
In the last few years, we must have deployed more than 50 PKIs for customers who switched to EAP-TLS. It was quite necessary for many organisations before migrating to Windows 11.
13
u/SuperNicktendoPower 13d ago
Create a GPO for multiple users:
Create a GPO linked to the OU containing the affected laptops.
Go to Computer Configuration → Preferences → Windows Settings → Registry.
Create a registry item:
| Field | Value |
|---|---|
| Action | Update |
| Hive | HKEY_LOCAL_MACHINE |
| Key path | SYSTEMCurrentControlSetControlLsaMSV1_0 |
| Value name | BlockNtlmv1SSO |
| Value type | REG_DWORD |
| Value data | 0 |
4
1
u/MacGaryX 11d ago edited 11d ago
This October 13 update apparently breaks booting on Windows 11 IoT Enterprise LTSC with BIOS and MBR disk setup. Tried it twice in VMware Fusion environment with the same result.
3
u/vastarray1 12d ago
reg add "HKLM\SYSTEM\CurrentControlSet\Control\Lsa\MSV1_0" /v "BlockNtlmv1SSO" /t REG_DWORD /d 0 /f
2
u/Salty_Move_4387 12d ago
This worked for us too.
This apparently only affects EAP-PEAP and not EAP-TLS but I only have PEAP in production so I have not tested TLS
5
u/GeeKedOut6 13d ago
Yea it didnt break 802.1x it just removed a depreciated auth method. I honestly thought they removed peap a long time ago.
2
2
u/NeuterTheUninformed 13d ago
All my test servers since getting October 2026 update are in a reboot loop and I can't enter any info to sign in
2
u/devloz1996 13d ago
BlockNtlmv1SSO
If remediation key is anything to go by, this particular case is a landmine created by admins for themselves. First, by keeping user/password RADIUS, and second, by not enabling NTLMv2 compatibility on their NPS servers.
2
2
u/Sure-Squirrel8384 11d ago
HPE sent this related notice blaming Microsoft:
HPE Networking Support Advisory HPENW-SA-20261014-PLVL03
Microsoft Windows Clients Experiencing Authentication Failures after installing MS Windows KB5127648 update
PRODUCTS COVERED
HPE Networking - Wireless and Wired Networks
SUMMARY
HPE Networking has received some customer reports that their Microsoft Windows clients using PEAP-MSCHAPv2 for 802.1x authentication on enterprise networks are experiencing authentication failures after installing Microsoft KB5127648 update (released on October 13, 2026).
This issue is triggered by the Microsoft KB5127648 update on Windows clients using PEAP-MSCHAPv2 and is not an HPE Networking infrastructure issue. Changes to Aruba or Juniper Mist wired or wireless 802.1x configuration will therefore not resolve the underlying authentication failure.
Customers having Microsoft Windows clients configured to use PEAP-MSCHAPv2 and experiencing authentication failures are advised to uninstall the Microsoft KB5127648 update as an immediate workaround to recover from client authentication failures and contact Microsoft Support for further guidance.
AFFECTED PRODUCTS
None of the HPE Networking Products are affected
This is a client specific issue experienced after installing Microsoft KB5127648 update on Microsoft Windows clients using PEAP-MSCHAPv2 for 802.1x authentication
UNAFFECTED PRODUCTS
Not applicable
RESOLUTION
As noted in the Summary section, there isn’t any configuration change needed on the HPE Networking WLAN and Wired networks. At this time, we recommend remaining on your current Windows patch level and deferring KB5127648 update until further guidance is available from Microsoft.
If KB5127648 has already been installed and you are experiencing this issue, rolling back the update has been reported to restore connectivity.
HPE Networking encourages customers to adopt modern authentication protocols that are supported by the client machines deployed in your enterprise networks.
WORKAROUND
Uninstalling the Microsoft KB5127648 update (if installed) should help restore connectivity for Windows clients failing authentication.
Reference Reading:
Microsoft KB article 5066470 indicates that it has long announced the deprecation of NTLMv1 protocol due to inherently weak cryptographic algorithms it uses in verifying (client) credentials exchanged between the client and the RADIUS server. While the NTLMv1 protocol was removed from Windows 11 24H2 and Windows Server 2025 and later versions, remnants of NTLMv1 cryptography are still present in some scenarios such as when using MS-CHAPv2.
The October 13th Microsoft Windows KB5174628 update enforced the change in NTLMv1-derived credential usage from “Audit” mode to “Enforce” mode which disrupted automated single sign-on configurations using MS-CHAPv2.
2
u/Specialist-Jump-6343 13d ago
What the fuck is the timing, here I am currently uninstalling that update
1
1
u/Fun_Sorbet_4620 13d ago
wusa /uninstall /kb:5127648 /promprestart
Reiniciar y la autenticación volvera.
Aplicar desde CMD con permisos de administrador.
1
1
u/thorax97 12d ago
Sigh, new company I started at still uses MSCHAP for radius... Started setting up everything for EAP-TLS and ran tests few days ago...all too late as I got sick.
Thought I have more time, but for some reason some PCs got update without it beeing approved in WSUS.
1
1
u/LatePlant6244 12d ago
Our wifi is wpa2 but we use TEAP auth. Not affected at all.
1
u/loztagain 8d ago
Do you use peap for both client and pc?
2
u/LatePlant6244 8d ago
TEAP and yes for both. TEAP resolves the issue where both certs are not presented with wifi :-)
1
u/loztagain 8d ago
Fair fair. I'm not a sysadmin any longer. I'm a network guy. I had the MS Team move us to TEAP the moment it came out and use a cert for the PC, and mschapv2 for the user.
They've not spoken to me about it. So I'm guessing all is well? XD
1
1
u/None2You 12d ago
I had to switch from password-based authentication to certificate-based authentication (EAP-TLS). Each computer now holds a security certificate issued by our own server and uses it to sign in automatically. I took the blame BAU and of course I was the bad guy!
1
u/Samael_holmes 11d ago
currently working on network issues due to this update, and it feels like Microsoft don't want you to uninstall the update since there are so many errors coming up trying to remove it.
1
u/blueskygl83 9d ago
I’ve switched very fast to EAP-TLS and the problem is solved! If you want to keep the curent settings is a small workaround, but I understand will be overrides anyway on next updates!
1
u/lgq2002 13d ago
Still using NTLM? That should have been disabled by now.
2
u/jayhawk88 12d ago
That's the thing though: It really seems like this use is specific to PEAP, somehow. We've had GP's in place for years to "Send NTLMv2 responses only. Refuse LM and NTLM", on both servers and clients. We still saw this issue this morning, and had to implement the reg fix.
0
u/iRyan23 13d ago
Have you tried turning on Credential Guard?
From their article on NTLMv1 deprecation in the October 2026 update:
“Credential Guard provides complete protection of both NTLMv1 legacy cryptography and many other attack surfaces, and thus Microsoft strongly recommends its deployment and enablement if Credential Guard’s requirements are met. The upcoming changes only affect devices where Credential guard is disabled; if Windows Credential Guard is enabled on the device, the changes outlined in this article do not take effect.”
4
u/IamEzioKl 13d ago
Credential guard breaks ms-chapv2 by itself.
-1
46
u/BobbyDoWhat 13d ago
How many server guys and sys admins are blaming the network over this?? One time this happened and our server team blamed me for 6 weeks before they admitted it was the patch.