KB5124008: Microsoft Gave Your Domain Trust Issues

Because apparently Active Directory needed relationship counselling.

There are certain things you expect from a Windows security update.

Security fixes.

A reboot at the least convenient possible moment.

Maybe a printer suddenly deciding it has never met your computer before.

What you generally don't expect is for Windows to wake up after patching, look at your Active Directory domain, and say:

“I don't know this man.”

Yet here we are.

Microsoft's September 8, 2026 Windows 11 security update, KB5124008, is reportedly causing some domain-joined Windows 11 systems to lose their secure channel with Active Directory after rebooting.

The result?

Perfectly valid domain credentials suddenly stop working.

Which is an exciting way to start your morning when you administer hundreds of computers.

Pour the coffee. We're going in.

The Update That Just Wanted to Help

KB5124008 applies to Windows 11 24H2 and 25H2 and includes the usual collection of security improvements and fixes.

Microsoft's official release notes talk about Secure Boot certificates, mouse cursors, desktop backgrounds, Teams, Outlook, Remote Desktop audio, and other improvements.

You know.

Normal patch stuff.

Microsoft has already documented several separate issues involving the September update, including problems with USB audio, Hyper-V/WSL shared folders, and Remote Desktop Services.

Microsoft: KB5124008 Windows 11 update details

And now administrators are reporting another particularly entertaining problem:

Windows machines forgetting that they belong to the domain.

BleepingComputer reports that Microsoft has confirmed it is investigating reports of domain trust failures following installation of KB5124008.

BleepingComputer: Windows 11 KB5124008 update breaks domain trust for some users

At the time of writing, Microsoft has not confirmed the root cause or published an official workaround for this specific domain-trust issue.

Which brings us to my favourite stage of every Microsoft incident:

Community-Based Production Debugging™

What Actually Breaks?

Domain-joined Windows computers have their own machine account credentials.

Those credentials help create a secure channel between the workstation and Active Directory.

Think of it as the computer walking into the domain controller's favourite coffee shop every morning.

Computer: Hey, it's me.
Domain Controller: Yep. I know you.
Computer: Cool.

After KB5124008, some administrators are reporting something more like:

Computer: Hey, it's me.
Domain Controller: Who are you?
Computer: What?
Domain Controller: I've literally never seen you before.
Computer: I WORK HERE.

When that secure channel breaks, users can get the classic Windows message:

“The trust relationship between this workstation and the primary domain failed.”

Or Windows simply tells them that their username or password is incorrect.

Naturally, the user then changes their password.

Then changes it again.

Then calls IT.

Then IT resets it.

Then everyone discovers the password was never the problem.

Perfect.

Reports cited by BleepingComputer describe affected systems working normally before the update, then losing domain authentication after installing KB5124008 and rebooting.

Cached credentials could still work offline, which points toward the machine/domain authentication path rather than every employee simultaneously forgetting their password.

One administrator reportedly saw 11 out of roughly 256 Windows 11 25H2 Enterprise systems lose domain trust after updating.

Another reported affected Windows 11 25H2 workstations rejecting legitimate domain credentials.

Nothing like a security update introducing a small side quest called:

Restore Authentication to the Corporation

Enter Machine Identity Isolation

The interesting part appears to involve a Windows security feature called Machine Identity Isolation.

Machine Identity Isolation is designed to protect machine account credentials using Credential Guard and virtualization-based security.

And conceptually, this is a good thing.

Machine account secrets are valuable.

Protecting them from being extracted from the operating system is exactly the sort of thing we want security controls to do.

The problem is that several administrators investigating KB5124008 reportedly found this registry value configured as:

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Lsa

MachineIdentityIsolation = 2

A value of 2 corresponds to enforcement mode.

In enforcement mode, Windows moves the machine account secret into Credential Guard and removes the copy stored in LSA.

Microsoft describes the behaviour in its documentation for Credential Guard protected machine accounts:

Microsoft Learn: Credential Guard protected machine accounts

Great for security.

Slightly less great if something goes sideways and the computer can no longer authenticate.

