AD FS: Am 13. Oktober schaltet Microsoft die Zwangs-Härtung des DKM-Containers scharf

Seit dem Juli-Patchday prüft AD FS die Berechtigungen seines DKM-Containers – und ändert nichts. Mit dem Oktober-Update kippt das: Ab dem 13. Oktober 2026 werden unsichere ACLs automatisch korrigiert, sofern Sie nicht ausdrücklich widersprechen. Wer dort in den vergangenen Jahren Dienst- oder Monitoring-Konten eingetragen hat, verliert sie ohne Rückfrage. Sie haben noch gut vier Wochen, um das zu prüfen.

Worum es geht

AD FS legt im Active Directory einen Distributed-Key-Manager-Container ab. Darin liegen die symmetrischen Schlüssel, mit denen die privaten Schlüssel der Token-Signing- und Token-Encryption-Zertifikate geschützt werden. Wer diesen Container lesen darf, kann unter Umständen den Token-Signing-Schlüssel entschlüsseln – und damit selbst gültige Token ausstellen. Das ist der Mechanismus hinter Golden-SAML-Angriffen. Aus einem scheinbar harmlosen Berechtigungsproblem im Verzeichnis wird so die Übernahme der gesamten Föderation, inklusive aller daran hängenden Cloud-Dienste.

Wichtig für die Einordnung: Das ist keine Lücke, die ein Unbekannter aus dem Internet gegen Ihren AD FS-Endpunkt auslöst. Ein Angreifer braucht bereits einen Fuß in der Tür. Der Schaden liegt darin, dass aus einem kleinen Fußabdruck die Kontrolle über die Föderationsgeheimnisse wird.

Warum das Juli-Update allein nichts repariert hat

Das ist der Punkt, an dem viele Umgebungen gerade ein falsches Sicherheitsgefühl haben. Das Update vom 14. Juli hat den Audit-Modus eingeführt, mehr nicht. AD FS prüft die ACL des Containers eine Minute nach dem Dienststart und danach alle 24 Stunden. Verändert wird nichts.

• Event-ID 1132 im Protokoll AD FS/Admin bedeutet: Die Berechtigungen des DKM-Containers entsprechen nicht der neuen Baseline. Handlungsbedarf.
• Event-ID 1135 protokolliert eine erfolgreich durchgeführte Korrektur – und enthält die vorherige ACL in SDDL-Form. Das ist Ihr einziges Rollback-Material. Exportieren Sie dieses Ereignis sofort, bevor der normale Protokollumlauf es überschreibt.
• Registrierungswert RemediateDkmAcl steuert das Verhalten: 1 bedeutet korrigieren, 0 bedeutet nicht korrigieren. Bis zum 13. Oktober entspricht „nicht gesetzt“ einem 0. Danach entspricht „nicht gesetzt“ einer 1.

Was die Korrektur konkret tut – und wem sie weh tut

Die Remediation deaktiviert die Vererbung am DKM-Container, verwirft sämtliche geerbten Zugriffseinträge und entfernt alle expliziten Allow-Einträge, die nicht zur Baseline gehören. Übrig bleiben genau vier Prinzipale:

Und genau hier liegt das Betriebsrisiko. Wenn in Ihrer Umgebung über die Jahre delegierte Identitäten, Backup- oder Monitoring-Dienstkonten oder eigene Automatisierung Zugriff auf den Container bekommen haben, verlieren die diesen Zugriff im Oktober. Das merken Sie nicht beim Einspielen des Updates, sondern beim nächsten Lauf des betroffenen Prozesses. Zwischen Ursache und Symptom liegen dann möglicherweise Tage.

Prüfung in drei Schritten

Schritt 1 – Audit-Ereignisse auslesen. Auf jedem AD FS-Knoten, nicht nur auf dem primären:

Schritt 2 – Die aktuelle ACL sichten. Den Pfad des Containers liefert AD FS selbst, dann schauen Sie nach, wer dort tatsächlich eingetragen ist:

Schritt 3 – Entscheiden und dokumentieren. Alles, was neben den vier Baseline-Prinzipalen auftaucht, braucht eine Antwort auf die Frage: Warum ist das da, und was passiert, wenn es weg ist? Wenn Sie diese Frage bis zum 13. Oktober nicht für jeden Eintrag beantworten können, setzen Sie RemediateDkmAcl bewusst auf 0, klären das in Ruhe und korrigieren danach kontrolliert. Ein bewusstes, befristetes Opt-out mit Wiedervorlage ist besser als eine Überraschung im laufenden Betrieb – aber es ist eben nur ein Aufschub, keine Lösung.

Die vier Fragen, die Sie beantworten können müssen

1. Laufen alle AD FS-Knoten auf einem Build mit dem Juli-Update oder neuer? Per Build-Nummer geprüft, nicht per Konsolen-Häkchen.
2. Entspricht die ACL des DKM-Containers heute der Baseline – und wenn nein, welche Einträge stören?
3. War der Container in der Vergangenheit für Prinzipale lesbar, die dort nichts zu suchen hatten? Ereignis-ID 5136 im Sicherheitsprotokoll der Domänencontroller zeigt Verzeichnisänderungen, sofern die Überwachung aktiviert ist.
4. Gibt es Hinweise, dass Schlüsselmaterial, Token-Signing-Zertifikate oder die Vertrauensstellung bereits kompromittiert wurden? Wenn diese Frage nicht sauber mit Nein beantwortet werden kann, ist der Austausch der Token-Signing-Zertifikate der nächste Schritt – nicht das Patchen.

Fazit

Microsoft macht hier etwas, das grundsätzlich richtig ist: Eine unsichere Voreinstellung wird zur sicheren Voreinstellung, mit drei Monaten Vorwarnzeit und einem Audit-Modus dazwischen. Genau diese drei Monate sind jetzt fast vorbei, und der Audit-Modus nützt nur denen, die hineingeschaut haben.

Zwei Dinge nehme ich aus dem Fall mit. Erstens: Ein Event im AD FS-Protokoll, das niemand liest, ist kein Audit, sondern eine Fußnote. Zweitens – und das ist die unbequemere Frage: Wer 2026 noch AD FS betreibt, sollte klären, warum. Jede dieser Härtungen ist Arbeit an einer Komponente, die Microsoft seit Jahren in Richtung Entra ID verabschiedet. Der Aufwand für die DKM-Prüfung ist überschaubar. Der Aufwand für die nächsten fünf Härtungen dieser Art ist es nicht.

Quellen: Microsoft Support-Artikel KB5121391 zu CVE-2026-56155; Microsoft Message Center MC1442510; Windows IT Pro Blog „Windows news you can use: August 2026“; CISA KEV-Katalog, Eintrag vom 14.07.2026. Alle ISW-Tools: isw-adtools.de