ADFS oder Entra ID in der Verwaltung
Die Migrationsfrage entlang der Fachverfahren – aus der Praxis eines LandschaftsverbandesADFS oder Entra ID in der Verwaltung: Die Entscheidung entlang der Fachverfahren
Der Workshop begann mit einem Satz, den man in dieser Form selten hört. Der Leiter der IT eines großen Landschaftsverbandes sagte: „Unsere ADFS-Farm läuft seit neun Jahren störungsfrei. Das ist das Problem." Nach einer kurzen Pause kam die Erklärung. Störungsfrei bedeutet in diesem Fall: Niemand hat sie in den letzten Jahren angefasst. Niemand weiß mehr genau, was auf ihr konfiguriert ist. Und der Kollege, der es wusste, geht in achtzehn Monaten in den Ruhestand.
Das ist keine Anekdote, sondern der Normalzustand. Active Directory Federation Services ist die vermutlich unauffälligste betriebskritische Komponente in deutschen Verwaltungsnetzen. Sie steht in irgendeinem Rack, sie hat zwei Knoten und zwei Proxyserver im Netzübergang, sie fällt exakt einmal im Jahr auf – nämlich dann, wenn ein Zertifikat abläuft und plötzlich niemand mehr in das Ratsinformationssystem kommt. Und irgendwann kommt die Frage: bleiben oder gehen?
Die Antwort ist selten so eindeutig, wie sie von Herstellerseite klingt, und selten so kompliziert, wie sie in der ersten Projektsitzung wirkt. Sie hängt nämlich nicht an ADFS. Sie hängt an den Fachverfahren, die daran angebunden sind. Dieser Beitrag geht die Entscheidung entlang genau dieser Verfahren durch – so, wie wir sie im erwähnten Workshop durchgegangen sind, in anonymisierter Form und ohne die Stellen wegzulassen, an denen es unbequem wurde.
Dieser Beitrag gehört zur Reihe Microsoft 365 in der öffentlichen Verwaltung. Dort finden Sie den Überblick über die Themen, die bei einer Einführung zusammenhängen – von der Betriebsmodell-Entscheidung bis zur Schriftgutverwaltung. Die Identitätsfrage ist eine davon, und sie kommt in der Praxis meist früher, als es im Projektplan steht.
Der Ausgangspunkt: ADFS ist nicht abgekündigt, aber es altert
Was Microsoft tatsächlich sagt – und was nicht
Fangen wir mit der Klarstellung an, weil an dieser Stelle regelmäßig Halbwissen durch die Flure wandert. ADFS ist nicht abgekündigt. Die Rolle ist in Windows Server 2025 weiterhin enthalten, sie ist unterstützt, sie taucht in keiner Liste entfernter oder veralteter Funktionen auf, und es gibt kein veröffentlichtes End-of-Support-Datum. Wer Ihnen erzählt, ADFS werde „nächstes Jahr abgeschaltet", verkauft Ihnen etwas.
Gleichzeitig empfiehlt Microsoft ausdrücklich, statt eines Farm-Upgrades die Migration nach Microsoft Entra ID zu prüfen. Und wenn man sich ansieht, was in den letzten Generationen tatsächlich an Funktionen hinzugekommen ist, versteht man, warum. Die letzten nennenswerten Neuerungen stammen aus Windows Server 2019: Unterstützung für Proof Key for Code Exchange im Autorisierungscode-Fluss und die Möglichkeit, den Ressourcenwert im Bereichsparameter mitzugeben. Danach kam wenig. Manches ist sogar weggefallen – die Bereiche für Profil- und E-Mail-Ansprüche werden nicht mehr unterstützt, ebenso wenig die Ausstellung von VPN-Zertifikaten. Der Verschlüsselungsalgorithmus für Token der vertrauenden Seite ist fest auf AES256 gesetzt und lässt sich nicht ändern.
Das ist die ehrliche Beschreibung: ein solides, funktionierendes, gepflegtes Produkt im Wartungsmodus. Für eine Behörde, deren Anforderungen sich in den nächsten fünf Jahren nicht verändern, ist das völlig ausreichend. Kennen Sie eine solche Behörde?
|
FAKTEN · Der Stand der Dinge in drei Sätzen ADFS ist in Windows Server 2025 enthalten und wird unterstützt. Ein Enddatum für den Support ist nicht veröffentlicht. Microsoft empfiehlt für den Anwendungsfall der Anmeldung an Microsoft 365 und an modernen Fachverfahren die Nutzung von Microsoft Entra ID statt eines Föderationsdienstes. Neue Funktionen fließen seit Jahren fast ausschließlich in die Cloud-Plattform. Wer auf der Farm bleibt, bekommt Sicherheitsaktualisierungen, aber keine Weiterentwicklung. |
|---|
Das eigentliche Risiko sitzt nicht im Rack
Im Workshop haben wir eine einfache Übung gemacht. Wir haben gefragt: Wer im Haus kann eine Anspruchsregel lesen und erklären, was sie tut? Antwort: eine Person. Wer kann einen Signaturzertifikatswechsel auf der Farm und an allen vertrauenden Seiten durchführen, ohne dabei nachzuschlagen? Dieselbe Person. Wer hat in den letzten drei Jahren ein Farm-Upgrade begleitet? Wieder dieselbe.
Das ist kein Vorwurf an die IT-Leitung. Das ist die logische Folge davon, dass ADFS ein Spezialwerkzeug ist, das im Alltag niemanden beschäftigt. Genau deshalb ist es aber ein Klumpenrisiko, das in keiner Risikoanalyse auftaucht, weil Risikoanalysen Systemausfälle betrachten und keine Ruhestandstermine. Dass dieselbe Konzentration bei privilegierten Konten auftritt, ist ein verwandtes Thema – dazu passt der Beitrag über Rollen und die privilegierte Identitätsverwaltung.
Wenn Sie sich fragen, wie sich das strukturell auflösen lässt, hilft der Beitrag Privilegierte Konten in der Verwaltungs-IT: Rollen, PIM und der Fall des einen Admins. Er beschreibt denselben Effekt an anderer Stelle: Ein Haus mit 2.400 Beschäftigten und einer Person, die alles darf, hat kein Berechtigungskonzept, sondern eine Personalakte als Notfallplan.

