ADFS in der Praxis: Der ehrliche Guide zu Active Directory Federation Services

ADFS ist tot? Erzählen Microsoft und die Cloud-Evangelisten gerne. Die Realität sieht anders aus: In erstaunlich vielen Unternehmen läuft ADFS weiter, klaglos, oft seit über einem Jahrzehnt – und nicht selten ohne dass irgendjemand wirklich versteht, was da unter der Haube passiert. Höchste Zeit für einen ehrlichen Überblick: Was ADFS kann, wann du es noch brauchst, wann du besser migrierst, und worauf es im Alltag wirklich ankommt.

Was ADFS eigentlich ist

Active Directory Federation Services – kurz ADFS – ist Microsofts klassischer On-Premises-Identity-Provider. Die Kurzfassung in einem Satz: Ein User meldet sich gegen das interne Active Directory an, ADFS stellt ein Security Token aus, und damit kann sich derselbe User bei Cloud-Diensten oder anderen Anwendungen anmelden, ohne sich nochmal mit Passwort herumzuplagen. Klassisches Single Sign-On, federiert über Unternehmensgrenzen hinweg.

Technisch betrachtet sprechen wir von einem Server, der mehrere Federation-Protokolle gleichzeitig beherrscht:

• WS-Federation – das ursprüngliche Microsoft-Protokoll, lebt vor allem im SharePoint- und CRM-Umfeld weiter
• WS-Trust – für aktive Clients wie Outlook (vor Modern Auth) oder Skype for Business
• SAML 2.0 – der De-facto-Standard für Enterprise-Federation, jeder zweite SaaS-Anbieter spricht das
• OAuth 2.0 und OpenID Connect – ab ADFS 2016 vernünftig nutzbar, ab 2019 wirklich erwachsen geworden

Klingt simpel, ist es aber nicht. Wer schon mal versucht hat, eine produktive ADFS-Farm sauber aufzusetzen, hochverfügbar zu betreiben und mit dem Web Application Proxy durch die DMZ zu schleusen, weiß: Hier steckt einiges an Komplexität. Und genau die Komplexität ist der Grund, warum ADFS-Migrationen so oft schmerzhaft werden.

Abb.: ADFS-Gesamtarchitektur mit Internet, DMZ und internem Netzwerk. Der WAP in der DMZ entkoppelt externe Zugriffe von der ADFS-Farm im Backend.

Warum ADFS 2026 immer noch relevant ist

Du denkst, das Thema ist erledigt, weil „alle eh in der Cloud sind“? Schauen wir mal in die Realität deutscher Unternehmen:

Erstens: Sehr viele Microsoft-365-Tenants laufen heute noch im Federated Mode. Nicht weil das gut wäre, sondern weil es mal so eingerichtet wurde, niemand es angefasst hat, und der Wechsel auf Cloud Authentication oder Pass-through Authentication zwar einfach klingt, in der Praxis aber ein Change-Projekt bedeutet.

Zweitens: ADFS ist nicht nur Microsoft-365-Vorhof. Eine ganze Reihe interner und externer Anwendungen hängt direkt an ADFS – SharePoint-Farmen, alte Web-Apps, branchenspezifische Software, Federation-Verbindungen mit Partnern, Behördenanwendungen, Krankenkassen-Portale. Da kannst du nicht einfach „abdrehen“, da musst du jeden Relying Party einzeln umziehen.

Drittens: ADFS bietet Funktionen, die sich nicht 1:1 in Entra ID abbilden lassen. Custom Claim Rules, komplexe Authentifizierungslogik, Federation mit nicht-Microsoft-IdPs auf SAML-Ebene – das geht in der Cloud zwar auch, aber anders. Und „anders“ heißt: planen, testen, migrieren, dokumentieren.

Viertens: Es gibt Branchen und Regionen, in denen On-Premises-Identity nicht aus Trägheit existiert, sondern aus Compliance-Gründen. Wer als Behörde oder kritische Infrastruktur unterwegs ist, hat unter Umständen Vorgaben, die einen vollständigen Cloud-Wechsel erschweren oder ausschließen.

 

