ADFS-Sicherheit: Angriffe, Härtung, Golden SAML und MFA

ADFS-Server sind die größte Angriffsfläche im Microsoft-Identity-Stack — sie stellen Token aus, mit denen sich User an Microsoft 365 anmelden, sie verwalten die Federation zur Cloud, sie halten die Token-Signing-Schlüssel. Wer einen ADFS-Server kompromittiert, hat oft Zugriff auf den gesamten Microsoft-365-Tenant. Dieser Artikel zeigt die häufigsten Angriffsmuster, erklärt im Detail wie Golden SAML funktioniert und wie HSMs dagegen schützen, vergleicht die drei Wege MFA bei ADFS zu implementieren, und gibt eine konkrete Härtungs-Checkliste — alles aus der Praxis, ohne Marketing-Floskeln. Für Identity-Architekten, ADFS-Admins und CISOs, die ihre Federation-Umgebung ernst nehmen.

Was ADFS-Sicherheit konkret bedeutet

ADFS-Sicherheit ist die Summe aller Maßnahmen, die einen produktiven ADFS-Stack vor unbefugtem Zugriff, Token-Diebstahl, Token-Forging und Federation-Manipulation schützen. Das umfasst fünf Schichten — Netzwerk, Betriebssystem, Service-Konten, Token-Signing und Detection — die alle eigenständig schützen müssen, weil jede einzelne versagen kann.

Der Schutz unterscheidet sich grundlegend von normalen Server-Workloads. Ein kompromittierter Exchange-Server bedeutet einen Datenleck. Ein kompromittierter ADFS-Server bedeutet potenziell den kompletten Verlust des Microsoft-365-Tenants und aller föderierten Anwendungen — über Wochen bis Monate hinweg, oft unbemerkt. Aus diesem Grund klassifiziert Microsoft ADFS als Tier-0-System und verlangt entsprechende Schutzmaßnahmen.

Die Bedrohungslage hat sich in den letzten Jahren verschärft. NIS2 verlangt ab 2024/2025 explizit dokumentierte Identity-Sicherheitsmaßnahmen, BSI-Grundschutz fordert Tier-0-Härtung, DORA bringt ähnliche Anforderungen für den Finanzsektor. Wer einen produktiven ADFS-Stack betreibt, muss diese Anforderungen mittlerweile in Audits nachweisen können — und das ist ohne strukturiertes Vorgehen kaum mehr leistbar.

Die ADFS-Angriffsoberfläche: sieben häufige Angriffsmuster

Bevor man sinnvoll härten kann, muss man verstehen, wogegen man härtet. Sieben Angriffsmuster tauchen in der Praxis immer wieder auf, jedes mit eigener Charakteristik und eigenem Schutzbedarf.

Abb.: Die sieben häufigsten Angriffsmuster gegen ADFS auf einen Blick. Sechs treffen das System direkt, einer kommt von der AD-Seite lateral. Plus ein Bonus-Vektor: Federation Metadata Drift.

Übersicht der häufigsten Angriffe

Die folgende Tabelle ordnet die Angriffsmuster nach Risikoklasse und gibt jeweils die wirksamste Schutzmaßnahme an.

Angriff	Was passiert	Schaden	Wirksame Verteidigung
1. Extranet Brute Force	Massive Login-Versuche gegen externes ADFS-Login-Portal	Mittel — gilt nur für schwache Passwörter	Extranet Smart Lockout mit niedriger Schwelle plus MFA für alle User
2. Token Replay	Gestohlene SAML-Token werden wiederverwendet	Hoch — MFA wird umgangen	Token-Lifetimes kurz halten (max. 1 h), Token-Single-Use prüfen, Session-Hijacking-Detection
3. Pass-the-Cookie	Browser-Session-Cookies aus Endgeräten extrahieren	Hoch — komplette authentifizierte Sessions übernommen	Endpoint-Härtung, Conditional Access mit Device Compliance, Conditional Access Cookie-Binding
4. WAP-Backend-Bypass	Direkter ADFS-Zugriff unter Umgehung des WAP	Sehr hoch — Pre-Auth-Schutz weg, Brute Force möglich	ADFS-Server NIE direkt aus Internet erreichbar, Firewall-Regeln streng setzen
5. Federated Domain Hijack	Microsoft Graph API-Manipulation der Federation-Konfiguration	Kritisch — fremder IdP akzeptiert	Privileged Identity Management, Microsoft Graph Audit-Logs überwachen
6. Golden SAML	Token-Signing-Schlüssel-Diebstahl, eigene Token erzeugen	Katastrophal — kompletter Tenant verloren	HSM für Token-Signing-Key, Tier-0-Härtung konsequent durchziehen
7. AD-Compromise (lateral)	Tier-1-Kompromittierung führt zu ADFS-Service-Konto	Sehr hoch — vollständiger ADFS-Stack übernommen	Tier-Modell strikt einhalten, gMSA für ADFS-Service, Privileged Access Workstations

 

