IT-Wissen · IT-Sicherheit

AD FS DKM-Härtung: Wie KMU die automatische ACL-Remediation sicher vorbereiten

Kurz zusammengefasst: Die DKM-Härtung schränkt den Zugriff auf einen sicherheitskritischen Active-Directory-Container ein, den AD FS zum Schutz seines Schlüsselmaterials verwendet. Für kleine Unternehmen und den Mittelstand ist die wichtigste Vorbereitung eine kontrollierte Bestandsaufnahme: betroffene Server aktualisieren, Warnereignisse auswerten, bestehende Sonderberechtigungen dokumentieren, eine Rückfallmöglichkeit sichern und die Remediation zunächst bewusst in einer geeigneten Wartungsphase auslösen. So wird aus einer potenziell überraschenden Berechtigungsänderung ein nachvollziehbarer Change mit überprüfbaren Ergebnissen.

Nutzen und Einordnung

Active Directory Federation Services stellt Sicherheitstoken für Anwendungen und Verbundpartner aus. Ein kompromittierter Verbundserver kann deshalb weitreichende Zugriffsrechte vermitteln. Die DKM-Struktur im Active Directory enthält symmetrische Schlüssel, die zum Schutz des AD-FS-Schlüsselmaterials dienen. Ist der Zugriff auf den DKM-Container zu großzügig vergeben, kann ein Angreifer mit ausreichendem Lesezugriff unter Umständen an geschützte private Schlüssel gelangen.

Die ACL-Härtung verfolgt daher ein klares Prinzip: Der DKM-Container soll nur noch den dafür vorgesehenen privilegierten Gruppen, dem Systemkonto und dem AD-FS-Dienstkonto zugänglich sein. Die Vererbung wird deaktiviert; nicht vorgesehene explizite Zugriffssteuerungen werden entfernt. Für KMU ist das vor allem eine Maßnahme zur Reduzierung einer besonders kritischen Angriffs- und Fehlkonfigurationsfläche.

Sicherheitsnutzen: weniger unkontrollierte Zugriffswege auf AD-FS-Schlüsselmaterial.
Betrieblicher Nutzen: eine definierte ACL-Baseline erleichtert Prüfung, Überwachung und spätere Fehlersuche.
Organisatorischer Nutzen: die Änderung lässt sich als normaler, dokumentierter Berechtigungs-Change behandeln.

Was sich mit der Remediation ändert

Nach Installation des vorgesehenen Windows-Updates prüft der AD-FS-Dienst die ACL des DKM-Containers beim Dienststart und anschließend regelmäßig. Im Audit-Modus wird dabei noch keine Änderung vorgenommen. Ein Warnereignis zeigt an, dass die aktuelle ACL nicht dem erwarteten sicheren Zustand entspricht. Ein erfolgreich erkannter sicherer Zustand wird ebenfalls protokolliert; Fehler bei der Prüfung, etwa durch ein LDAP- oder Berechtigungsproblem, werden separat gemeldet.

Für Windows Server 2016 und spätere Versionen kann die Remediation in der Audit-Phase gezielt aktiviert werden. Dafür wird auf einem AD-FS-Server der Farm unter HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\ADFS der DWORD-Wert RemediateDkmAcl mit dem Datenwert 1 gesetzt. Ein Neustart des AD-FS-Dienstes kann die Prüfung und Remediation früher auslösen; andernfalls erfolgt sie beim nächsten Prüfzyklus.

Die erwartete Zielkonfiguration umfasst Domain Admins, Enterprise Admins, SYSTEM und das AD-FS-Dienstkonto. Für das Dienstkonto sind die von Microsoft vorgesehenen Rechte erforderlich, darunter Lesen, Schreiben, Erstellen untergeordneter Objekte, Schreiben des Besitzers und Löschen des Objektbaums. Die konkrete Darstellung kann je nach Serverversion und Verwaltungsmethode unterschiedlich aussehen; maßgeblich ist die tatsächlich gesetzte Berechtigung im Active Directory.