Skizze 1: Derselbe Anmeldevorgang, zwei Betriebsmodelle. Links das, was heute im Rack steht. Rechts das, was danach betrieben werden muss – weniger Blech, mehr Regelwerk.
|
WARNUNG · Der Klassiker, den wir in jedem zweiten Haus finden Die ADFS-Farm ist im Notfallhandbuch als „unkritisch" eingestuft, weil sie keine Fachdaten hält. Fällt sie aus, kommt niemand mehr in das Fachverfahren, in das Ratsinformationssystem und in Microsoft 365. Das ist die Definition von kritisch. Prüfpunkt: Steht die Farm in Ihrer Notfallplanung mit einer Wiederanlaufzeit? Ist der Zertifikatskalender dokumentiert und außerhalb der Farm hinterlegt? Wenn Sie beides nicht in fünf Minuten beantworten können, haben Sie Ihre erste Aufgabe unabhängig von jeder Migrationsentscheidung. |
|---|
Die Inventur: Welche Fachverfahren hängen eigentlich dran?
Bevor irgendjemand über Migrationspfade redet, braucht es eine Liste. Nicht die Liste, die vor sechs Jahren einmal in einer Excel-Datei angelegt wurde, sondern eine belastbare aus dem laufenden System. Der Landschaftsverband hatte eine Liste mit elf Anwendungen. In der Farm standen dreiunddreißig vertrauende Seiten.
Die Werkzeuge, die Microsoft dafür mitliefert
Für die Bestandsaufnahme gibt es im Microsoft Entra Admin Center die ADFS-Anwendungsmigration. Sie sitzt unter „Nutzung und Erkenntnisse" und liest über die Health-Agenten für ADFS die Konfiguration der vertrauenden Seiten sowie die Anmeldeprotokolle aus. Voraussetzung sind Entra Connect auf der lokalen Seite, die Connect-Health-Agenten für ADFS auf den Farmknoten, eine Lizenz Entra ID P1 oder P2 und eine passende Rolle – Anwendungsadministrator, Cloudanwendungsadministrator oder lesend Globaler Leser beziehungsweise Berichtsleser.
Das Werkzeug bewertet jede Anwendung und vergibt einen von drei Zuständen. „Bereit für die Migration" bedeutet, dass die Konfiguration vollständig in Entra ID abbildbar ist. „Überprüfung erforderlich" bedeutet, dass Teile übernommen werden können, einzelne Einstellungen aber nachgesehen werden müssen – ohne dass sie die Migration blockieren. „Weitere Schritte erforderlich" bedeutet, dass Entra ID mindestens eine Einstellung nicht unterstützt und die Anwendung so nicht umziehen kann.
Für die Anspruchsregeln gibt es eine eigene Prüfung mit sprechenden Befunden. Reguläre Ausdrücke in Bedingungen oder Transformationen werden markiert, weil Entra ID sie nicht eins zu eins kennt, sondern über vordefinierte Funktionen abbildet – Extract, Trim, ToLower, IfEmpty, StartWith, Contains. Ein Attributspeicher außerhalb von Active Directory wird als Blocker markiert, weil Entra ID Ansprüche derzeit nur aus Active Directory oder aus dem Verzeichnis selbst bezieht. Und geschützte Ansprüche lassen sich zwar ausstellen, aber weder in ihrer Quelle ändern noch transformieren.
|
WARNUNG · Das 30-Tage-Fenster ist eine Falle, wenn man es nicht kennt Das Migrations-Dashboard zeigt ausschließlich vertrauende Seiten, an denen in den letzten 30 Tagen tatsächlich Anmeldungen stattgefunden haben. Der Filter lässt sich auf einen Tag, sieben Tage oder dreißig Tage stellen – weiter zurück geht er nicht. Für eine Verwaltung heißt das: Ein Verfahren, das nur zum Jahresabschluss, zur Haushaltsplanung oder zur Kommunalwahl benutzt wird, taucht schlicht nicht auf. Wer die Farm nach Dashboard-Liste abschaltet, schaltet mit hoher Wahrscheinlichkeit ein Verfahren mit ab, das im November gebraucht wird. Gegenmaßnahme: Immer zusätzlich die vertrauenden Seiten direkt aus der Farm exportieren und beide Listen gegeneinanderlegen. Die Differenz ist die interessante Menge – und die Gesprächsgrundlage mit den Fachämtern. |
|---|
Was die Inventur regelmäßig zutage fördert
Der Befund im Workshop war unspektakulär und deshalb repräsentativ. Von dreiunddreißig vertrauenden Seiten waren vier reine Testeinträge aus einem Projekt, das 2019 endete. Drei gehörten zu Microsoft selbst und werden im Dashboard ohnehin nicht angezeigt – Einträge wie der für die Anmeldung an Microsoft 365 oder die Zertifikatsbereitstellung für Windows Hello. Zwei Verfahren waren bereits abgelöst, die vertrauende Seite hatte nur niemand entfernt. Blieben vierundzwanzig, die wirklich jemanden betreffen.
|
Befundkategorie |
Anzahl |
Was daraus folgte |
|---|---|---|
|
Karteileichen |
9 |
Vertrauende Seiten ohne Anmeldung seit über einem Jahr. Nach Rückfrage im Fachamt und Vermerk in der Akte abgeschaltet. |
|
SAML 2.0, Standardansprüche |
11 |
Direkt als Unternehmensanwendung in Entra ID abbildbar. Der Assistent übernimmt Bezeichner, Antwort-URL und die übersetzbaren Ansprüche. |
|
SAML 2.0, komplexe Regeln |
5 |
Reguläre Ausdrücke und mehrstufige Bedingungen. Migration möglich, aber Handarbeit an den Anspruchszuordnungen. |
|
WS-Federation mit SAML 1.1 |
4 |
Zwei SharePoint-Anwendungen und zwei ältere Fachverfahren. Manuell über PowerShell oder generische Katalogvorlage. |
|
Kein modernes Protokoll |
3 |
Integrierte Windows-Authentifizierung und ein kopfzeilenbasiertes Portal. Kandidaten für den Anwendungsproxy. |
|
Echte Blocker |
1 |
Ein Verfahren mit WS-Trust im ActAs-Muster. Weder Assistent noch Handarbeit helfen; Gespräch mit dem Hersteller unvermeidlich. |
|
TIPP · Die Inventur ist mehr wert als das Migrationsergebnis Rechnen Sie die Bestandsaufnahme nicht als Vorarbeit, sondern als eigenständiges Ergebnis. Eine belastbare Liste aller Verfahren mit Anmeldeweg, Ansprechpartner im Fachamt, Herstellerkontakt und Nutzungsintensität ist in vielen Häusern das erste vollständige Anwendungsverzeichnis überhaupt. Sie brauchen dieses Verzeichnis ohnehin – für das Verarbeitungsverzeichnis, für den Schutzbedarf, für die Notfallplanung und für die nächste Ausschreibung. Wenn die Migration danach politisch verschoben wird, haben Sie trotzdem etwas gewonnen. |
|---|
Der Migrationspfad je Anwendungstyp
Und damit zum Kern. Die Entscheidung „ADFS oder Entra ID" ist keine einzelne Entscheidung, sondern eine pro Verfahren. Das klingt nach mehr Arbeit und ist tatsächlich weniger, weil es die Diskussion von der Grundsatzebene auf die Sachebene holt. Es gibt keinen Grund, wegen eines einzigen sperrigen Verfahrens alle anderen auf der Farm zu lassen.
SAML-Fachverfahren: der Hauptteil und der einfache Teil
Die große Mehrheit der Verfahren, die heute an ADFS hängen, spricht SAML 2.0. Diese Verfahren werden in Entra ID als Unternehmensanwendung angelegt – entweder aus dem Katalog, wenn der Hersteller dort vertreten ist, oder als eigene Anwendung ohne Vorlage. Die Zuordnung der Einstellungen ist erfreulich geradlinig: Der Bezeichner der vertrauenden Seite wird zum Bezeichner der Anwendung und landet im Zielgruppenelement des Tokens, die Endpunktadresse wird zur Antwort-URL und landet im Zielelement, und die Regel, die bei ADFS den Namensbezeichner ausstellt, wird zum Namensbezeichner-Anspruch.
Auf der Gegenseite ändern sich vier Werte, die im Fachverfahren hinterlegt werden müssen: die Anmeldeadresse, die Abmeldeadresse, der Aussteller und das Signaturzertifikat. Bei ADFS war das der Dienstname mit dem Pfad zum Anmeldedienst. Bei Entra ID sind es die Endpunkte des Mandanten für das SAML-Protokoll und ein Aussteller in der Form eines Sicherheitstokendienstes mit der Mandantenkennung. Das Signaturzertifikat wird ausdrücklich nicht mitmigriert – Sie laden es aus Entra ID herunter und hinterlegen es in der Anwendung.
Ein Detail, das im Projekt regelmäßig Zeit kostet: Entra ID liest die Föderationsmetadaten der Anwendung nicht selbst ein. Was bei ADFS über die Überwachungsfunktion automatisch aktualisiert wurde, ist hier ein manueller Import. Wer viele Anwendungen mit rotierenden Verschlüsselungszertifikaten hat, sollte das in den Betriebsablauf schreiben und nicht auf ein Ticket warten.
WS-Federation-Altlasten: machbar, aber ohne Komfort
Der Migrationsassistent hilft hier nicht. Er unterstützt ausschließlich SAML-Konfigurationen; OpenID Connect, OAuth und WS-Federation sind ausdrücklich ausgenommen. Das heißt aber nicht, dass diese Anwendungen nicht umziehen können.
Entra ID stellt einen eigenen Endpunkt für das WS-Federation-Protokoll bereit, und Anwendungen, die ein Token nach SAML 1.1 erwarten – klassischerweise SharePoint – lassen sich manuell über PowerShell konfigurieren. Alternativ gibt es im Katalog eine vorintegrierte generische Vorlage für SharePoint und SAML-1.1-Anwendungen. Der Weg ist beschrieben, er ist unterstützt, und er ist mühsam. Rechnen Sie pro Anwendung mit einem Vielfachen des Aufwands einer SAML-2.0-Anwendung, und rechnen Sie fest mit einer Testrunde, bei der die Anwendung mit einem Anspruch nicht zufrieden ist, der bei ADFS jahrelang unauffällig war.
Bei SharePoint-Anwendungen im Sozialbereich lohnt sich an dieser Stelle ein Blick auf die fachliche Seite. Eine Stadtverwaltung, die SharePoint dort im Einsatz hat, diskutiert bei der Föderationsumstellung fast zwangsläufig auch über Berechtigungen und über die Frage, wo die Grenze zur E-Akte nach Landesrecht verläuft. Der Beitrag SharePoint als E-Akte? Was geht, was nicht und wo die Grenze nach Landesrecht liegt zieht diese Grenze ausführlich – und macht deutlich, dass die Anmeldefrage und die Frage der aktenführenden Stelle zwei verschiedene Baustellen sind, die man nicht im selben Vermerk erledigt.
|
WARNUNG · Zwei Muster, die heute nicht migrieren können WS-Trust im ActAs-Muster. Anwendungen, die im Namen eines Benutzers ein Token für einen nachgelagerten Dienst anfordern, finden in Entra ID keine Entsprechung. Typisch für ältere mehrschichtige Fachverfahren mit einem Portal vor einem Anwendungsserver. SAML-Artefaktauflösung. Der Umweg über eine Artefaktreferenz statt eines direkt übermittelten Tokens wird nicht unterstützt. Vereinzelt in älteren Verfahren mit Landesbezug anzutreffen. Für beide Fälle gibt es genau drei Handlungsoptionen: Umbau durch den Hersteller, Ablösung des Verfahrens, oder eine bewusst befristete Restföderation für dieses eine Verfahren. Die dritte Option ist legitim – solange sie befristet, dokumentiert und mit einem Termin versehen ist. Sonst wird aus der Restföderation ein Dauerbetrieb mit einem Verfahren und zwei Servern. |
|---|
OpenID Connect und OAuth: die Verfahren, die kein Problem sind
Anwendungen, die OpenID Connect oder OAuth 2.0 sprechen – typischerweise neuere Fachverfahren als Dienstleistung und selbst entwickelte Lösungen –, werden in Entra ID als Anwendungsregistrierung angelegt. Der Assistent hilft auch hier nicht, aber diese Anwendungen brauchen ihn auch nicht. Die Konfiguration besteht aus einer Registrierung, einer Umleitungsadresse, einem Geheimnis oder Zertifikat und der Zuweisung von Berechtigungen.
Der interessante Teil ist nicht technisch, sondern organisatorisch: Bei Verfahren als Dienstleistung entscheidet oft der Hersteller, welche Identitätsanbieter unterstützt werden. Die Frage gehört deshalb in die Leistungsbeschreibung, und zwar früher, als es den meisten Vergabestellen lieb ist.
Wie man das sauber formuliert, ohne sich vergaberechtlich festzulegen, ist ein eigenes Thema. Der Beitrag Microsoft 365 rechtssicher beschaffen: Vergabe, Leistungsbeschreibung, Rahmenverträge geht auf die Formulierungsfragen ein. Für unseren Zusammenhang genügt ein Satz: Eine Anforderung wie „Die Anwendung unterstützt die Anmeldung über OpenID Connect oder SAML 2.0 gegen einen vom Auftraggeber gestellten Identitätsanbieter" kostet nichts und erspart später sehr viel.
Alles ohne modernes Protokoll: der Anwendungsproxy
Bleibt die Gruppe, die weder SAML noch OpenID Connect kann: Webanwendungen mit integrierter Windows-Authentifizierung, kopfzeilenbasierte Portale, Formularanmeldungen. Hier greift der Anwendungsproxy von Microsoft Entra. Er besteht aus dem Dienst in der Cloud und einem privaten Netzwerkkonnektor, der als schlanker Agent auf einem Windows-Server im eigenen Netz läuft.
Für die Sicherheitsbetrachtung ist ein Punkt zentral: Der Konnektor baut ausschließlich ausgehende Verbindungen über die Ports 80 und 443 auf. Es müssen keine eingehenden Verbindungen durch die Firewall geöffnet werden, und ein Netzübergang mit domänengebundenen Servern wird nicht gebraucht. Der gesamte Verkehr zur Zielanwendung endet im Dienst und wird zum Backend neu aufgebaut. Für Anwendungen mit integrierter Windows-Authentifizierung übernimmt der Konnektor die eingeschränkte Kerberos-Delegierung. Kopfzeilenbasierte Anwendungen brauchen einen Partnerdienst, der die Kopfzeilen setzt. Die Kennwortablage ist technisch möglich und sollte die letzte Wahl bleiben.
|
WICHTIG · Der Anwendungsproxy ist nicht für den Innendienst gedacht Microsoft weist ausdrücklich darauf hin, dass der Anwendungsproxy Fernzugriff ersetzt und nicht für Nutzerinnen und Nutzer im internen Netz gedacht ist. Wenn interne Zugriffe unnötig über den Proxy laufen, bekommen Sie Leistungsprobleme, die schwer zuzuordnen sind. Für die Verwaltung heißt das konkret: Ein Bauhof-Portal, das ausschließlich vom Bauhof-WLAN aus benutzt wird, gehört nicht hinter den Anwendungsproxy. Ein Zeiterfassungsportal, das aus dem Homeoffice erreichbar sein muss, sehr wohl. Die Zuordnung machen Sie im Rahmen der Inventur, nicht im laufenden Betrieb. |
|---|