Wichtiger Punkt: Diese Angriffe kombinieren sich In realen Angriffen treten die Muster fast nie isoliert auf. Ein typischer Angriffspfad beginnt mit Initial Access via Phishing (Tier-2), eskaliert über AD-Compromise lateral (Tier-1), erreicht über Service-Konten den ADFS-Server (Tier-0), führt dort zum Token-Signing-Key-Diebstahl (Golden SAML) und endet mit dauerhaftem Microsoft-365-Zugriff. Jede Stufe des Angriffs lässt sich mit anderen Schutzmaßnahmen blockieren — Defense-in-Depth bedeutet, dass mehrere Schichten gleichzeitig versagen müssen, damit der Angriff erfolgreich ist.

ADFS als Tier-0-System: was das praktisch bedeutet

Microsoft klassifiziert ADFS-Server als Tier-0-Systeme, gemeinsam mit Domain Controllern, der PKI und Entra ID Connect. Das hat konkrete Konsequenzen für Administration, Härtung und Netzwerk-Topologie — und es ist die Grundlage für jede sinnvolle Sicherheits-Architektur.

Abb.: Microsofts Tier-Modell: ADFS gehört in Tier 0 — die höchste Schutzklasse. Tier-Verstöße bedeuten direkt erweiterte Angriffsoberfläche.

Die drei Tier-Ebenen kurz erklärt

Tier 0 umfasst Systeme, die die Identitäts-Infrastruktur verwalten: Domain Controller, ADFS-Server, Entra ID Connect, PKI-Server und Privileged Access Workstations. Eine Kompromittierung hier bedeutet den Verlust der gesamten Identitäts-Plattform — Domain-Admin-Rechte, Token-Signing-Schlüssel, Cloud-Trust-Beziehungen.

Tier 1 umfasst Server-Workloads: Application-Server, Exchange, SharePoint, SQL-Server. Eine Kompromittierung bedeutet Datenleck oder Service-Ausfall, aber nicht den Verlust der Identitäts-Infrastruktur — wenn das Tier-Modell strikt eingehalten wird.

Tier 2 umfasst User-Endgeräte: Workstations, Notebooks, mobile Geräte. Die häufigsten Angriffsvektoren — Phishing, Malware, Drive-by-Downloads — treffen primär diese Ebene.

Die goldene Regel: Anmeldungen nur von hoch nach niedrig

Die zentrale Regel des Tier-Modells lautet: Ein Konto darf sich nur an Systemen anmelden, die der eigenen Tier-Stufe oder einer niedrigeren entsprechen — niemals umgekehrt. Ein Tier-0-Admin-Konto darf sich also an Domain Controllern und ADFS-Servern anmelden, aber nicht an Workstations oder Application-Servern. Ein Tier-1-Konto darf sich an Application-Servern und Workstations anmelden, aber nicht an ADFS.

Warum diese Regel kritisch ist: Wenn ein Tier-2-Endgerät kompromittiert wird und dort ein Tier-0-Admin angemeldet war — etwa weil der Admin „schnell mal“ die ADFS-Konfiguration vom eigenen Notebook geprüft hat —, hat der Angreifer ab diesem Moment einen Tier-0-Credential im Zugriff. Lateral Movement in die ADFS-Umgebung ist nur noch eine Frage von Stunden.

 

Praxis-Tipp: Privileged Access Workstations (PAW) Tier-0-Administration sollte ausschließlich von dedizierten Privileged Access Workstations stattfinden — gehärtete Geräte, die nur für die Tier-0-Administration genutzt werden, ohne Mail, ohne Internet, ohne Office-Anwendungen. Microsoft hat dafür einen offiziellen Standard mit Hardware-Anforderungen und Konfigurations-Vorlagen. Wer das nicht umsetzt, kann die Tier-Trennung schlicht nicht einhalten — ein normales Admin-Notebook ist immer Tier-2 und damit nicht für Tier-0-Aufgaben geeignet.

Golden SAML: der gefährlichste ADFS-Angriff im Detail

