BuildNot yet confirmed elsewhere1 publisher2 min readPublished
Microsoft's AD FS DKM fix records the old ACL in one event that can roll over
Microsoft's KB5121391 will automatically fix insecure AD FS DKM container ACLs on Windows Server 2016 and later by October 13. The only record of what the ACL held before is a single local event that can roll over, so each team has to save its own copy.
The Engineer · Build desk
2016+ farms: auto-fixed by October 13, 2026 unless the registry says otherwise. 2012/2012 R2: manual. RemediateDkmAcl 0 opts out, leaving the container vulnerable. Overwritten logs permanently lose the old SDDL. Post author: in many orgs the AD team owns the rewritten ACL.
- exposure Server 2016+ farms October update automatically remediates insecure DKM ACLs by October 13, 2026 unless the registry value says otherwise, claim 1
- constraint Server 2012 / 2012 R2 farms Automatic remediation does not apply; the ACL change is manual work, claim 2
- decision Admins who opt out Setting RemediateDkmAcl to 0 opts out of enforcement and, Microsoft says, "leaves your DKM container vulnerable", claim 8
- constraint Anyone needing the prior ACL Event logs can roll over on size limits; if the event is overwritten, the previous SDDL "will be permanently lost", claim 14
- exposure AD team (post author's view) Per the post author, in many orgs it owns the DKM ACL that an AD FS action rewrites, with evidence in a log it may never read, claim 19
| Who | How | Kind | Claim |
|---|---|---|---|
| Server 2016+ farms | October update automatically remediates insecure DKM ACLs by October 13, 2026 unless the registry value says otherwise | exposure | 1 |
| Server 2012 / 2012 R2 farms | Automatic remediation does not apply; the ACL change is manual work | constraint | 2 |
| Admins who opt out | Setting RemediateDkmAcl to 0 opts out of enforcement and, Microsoft says, "leaves your DKM container vulnerable" | decision | 8 |
| Anyone needing the prior ACL | Event logs can roll over on size limits; if the event is overwritten, the previous SDDL "will be permanently lost" | constraint | 14 |
| AD team (post author's view) | Per the post author, in many orgs it owns the DKM ACL that an AD FS action rewrites, with evidence in a log it may never read | exposure | 19 |
What happened
- Windows Server 2012 and 2012 R2 farms get no automatic fix, and Microsoft's page leaves the ACL change on those versions as manual work.
- Since the July 14 update, AD FS has checked the container one minute after service start and every 24 hours, logging event 1132 on a mismatch without changing the ACL.
- Admins can opt out of enforcement by setting RemediateDkmAcl to 0, a choice Microsoft's page says "leaves your DKM container vulnerable."
- Microsoft says the flaw, CVE-2026-56155, lets anyone with read access to DKM key material decrypt token-signing private keys; no exploitation has been reported.
Why it matters
- exposure An AD team that owns the DKM container's permissions can find them rewritten by an AD FS service action, with the change logged only where the AD FS team looks.
- decision Farms on 2012 or 2012 R2 have to pick their own date and make the ACL change by hand, because October 13 triggers nothing on those versions.
- precedent Microsoft says more DKM hardening will follow in later updates, so an evidence step built now for event 1135 is likely to be needed again.
On a 2016 or later farm, the October update turns remediation on by default, with the same effect as setting RemediateDkmAcl to 1 [1][7]. With that value set, remediation runs at the next detection cycle or on a service restart [6]. A farm that has not opted out should see its ACL rewritten within a day of installing the update, or sooner if the AD FS service restarts first [17].
The permission being rewritten sits on an Active Directory object. AD FS servers run the detection, and one of them makes the change [11]. The container holds the symmetric keys that protect the private keys of AD FS's token-signing and token-encryption certificates [3]. Every event Microsoft defines for this carries a single "Container DN", and the KB page tells admins to "Ensure the AD FS service account has access to the DKM group container in Active Directory." [10]
The evidence stays on the server that logged it. All five DKM hardening events go to the AD FS/Admin log of whichever server wrote them [12]. Event 1135, the success event, includes the previous ACL in SDDL [13]. One server makes the change, so that event should exist in one server's log [18]. Microsoft's page warns that event logs roll over at size limits, and that once the event is overwritten the previous SDDL "will be permanently lost" [14].
Putting the prior SDDL inside the success event is good engineering. The operator gets a record of the old state without having to take a backup first. Microsoft's suggested capture is a short PowerShell step: fetch the newest event with `Get-WinEvent -FilterHashtable @{LogName='AD FS/Admin'; Id=1135} -MaxEvents 1`, then write `$event.Message` to a file [15]. The page calls this a recommended precaution, not a requirement [15]. On a farm with several servers, the step has to run on the server that made the change [18].
The dev.to post that walked through the KB expects most change records to close this item as "October update installed" [20]. Its author wrote that in that pattern "a closure signal fires on execution, not on the verified state it was meant to represent." [20] On the saved 1135 message, the author wrote: "Treat it as the change evidence." [16]
We agree with that, and we'd go one step further. In our view, the closed ticket should hold the saved 1135 message, the name of the server that logged it, and the Container DN the event names [10][13]. Those three items are what tie the patch to the permission it changed.
What to watch
- Any revision to KB5121391 before the October 13 enforcement date, especially to the opt-out behaviour or the event definitions.
- Any report of CVE-2026-56155 being exploited; a report would make an opt-out or a delayed 2012 R2 fix harder to defend.
Clarity's read
What the record supports and how the coverage leans. The claims behind it follow.
Reality
- Evidence60
- Adoption
- Insufficient
- Hype gap0
- Incentives25
- Confidence60
Claim ledger
Ranked by verification strength, evidence, and original report placement.
- [1]
Microsoft's KB5121391, first published July 14, 2026, says that on Windows Server 2016 and later the October 2026 update "will automatically remediate insecure ACLs" on the AD FS DKM container by October 13, 2026 unless the registry value says otherwise.
- [2]
On Windows Server 2012 and 2012 R2, enforcement auto-remediation does not apply and the work is manual.
- [3]
AD FS relies on the Distributed Key Manager container to store the symmetric keys that protect the private keys of its token-signing and token-encryption certificates.
- [4]
Microsoft's stated risk is that if the DKM container's ACL is overly permissive, an attacker with read access to the DKM key material can decrypt the token-signing private keys; the page frames this as elevation of privilege, CVE-2026-56155, and does not report exploitation.
- [5]
In audit mode from the July 14 update, detection runs one minute after the AD FS service starts and then every 24 hours; no changes are made to the ACL, and a mismatch logs event 1132.
- [6]
Opt-in remediation is enabled by setting RemediateDkmAcl (DWORD) to 1 under HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\ADFS on any one AD FS server in the farm; remediation runs at the next detection cycle or on a service restart.
- [7]
From the October 2026 update, remediation "runs by default without requiring the registry key," equivalent to RemediateDkmAcl = 1.
- [8]
Setting RemediateDkmAcl to 0 opts out of enforcement, and Microsoft's page says opting out "leaves your DKM container vulnerable."
- [9]
Microsoft's page says further DKM hardening will follow in future updates.
- [10]
Every DKM hardening event the page defines carries a single "Container DN," and the page says: "Ensure the AD FS service account has access to the DKM group container in Active Directory."
- [11]
AD FS servers run the detection and one of them performs the change, but the thing changed is a permission on an Active Directory object, not on an AD FS server.
- [12]
All five DKM ACL hardening events are written to the AD FS/Admin log on the AD FS server that logged them.
- [13]
Event 1135 records the previous ACL in SDDL as part of the success event.
- [14]
Microsoft's note says event logs can roll over due to size limits and that if the event is overwritten the previous SDDL "will be permanently lost."
- [15]
Microsoft recommends saving the 1135 message immediately on the AD FS server using Get-WinEvent -FilterHashtable @{LogName='AD FS/Admin'; Id=1135} -MaxEvents 1 and writing $event.Message to a file, framed as a recommended precaution, not a requirement.
- [16]
"Treat it as the change evidence."
- [17]
On a Server 2016+ farm that has not opted out, the DKM ACL should be rewritten within about 24 hours of the October update being installed, or at the first AD FS service restart if that comes sooner.
- [18]
Because one AD FS server performs the change and each event is written only to the local log of the server that logged it, the 1135 success event with the previous SDDL should exist in one server's AD FS/Admin log, and the capture step has to run on that server.
- [19]
In many organizations the AD team owns the DKM container's ACL while the AD FS team owns the service and the event log, so remediation is an AD FS service action rewriting a permission the AD team may believe is theirs, with the evidence landing in a log the AD team may never read.
- [20]
In most change records the closure signal for this item will read "October update installed"; the author wrote that in this pattern "a closure signal fires on execution, not on the verified state it was meant to represent."
Sources
1 independent publisher whose own reporting we read for this story.
- dev.toDKM ACL Hardening Is Scheduled. The Evidence It Worked Is Not.
1 article · October 11, 2026
Topics and entities
Follow any of these and your For You feed starts watching them — no settings page required.