Info: Die strategische Richtung ist trotzdem klar ADFS verschwindet nicht so schnell, wie das Marketing es gerne hätte. Aber Microsoft investiert nicht mehr substantiell in neue ADFS-Features – die kommen primär in Entra ID. Wer heute ADFS neu einführt, hat einen sehr guten Grund dafür oder einen sehr schlechten. Wer ADFS betreibt, sollte parallel die Migrationsstrategie planen.

Die ADFS-Architektur in der Praxis

Eine produktiv betriebene ADFS-Umgebung besteht typischerweise aus drei Komponenten, plus einer ganzen Reihe von Abhängigkeiten:

Die Federation Server Farm

Das Herzstück sind die ADFS-Server selbst, mindestens zwei, in größeren Umgebungen vier oder mehr. Sie stehen im internen Netzwerk und sprechen direkt mit den Domain Controllern. Sie stellen Tokens aus, halten die Konfiguration vor (in einer SQL-Datenbank oder im internen Windows Internal Database), und kümmern sich um die ganze Federation-Logik.

Hochverfügbarkeit kommt klassisch über einen Network Load Balancer davor. F5, Kemp, Citrix ADC, Azure NLB – ist alles üblich. Wichtig: SSL-Offloading wird zwar oft gemacht, ist aber bei ADFS nicht unproblematisch, weil bestimmte Authentifizierungs-Flows die Original-Verbindung erwarten. Wer hier nicht aufpasst, baut sich subtile Probleme ein, die erst Monate später auffallen.

Der Web Application Proxy

Damit User von außen authentifizieren können, ohne die ADFS-Server direkt aus dem Internet erreichbar zu machen, gibt es den Web Application Proxy – kurz WAP. Das Ding steht in der DMZ, hat keine AD-Mitgliedschaft, und reicht Authentifizierungsanfragen nach innen weiter. Sicherheitstechnisch ist das vernünftig konstruiert: Der WAP terminiert die Verbindung von außen, validiert die Anfrage soweit möglich, und routet dann Richtung interner ADFS-Farm.

In der Praxis sind die WAPs oft die Stelle, an der es zuerst weh tut. Zertifikate laufen ab, der Health Check schlägt aus unerklärlichen Gründen fehl, das Trust-Verhältnis zwischen WAP und ADFS bricht weg.

 

Warnung: WAP ist kein Set-and-forget Wer WAP betreibt, sollte Monitoring und Zertifikatsmanagement im Griff haben. „Wir gucken einmal im Quartal“ reicht nicht. Mindestens: automatischer Alarm bei abgelaufenem Zertifikat (60 Tage Vorlauf), Health-Check-Monitoring, dokumentierter Wiederanlauf-Prozess. Sonst stehst du irgendwann nachts um drei vor einem komplett toten externen Login.

Datenbank und Konfiguration

Die ADFS-Konfiguration liegt entweder in einem dedizierten SQL Server oder in der Windows Internal Database. WID ist für kleinere Umgebungen okay, hat aber Einschränkungen: keine echte Replikation, kein SAML-Token-Replay-Detection-Cache über mehrere Server, und die Skalierung ist limitiert. Für ernsthaften Produktiv-Betrieb ist SQL Server der bessere Weg, idealerweise als AlwaysOn Availability Group.

Zertifikate – das ewige Sorgenkind

ADFS hängt an einer ganzen Reihe von Zertifikaten:

• SSL-Zertifikat für die Service Communication
• Token Signing Certificate zum Signieren der ausgestellten Tokens
• Token Decryption Certificate für verschlüsselte Tokens
• Service Communication Certificate für die interne Kommunikation
• Plus die Zertifikate auf den WAPs

Je nachdem, wie ADFS konfiguriert ist, rotieren diese Zertifikate automatisch (AutoCertificateRollover) oder müssen manuell gewechselt werden. Beides hat seine Tücken. Wer schon mal einen automatischen Token-Signing-Rollover hatte, der nicht zu allen Relying Parties weiterpropagiert wurde, kennt die Folgen: ein wunderschöner Komplettausfall der Federation, nachts um drei, weil das Zertifikat genau dann gewechselt hat.

Abb.: Die ADFS-Zertifikatslandschaft mit den vier Rollen Service Communication, Token Signing, Token Decryption und WAP Trust. Wer hier die Übersicht verliert, baut sich Ausfälle ein.

Wie ein Login wirklich abläuft