Golden SAML ist ein Angriffsmuster, bei dem ein Angreifer den Token-Signing-Schlüssel der ADFS-Farm stiehlt und damit selbst beliebige SAML-Token erzeugt — als wäre er der legitime ADFS-Server. Der Angriff wurde 2017 von Forschern bei CyberArk dokumentiert und wurde 2020 durch den SolarWinds-Vorfall weltweit bekannt: Über neun Monate hinweg hatten Angreifer in mehreren Organisationen ungehinderten Zugriff auf Microsoft 365 und föderierte Anwendungen — durch selbst-gefälschte SAML-Token.

Abb.: Die Golden-SAML-Angriffskette in fünf Schritten — von Initial Access bis zur dauerhaften Persistence. Schritt 3 (Key-Diebstahl) ist der kritische Moment. Schritt 4 (Token-Forging) läuft außerhalb des Opfer-Netzwerks.

Die fünf Schritte der Angriffskette

Schritt 1 — Initial Access: Der Angreifer verschafft sich Erstzugang zum Netzwerk — durch Phishing, Supply-Chain-Angriff (bei SolarWinds über manipulierte Software-Updates), Zero-Day-Exploit oder gestohlene Credentials. Dauer typischerweise Stunden bis Wochen.

Schritt 2 — Privilege Escalation: Der Angreifer eskaliert vom Initial Access zu Tier-0-Admin-Rechten. Methoden: Kerberoasting (Service-Account-Tickets cracken), AS-REP Roasting, Pass-the-Hash, Ausnutzung schlecht konfigurierter Service-Konten. Dauer typischerweise Tage bis Monate.

Schritt 3 — Token-Signing-Key-Diebstahl: Der kritische Moment. Mit Tier-0-Rechten extrahiert der Angreifer den DKM-Master-Key aus dem Active Directory, dann den Token-Signing-Schlüssel aus dem Windows Certificate Store des ADFS-Servers. Mit Hilfe des DKM-Master-Keys wird der Schlüssel entschlüsselt — der Angreifer hat ihn jetzt im Klartext.

Schritt 4 — Token-Forging: Mit dem Token-Signing-Schlüssel im Besitz kann der Angreifer auf einem beliebigen Rechner — außerhalb des Opfer-Netzwerks — selbst SAML-Token erzeugen. Beliebige User-Identität, beliebige Claims, beliebige Group Memberships, MFA-Claim einfach mitgefälscht. Die Token sind kryptographisch valide und werden von Microsoft 365 und allen föderierten Anwendungen akzeptiert.

Schritt 5 — Persistence: Solange der Token-Signing-Schlüssel gültig ist, kann der Angreifer beliebig oft neue Token erzeugen. Passwort-Reset aller User? Hilft nichts — die Token brauchen kein Passwort. MFA aktiviert? Hilft nichts — der MFA-Claim wird mitgefälscht. Nur eine Schlüssel-Rotation unterbricht den Zugang. Beim SolarWinds-Vorfall lag die durchschnittliche Verweildauer der Angreifer bei rund neun Monaten.

 

Warum Golden SAML so gefährlich ist Token-Erstellung läuft außerhalb des Netzwerks — keine Spuren in der ADFS-Umgebung. MFA wird komplett umgangen — der MFA-Claim wird einfach mitgesetzt. Conditional Access ist wirkungslos — alle Bedingungen lassen sich durch geeignete Claims fälschen. Persistence ohne Backdoor — der Angreifer braucht keinen aktiven Zugang mehr, solange er den Schlüssel hat. Detection ist extrem schwer — die Token sehen kryptographisch korrekt aus, weil sie es sind.

HSM: die einzige wirksame Verteidigung gegen Golden SAML

Ein Hardware Security Module (HSM) ist ein dediziertes Hardware-Gerät, das kryptographische Schlüssel intern erzeugt, speichert und für Operationen verwendet — ohne dass die Schlüssel jemals als Klartext extrahierbar werden. Für ADFS-Token-Signing ist HSM-Einsatz die einzige Maßnahme, die Golden SAML zuverlässig verhindert.

Abb.: Token Signing ohne HSM (links) versus mit HSM (rechts). Ohne HSM kann der Token-Signing-Key bei Tier-0-Kompromittierung extrahiert werden. Mit HSM ist das Hardware-blockiert — Golden SAML unmöglich.

Wie HSM-Token-Signing funktioniert

Beim ADFS-Setup mit HSM wird der Token-Signing-Schlüssel im HSM selbst erzeugt und verlässt das Gerät nie. Der ADFS-Server kennt nur eine Referenz auf den Schlüssel — typischerweise über die Cryptography Next Generation (CNG) API mit einem HSM-spezifischen Key Storage Provider (KSP). Wenn ein SAML-Token signiert werden muss, sendet ADFS die Token-Daten an das HSM, das HSM signiert intern und gibt das signierte Token zurück.