1132: DKM-ACL entspricht nicht der sicheren Baseline und muss geprüft werden.
1133: DKM-ACL entspricht der erwarteten sicheren Baseline.
1134: Prüfung ist fehlgeschlagen, beispielsweise wegen eines Verbindungs- oder Zugriffsproblems.
1135: Remediation war erfolgreich; die vorherige ACL wird als SDDL protokolliert.
1136: Remediation ist fehlgeschlagen und muss technisch untersucht werden.

Sichere Vorbereitung in fünf Schritten

Erstens sollte die Zuständigkeit geklärt werden. Die Änderung betrifft nicht nur den einzelnen AD-FS-Server, auf dem ein Registry-Wert gesetzt wird, sondern den gemeinsam verwendeten DKM-Container im Active Directory. Deshalb müssen AD-FS-Administration, Active-Directory-Verantwortung und gegebenenfalls der Dienstleister gemeinsam freigeben, was geändert werden darf.

Zweitens wird eine Bestandsaufnahme durchgeführt. Dazu gehören die Windows-Server-Versionen aller AD-FS-Knoten, die installierten Updates, die verwendete Dienstkontoart, die AD-FS-Farmstruktur und der Speicherort beziehungsweise Distinguished Name des DKM-Containers. Die aktuelle ACL sollte mit geeigneten, lesenden Verfahren dokumentiert werden. Unbekannte delegierte Gruppen oder historische Sonderrechte werden vor der Remediation fachlich bewertet und nicht vorschnell als harmlos eingestuft.

Drittens wird der Change vorbereitet. Dazu gehören ein Wartungsfenster, ein Ansprechpartner für AD FS und Active Directory, eine Sicherung der relevanten Registry-Konfiguration sowie ein nachvollziehbarer Rollback-Plan. Nach erfolgreicher Remediation sollte die im Ereignis 1135 enthaltene vorherige SDDL unmittelbar gesichert werden, weil Ereignisprotokolle durch ihre Größenbegrenzung überschrieben werden können.

Viertens wird die Remediation gezielt auf einem Farmknoten aktiviert. Es ist nicht sinnvoll, denselben Schalter unkoordiniert auf jedem Server zu setzen. Nach dem Auslösen werden die AD-FS- und Sicherheitsereignisse geprüft. Entscheidend ist nicht allein, dass der Dienst neu gestartet wurde, sondern dass ein erfolgreiches Remediation-Ereignis und anschließend ein funktionsfähiger Verbundbetrieb nachgewiesen sind.

Fünftens erfolgt die Nachkontrolle. Die ACL wird erneut ausgelesen, die erwarteten Principals werden abgeglichen und die wichtigsten Anwendungsfälle werden getestet: interaktive Anmeldung, Tokenausstellung, Zugriff auf die angebundenen Anwendungen sowie gegebenenfalls die Kommunikation mit Web Application Proxy und Microsoft Entra ID. Abweichungen werden als Fehler behandelt, nicht durch ein dauerhaftes Abschalten der Remediation verdeckt.

Keine Berechtigungsänderung ohne vorherige Dokumentation der aktuellen ACL.
Keine Aktivierung ohne geklärtes Dienstkonto und ausreichende AD-Berechtigungen.
Keine Abschlussmeldung ohne Ereignisprüfung und funktionalen Anmeldetest.
Sonderdelegationen zuerst fachlich bewerten; nicht jede zusätzliche ACE ist automatisch betrieblich entbehrlich.

Besonderheiten älterer Serverversionen

Für Windows Server 2012 und Windows Server 2012 R2 gelten zusätzliche Vorbereitungsschritte. Vor dem Aktivieren der Remediation muss das AD-FS-Dienstkonto ausdrücklich mit den erforderlichen Rechten ausgestattet werden. Dazu gehören insbesondere WriteOwner und WriteDacl. Ohne diese Voraussetzungen können Remediation-Versuche fehlschlagen.

Bei diesen älteren Versionen ist deshalb eine besonders sorgfältige Prüfung des Dienstkontos erforderlich. Dabei muss unterschieden werden, ob ein klassisches Benutzerkonto oder ein Group Managed Service Account verwendet wird. Die Identität sollte über die lokale AD-FS-Dienstkonfiguration und das Active Directory verifiziert werden. Ein Skript sollte erst nach Prüfung von Ziel-DN, Konto, Domäne und Ausführungsberechtigung eingesetzt werden.

