AD FS Zero-Day Puts Token-Signing Keys Behind An ACL Audit

Microsoft disclosed CVE-2026-56155 on July 14, 2026 and says the AD FS elevation-of-privilege vulnerability has been exploited. The flaw concerns permissions on the Distributed Key Manager container in Active Directory. AD FS stores key material there to protect the private keys for token-signing and token-encryption certificates. If the container's access-control list is too permissive, an attacker who can read the DKM material can decrypt the token-signing private keys.

Installing the July Windows security update starts an audit phase, not an automatic repair. Updated AD FS servers check the DKM ACL after service startup and every 24 hours, then report whether it needs attention. Administrators must review Event IDs 1132 through 1134 and opt in to remediation when required. Automatic remediation for Windows Server 2016 and later begins with the October 13 update unless an administrator opts out; Windows Server 2012 and 2012 R2 remain a manual path.

CVE-2026-56155 is an insufficient-granularity access-control flaw in Active Directory Federation Services. Microsoft's vector describes a local attack with low complexity, low privileges, and no user interaction, with high potential impact to confidentiality, integrity, and availability. The company rates it Important at CVSS 7.8 and marks it exploited. That does not make the public AD FS sign-in endpoint an unauthenticated remote exploit path; the published prerequisites start with an authorized, low-privilege foothold.

Microsoft credited members of its Detection and Response Team, but it has not published an actor name, victim count, incident timeline, initial-access route, indicators, or a description of how the flaw was used after exploitation. CISA added the CVE to its Known Exploited Vulnerabilities catalog on July 14 with a July 28 federal due date. The catalog lists known ransomware use as unknown. Those limits should remain visible in incident tickets and executive summaries.

The affected record spans AD FS-capable Windows Server releases from 2012 through 2025, including Server Core variants, with version-specific fixed builds. The practical scope is narrower than every Windows server in that list: find systems that actually run the AD FS role, identify each farm member and service account, locate the certificate-sharing container, record the operating-system build, and confirm that the July 14 update or a later cumulative update is present.

AD FS uses its Distributed Key Manager container in Active Directory to share and protect managed certificate private keys across a federation-server farm. Microsoft's hardening guidance says the DKM material protects the private keys for token-signing and token-encryption certificates. When the ACL allows an unintended principal to read that material, the principal can decrypt the token-signing private keys. The security issue is therefore not simply a directory permission that is untidy; it reaches the cryptographic identity of the federation service.

Token-signing certificates allow relying parties to verify that a security token came from the federation service and was not modified. Microsoft calls the private and public key pairing the most important validation mechanism in a federation partnership. An attacker who obtains usable signing private-key material may be able to impersonate the issuer to systems that trust that certificate. The exact reach depends on claims rules, relying-party configuration, certificate trust, token lifetime, and what the attacker actually obtained.

That last point is an inference from the documented role of the signing key, not a description Microsoft has confirmed for the observed attacks. Do not claim that every weak DKM ACL produced forged tokens. Determine which principals had read access, whether those accounts or hosts show signs of compromise, which relying parties trust the certificate, and how long relevant logs and tokens remain available. The configuration finding defines exposure; incident evidence determines whether it became compromise.

After the July update is installed on AD FS servers, the service checks the DKM container ACL one minute after startup and every 24 hours. Event ID 1132 is a warning that permissions do not match Microsoft's expected secure state. Event ID 1133 reports that the ACL matches. Event ID 1134 means the detection task failed, for example because LDAP connectivity was unavailable. A failed check is not a clean result, and the absence of 1132 is not useful until 1133 or another verified result appears.

Audit mode makes no automatic ACL change. That detail matters because a patch dashboard can show every server compliant while the risky directory permissions remain. Collect the three event outcomes from every farm, associate them with the DKM container distinguished name and service account, and open remediation work for every 1132 or 1134. Retain the evidence centrally because local event logs can roll over before an identity team completes the change window.

For Windows Server 2016 and later, setting the RemediateDkmAcl DWORD to 1 under HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\ADFS on one server in the farm opts in to repair. Restarting the AD FS service triggers it sooner, or the team can wait for the next cycle. Beginning with the October 13, 2026 Windows update, these newer releases remediate by default unless the value is set to 0. Plan and test now rather than discovering a dependency when enforcement arrives.

Microsoft's expected state gives Domain Admins, Enterprise Admins, and System full control. The AD FS service account receives the read, write, create-child, write-owner, and delete-tree rights the service needs. Remediation disables inheritance, discards inherited access-control entries, and removes other explicit Allow entries. That is a meaningful permission change, especially in environments where backup, monitoring, migration, or delegated administration processes have accumulated undocumented access.

Successful remediation records Event ID 1135 with the previous security descriptor in SDDL form. Microsoft recommends saving that value because event-log retention can overwrite it. Store it in a controlled change record before the log rolls, along with the container name, service account, time, operator, and resulting ACL. The saved descriptor is a recovery aid for unforeseen compatibility trouble, not a reason to restore insecure permissions as a routine rollback.

Validate the identity service after the change. Test internal and external sign-in, token issuance, federation metadata, token signing and decryption, Web Application Proxy paths, representative relying parties, certificate rollover state, monitoring, and failover across farm members. Review Events 1133 and 1135, and confirm that no automation restores the old ACL. If a legitimate integration breaks, identify the precise operation it required and redesign its access instead of broadly re-enabling inherited permissions.

Windows Server 2012 and 2012 R2 do not follow the same automatic enforcement path. Before opting in, administrators must grant the AD FS service account the WriteOwner and WriteDacl permissions required to remediate the container. They then set the same RemediateDkmAcl value and trigger or wait for the detection cycle. Skipping the preparatory permission step causes remediation to fail. Microsoft's support article provides the platform-specific PowerShell sequence and should be followed directly rather than copied from a newer-server procedure.

October automatic remediation does not apply to these older releases. That creates a governance risk: a mixed-version estate can look complete after the enforcement update while legacy farms still depend on manual action. Track operating system, extended-support status, farm owner, service account type, audit result, opt-in state, remediation result, and replacement plan as separate inventory fields. Do not let the newer default close the ticket for the older systems.

The age of the platform also changes recovery planning. Confirm that current cumulative updates and any required extended security coverage are available, that configuration and certificate backups are recoverable, and that the team can rebuild the service on a supported release. ACL hardening fixes this specific exposure. It does not remove the operational cost of keeping a federation service on an older operating system with a shrinking support and testing surface.

Because exploitation is confirmed, patching and ACL remediation should run alongside a scoped compromise review. Preserve AD FS Admin and security logs, domain-controller events, directory-service access records where enabled, endpoint telemetry, PowerShell history, remote-management logs, and network flows. Review unexpected access to the DKM object, changes to its ACL or owner, service-account activity, new administrators, unusual processes on federation servers, and sign-in or token patterns that do not fit normal relying-party use.

Event ID 1132 alone does not prove key material was read. Event ID 1133 after patching does not prove it was never readable. If evidence shows an unauthorized principal could have accessed the container, engage identity incident response and relying-party owners to decide whether token-signing and token-encryption certificates must roll. Rotation needs a coordinated trust and metadata plan because unplanned certificate removal can disrupt applications. Patch and ACL repair do not invalidate key material that may already have been copied.

The near-term priority is therefore layered: update every AD FS server, collect audit results, remediate unsafe ACLs in a tested window, preserve the previous descriptor, validate federation behavior, and investigate the period before the fix. Document the public unknowns rather than filling them with assumptions. Close the work only when current permissions, server versions, identity telemetry, certificate decisions, and relying-party validation all support the same conclusion.