Der entscheidende Punkt: Auch ein Tier-0-Admin kann den Schlüssel nicht extrahieren. Das HSM verweigert jede Export-Anfrage, selbst mit höchsten Berechtigungen. Wer dennoch versucht, das HSM zu manipulieren, löst typischerweise eine Schlüssel-Vernichtung aus (Anti-Tamper-Mechanismen). Damit ist Golden SAML auch dann nicht möglich, wenn der Angreifer Tier-0-Rechte erlangt hat.

HSM-Auswahl: was du beachten musst

Für ADFS-Token-Signing kommen mehrere HSM-Produkte in Frage. Die wichtigsten Auswahlkriterien:

HSM-Produkt	Form-Faktor	Typischer Einsatz	Preisklasse
Thales Luna SA	Netzwerk-Appliance	Großunternehmen, mehrere Anwendungen	10.000-30.000 EUR
Entrust nShield	Netzwerk-Appliance	Großunternehmen, Bankensektor	10.000-30.000 EUR
Yubico HSM 2	USB-Gerät	Kleinere Umgebungen, Einzelserver	500-1.000 EUR
Azure Dedicated HSM	Cloud-HSM	Hybrid-Setups mit Cloud-Affinität	~ 5.000 EUR/Monat
Azure Key Vault Managed HSM	Cloud-HSM (verwaltet)	Hybrid-Setups, weniger Verwaltungsaufwand	ab ~ 3.000 EUR/Monat

 

Praxis-Tipp: Auto-Cert-Rollover bei HSM-Nutzung DEAKTIVIEREN ADFS hat eine Funktion namens Auto-Certificate-Rollover, die Token-Signing-Zertifikate automatisch generiert und ersetzt. Bei HSM-Nutzung muss diese Funktion deaktiviert werden, weil ADFS sonst versucht, ein neues Software-Zertifikat zu erzeugen — was den Sinn des HSM-Einsatzes komplett zerstört. PowerShell: `Set-AdfsProperties -AutoCertificateRollover $false`. Stattdessen wird die Schlüssel-Rotation manuell oder über ein HSM-eigenes Rollover-Verfahren durchgeführt — empfohlen vierteljährlich, mindestens jährlich.

Härtungs-Schichten: Defense-in-Depth bei ADFS

Defense-in-Depth ist die Strategie, mehrere unabhängige Schutzschichten zu kombinieren, sodass das Versagen einer Schicht durch andere kompensiert wird. Bei ADFS lassen sich fünf konkrete Schichten identifizieren — jede mit eigenen Maßnahmen und eigenen Verantwortlichkeiten.

Abb.: Die fünf Härtungs-Schichten von ADFS: Netzwerk, Betriebssystem, Service-Konten, Token-Signing, Detection. Jede Schicht muss eigenständig funktionieren — der Angreifer muss alle fünf gleichzeitig brechen.

Schicht 1: Netzwerk und DMZ

Die äußerste Schicht. ADFS-Server gehören niemals direkt aus dem Internet erreichbar — der Zugang läuft immer über den Web Application Proxy in einer DMZ. Wichtige Maßnahmen: Drei-Zonen-Modell mit zwei Firewalls, Outbound-Filterung (ADFS-Server dürfen nicht ins Internet, Ausnahme bei Azure-MFA-Nutzung), Microsegmentation zwischen Tier-0- und Tier-1-Systemen, Geo-Blocking auf WAP-Ebene für nicht-relevante Länder.

Schicht 2: Betriebssystem

Die OS-Schicht. ADFS-Server sollten auf Windows Server Core laufen — keine GUI, minimaler Footprint, kleinere Angriffsfläche. Konkrete Maßnahmen: nur erforderliche Rollen installiert, BSI-Grundschutz oder CIS-Benchmarks angewandt, Local Administrator Password Solution (LAPS) aktiv, Credential Guard und Device Guard aktiviert, Windows Defender Application Control (WDAC) für Process-Whitelisting.

Schicht 3: Service-Konten und Identitäten

Das ADFS-Service-Konto ist eines der kritischsten Konten der gesamten Umgebung. Empfohlene Konfiguration: Group Managed Service Account (gMSA) — passwortlos, automatische Rotation alle 30 Tage. Das gMSA ist Mitglied der Protected Users Group, was zusätzliche Schutzmaßnahmen aktiviert (keine NTLM-Authentication, kürzere Ticket-Gültigkeit, keine unverschlüsselte Delegierung).

Schicht 4: Token-Signing

Die kritischste Schicht — siehe vorigen Abschnitt zu HSM. Token-Signing-Schlüssel in HSM, manuelle Rotation alle 90 Tage, Federation-Metadata-Watcher für unauthorized Trust-Änderungen, DKM-Master-Key zusätzlich in HSM gesichert.