Theorie ist nett, der Flow im Detail ist nützlicher. Hier der typische Ablauf, wenn ein User extern auf seine Microsoft-365-Mailbox zugreift, mit einem föderierten Tenant:

Abb.: Authentifizierungsfluss von User-Browser über Microsoft 365, WAP und ADFS bis zum Active Directory. Beim zweiten Login innerhalb der Token-Lifetime entfallen die Schritte 5–7.

Drei Dinge sind hier interessant: Erstens, die Anzahl der Hops. Jeder zusätzliche Hop ist ein potentielles Problem (Latenz, Zertifikat, Firewall-Regel). Zweitens, der WAP sieht den Request, kann ihn aber nicht entschlüsseln – er reicht nur durch. Drittens, der eigentliche Authentifizierungs-Aufwand passiert komplett im internen Netz. Genau das ist der Grund, warum ADFS bei externen Login-Stürmen unter Last kommen kann.

Claims – das Konzept hinter ADFS

Ohne ein Verständnis von Claims kommst du bei ADFS nicht weit. Die Idee ist eigentlich simpel: Ein Token enthält Aussagen über den User. Diese Aussagen heißen Claims. Klassische Beispiele:

• „Dieser User heißt max.muster@example.com“
• „Dieser User ist Mitglied der Gruppe Buchhaltung“
• „Dieser User hat sich mit MFA authentifiziert“
• „Dieser User kommt aus dem internen Netzwerk“

Welche Claims im Token landen, bestimmst du über die Claim Rules. Die werden in einer eigenen Sprache geschrieben, der Claims Rules Language, und sind so etwas wie das Lieblings-Streitobjekt zwischen ADFS-Admins. Die Syntax ist eigenwillig, das Debugging mühsam, und die Doku entweder zu knapp oder zu akademisch. Aber: Hat man’s einmal verstanden, ist die Logik wirklich mächtig.

Ein typisches Setup hat zwei Sets von Claim Rules: einmal beim Claims Provider Trust (das holt Claims aus dem AD), einmal beim Relying Party Trust (das transformiert die Claims für die Zielanwendung und filtert, was rausgehen darf). Dazwischen kann man transformieren, anreichern, filtern, neue Claims aus bestehenden ableiten – die Möglichkeiten sind groß, die Fehlerquellen leider auch.

Abb.: Die Claims-Pipeline in drei Stufen: Aus AD-Attributen werden via Claims Provider Trust initiale Claims, in der ADFS-Pipeline gehalten, und im Relying Party Trust pro Zielanwendung gefiltert und transformiert.

 

Praxis-Tipp: Claim Rules immer in Test-RPs ausprobieren Lege dir einen dedizierten Test-Relying-Party an, der einfach das komplette Token zurückspiegelt – etwa eine kleine Web-App oder einen öffentlichen SAML-Tester. Damit kannst du Claim-Rule-Änderungen risikofrei prüfen, bevor du sie auf produktive RPs loslässt. Das spart dir mehr Nerven, als du dir aktuell vorstellen kannst.

Trusts: Claims Provider und Relying Party

Zwei Begriffe, die du verstehen musst: Claims Provider Trust und Relying Party Trust.

Ein Claims Provider Trust ist die Quelle der Identität. In den allermeisten Fällen ist das das eigene Active Directory – ADFS holt sich von dort die User-Attribute und macht daraus initiale Claims. Du kannst aber auch andere IdPs als Claims Provider eintragen, etwa wenn du eine Federation mit einem Partnerunternehmen aufbaust und deren User über ADFS auf eure Anwendungen zugreifen sollen.

Ein Relying Party Trust ist die Zielanwendung, die ADFS vertraut. Das kann Microsoft 365 sein, eine SharePoint-Farm, ein SaaS-Anbieter wie Salesforce, oder eine selbstgebaute Anwendung. Pro Relying Party konfigurierst du, welche Claims das Token enthält, mit welchen URLs gearbeitet wird, ob Token verschlüsselt werden, welche Authentifizierungsmethode verlangt wird, und vieles mehr.

In der Praxis sammeln sich Relying Party Trusts über die Jahre an wie Staub in einem alten Serverraum. Du wirst regelmäßig welche entdecken, von denen niemand mehr weiß, wer die mal eingerichtet hat. Eine ehrliche Inventarisierung der Relying Parties ist meist der erste Schritt, bevor du über eine ADFS-Migration nachdenkst.