Skizze 2: Der Entscheidungsbaum, den wir im Workshop für jedes einzelne Verfahren durchlaufen haben. Vier Fragen, fünf mögliche Ausgänge – und ein Ausgang, der ehrlicherweise „Gespräch mit dem Hersteller" heißt.
Die folgende Tabelle fasst zusammen, was wir im Workshop an die Wand geschrieben haben. Die Aufwandsangaben sind Erfahrungswerte je Anwendung, ohne Test durch das Fachamt und ohne Abstimmungsrunden – rechnen Sie diese großzügig obendrauf.
|
Anwendungstyp |
Weg nach Entra ID |
Aufwand je Verfahren |
|---|---|---|
|
SAML 2.0, Standardansprüche |
Unternehmensanwendung aus dem Katalog oder ohne Vorlage; Assistent übernimmt Bezeichner, Antwort-URL, Gruppen und übersetzbare Ansprüche |
Gering: wenige Stunden Konfiguration, ein Testtermin |
|
SAML 2.0, komplexe Anspruchsregeln |
Wie oben, aber Anspruchszuordnungen von Hand; reguläre Ausdrücke werden durch Funktionen wie Extract, Trim, IfEmpty oder Contains ersetzt |
Mittel: ein bis drei Tage, abhängig von der Regeltiefe |
|
WS-Federation mit SAML-1.1-Token |
Manuell über PowerShell oder generische Katalogvorlage für SharePoint und SAML 1.1; kein Assistent |
Mittel bis hoch: mehrere Tage, mindestens zwei Testrunden |
|
OpenID Connect / OAuth 2.0 |
Anwendungsregistrierung mit Umleitungsadresse, Geheimnis oder Zertifikat, Berechtigungszuweisung |
Gering, sofern der Hersteller Entra ID unterstützt |
|
Integrierte Windows-Authentifizierung |
Anwendungsproxy mit privatem Netzwerkkonnektor und eingeschränkter Kerberos-Delegierung |
Mittel: Konnektor, Dienstkonto, Delegierung, Test |
|
Kopfzeilenbasierte Anwendung |
Anwendungsproxy plus Partnerdienst für die Kopfzeilen |
Mittel bis hoch: zusätzliche Komponente, zusätzlicher Vertrag |
|
Formularanmeldung ohne Schnittstelle |
Anwendungsproxy mit Kennwortablage – funktioniert, ist aber die schwächste Variante |
Gering im Aufwand, hoch in der Folgediskussion |
|
Anspruchsanbieter-Vertrauensstellung zu Dritten |
Ersetzt durch Gastzugang über Entra Business-to-Business |
Mittel: Prozess für Einladung und Entzug ist der eigentliche Aufwand |
|
WS-Trust im ActAs-Muster |
Nicht migrierbar. Umbau, Ablösung oder befristete Restföderation |
Nicht kalkulierbar ohne Hersteller |
|
SAML-Artefaktauflösung |
Nicht migrierbar. Gleiche Optionen wie oben |
Nicht kalkulierbar ohne Hersteller |
Die vorletzte Zeile verdient einen eigenen Hinweis. Anspruchsanbieter-Vertrauensstellungen zu Planungsbüros, freien Trägern oder Nachbarkommunen sind in der Verwaltung häufiger, als man denkt. Sie werden nicht migriert, sondern durch den Gastzugang ersetzt – ein Wechsel, der technisch klein und organisatorisch groß ist. Wie man das in Teams und SharePoint sauber aufsetzt, steht in Gäste in Teams und SharePoint: Planungsbüros, Träger und Gremienmitglieder sicher einbinden.
Die Koexistenzphase: der Teil, den alle unterschätzen
Wenn im Projektplan steht „Migration ADFS nach Entra ID: 6 Monate", dann steht dort in Wirklichkeit „6 Monate Doppelbetrieb". Das ist die teuerste und die störungsanfälligste Phase, und sie verdient mehr Aufmerksamkeit als die Frage, ob Anspruch X in Entra ID heißt wie in ADFS.
Gestaffelte Einführung ist ein Testinstrument, kein Zielzustand
Microsoft stellt für die Umstellung der Anmeldung an Microsoft 365 die gestaffelte Einführung bereit. Damit lässt sich eine Gruppe von Konten auf die verwaltete Anmeldung umstellen, während die Domäne insgesamt föderiert bleibt. Das ist ideal für einen Pilotbetrieb im Hauptamt, bevor die Ordnungsverwaltung folgt.
Es ist aber ausdrücklich nicht als Dauerzustand vorgesehen. Microsoft formuliert das ungewöhnlich deutlich: Ein permanenter Mischzustand wird nicht empfohlen, weil er zu unerwarteten Anmeldeabläufen führt. Wer die gestaffelte Einführung nach der Migration beibehält und den Föderationsanbieter abschaltet, bekommt Anmeldefehler, die niemand mehr zuordnen kann.
Dazu kommen Grenzen, die man vorher kennen sollte. Pro Funktion – also je für Kennworthashsynchronisierung, Passthrough-Authentifizierung und nahtloses einmaliges Anmelden – sind maximal zehn Gruppen möglich. Verschachtelte Gruppen und dynamische Gruppen funktionieren nicht. Beim erstmaligen Hinzufügen einer Gruppe sind Sie auf 200 Mitglieder begrenzt, danach können Sie weitere Konten direkt in die Gruppe aufnehmen. Änderungen an einer bestehenden Gruppe können bis zu 24 Stunden brauchen, bis sie wirken – eine Zahl, die man dem Servicedesk vorher sagt.
|
TIPP · Der Trick mit dem befristeten Zugriffspass Wer neu in eine Gruppe der gestaffelten Einführung aufgenommen wird, muss sich in der Regel noch einmal über den Föderationsweg anmelden, bevor die verwaltete Anmeldung greift. Das ist unschön, weil die Leute genau in dem Moment die alte Anmeldemaske sehen, in dem sie die neue erwarten. Microsoft evaluiert einen befristeten Zugriffspass, bevor umgeleitet wird. Sie können also die Person in die Gruppe aufnehmen, einen Pass ausstellen und die erste Anmeldung damit durchführen lassen. Danach ist die Person im verwalteten Modus und kann direkt weitere Anmeldemethoden registrieren. Für eine Pilotgruppe im Rathaus ist das ein sauberer Ablauf, den man dem Servicedesk auf eine halbe Seite schreiben kann. |
|---|
Was die gestaffelte Einführung nicht abdeckt
Die Ausnahmeliste ist überschaubar, trifft aber in der Verwaltung häufiger als anderswo. Ältere Anmeldeverfahren wie POP3 und SMTP werden nicht unterstützt. Anwendungen, die einen Domänenhinweis mitschicken, bleiben beim Föderationsweg. Kennwortrücksetzung mit Rückschreiben in das lokale Verzeichnis ist im Zusammenspiel nicht garantiert. Und – das ist der praktisch relevante Fall – bei nicht persistenten virtuellen Arbeitsplätzen ab Windows 10 Version 1903 ist der Wechsel auf eine verwaltete Domäne nicht unterstützt; hier bleibt es beim Föderationsweg.
Ebenfalls nicht unterstützt: Windows Hello for Business im hybriden Zertifikatsvertrauen, wenn der Föderationsserver als Registrierungsstelle arbeitet, sowie Chipkartenanmeldungen über den Föderationsdienst. Wenn Ihr Haus Chipkarten im Einsatz hat – und in Bereichen mit erhöhtem Schutzbedarf ist das nicht selten –, dann ist das kein Nebensatz, sondern ein eigenes Teilprojekt.
Ob und in welchem Umfang Ihr Haus überhaupt hybrid bleiben muss oder auf einen Standard-Mandanten zugehen kann, ist die vorgelagerte Entscheidung. Der Beitrag Standard-Tenant oder Hybrid: Die Betriebsmodell-Entscheidung für Verwaltungen nimmt sie auseinander. Wer sie noch nicht getroffen hat, sollte die ADFS-Entscheidung nicht vorziehen: Sie hängt daran.
Der Domänen-Cutover und das Wartungsfenster
Am Ende der Koexistenz steht die Umstellung der Domäne von föderiert auf verwaltet. Diese Umstellung ist keine Sache von Minuten. Microsoft nennt bis zu vier Stunden, bis der Wechsel vollständig durchgeschlagen ist, und empfiehlt, das Wartungsfenster entsprechend zu planen. Für eine Verwaltung mit Publikumsverkehr heißt das: Freitag nach Dienstschluss, nicht Dienstagvormittag.
Ein Punkt, der in der Beschlussvorlage gerne fehlt: Die Migration einer Anwendung ist nicht abgeschlossen, wenn sie in Entra ID konfiguriert ist. Sie ist abgeschlossen, wenn die Anwendung selbst auf den neuen Aussteller umgestellt wurde. Solange die neu angelegte Unternehmensanwendung existiert, aber niemand den Anmeldeverkehr dorthin lenkt, ist sie inaktiv. Das ist übrigens auch die Rücknahmemöglichkeit: Solange nicht umgelenkt wurde, genügt es, die neu angelegte Anwendung wieder zu löschen. Eine automatische Aufräumfunktion gibt es nicht.