Schicht 5: Detection und Monitoring

Die innerste Schicht. Sicherheitsmaßnahmen ohne Detection sind blind — du weißt nicht, ob sie funktionieren. Vollständige ADFS-Eventlog-Sammlung in zentrales SIEM, Microsoft 365 Sign-In Log überwachen, Extranet Smart Lockout aktiviert, ADFS-Diagnostiker für End-to-End-Trace, Honeytoken-User mit Login-Tracking.

Härtungs-Checkliste auf einen Blick

Schicht	Maßnahme	Priorität
Netzwerk	Drei-Zonen-Modell mit WAP in DMZ	Pflicht
Netzwerk	Outbound-Filterung für ADFS-Server	Pflicht
Netzwerk	Microsegmentation zwischen Tier-Ebenen	Hoch
Netzwerk	Geo-Blocking auf WAP	Mittel
Betriebssystem	Windows Server Core verwenden	Hoch
Betriebssystem	BSI-Grundschutz / CIS-Benchmarks angewandt	Pflicht
Betriebssystem	LAPS aktiv	Pflicht
Betriebssystem	Credential Guard aktiviert	Pflicht
Identitäten	gMSA für ADFS-Service-Account	Pflicht
Identitäten	gMSA Mitglied der Protected Users Group	Hoch
Identitäten	Tier-Modell strikt eingehalten	Pflicht
Identitäten	Privileged Access Workstations für ADFS-Admin	Hoch
Token-Signing	HSM für Token-Signing-Key	Pflicht (NIS2)
Token-Signing	Auto-Cert-Rollover deaktiviert bei HSM	Pflicht
Token-Signing	Vierteljährliche Key-Rotation	Hoch
Token-Signing	Federation-Metadata-Watcher aktiv	Hoch
Detection	ADFS-Eventlogs zu zentralem SIEM	Pflicht
Detection	Entra Sign-In Logs zu SIEM	Pflicht
Detection	Extranet Smart Lockout aktiv	Pflicht
Detection	Korrelations-Regeln für Golden SAML	Hoch
Detection	ADFS-Diagnostiker oder vergleichbares Tool	Empfohlen

MFA bei ADFS: drei Wege im Vergleich

Multi-Factor Authentication (MFA) ist die zweite Identitäts-Prüfung über den klassischen Username/Passwort-Login hinaus — typischerweise über einen zweiten Kanal wie Smartphone-Push, Hardware-Token oder Smartcard. Bei ADFS gibt es drei prinzipielle Wege, MFA zu implementieren, mit deutlich unterschiedlichen Eigenschaften.

Abb.: Drei MFA-Varianten für ADFS: Built-in (Zertifikate, Smartcards), Drittanbieter (Duo, RSA, Yubikey) und Azure MFA (Microsoft Authenticator über Entra ID). Jede Variante hat eigene Stärken — Azure MFA ist heute die empfohlene Wahl für die meisten Umgebungen.

Variante 1: Built-in ADFS-MFA

ADFS bringt seit Server 2012 R2 einige eingebaute zweite Faktoren mit: Zertifikats-basierte Authentication, Smartcard-Authentication und mit Einschränkungen Windows Hello for Business. Kein zusätzlicher Lizenz-Bedarf, vollständig on-premises, cloud-unabhängig. Nachteil: keine modernen Push-Notifications, keine TOTP/OTP-Codes ohne Erweiterung, schlechte User-Experience auf Mobile-Geräten. Heute nur noch in Spezialfällen sinnvoll — Behörden mit Smartcard-Pflicht, Hochsicherheits-Umgebungen ohne Cloud-Anbindung.

Variante 2: Drittanbieter-MFA

Etablierte MFA-Anbieter wie Duo Security, RSA SecurID, Okta, Yubico oder OneLogin bieten Authentication-Provider-Adapter, die in ADFS installiert werden. Diese fragen den zweiten Faktor über ihre jeweilige Infrastruktur ab — Push-Notifications über die Duo-App, Hardware-Token bei RSA oder Yubikey, TOTP/OTP. Vorteile: moderne UX, unabhängig vom Microsoft-Stack, Hardware-Token möglich. Nachteile: zusätzliche Lizenz-Kosten, eigene Verwaltungs-Infrastruktur, nicht in Conditional Access integriert. Heute oft historisch gewachsen — wer Duo oder RSA bereits hat, behält es typischerweise.

Variante 3: Azure MFA