Wann ADFS noch Sinn ergibt – und wann nicht

Lass uns kurz die Karten auf den Tisch legen.

Pro ADFS in 2026

• Du hast eine etablierte ADFS-Umgebung, sie läuft stabil, und es gibt keinen geschäftlichen Druck zu migrieren
• Du hast Anwendungen, die nur SAML oder WS-Fed sprechen und keine direkte Cloud-Authentifizierung unterstützen
• Du hast strenge Datenresidenz- oder Compliance-Anforderungen, die On-Premises-IdP erzwingen
• Du betreibst komplexe Federation-Szenarien mit mehreren Partnern, die sich nicht trivial auf Entra ID External Identities übertragen lassen
• Du brauchst sehr spezifische Claim-Transformations, die sich in Entra ID nur über Workarounds abbilden lassen

Contra ADFS

• Microsoft investiert nicht mehr substantiell in ADFS-Funktionen
• Die Angriffsfläche ist real – ADFS-Server waren in den letzten Jahren mehrfach Ziel ernster Sicherheitsvorfälle (Stichwort SolarWinds, Golden SAML)
• Der Betriebsaufwand ist hoch: Patching, Zertifikatsmanagement, Hochverfügbarkeit, WAP-Betrieb, Monitoring
• Moderne Authentifizierungsfeatures wie Conditional Access, Identity Protection, Risk-based Sign-In bekommst du nur in Entra ID
• Die Talent-Lage ist schwierig: ADFS-Wissen wird zunehmend rar, weil neue Admins direkt mit Cloud-Identity einsteigen

Heißt nicht, dass ADFS schlecht ist. Heißt nur: Die strategische Richtung ist klar, und wenn du heute neu planst, musst du sehr gute Argumente haben, um nicht direkt auf Entra ID zu setzen.

ADFS und Microsoft 365: die typischen Szenarien

Wenn du Microsoft 365 betreibst, hast du grundsätzlich vier Wege, wie deine User authentifiziert werden:

• Cloud-only – Identitäten leben nur in Entra ID, kein On-Prem-AD beteiligt
• Password Hash Sync (PHS) – Hashes der Passwörter werden in die Cloud synchronisiert, Authentifizierung passiert in der Cloud
• Pass-through Authentication (PTA) – Authentifizierung wird in Echtzeit ans On-Prem-AD durchgereicht, ohne Hash-Sync
• Federated Authentication – ADFS oder ein Drittanbieter-IdP authentifiziert die User

Abb.: Vergleich der vier Authentifizierungsmodi für Microsoft 365. Je weiter rechts, desto mehr On-Prem-Aufwand und Abhängigkeit vom internen Betrieb.

Federation war historisch der „richtige“ Weg für ernsthafte Enterprise-Setups. Heute ist es eher der Sonderfall. PHS plus Seamless SSO deckt die meisten Anforderungen ab, ist deutlich einfacher zu betreiben, und bietet als Bonus die Disaster-Recovery-Option, dass die Authentifizierung weiterläuft, auch wenn dein On-Prem komplett auseinanderfällt.

Wenn du heute noch federiert bist, lautet die ehrliche Frage: Warum eigentlich? In neun von zehn Fällen lässt sich das auf PHS umstellen, ohne dass jemand etwas merkt – außer dass der Login-Vorgang etwas schneller wird und die ADFS-Farm endlich abgebaut werden kann.

Migration zu Entra ID: was du wirklich beachten musst

Wenn du den Sprung wagen willst, sind hier die wichtigsten Bausteine:

Inventarisierung

Du musst wissen, was alles auf ADFS hängt. Das klingt trivial, ist es aber nicht. Microsoft 365 ist offensichtlich. Die SharePoint-Farm im Keller weniger. Das Partnerportal, das vor sieben Jahren mal eingerichtet wurde, schon gar nicht. Hier hilft entweder eine systematische ADFS-Konfigurationsanalyse oder ein dediziertes Diagnose-Tool, das die Relying Parties auflistet, ihre Konfiguration extrahiert und kategorisiert.

Modernisierung der Anwendungen

Je nach Anwendung ist die Migration unterschiedlich:

