{"id":455,"date":"2026-10-23T15:57:03","date_gmt":"2026-10-23T15:57:03","guid":{"rendered":"https:\/\/hostcare.nl\/?p=455"},"modified":"2026-10-23T15:57:03","modified_gmt":"2026-10-23T15:57:03","slug":"adfs-dkm-acl-hardening-cve-2026-56155","status":"publish","type":"post","link":"https:\/\/hostcare.nl\/?p=455","title":{"rendered":"Windows-update herstelt onveilige AD FS-toegangsrechten op de DKM-container"},"content":{"rendered":"\n

De Windows-beveiligingsupdate van 13 oktober 2026 dwingt voortaan standaard veilige toegangsrechten (ACL\u2019s) af op de Distributed Key Manager-container (DKM) van AD FS. In een AD FS-farm herstelt de AD FS-service een onveilige DKM-ACL automatisch, tenzij een beheerder v\u00f3\u00f3r de update bewust een tijdelijke uitzondering instelt. De wijziging beperkt CVE-2026-56155, een kwetsbaarheid waarmee bevoegdheden kunnen worden verhoogd.<\/p>\n\n\n\n

Dit onderwerp is alleen relevant voor omgevingen die Active Directory Federation Services gebruiken. Het betreft geen algemene wijziging van alle Windows Server- of Entra ID-implementaties. Voor een AD FS-farm is de impact wel belangrijk: de DKM-container bewaart symmetrische sleutels die de priv\u00e9sleutels voor tokenondertekening en tokenversleuteling beschermen. Wanneer de ACL van die container te ruim is, kan een actor met leesrechten op het DKM-sleutelmateriaal volgens Microsoft de priv\u00e9sleutels voor tokenondertekening ontsleutelen.<\/p>\n\n\n\n

Van detectie naar standaardherstel<\/h3>\n\n\n\n

Microsoft begon op 14 juli 2026 met een eerste verhardingsfase. Die fase detecteerde onveilige DKM-ACL\u2019s en bood herstel als vrijwillige keuze. Vanaf de beveiligingsupdate van 13 oktober 2026 probeert AD FS een onveilige ACL standaard te herstellen op ondersteunde Windows Server-versies. De Windows Message Center-aankondiging noemt dit de afdwingmodus (Enforcement mode<\/em>).<\/p>\n\n\n\n

Windows Server 2012 en Windows Server 2012 R2 vormen daarbij een belangrijke uitzondering: zij worden in de handhavingsfase niet automatisch hersteld en vereisen handmatig herstel. Microsoft noemt het automatische standaardherstel voor ondersteunde versies van Windows Server; beoordeel de serverversie en de ondersteuningsstatus dus per farm voordat een wijzigingsvenster wordt gepland.<\/p>\n\n\n\n

Wat AD FS tijdens de controle doet<\/h3>\n\n\n\n

Na installatie controleert de AD FS-service de DKM-container telkens wanneer de service start en vervolgens elke 24 uur. Als de ACL niet aan de verwachte beveiligde toestand voldoet, probeert AD FS die automatisch te corrigeren. De verwachte toestand bevat uitgeschakelde overerving en toegang voor uitsluitend Domain Admins, Enterprise Admins, SYSTEM en het AD FS-serviceaccount.<\/p>\n\n\n\n

De DKM-container is \u00e9\u00e9n gedeeld Active Directory-object voor alle servers in dezelfde AD FS-farm. De controletaak draait echter op elke AD FS-server. Dat betekent dat de configuratie van \u00e9\u00e9n server gevolgen kan hebben voor hetzelfde gedeelde object dat de hele farm gebruikt. Plan de update, verificatie en eventuele uitzondering daarom farmbreed en niet server voor server als losstaande wijziging.<\/p>\n\n\n\n

Voorbereiden voordat de update wordt uitgerold<\/h3>\n\n\n\n
  1. Bevestig dat de farm AD FS gebruikt.<\/strong> Inventariseer alle farmleden, de gebruikte Windows Server-versies en het AD FS-serviceaccount. Dit voorkomt dat een algemene Windows-updateronde het specifieke AD FS-controlepunt mist.<\/li>
  2. Controleer eerder geconstateerde afwijkingen.<\/strong> Als de auditmodus al waarschuwingen heeft opgeleverd, behandel die v\u00f3\u00f3r de handhavingsuitrol als een wijziging met eigenaar en testplan.<\/li>
  3. Documenteer de huidige toestand.<\/strong> Leg de relevante AD FS\/Admin-gebeurtenissen en de actuele DKM-ACL vast. Microsoft adviseert na een succesvol herstel ook de vorige ACL in SDDL-vorm te bewaren; dat ondersteunt diagnose of een zorgvuldig geplande terugval.<\/li>
  4. Plan installatie op alle AD FS-servers.<\/strong> Installeer een passende Windows-beveiligingsupdate van 13 oktober 2026 of later op alle AD FS-servers in de farm. Controleer daarna per server de service- en gebeurtenislogboekstatus.<\/li>
  5. Beoordeel een uitzondering alleen bij aantoonbare compatibiliteit.<\/strong> Een tijdelijke uitzondering laat de DKM-ACL in een onveilige toestand. Maak die keuze daarom alleen tijdelijk, na risicobeoordeling en met een eigenaar, einddatum en herstelplan.<\/li><\/ol>\n\n\n\n

    Microsoft adviseert niet om de verharding standaard uit te schakelen. Als er een concrete compatibiliteitsreden is, moet de registerwaarde RemediateDkmAcl<\/code> v\u00f3\u00f3r installatie op 0<\/code> worden gezet op iedere<\/strong> AD FS-server in de farm. Ontbreekt de waarde of is deze op \u00e9\u00e9n server niet nul, dan kan die server de gedeelde DKM-container alsnog automatisch herstellen zodra de update is ge\u00efnstalleerd. Een gedeeltelijke tijdelijke uitzondering is dus geen betrouwbare pauzeknop.<\/p>\n\n\n\n

    Controleer het AD FS\/Admin-gebeurtenislogboek gericht<\/h3>\n\n\n\n
    Gebeurtenis-id<\/th>Betekenis volgens Microsoft<\/th>Praktische opvolging<\/th><\/tr><\/thead>
    1133<\/td>De DKM-ACL is in de verwachte beveiligde toestand.<\/td>Geen verder herstel nodig; leg de succesvolle verificatie vast.<\/td><\/tr>
    1132<\/td>De ACL is onveilig en automatisch herstel wordt uitgevoerd.<\/td>Zoek de bijbehorende gebeurtenissen met id 510 op basis van dezelfde instantie-id en wacht op de uitkomst van 1135, 1136 of 1137.<\/td><\/tr>
    1135<\/td>Het herstel is geslaagd.<\/td>Bewaar de vorige ACL\/SDDL uit de gekoppelde details van gebeurtenis 510, zoals Microsoft aanbeveelt.<\/td><\/tr>
    1136<\/td>Het herstel is mislukt.<\/td>Lees de gekoppelde ACL- en uitzonderingsdetails, herstel de onderliggende oorzaak en herstart de AD FS-service of wacht op de volgende detectiecyclus.<\/td><\/tr>
    1137<\/td>AD FS kon geen eigenaar worden van de DKM-container.<\/td>Controleer de benodigde WriteOwner<\/code>– en WriteDacl<\/code>-rechten van het AD FS-serviceaccount; herstart daarna de service of wacht op de volgende cyclus.<\/td><\/tr>
    1134<\/td>De detectietaak zelf gaf een fout, bijvoorbeeld bij een verbinding met LDAP.<\/td>Onderzoek de AD FS-foutopsporingslogboeken en de aangegeven fout voordat van een correcte ACL-status wordt uitgegaan.<\/td><\/tr><\/tbody><\/table><\/figure>\n\n\n\n

    Gebeurtenis-id 510 bevat aanvullende ACL- of uitzonderingsdetails. Bij een grote ACL kunnen er meerdere 510-gebeurtenissen worden weggeschreven. Koppel die aan 1132, 1135 of 1136 met de gemeenschappelijke instantie-id; een losse 510 zonder die context is onvoldoende om de afloop te beoordelen.<\/p>\n\n\n\n

    De speciale situatie bij oudere farms<\/h3>\n\n\n\n

    Microsoft vermeldt dat Event ID 1137 kan voorkomen bij farms die oorspronkelijk op Windows Server 2012 of Windows Server 2012 R2 zijn gemaakt. In dat geval kan het AD FS-serviceaccount niet de benodigde eigenaarswisseling uitvoeren. De voorgeschreven route is niet het breed openen van de DKM-ACL, maar het verlenen van de vereiste rechten aan het AD FS-serviceaccount en daarna opnieuw laten uitvoeren van de controle. Microsoft noemt daarvoor WriteOwner<\/code> en WriteDacl<\/code>.<\/p>\n\n\n\n

    Pas een ACL niet op basis van algemene Active Directory-voorbeelden aan. De DKM-container bevat gevoelig sleutelmateriaal en de Microsoft-documentatie beschrijft een specifieke verwachte veilige toestand. Werk bij een fout vanuit de gebeurtenisdetails, leg de wijziging vast en controleer na herstel opnieuw de relevante AD FS\/Admin-gebeurtenissen. Zo blijft onderscheid zichtbaar tussen een succesvol technisch herstel, een tijdelijke uitzondering en een nog onopgelost bevoegdheidsprobleem.<\/p>\n\n\n\n

    Terugval alleen met een gedocumenteerde reden<\/h3>\n\n\n\n

    Microsoft beschrijft een herstelroute voor de vorige volledige beveiligingsdescriptor uit de opgeslagen SDDL. Voor dat herstel is een account nodig met SeSecurityPrivilege<\/code>, wat doorgaans bij Domain Admins aanwezig is. Voer de handeling uit vanuit een PowerShell-sessie met verhoogde rechten op een computer die lid is van het domein. Nadat een ACL is teruggezet, moet RemediateDkmAcl<\/code> op iedere AD FS-server op 0<\/code> staan om te voorkomen dat een volgende cyclus de ACL opnieuw herstelt.<\/p>\n\n\n\n

    Dat is een technische terugvalprocedure, geen aanbevolen eindsituatie. De tijdelijke registeruitzondering onderbreekt juist de automatische bescherming waarvoor de handhaving is ingevoerd. Leg daarom in het wijzigingsdossier vast welk probleem ermee wordt ondervangen, welke servers het betreft, wie verantwoordelijk is voor de tijdelijke afwijking en wanneer de beveiligde toestand opnieuw wordt hersteld.<\/p>\n\n\n\n

    Een beheersbare oplevercontrole<\/h3>\n\n\n\n
    1. Installeer en herstart volgens het bestaande wijzigingsproces.<\/strong> Houd de farmleden en ge\u00efnstalleerde updateversies bij.<\/li>
    2. Lees het AD FS\/Admin-gebeurtenislogboek op elk farmlid uit.<\/strong> Zoek specifiek naar 1132 tot en met 1137 en koppel eventuele 510-gebeurtenissen aan de juiste instantie-id.<\/li>
    3. Bevestig de eindstatus.<\/strong> Een 1133 of 1135 levert een andere conclusie op dan een detectiefout, mislukt herstel of een fout bij het verkrijgen van eigenaarschap. Sluit een wijziging pas af met een positieve, gedocumenteerde uitkomst.<\/li>
    4. Bewaar herstelgegevens zorgvuldig.<\/strong> Sla eerdere SDDL-informatie op in een beveiligde beheerlocatie met beperkte toegang; deze gegevens beschrijven immers een beveiligingsdescriptor van de directorycontainer.<\/li>
    5. Herstel alleen gerichte fouten.<\/strong> Gebruik bij 1136 of 1137 de Microsoft-richtlijn en gebeurtenisdetails, toets de gevolgen in de farm en laat de volgende controlecyclus de nieuwe toestand bevestigen.<\/li><\/ol>\n\n\n\n

      Voor organisaties zonder AD FS is er geen actie vanuit deze specifieke wijziging. Organisaties met een AD FS-farm doen er goed aan de update niet als een gewone maandelijkse patch te behandelen: de bescherming grijpt in op een gedeeld directoryobject dat de sleutelbescherming van de federatieservice raakt. Een korte, farmbrede verificatie van de eventlogs levert dan meer zekerheid op dan alleen vaststellen dat de Windows-update is ge\u00efnstalleerd.<\/p>\n\n\n\n

      Offici\u00eble documentatie<\/h3>\n\n\n\n