Microsoft's documentation specifically warns that if Credential Guard fails to start correctly after reboot, domain authentication can fail.

And suddenly our coffee has become an Irish coffee.

"Just Disable It"

Please Don't Do That Yet

Naturally, once administrators discovered the Machine Identity Isolation connection, some testing involved disabling it.

Affected administrators have reported success setting:

MachineIdentityIsolation = 0

Rebooting, and then repairing the workstation's secure channel using PowerShell:

Test-ComputerSecureChannel -Repair -Credential(Get-Credential)

Some systems reportedly restored their domain relationship afterward.

But before someone copies that registry change into Intune, Group Policy, SCCM, their RMM platform, PowerShell, or whatever other tool they use to ruin 4,000 computers simultaneously:

Don't treat this as a universal fix.

There is an important catch.

A very Microsoft-shaped catch.

Microsoft's documentation warns that if Machine Identity Isolation was previously running in enforcement mode, disabling it can itself break domain authentication and may require the machine to be manually removed and rejoined to the domain.

So the current troubleshooting workflow basically looks like this:

Domain trust broken.

        ↓

Maybe Machine Identity Isolation.

        ↓

Disable Machine Identity Isolation.

        ↓

Domain trust may break.

        ↓

Excellent.

Security engineering is beautiful.

What Should Administrators Do?

For now, I would not start mass-changing MachineIdentityIsolation settings across an environment based solely on the reports circulating online.

Microsoft is investigating, and there isn't yet a confirmed root cause or official workaround for the domain-trust problem.

If you're deploying KB5124008 in an enterprise environment, this is one of those situations where deployment rings become extremely valuable.

You know that annoying patch strategy where you deploy updates to:

IT → Pilot Users → Larger Test Group → Production

This.

This is why we do that.

Because:

“Security update causes hundreds of computers to stop authenticating against Active Directory”

is generally considered a career-enhancing event.

Depending heavily on whose career we're talking about.

If machines are already affected, validate the actual problem before randomly resetting passwords.

Start with:

Test-ComputerSecureChannel -Verbose

Check your event logs.

Look at Kerberos, Netlogon, and NTLM authentication failures.

Confirm whether the secure channel is actually broken.

Check whether Machine Identity Isolation is configured.

And, importantly, determine whether it was configured before the update.

Most importantly:

Don't make a fleet-wide registry change because someone on Reddit said it worked on Dave's laptop.

Dave's laptop has been through enough.

The Bigger Problem

The frustrating part isn't simply that Microsoft introduced a bug.

Software has bugs.

Windows has an absolutely enormous hardware and enterprise ecosystem, and security changes involving Credential Guard, virtualization-based security, Kerberos, and Active Directory are complicated.

The annoying part is the familiar cycle.

Security update deployed.

Something important breaks.

Administrators discover it.

Reddit discovers it.

Microsoft forums discover it.

Security news websites discover it.

Microsoft says:

“We're investigating.”

And IT departments everywhere slowly rotate their chairs toward the coffee machine.

Again.

This is particularly frustrating when the feature involved is designed to improve credential security.

Because now administrators potentially face the uncomfortable choice between leaving a security control enabled while troubleshooting authentication failures...

...or modifying that security control and potentially causing...

authentication failures.

Marvelous.

Final Sip ☕

KB5124008 isn't necessarily going to destroy every Active Directory environment.

The reports so far show that the behaviour isn't universal, and Microsoft still hasn't confirmed Machine Identity Isolation as the definitive root cause.

But if you're running Windows 11 24H2 or 25H2 in a domain environment, this is absolutely something worth watching before blindly pushing the September update everywhere.

Test your patches.

Use deployment rings.

Keep a local administrator account available.

Know how to repair a workstation secure channel.

And maybe don't schedule your company-wide Windows patch deployment for Friday afternoon.

Most importantly, keep the coffee pot full.

Because Microsoft may patch the operating system...

but apparently we're responsible for patching the trust issues.

Brew a Byte and Code a Bean! ☕💻