Microsofts Cloud-basierte MFA-Lösung, integriert in Entra ID. Push-Notifications über die Microsoft Authenticator-App, plus TOTP, SMS, Voice-Call, FIDO2-Keys und Windows Hello. Vorteile: in Microsoft 365 E3/E5 enthalten, cloud-skaliert ohne eigenen Server, User-Self-Service-Registrierung, native Integration mit Conditional Access. Nachteile: On-Premises-ADFS muss Internet erreichen können (Tier-0-Bruch im engeren Sinne), Trust zu Entra ID nötig, Auth-Provider-Adapter installieren. Heute die empfohlene Wahl für die meisten Umgebungen — gerade als Brücke zur späteren Entra-ID-Migration.

Azure MFA mit ADFS im Detail

Weil Azure MFA in der Praxis die am häufigsten gewählte Variante ist und die Integration einige Stolperfallen mitbringt, lohnt sich eine detaillierte Betrachtung der Architektur.

Abb.: Azure MFA mit ADFS: die beteiligten Komponenten und die sieben Schritte einer typischen Login-Sequenz. Total-Dauer typischerweise 4-8 Sekunden — der User merkt nur die Push-Bestätigung.

Die beteiligten Komponenten

ADFS-Server (On-Premises): Empfängt den Login-Request, validiert Username/Passwort gegen AD, entscheidet anhand der Authentication Policy, ob MFA nötig ist. Azure MFA Adapter: Ein PowerShell-Modul, das auf dem ADFS-Server installiert wird und als Brücke zwischen ADFS und Entra ID fungiert. Entra ID (Cloud): Hostet den Azure-MFA-Service mit der User-MFA-Konfiguration. Microsoft Authenticator-App: Auf dem User-Smartphone installiert, empfängt Push-Notifications und sendet die User-Bestätigung zurück.

Die Login-Sequenz Schritt für Schritt

Ein typischer Login eines externen Users an Microsoft 365 mit Azure MFA durchläuft sieben Schritte, die in der Praxis 4-8 Sekunden dauern. Schritt 1: User gibt Username und Passwort am ADFS-Login-Portal ein, ADFS validiert gegen Active Directory. Schritt 2: ADFS prüft Conditional Access Policy — ist MFA erforderlich? Wenn ja, ruft die ADFS-Pipeline den registrierten Azure MFA Adapter auf. Schritt 3: Azure MFA Adapter sendet Request an Entra ID, Server-zu-Server-Authentifizierung über einen Service-Principal. Schritt 4: Entra ID sendet Push-Nachricht an den Microsoft Authenticator des Users. Schritt 5: User bestätigt mit „Approve“ (oder gibt Number Matching ein), Entra ID empfängt die Bestätigung. Schritt 6: ADFS stellt SAML-Token mit MFA-Claim aus. Schritt 7: Microsoft 365 erhält das Token und akzeptiert die Session als vorauthentifiziert.

Konfigurations-Voraussetzungen

• Entra-ID-Tenant mit Microsoft-365-E3/E5- oder Entra-ID-P1/P2-Lizenz für alle MFA-User
• Outbound-Internet-Verbindung vom ADFS-Server zu Entra-ID-Endpoints (login.microsoftonline.com, strongauthenticationservice.auth.microsoft.com)
• Microsoft.IdentityServer.Multifactor.AzureMfa-Adapter auf jedem ADFS-Server installiert
• Trust-Beziehung zwischen On-Premises-ADFS und Entra-ID-Tenant über einen Service-Principal eingerichtet
• User-Registrierung: Jeder MFA-User muss sich einmalig bei Azure MFA registrieren — über das Self-Service-Portal oder durch Administration

 

Wichtig: Internet-Zugriff vom ADFS-Server ist ein Tier-0-Kompromiss Für Azure MFA muss der ADFS-Server ausgehende HTTPS-Verbindungen zu Microsoft-Endpoints aufbauen können. Das ist ein Bruch der strengen Tier-0-Regel „kein Internet von ADFS“ — und muss durch andere Maßnahmen kompensiert werden. Konkret: Firewall-Regeln so eng wie möglich (nur die wirklich benötigten Microsoft-Endpoints, am besten als FQDN-basierte Allowlist), Outbound-Proxy mit TLS-Inspection, regelmäßige Audit der ausgehenden Verbindungen. Wer diese Maßnahmen nicht umsetzen kann, sollte alternative MFA-Varianten erwägen — etwa Drittanbieter-MFA mit eigenem On-Premises-Server.

Detection und Monitoring: ohne Sichtbarkeit keine Sicherheit