Skizze 3: Die Koexistenzphase im Überblick. Der rote Balken ist der teure Teil – solange er läuft, zahlen Sie zweimal Betrieb und einmal Projekt.
|
FAKTEN · Was in der Koexistenz parallel läuft Weiter im Betrieb: ADFS-Farm mit Patchtag, Zertifikatswechsel, Lastverteiler und Rückfallweg. Der Föderationsanbieter muss verfügbar bleiben, solange die gestaffelte Einführung läuft – er ist der Rückfallweg. Neu im Betrieb: Entra ID mit Unternehmensanwendungen, Anspruchszuordnungen, Regelwerk für Bedingten Zugriff und Anmeldeprotokoll. Ab der ersten Pilotgruppe produktiv. Neu im Projekt: Kommunikation an die Fachämter, Testtermine, Schulung des Servicedesks, Dokumentation für die Rechnungsprüfung. Drei Linien gleichzeitig, und die mittlere wird gerne vergessen, weil sie im Projektplan nicht als Meilenstein auftaucht. |
|---|
Das Lizenzargument: P1 ist das Mindestmaß
Kommen wir zu dem Teil, der in der Kämmerei landet. Eine ADFS-Migration ohne Entra ID P1 ist nicht sinnvoll planbar. Das ist keine Verkaufsargumentation, sondern eine Aufzählung von Funktionen, die schlicht an dieser Lizenzstufe hängen.
|
Was Sie brauchen |
Erforderliche Lizenz |
Wenn Sie es nicht haben |
|---|---|---|
|
ADFS-Anwendungsmigration im Admin Center |
Entra ID P1 oder P2 |
Inventur nur manuell aus der Farm; keine Bewertung der Anspruchsregeln |
|
Connect Health für ADFS |
Entra ID P1 oder P2 |
Keine Anmeldedaten je vertrauender Seite; Nutzungsbewertung entfällt |
|
Bedingter Zugriff |
Entra ID P1 oder P2 |
Die Autorisierungsregeln aus ADFS lassen sich nicht ersetzen – der eigentliche Blocker |
|
Anwendungsproxy |
Entra ID P1 oder P2 |
Kein Weg für Kerberos-, Kopfzeilen- und Formularanwendungen |
|
Verschlüsselung des SAML-Tokens |
Entra ID P1 oder P2 |
Verfahren, die verschlüsselte Aussagen erwarten, bleiben auf der Farm |
|
Identitätsschutz mit Risikobewertung |
Entra ID P2 |
Risikobasierte Regeln nicht möglich; für Administratorkonten spürbar |
|
Privilegierte Identitätsverwaltung |
Entra ID P2 |
Dauerhaft zugewiesene Administratorrollen statt zeitlich befristeter Aktivierung |
Die entscheidende Zeile ist die dritte. Die Autorisierungsregeln, die heute in ADFS auf den vertrauenden Seiten hängen – „nur aus dem internen Netz", „nur mit zweitem Faktor", „nur für Mitglieder dieser Gruppe" –, werden in Entra ID durch den Bedingten Zugriff abgebildet. Ohne P1 gibt es keinen Bedingten Zugriff. Ohne Bedingten Zugriff verlieren Sie bei der Migration Sicherheitsfunktionen, die Sie heute schon haben. Das ist die Variante, die Ihnen die Rechnungsprüfung mit Recht um die Ohren haut.

