CVE-2026-56155: AD FS Distributed Key Manager container ACL hardening

1. Opt-in to remediation by setting the RemediateDkmAcl registry key to 1. See the Windows Server 2016 and later topic in the Opt-in remediation section for more information.

2. By October 13, 2026, if the registry key is not configured, the update will automatically remediate insecure ACLs. To opt out of automatic remediation, set the registry key to 0.

1. Grant AD FS service account permissions to remediate, see the Windows Server 2012 and Windows Server 2012 R2 topic in the Opt-in remediation section.

2. After that, opt-in to remediation by setting the RemediateDkmAcl registry key to 1.

After installing the July 2026 update, detection automatically runs one minute after the AD FS service starts and then every 24 hours thereafter. Check the AD FS/Admin event log for the following events.

Note No automatic changes are made to the ACL during Audit Mode.

Use the platform-specific remediation guidance below.

Windows Server 2016 and later

We strongly recommend that administrators remediate during the Audit Mode phase to identify and resolve any compatibility issues before enforcement begins in October 2026. To enable remediation, set the following registry key on any one AD FS server in the farm.

After setting the registry key, either:

• Wait up to 24 hours for the next detection cycle, or

• Restart the AD FS service to trigger remediation sooner

On successful remediation, event 1135 (Information) is logged with the previous ACL in SDDL format.

Windows Server 2012 and Windows Server 2012 R2

For these platforms, grant the required permissions to the AD FS service account by following the steps below on any one AD FS server in the farm before enabling the RemediateDkmAcl registry. Otherwise, remediation attempts will fail.

1. Identify the DKM container DN:

   $dkmContainerDn = (Get-AdfsProperties).CertificateSharingContaine
   $dkmContainerDn
   

2. Identify the AD FS service account:

   $serviceAccount = (Get-CimInstance Win32_Service -Filter "Name='adfssrv'").StartName
   $serviceAccount
   

3. Grant explicit Allow ACEs for WriteOwner and WriteDacl:

   $sid = (New-Object System.Security.Principal.NTAccount($serviceAccount)).Translate([System.Security.Principal.SecurityIdentifier]) 
   $entry = New-Object System.DirectoryServices.DirectoryEntry("LDAP://$dkmContainerDn") 
   $rule = New-Object System.DirectoryServices.ActiveDirectoryAccessRule( 
    $sid, 
    ([System.DirectoryServices.ActiveDirectoryRights]::WriteOwner -bor [System.DirectoryServices.ActiveDirectoryRights]::WriteDacl), 
    [System.Security.AccessControl.AccessControlType]::Allow, 
    [System.DirectoryServices.ActiveDirectorySecurityInheritance]::All 
   ) 
   $entry.ObjectSecurity.AddAccessRule($rule) 
   $entry.CommitChanges() 
   $entry.Close() 
   

4. After the required permissions are granted, set the following registry key on any one AD FS server in the farm to enable remediation.

   Information	Details
   Registry key	HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\ADFS
   Value:	RemediateDkmAcl
   Type:	DWORD
   Data:	1
   Note	If "HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\ADFS" is not present, create the "ADFS" key first, then set RemediateDkmAcl under that key.

5. After setting the registry key, either:

• Wait up to 24 hours for the next detection cycle, or

• Restart the AD FS service to trigger remediation sooner

On successful remediation, event 1135 (Information) is logged with the previous ACL in SDDL format.

Save the previous SDDL (Recommended)

As a precautionary measure, we recommend saving the previous ACL (SDDL) from event 1135 after successful remediation. While the previous ACL is not expected to be needed in most cases (since the original permissions were insecure), having it available provides a safety net for any unforeseen compatibility issues.

Note Event logs can roll over due to size limits. If you need the previous SDDL in the future and the event has been overwritten, it will be permanently lost.

To save the SDDL to a file:

# Run this on the AD FS server immediately after remediation (event 1135) 
$event = Get-WinEvent -FilterHashtable @{LogName='AD FS/Admin'; Id=1135} -MaxEvents 1 
$event.Message | Out-File "C:\ADFSBackup\dkm-acl-previous-sddl.txt

How to restore the previous ACL

If you experience issues after remediation and need to revert to the previous ACL:

# Restore the full security descriptor (DACL + Owner + SACL) from the saved SDDL 
$dn = "<Container DN from event 1135 or C:\ADFSBackup\dkm-acl-previous-sddl.txt>" 
$sddl = "<Previous ACL (SDDL) value from event 1135 or C:\ADFSBackup\dkm-acl-previous-sddl.txt>” 
 
$entry = New-Object System.DirectoryServices.DirectoryEntry("LDAP://$dn") 
$entry.ObjectSecurity.SetSecurityDescriptorSddlForm($sddl, [System.Security.AccessControl.AccessControlSections]::All) 
$entry.CommitChanges() 
$entry.Close() 

Note This command requires the account running it to have SeSecurityPrivilege (typically Domain Admins have this). Run this from an elevated PowerShell session on a domain-joined machine.

Set-ItemProperty -Path "HKLM:\SOFTWARE\Microsoft\ADFS" -Name "RemediateDkmAcl" -Value 0 -Type DWord 

After restoring, set RemediateDkmAcl = 0 to prevent the service from re-remediating on the next cycle.

Starting with the October 2026 update, remediation runs by default without requiring the registry key. The behavior is equivalent to having RemediateDkmAcl = 1 set.

Enforcement auto-remediation does not apply to Windows Server 2012 or Windows Server 2012 R2. For these platforms, remediate manually by following the steps in the Windows Server 2012 and Windows Server 2012 R2 topic in the Opt-in remediation section.

If you need to disable automatic remediation after the October 2026 update, set the RemediateDkmAcl value in the registry.

This explicitly disables remediation. Detection (event 1132) continues to fire so admins are aware of the insecure state.

Important Opting out leaves your DKM container vulnerable. Only use this if you have a specific compatibility requirement and plan to manually harden the ACL.