Härtungs-Maßnahmen ohne Detection sind blind. Du weißt nicht, ob sie funktionieren, du erkennst keinen Angriff im Frühstadium, du hast keine Datenbasis für Incident Response. Detection ist deshalb keine optionale fünfte Schicht — sie ist Pflicht-Bestandteil jeder ernsthaften ADFS-Sicherheits-Architektur.

Abb.: Der Detection-Stack: drei Log-Quellen (ADFS-Eventlogs, Entra Sign-In Logs, DC Security Logs) werden im zentralen SIEM korreliert. Top-Detection-Regeln decken die kritischen Angriffsmuster ab.

Drei Log-Quellen, drei Strategien

ADFS-Eventlogs (lokal): Vier Logs sind relevant — „AD FS“ (Application-Eventlog), „AD FS Tracing“, Security-Log und Application-Log. Auf folgende Events besonders achten: Event 411 (Token-Validierung fehlgeschlagen), Event 364 (Audit-Failure), Event 1200 (Token-Signing-Cert-Rollover), Event 510 (Token-Format-Anomalie), Event 1102 (Audit-Log gelöscht — Angreifer-Indikator).

Entra Sign-In Logs (Cloud): Über die Microsoft Graph API zugänglich. Verdächtige Muster: Sign-Ins mit Token, aber ohne korrespondierenden ADFS-Eventlog-Eintrag (Golden SAML), Time-Travel-Anomalien (User loggt sich gleichzeitig in zwei Kontinenten ein), Token aus untypischen IP-Bereichen, Service-Principal-Logins für User-Accounts, Token-Lifetime ungewöhnlich lang.

Domain Controller Logs: Event 4768 (Kerberos-Ticket angefordert), Event 4625 (Login-Fehlversuch), Event 4769 (TGS-Ausstellung), Event 4624 mit Login-Type 9 (NewCredentials — hinweisend auf Pass-the-Ticket), Privileged Group Modifications.

Korrelation: wo die Angriffe wirklich sichtbar werden

Einzelne Events sind oft unauffällig — Korrelation deckt die Muster auf. Die wichtigste Detection-Regel für Golden SAML: Entra Sign-In ohne korrespondierenden ADFS-Eventlog-Eintrag innerhalb von 60 Sekunden. Da bei Golden SAML die Token-Erstellung außerhalb des ADFS-Servers passiert, gibt es keinen entsprechenden Event im ADFS — der Entra-Login erscheint aber trotzdem. Diese Diskrepanz ist der Indikator.

Angriffsmuster	Detection-Regel	Reaktion
Golden SAML	Entra-Sign-In ohne ADFS-Event innerhalb 60 s	Sofortige Token-Signing-Key-Rotation, Incident Response
Brute Force	> 50 Login-Fehler/Minute oder Source-IP-Burst	Source-IP blocken, Extranet Lockout prüfen
Token Replay	Gleiche SAML AssertionID zweimal verwendet	Session terminieren, Token-Revocation
Federation Hijack	Set-MsolDomainAuthentication oder ähnliche Cmdlets	Sofortige Privileged-User-Prüfung
Pass-the-Cookie	Sign-In aus untypischer Geo + Device-Wechsel	MFA-Re-Auth erzwingen
AD-Compromise	Service-Konto-Anmeldung an Tier-1 oder Tier-2	Sofortige Isolation, gMSA-Rotation

Compliance-Mapping: NIS2, BSI-Grundschutz, DORA

Mehrere regulatorische Anforderungen treffen ADFS-Sicherheit direkt — NIS2 (EU-weit), BSI-Grundschutz (Deutschland), DORA (EU-Finanzsektor). Wer einen produktiven ADFS-Stack betreibt, muss diese Anforderungen in Audits nachweisen können.

Anforderung	NIS2	BSI-Grundschutz	DORA
MFA für externe Anmeldungen	Pflicht (Art. 21)	ORP.4.A22	Pflicht (Art. 9)
Identity-Logging und Audit	Pflicht	ORP.4.A21, OPS.1.1.5	Pflicht (Art. 17)
Tier-0-System-Härtung	Implizit (Risikomanagement)	SYS.2.2 (Privileged)	Implizit
Token-Signing-Key-Schutz	Stand der Technik	CON.1.A14	Stand der Technik
Incident Response Plan	Pflicht (24h-Meldung)	DER.2.1	Pflicht (Art. 17)
Vulnerability Management	Pflicht	OPS.1.1.3	Pflicht (Art. 8)
Backup und Recovery	Pflicht	CON.3	Pflicht (Art. 12)