Skizze 4: Die drei Lizenzstufen und was tatsächlich an ihnen hängt. Die mittlere Spalte ist der Mindestumfang für eine ADFS-Ablösung.
Die gute Nachricht für Häuser, die ohnehin Microsoft 365 einführen: Entra ID P1 ist in Microsoft 365 E3 enthalten, P2 in Microsoft 365 E5. Wer also E3 beschafft hat, hat das Mindestmaß bereits. Wer reine Office-Pläne beschafft hat, hat es nicht. Die Unterschiede zwischen den Plänen und die Konditionen für Behörden sind in Microsoft 365 Lizenzen für Verwaltungen: E3, E5, F3 und die Behördenkonditionen ausführlich dargestellt.
|
WICHTIG · Wie die Rechnung in der Beschlussvorlage aussehen sollte Stellen Sie die Lizenzkosten nicht gegen null, sondern gegen den tatsächlichen Betriebsaufwand der Farm. Auf der Gegenseite stehen: Serverlizenzen und Hardware beziehungsweise Virtualisierungsanteil für vier Knoten, Zertifikatskosten, Lastverteileranteil, Patchaufwand, Farm-Upgrade im Turnus, Kapazitätsplanung und der Aufwand für den Zertifikatswechsel an jeder vertrauenden Seite. Und ein Posten, der sich schwer beziffern lässt und trotzdem hineingehört: das Personalrisiko. Eine Kompetenz, die auf einer Person ruht, ist kein Betriebsmodell. Formulierungshinweis: Wertgrenzen, Vergabearten und Fristen richten sich nach dem jeweiligen Landesrecht und den Vorgaben Ihres Hauses. Die Zahlen gehören mit der Vergabestelle abgestimmt, nicht aus einem Fachartikel abgeschrieben. |
|---|
Was die Entscheidung in der Verwaltung wirklich blockiert
Bis hierhin war alles technisch. In der Praxis scheitert die Entscheidung selten an der Technik. Sie scheitert daran, dass sechs Stellen im Haus mitreden und keine davon Anspruchsregeln liest.

