Patch Tuesday Broke Half My Domain: The KB5124008 Secure-Channel Fiasco

I keep waiting for the day a routine Patch Tuesday update does more damage than the vulnerability it's actually fixing, and this September cycle came uncomfortably close. Microsoft's KB5124008, the security update that pushes Windows 11 25H2 to build 26200.9445, has started silently breaking domain trust relationships on enterprise fleets. Install it, reboot, and suddenly the machine can no longer prove itself to Active Directory. Users get the classic "your password is wrong" error even when it isn't, domain logons fail, and admins stare at ERROR_NO_TRUST_LSA_SECRET trying to work out what a Tuesday patch did to their secure channel. Microsoft has confirmed it's aware and investigating, which is as far as you get before you start pulling the update and rejoining PCs to the domain by hand.

The interesting bit isn't that a patch broke something — patches do that, it's in the job description. It's where it broke. The failures trace back to stricter Netlogon secure-channel negotiation settings that KB5124008 turns on, and they line up specifically with Windows Server 2019 domain controllers and certain Windows Server 2022 configurations that don't support the new negotiation level the updated client is now asking for. Reports point at the Windows Machine Identity Isolation feature, especially in audit or enforcement mode, as the tripwire. In other words, this is the old, boring infrastructure doing exactly what it's designed to do: a modern client and an older domain controller negotiate, disagree, and the secure channel drops. The machine account credentials no longer match what AD expects, and the trust relationship quietly rots. It's the kind of thing that surfaces in a Reddit thread and a Microsoft Q&A post long before it lands in a support article, because the symptom — "why is my password wrong?" — looks like a user error until it isn't.

Source article image
Source image 1

What I actually find telling is how the workaround went. Remove KB5124008, rejoin the affected machine to the domain, logon comes back. Reinstall the update, the break returns. That clean round-trip is basically a confession that the patch is the culprit, and it's the sort of confirmation you only get when a fleet of sysadmins independently reproduce the same failure and start comparing notes. The follow-up fix that was supposed to patch over it — KB5129195 — appears to have stumbled too, leaving operators with the same stop-the-deployment, wait-for-the-real-fix posture you get whenever a security feature has quietly outgrown the directory you pointed it at. The takeaway for anyone running a traditional AD environment is a familiar one that keeps getting more expensive: the more modern your endpoint gets, the more it can trip over the domain controllers it depends on, and the blast radius of a single update scales with how old your DCs are. So I'm left with the questi

Source article image
Source image 2
on that matters to anyone who's been burned by this before: if you're still on Windows Server 2019 or early 2022 DCs, do you gate the client side of the fleet on the domain controller's version, or do you just accept that every major client update is now a controlled burn and test it like one?

Sources

Comments

Popular posts from this blog

AI Is Starting to Feel Less Like a Gadget and More Like Infrastructure

When Two AI Bots Finally Learned to Talk in Discord

Enterprise AI Is Quietly Becoming a Systems Integration Problem