Die automatische Durchsetzung für neuere Systeme darf nicht als Ersatz für eine Modernisierungsplanung verstanden werden. Ein älterer AD-FS-Bestand bleibt unabhängig von der ACL-Frage ein eigener Betriebs- und Sicherheitsprüfpunkt. Microsoft empfiehlt für AD-FS unter anderem aktuelle Updates, eingeschränkte Administrationsrechte, geschützte Zertifikate, zentrale Protokollauswertung und eine abgeschottete Platzierung hinter einer Firewall.

2012 und 2012 R2 benötigen zusätzliche Dienstkonto-Berechtigungen vor der Aktivierung.
Ein Group Managed Service Account ist anders zu identifizieren als ein klassisches Benutzerkonto.
Die DKM-Härtung ersetzt weder Patchmanagement noch Netzwerksegmentierung noch Überwachung.

Beispiel aus der Praxis

Beispiel: Ein mittelständischer Betrieb betreibt eine kleine AD-FS-Farm für mehrere interne und cloudbasierte Anwendungen. Nach dem Update erscheint im AD-FS-Administrationsprotokoll ein Warnereignis zur DKM-ACL. Die IT dokumentiert zunächst den Container-DN, die bestehende SDDL, die Farmknoten und das Dienstkonto. Eine zusätzlich berechtigte Administrationsgruppe wird mit dem Anwendungs- und Sicherheitsverantwortlichen bewertet; sie wird nicht automatisch übernommen, weil ihre Notwendigkeit nicht belegt ist. Danach setzt die IT den RemediateDkmAcl-Wert kontrolliert auf einem Farmknoten, sichert die im Erfolgsereignis enthaltene vorherige SDDL und prüft die ACL. Anschließend testet sie die Anmeldung an einer repräsentativen Anwendung, die Tokenausstellung und die Erreichbarkeit über den vorgesehenen Proxy. Erst wenn Ereignisse, ACL und Funktionstest zusammenpassen, wird der Change geschlossen. Das Beispiel beschreibt einen realistischen Ablauf, ist aber keine Kundenreferenz.

Chancen für Unternehmen

Die Audit-Phase schafft einen kontrollierten Vorlauf, in dem Unternehmen Abweichungen erkennen und Kompatibilitätsfragen vor einer verpflichtenden Durchsetzung klären können.
Eine standardisierte ACL-Baseline erleichtert wiederkehrende Kontrollen und kann in zentrale Ereignisüberwachung oder ein SIEM aufgenommen werden.
Die Vorbereitung ist ein geeigneter Anlass, AD-FS-Dienstkonten, privilegierte Gruppen, Zertifikatsschutz, Farmtopologie und Administrationswege gemeinsam zu überprüfen.
Die dokumentierte SDDL und ein klarer Rollback-Plan verbessern die Nachvollziehbarkeit gegenüber internen Verantwortlichen und externen Prüfern.

Grenzen und Prüfpunkte

Eine erfolgreiche ACL-Remediation beweist nicht, dass die gesamte AD-FS- oder Active-Directory-Umgebung sicher ist. Angriffswege über Server, Konten, Zertifikate, Gruppenrichtlinien oder Netzwerkzugänge bleiben separat zu prüfen.
Das Zurücksetzen von RemediateDkmAcl auf 0 verhindert die automatische Korrektur, lässt eine unsichere ACL aber bestehen. Ein solcher Opt-out sollte daher nur bei einem konkret dokumentierten Kompatibilitätsproblem und mit manueller Nachbearbeitung erfolgen.
Die Änderung kann historische Sonderdelegationen entfernen. Ohne vorherige Bestandsaufnahme besteht das Risiko, eine bislang genutzte, aber nicht dokumentierte Abhängigkeit zu übersehen.
Ein Ereignis 1135 ist kein vollständiger Funktionstest. Erst die Kombination aus Ereignisprüfung, erneuter ACL-Kontrolle und realistischem Anmelde- beziehungsweise Token-Test erlaubt eine belastbare Abschlussbewertung.
Bei Windows Server 2012 und 2012 R2 sind zusätzliche Berechtigungen und manuelle Schritte erforderlich. Die Abläufe dürfen nicht unbesehen aus einer neueren Serverversion übernommen werden.