• Microsoft 365: Trivial. Set-MsolDomainAuthentication -Authentication Managed, fertig. Vorher PHS einrichten, danach ADFS-Trust ausbauen.
• Cloud-Apps mit OIDC/OAuth-Support: Direkt auf Entra ID umstellen, neue App-Registrierung, Konfiguration anpassen.
• SAML-Apps: Neue Enterprise Application in Entra ID anlegen, Claims neu mappen, Endpoints umkonfigurieren. Aufwand variabel.
• Legacy-Apps mit WS-Fed: Schwieriger. Entra ID kann WS-Fed, aber die Klick-Wege sind anders. Manchmal ist hier ein Application Proxy oder eine Modernisierung der App der einzige Weg.
• Apps, die nur Kerberos sprechen: Bleiben on-prem, brauchen Application Proxy oder einen anderen Brückenkopf.

Conditional Access als Ablösung der ADFS-Logik

Vieles, was du in ADFS mit Claim Rules gemacht hast – Netzwerk-basierte Filter, MFA-Erzwingung, Anwendungs-spezifische Authentifizierung – machst du in Entra ID mit Conditional Access. Das ist mächtiger und übersichtlicher, aber eben anders. Plane Zeit ein, die alten Regeln zu verstehen, zu dokumentieren und in Conditional-Access-Policies zu übersetzen.

Pilotierung und Wellen

Eine Big-Bang-Migration ist bei ADFS selten klug. Migriere in Wellen: Erst weniger kritische Apps, dann produktive Systeme, am Ende Microsoft 365. Halte ADFS so lange parallel, bis wirklich alle Relying Parties umgezogen sind. Plane mindestens drei bis sechs Monate Migrationsphase, bei größeren Umgebungen auch mehr.

Abb.: Typischer Migrationspfad in vier Wellen. Welle 1 ist die wichtigste – wer hier schludert, bekommt in Welle 4 unangenehme Überraschungen.

Sicherheit: ADFS härten ist kein Optional

Wenn du ADFS weiter betreibst, dann bitte richtig. ADFS-Server sind extrem attraktive Angriffsziele, weil sie die Brücke zwischen On-Prem und Cloud darstellen. Kompromittiere den Token-Signing-Schlüssel, und du kannst beliebige Tokens für beliebige User ausstellen – willkommen im Golden-SAML-Szenario.

 

Warnung: ADFS ist Tier-0 ADFS-Server gehören in dieselbe Schutzklasse wie Domain Controller. Kein Browsen, kein E-Mail, keine Drittanwendungen, separates Admin-Konzept, separate Workstations für die Verwaltung, Hardware Security Module für die Schlüssel. Wer hier schludert, baut sich die Bühne für ein klassisches Identity-Disaster.

Abb.: Das Microsoft-Tier-Modell: ADFS gehört in Tier 0, gleichberechtigt neben Domain Controllern und PKI. Vertikale Bewegung zwischen den Tiers ist die Grenze, an der Sicherheit gewonnen oder verloren wird.

Die Mindestanforderungen für einen vernünftigen Betrieb:

• Tier-0-Behandlung wie oben beschrieben
• Hardware Security Module für die Schlüssel: Wenn dein Token-Signing-Key in Software auf dem Server liegt, ist er bei Kompromittierung des Servers sofort weg. HSM-Anbindung verhindert genau das.
• Extranet Smart Lockout: Verhindert, dass externe Brute-Force-Angriffe interne Account Lockouts auslösen.
• Modern Authentication erzwingen: Legacy-Auth-Protokolle abschalten, wo immer möglich.
• Logging und Monitoring auf Profi-Niveau: ADFS-Audit-Logs in ein SIEM, Auswertung auf verdächtige Token-Ausstellungen, Alarme auf ungewöhnliche Patterns.
• Patching ohne Verzögerung: ADFS-Patches sofort einspielen. Das ist kein „machen wir nächsten Monat“-Thema.
• Regelmäßige Konfigurations-Audits: Wer hat was an Claim Rules geändert? Welche Relying Partys wurden hinzugefügt? Drift erkennen, dokumentieren, entscheiden.

Warum das alles? Weil im Worst Case nicht nur ein User-Konto kompromittiert wird, sondern die gesamte Federation – und damit jeder einzelne Account, der je über ADFS authentifiziert wurde:

Abb.: Golden-SAML-Angriff: Wer den Token Signing Key extrahiert, kann beliebige Tokens für beliebige User ausstellen – komplett offline, ohne dass auch nur ein Eintrag in einem ADFS-Audit-Log auftaucht. Genau das ist der Grund, warum HSM und Tier-0-Trennung kein Optional sind.

Troubleshooting: die Klassiker

Was bei ADFS in der Praxis am häufigsten knallt:

Zertifikatsprobleme – Token-Signing läuft ab, niemand merkt es vorher, Federation steht still. Vorbeugen: Monitoring auf Zertifikatsablauf, mindestens 60 Tage Vorlauf, dokumentierter Rollover-Prozess.

Replication-Issues bei mehreren ADFS-Servern – Konfigurationsänderungen kommen nicht überall an, ein Server zeigt anderes Verhalten als ein anderer. Vorbeugen: SQL-basierte Konfiguration statt WID, Health Checks aktivieren, regelmäßig auf Konsistenz prüfen.

Falsche Claim Rules – nach einem Change kommt das gewünschte Attribut nicht im Token an, der Login bei der Zielanwendung schlägt fehl. Vorbeugen: Claim Rules immer in Test-RP testen, ADFS-Diagnostics nutzen, Token-Inhalte mit Tools wie SAML Tracer oder Fiddler verifizieren.

WAP-Probleme – externe Logins funktionieren nicht, interne schon. Klassiker: WAP-Trust gebrochen, Service Communication Certificate auf WAP nicht aktualisiert, Firewall-Regel verändert. Vorbeugen: WAP separat monitoren, Trust-Status regelmäßig prüfen, dokumentierte Recovery-Schritte.

Performance-Probleme unter Last – Login-Stürme nach einem Outage, ADFS antwortet langsam oder gar nicht. Vorbeugen: Sizing-Berechnung machen, ADFS-Performance-Counter auswerten, ggf. mehr Server, SQL als Backend, Token-Cache-Größe tunen.

 

Praxis-Tipp: Diagnose-Werkzeuge bereithalten Drei Werkzeuge gehören in jedes ADFS-Notfall-Kit: ein SAML-Tracer (Browser-Extension oder Fiddler) zum Inspizieren der Token, das ADFS-Diagnostic-PowerShell-Modul für strukturierte Health-Checks, und ein dediziertes Konfigurations-Diagnose-Tool, das Drift und Best-Practice-Verstöße sichtbar macht. Wer das erst im Vorfall installiert, hat es schon verloren.

Wartung: was im Jahresrhythmus zu tun ist

Eine produktive ADFS-Umgebung braucht Pflege. Mein Pragmatik-Plan für den Betrieb:

• Wöchentlich: Eventlog-Sichtung, Health-Status der Farm, WAP-Status, Zertifikate-Restlaufzeit prüfen
• Monatlich: Patches einspielen (nicht erst quartalsweise!), Token-Issuance-Statistik auswerten, ungewöhnliche Patterns prüfen
• Quartalsweise: Konfigurations-Audit (welche Claim Rules wurden geändert? welche RPs hinzugefügt?), Backup-Restore-Test, Disaster-Recovery-Drill
• Jährlich: Komplette Sicherheits-Review, Zertifikats-Rollover-Plan validieren, Sizing prüfen, Strategie-Review (lohnt der Weiterbetrieb noch?)

Wer das ernst nimmt, hat einen ruhigen Federation-Betrieb. Wer das nicht macht, hat irgendwann eines Nachts einen sehr unruhigen Anruf.

Fazit: ADFS ist nicht tot, aber auf der Zielgeraden

Active Directory Federation Services bleibt ein wichtiges Stück Infrastruktur in vielen Microsoft-Umgebungen, und es wird auch die nächsten Jahre nicht komplett verschwinden. Aber die strategische Richtung ist eindeutig: Wer heute kann, sollte migrieren. Wer es nicht kann, sollte es professionell betreiben – mit ordentlichem Sicherheitskonzept, sauberem Monitoring, dokumentierten Prozessen, und einer klaren Roadmap, wann und wie der Ausstieg kommt.

Was du nicht machen solltest: ADFS einfach laufen lassen, ohne hinzuschauen. Genau das ist der häufigste Fehler – und gleichzeitig das größte Risiko.