NIS2 ist seit Oktober 2024 in der EU bindend und betrifft „wesentliche“ und „wichtige“ Einrichtungen — also viele Mittelständler. Die Anforderungen sind technologie-neutral formuliert, was bei der konkreten Umsetzung Spielraum lässt. Konkret für ADFS: MFA ist Pflicht, Token-Signing-Schlüssel müssen „dem Stand der Technik“ entsprechend geschützt sein (was HSM impliziert), Vorfälle müssen innerhalb von 24 Stunden gemeldet werden.

BSI-Grundschutz ist deutscher Standard und detaillierter. Relevant für ADFS: SYS.2.2 (Privileged Access), CON.1.A14 (Schutz kryptographischer Schlüssel), OPS.1.1.3 (Schwachstellenmanagement). Wer nach BSI-Grundschutz zertifiziert ist, hat ADFS-Sicherheit in der Regel sauber adressiert.

DORA (Digital Operational Resilience Act) gilt seit Januar 2025 für den EU-Finanzsektor — Banken, Versicherungen, Zahlungsdienstleister. Identity-Sicherheit ist zentraler Bestandteil, mit harten Audit-Anforderungen und Sanktionen bei Verstößen.

 

NIS2-Mapping konkret Für eine NIS2-konforme ADFS-Umgebung sollten mindestens diese Punkte umgesetzt sein: MFA für alle externen Anmeldungen, HSM für Token-Signing-Key (oder vergleichbar gehärteter Schutz), strukturiertes Identity-Audit-Log in zentralem SIEM, dokumentierter Incident Response Plan mit 24h-Meldekette, regelmäßige Vulnerability Scans der ADFS-Server, dokumentierter Backup- und Recovery-Plan für ADFS-Konfiguration und Token-Signing-Schlüssel. Wer diese Punkte erfüllt, ist NIS2-konform — und gleichzeitig gegen die häufigsten Angriffe gut geschützt. Ein vollständiges NIS2-Mapping inklusive Audit-Vorbereitung ist Teil des ADFS-Sicherheits-Workshops und der Sicherheits-Beratung.

Fazit: ADFS-Sicherheit ist keine Pflichtübung

ADFS-Server sind die exponiertesten Komponenten im Microsoft-Identity-Stack — wer sie kompromittiert, hat Zugriff auf den gesamten Tenant. Gleichzeitig ist die ADFS-Sicherheit handhabbar, wenn sie strukturiert angegangen wird. Defense-in-Depth über fünf Schichten, HSM für Token-Signing, durchdachte MFA-Strategie und kontinuierliche Detection — das ist der Kanon, der die häufigsten Angriffe wirksam abwehrt.

Die wichtigsten Take-aways: Erstens, ADFS-Server sind Tier-0-Systeme und müssen entsprechend behandelt werden — keine Mischung mit Tier-1- oder Tier-2-Workloads, dedizierte Administration über Privileged Access Workstations. Zweitens, Golden SAML ist die gefährlichste Bedrohung und wird nur durch HSM-Einsatz für den Token-Signing-Key zuverlässig verhindert. Drittens, MFA ist heute Pflicht, nicht Empfehlung — Azure MFA ist für die meisten Umgebungen die richtige Wahl. Viertens, ohne Detection ist Härtung blind — Eventlogs aus drei Quellen koordiniert ins SIEM. Fünftens, NIS2 und DORA machen ADFS-Sicherheit zur regulatorischen Anforderung, nicht mehr nur zur Best Practice.

Wer in seiner Umgebung den Reife-Grad der ADFS-Sicherheit strukturiert prüfen möchte: Das ADFS-Diagnostiker-Werkzeug enthält dafür einen dedizierten Hardening Checker, der gegen aktuelle Best Practices prüft, plus einen Token Lifetime Analyzer für NIS2- und BSI-Audit-Vorbereitung. Beratung zu ADFS-Sicherheits-Audit und Härtung ist als strukturiertes Beratungsformat verfügbar — typischerweise als zweitägiger Workshop mit Audit-Report und konkretem Maßnahmen-Plan.

 

Weiterführende Inhalte Übergeordnete Überblicksseite: ADFS in der Praxis. Detailseite zur Beratung mit dem Fünf-Phasen-Modell, Detailseite zum ADFS-Diagnostiker mit den 14 Modulen (inklusive Hardening Checker), Detailseite zu den Schulungen mit dem eintägigen Sicherheits-Workshop „ADFS Sicherheit und Härtung“. Das geplante Buch ADFS in der Praxis behandelt Sicherheit ausführlich in Teil V (Sicherheit und Härtung) und Teil VI (Monitoring und Audit-Vorbereitung). Begleitender Cluster-Artikel zum Web Application Proxy: dort wird die DMZ-Architektur und die WAP-Härtung im Detail behandelt.