Skizze 5: Die Beteiligten und ihre jeweilige Frage. Wer diese sechs Fragen vorbereitet beantwortet, hat die Beschlussvorlage im Wesentlichen fertig.
Die Fragen, die tatsächlich gestellt werden
|
Wer fragt |
Was gefragt wird |
Was in der Antwort stehen sollte |
|---|---|---|
|
Verwaltungsspitze |
Müssen wir das jetzt machen? |
Nein, es gibt keine Frist. Ja, es gibt ein Personalrisiko mit Datum und einen Innovationsstillstand mit Folgen für künftige Verfahren. |
|
Kämmerei |
Was kostet es und wo steht es im Haushalt? |
Lizenzanteil, Projektaufwand, Doppelbetrieb während der Koexistenz, wegfallender Betriebsaufwand nach dem Rückbau. |
|
Vergabestelle |
Brauchen wir ein Verfahren? |
Kommt darauf an, was beschafft wird und was über bestehende Rahmenverträge abrufbar ist. Frühzeitig klären, nicht am Ende. |
|
Datenschutzbeauftragte |
Welche Protokolldaten entstehen wo? |
Anmeldeprotokoll und Überwachungsprotokoll in Entra ID, Aufbewahrungsdauer je Lizenzstufe, Eintrag im Verarbeitungsverzeichnis. |
|
Personalrat |
Wird damit Verhalten überwacht? |
Das Anmeldeprotokoll erfasst Zeit, Ort, Gerät und Ergebnis. Das ist mitbestimmungsrelevant und gehört sauber geregelt. |
|
Rechnungsprüfungsamt |
Wie weisen Sie nach, dass es funktioniert? |
Inventurstand, Testprotokolle, Abnahmen je Fachverfahren, Nachweis über den Rückbau und die Löschung der vertrauenden Seiten. |
|
Fachämter |
Was ändert sich für uns? |
Anmeldemaske, gegebenenfalls zweiter Faktor, ein Testtermin. Sonst nichts – wenn es gut läuft. |
Der Personalrat gehört an den Tisch, nicht ans Ende
Der Bedingte Zugriff ist der Punkt, an dem die technische Migration auf die Mitbestimmung trifft. Eine Regel wie „Anmeldung von außerhalb Deutschlands nur mit zweitem Faktor" ist technisch trivial und personalvertretungsrechtlich nicht trivial, weil sie voraussetzt, dass Standortinformationen ausgewertet werden. Dasselbe gilt für Gerätekonformität und für risikobasierte Regeln.
Die praktikable Reihenfolge ist: erst das Regelwerk fachlich entwerfen, dann mit dem Personalrat besprechen, dann technisch umsetzen. Nicht umgekehrt. Ein Regelwerk, das bereits produktiv ist und nachträglich verhandelt wird, erzeugt Misstrauen, das man über Jahre nicht mehr los wird.
Zum Aufbau eines solchen Regelwerks für Rathaus, Bauhof und Homeoffice gibt es einen eigenen Beitrag: Conditional Access für Verwaltungen: Regelwerk für Rathaus, Bauhof und Homeoffice. Und für die Frage, welche Nachweise Sie der Rechnungsprüfung tatsächlich vorlegen können und müssen, lohnt Microsoft 365 Audit-Log und Rechnungsprüfung: Nachweise, die Verwaltungen liefern müssen.
Die Rolle des kommunalen Rechenzentrums
In vielen Häusern betreibt nicht die eigene IT die Farm, sondern das kommunale Rechenzentrum oder ein Systemhaus. Das ist eine sinnvolle Arbeitsteilung und ändert an der Entscheidung nichts – wohl aber an ihrer Vorbereitung. Die Frage lautet dann nicht „migrieren wir?", sondern „wer macht was, ab wann, und wie sieht die Schnittstelle danach aus?".
Ein häufiges Missverständnis: Die Ablösung der Farm bedeutet nicht, dass der Dienstleister überflüssig wird. Sie verschiebt seine Leistung von der Serverpflege in die Mandantenverwaltung. Wer das früh sagt, führt ein sachliches Gespräch. Wer es nicht sagt, führt ein anderes.
Die Rollenverteilung zwischen Haus und Rechenzentrum, inklusive der Frage, wann eine Zweitmeinung angemessen ist, behandelt Microsoft 365 und das kommunale Rechenzentrum: Rollen, Schnittstellen, Zweitmeinung.
Und was ist mit der Delos Cloud?
Die Frage kommt in jedem Workshop, meist gegen Nachmittag. Die Delos Cloud ist ein Angebot für die öffentliche Verwaltung, das Microsoft-Technologie in einer souveränen Betriebsumgebung bereitstellen soll. Für die Identitätsfrage ist der nüchterne Stand: Sie ist keine Begründung, eine ADFS-Farm ohne Nachfolgeplanung weiterzubetreiben, und sie ist auch keine Begründung, eine Migration zu überstürzen.
Was Sie in beiden Fällen brauchen, ist dasselbe: eine belastbare Inventur der Fachverfahren, ein dokumentiertes Regelwerk für den Zugriff und ein Anwendungsverzeichnis, das nicht auf einer Person ruht. Diese Vorarbeit ist plattformunabhängig wertvoll. Terminversprechen sollten Sie hingegen von niemandem annehmen, auch nicht von uns.
Eine sachliche Einordnung des Angebots – was es ist, wen es betrifft, was fehlt – finden Sie in Delos Cloud für Kommunen: Was das Angebot ist, wen es betrifft und was fehlt.
Drei Beispiele aus der Praxis
Der große Landschaftsverband
Das Haus aus der Einleitung. Ergebnis des Workshops war keine Entscheidung, sondern ein Beschlusspaket in drei Stufen. Stufe eins: Inventur mit Connect Health und Abgleich gegen den Farmexport, Abschaltung der Karteileichen, Dokumentation des Zertifikatskalenders. Aufwand überschaubar, Nutzen sofort, kein Beschluss der Verwaltungsspitze nötig. Stufe zwei: Migration der elf einfachen SAML-Verfahren innerhalb eines Haushaltsjahres. Stufe drei: die Sonderfälle, mit Herstellergesprächen und offenem Ausgang.
Der entscheidende Kniff war die Aufteilung. Eine Beschlussvorlage über „ADFS-Ablösung" wäre in der Diskussion versandet. Drei Vorlagen mit klar abgegrenztem Nutzen sind beschlussfähig.
Die Stadtverwaltung mit rund 1.000 Rufnummern
Hier lief die Identitätsfrage im Windschatten eines Telefonieprojekts mit. Das war zunächst ein Zufall und wurde dann ein Vorteil: Die Telefonie zwang ohnehin dazu, jedes Konto und jede Zuordnung sauber zu erfassen. Die Inventur der vertrauenden Seiten fiel dabei als Nebenprodukt an.
Die Lehre daraus ist unspektakulär: Identitätsprojekte haben in der Verwaltung selten eine eigene politische Zugkraft. Sie brauchen ein Trägerprojekt. Telefonie, Homeoffice-Ausstattung oder eine anstehende Prüfung eignen sich gut. Eine Migration, die nur mit „das ist technisch veraltet" begründet wird, bekommt kein Geld.
Die Stadtverwaltung mit SharePoint im Sozialbereich
Der unangenehmste der drei Fälle. Zwei SharePoint-Anwendungen mit WS-Federation und SAML-1.1-Token, eine davon mit Berechtigungsstrukturen, die über Jahre gewachsen sind. Die technische Migration war beschreibbar. Die eigentliche Arbeit lag woanders: In dem Moment, in dem jemand die Berechtigungen im Detail ansieht, findet er Dinge, die er nicht ignorieren kann.
Das ist ein bekanntes Muster. Eine Föderationsmigration ist ein Anlass, bei dem Berechtigungsfragen sichtbar werden, die vorher niemand gestellt hat. Planen Sie das ein – als Chance und als Aufwand. Und trennen Sie es sauber von der Anmeldefrage, sonst wird aus einem sechsmonatigen Projekt ein zweijähriges.
|
TIPP · Zwei Dinge, die den Unterschied machen Erstens: Der Servicedesk muss vor der ersten Pilotgruppe wissen, was sich ändert. Eine veränderte Anmeldemaske erzeugt Anrufe. Eine veränderte Anmeldemaske plus ein informierter Servicedesk erzeugt kurze Anrufe. Zweitens: Die Fachämter brauchen einen Testtermin mit ihrem eigenen Verfahren und ihrem eigenen Konto. Nicht eine Vorführung, sondern einen Termin, an dem sie selbst arbeiten. Was dabei auffällt, fällt sonst am Umstellungswochenende auf. |
|---|
Für die Vorbereitung der Belegschaft und des Servicedesks gibt es strukturierte Angebote; wenn Sie das nicht selbst aufbauen wollen, finden Sie unter Microsoft 365 Schulung für Verwaltungen einen Überblick. Und wenn die Entscheidung selbst begleitet werden soll – von der Inventur über den Migrationspfad bis zur Beschlussvorlage –, beschreibt Microsoft 365 Beratung für Verwaltungen, wie das typischerweise abläuft.
Häufige Fragen
Wird ADFS abgeschaltet? Wir haben gehört, der Support endet bald.
Nein. Die Rolle ist in Windows Server 2025 enthalten und wird unterstützt. Sie steht in keiner Liste entfernter oder veralteter Funktionen, und ein Enddatum für den Support ist nicht veröffentlicht. Was stimmt: Microsoft empfiehlt bei einem anstehenden Upgrade, stattdessen die Migration nach Entra ID zu prüfen, und neue Funktionen entstehen praktisch ausschließlich auf der Cloud-Plattform. Der Druck ist real, aber er kommt nicht aus dem Supportkalender.
Können wir ADFS und die Anmeldung über Entra ID parallel betreiben?
Ja, das ist sogar der übliche Weg. Über die gestaffelte Einführung stellen Sie eine Gruppe von Konten auf die verwaltete Anmeldung um, während die Domäne föderiert bleibt. Der Föderationsdienst muss dabei verfügbar bleiben, weil er der Rückfallweg ist. Gedacht ist das als Testphase, nicht als Dauerlösung – ein permanenter Mischzustand wird ausdrücklich nicht empfohlen.
Wie lange dauert die Umstellung der Domäne von föderiert auf verwaltet?
Microsoft nennt bis zu vier Stunden, bis der Wechsel vollständig wirksam ist. Planen Sie das Wartungsfenster entsprechend, und legen Sie es nicht auf einen Tag mit Publikumsverkehr. Laufende Sitzungen sind übrigens nicht betroffen; sie bleiben gültig, und erst die nächste Anmeldung läuft über den neuen Weg.
Unser Fachverfahren spricht nur WS-Federation. Ist es damit verloren?
Nein, aber es wird Handarbeit. Der Migrationsassistent unterstützt ausschließlich SAML-Konfigurationen. Entra ID stellt aber einen eigenen Endpunkt für WS-Federation bereit, und Anwendungen, die ein SAML-1.1-Token erwarten, lassen sich manuell über PowerShell konfigurieren oder über eine generische Katalogvorlage anlegen. Rechnen Sie mit mehr Zeit und mindestens zwei Testrunden.
Was passiert mit unseren Anspruchsregeln?
Einfache Regeln werden übersetzt. Regeln mit regulären Ausdrücken werden markiert und müssen über die vorhandenen Funktionen nachgebaut werden – Extract, Trim, ToLower, IfEmpty, StartWith, Contains decken die meisten Fälle ab. Regeln, die Ansprüche aus einem Attributspeicher außerhalb von Active Directory beziehen, sind ein echter Blocker: Entra ID bezieht Ansprüche derzeit nur aus Active Directory oder aus dem Verzeichnis selbst. Und geschützte Ansprüche können Sie zwar ausstellen, aber weder in ihrer Quelle ändern noch transformieren.
Reicht unsere vorhandene Lizenz?
Wenn Sie Microsoft 365 E3 haben, haben Sie Entra ID P1 und damit das Mindestmaß: Migrationsassistent, Connect Health für ADFS, Bedingten Zugriff, Anwendungsproxy und Tokenverschlüsselung. Mit E5 kommen Identitätsschutz und die privilegierte Identitätsverwaltung dazu. Mit reinen Office-Plänen oder der kostenfreien Stufe fehlen Ihnen die Werkzeuge, mit denen die Migration überhaupt planbar wird – vor allem der Bedingte Zugriff, ohne den Sie bestehende Autorisierungsregeln nicht ersetzen können.
Warum zeigt uns das Dashboard nicht alle unsere Anwendungen?
Dafür gibt es zwei erwartbare Gründe. Erstens werden nur vertrauende Seiten angezeigt, an denen in den letzten dreißig Tagen Anmeldungen stattgefunden haben. Zweitens werden Microsoft-eigene Einträge – etwa der für die Anmeldung an Microsoft 365 oder die Zertifikatsbereitstellung – grundsätzlich nicht angezeigt. Ein Verfahren, das nur zum Jahresabschluss genutzt wird, taucht deshalb nicht auf. Gleichen Sie immer gegen einen direkten Export aus der Farm ab.
Wir haben eine Vertrauensstellung zu einem externen Partner. Was wird daraus?
Aus einer Anspruchsanbieter-Vertrauensstellung wird der Gastzugang über Entra Business-to-Business. Technisch ist das ein überschaubarer Wechsel. Organisatorisch ist es der Punkt, an dem Sie einen Prozess brauchen: Wer lädt ein, wer genehmigt, wie lange gilt der Zugang, wer entzieht ihn wieder. Genau dieser Prozess fehlt in den meisten Häusern – bei der bestehenden Vertrauensstellung übrigens auch, er fällt nur nicht auf.
Was ist mit unseren Chipkarten?
Das ist der Fall, bei dem Sie nicht improvisieren sollten. Chipkartenanmeldung über den Föderationsdienst und Windows Hello for Business im hybriden Zertifikatsvertrauen mit dem Föderationsserver als Registrierungsstelle sind in der gestaffelten Einführung nicht unterstützt. Wenn Ihr Haus damit arbeitet – etwa in Bereichen mit erhöhtem Schutzbedarf –, behandeln Sie das als eigenes Teilprojekt mit eigener Planung und eigenem Zeitrahmen.
Müssen wir wirklich alles migrieren?
Nein. Eine befristete Restföderation für ein oder zwei Verfahren, die technisch nicht umziehen können, ist eine vertretbare Entscheidung. Die Bedingungen: Sie ist dokumentiert, sie hat einen Termin, sie hat eine benannte verantwortliche Stelle, und sie steht in der Notfallplanung. Was nicht vertretbar ist, ist eine Restföderation, die aus Erschöpfung entsteht und dann fünf Jahre läuft, weil das Projekt formal beendet ist.
Fazit
Die Frage „ADFS oder Entra ID" lässt sich nicht als Grundsatzentscheidung beantworten, und der Versuch, es doch zu tun, ist der häufigste Grund, warum solche Projekte in der Verwaltung nicht vorankommen. Beantwortbar wird sie erst entlang der Fachverfahren.
Die nüchterne Lage: ADFS ist nicht abgekündigt und läuft weiter. Es entwickelt sich aber nicht mehr, es bindet Betriebsaufwand, und es hängt in den meisten Häusern an einer einzigen Person. Entra ID ist das erklärte Ziel der Plattform, es bringt mit dem Bedingten Zugriff eine Fähigkeit mit, die die alten Autorisierungsregeln ablöst, und es setzt ab Entra ID P1 an – das ist kein Verhandlungsspielraum, sondern eine Funktionsgrenze.
Der Weg dorthin führt über eine Inventur, die mehr wert ist als das Migrationsergebnis, über einen Migrationspfad je Anwendungstyp und über eine Koexistenzphase, die man befristen muss, weil sie sonst zum Zustand wird. Zwei Muster – WS-Trust im ActAs-Muster und die SAML-Artefaktauflösung – gehen heute nicht, und das gehört ehrlich in die Vorlage geschrieben, nicht in eine Fußnote.
Und der wichtigste Satz zum Schluss, weil er die häufigste Enttäuschung verhindert: Der Betrieb wandert, er verschwindet nicht. Sie tauschen eine Farm mit Zertifikatskalender gegen einen Mandanten mit Regelwerk. Das ist ein guter Tausch, aber es ist ein Tausch. Wer ihn als Einsparung verkauft, steht in zwei Jahren vor demselben Personalrat und erklärt, warum die Stelle trotzdem gebraucht wird.
Fangen Sie mit der Liste an. Alles Weitere ergibt sich daraus – und die Liste brauchen Sie ohnehin, ganz gleich, wie die Entscheidung ausfällt.
Dieses Consulting-Dokument steht als PDF zum Download bereit: https://www.boddenberg.de/ArtikelPdf/unsere-adfs-farm.pdf — © Ulrich B. Boddenberg · boddenberg.de






