ADFS-Beratung: Methodik, Phasenmodell und Beratungsformate

Beratung ist nicht das, was im PDF steht. Beratung ist das, was nach der Übergabe noch funktioniert. Diese Seite zeigt im Detail, wie eine ADFS-Beratung bei mir abläuft, welche Phasen sie hat, welche Formate du buchen kannst — und welche vier Prinzipien dahinterstehen, die das Ganze von einem Standard-Folien-Geschäft unterscheiden.

Methodik: Vier Prinzipien, die den Unterschied machen

Es gibt eine ganze Reihe von Beratungshäusern, die ADFS-Beratung anbieten. Das ist auch in Ordnung. Was diese Beratung hier auszeichnet, sind vier Prinzipien — keine Marketing-Versprechen, sondern Arbeitsweisen, die sich in über 20 Jahren Praxis herausgeschält haben.

Hands-on statt PowerPoint

Befunde werden live in der Farm erhoben, nicht aus Excel-Templates abgeschrieben. Wenn du sehen willst, wie deine ADFS-Konfiguration wirklich aussieht, dann müssen die Konfig-Exporte, die Eventlogs und die Federation-Metadata her — nicht ein Fragebogen, den du selbst ausfüllst. Das macht die Beratung intensiver, dafür aber auch ehrlicher. Was im Befundbericht steht, hat jemand mit eigenen Augen gesehen.

Eigene Werkzeuge statt Standardprodukte

Wo Microsoft-Bordmittel und PowerShell-Skripte nicht reichen, kommt hauseigene Software zum Einsatz. Allen voran der ADFS-Diagnostiker — ein Werkzeug, das die ADFS-Konfiguration strukturiert ausliest, gegen Best Practices vergleicht, Drift gegenüber dokumentierten Soll-Zuständen erkennt und Migrations-Reports erzeugt. Das ist weder ein Microsoft-Produkt noch eine offene Lösung aus dem Internet, sondern ein Werkzeug, das speziell für diese Beratungstiefe entstanden ist.

Der Viersprung als Wirkungsmodell

Beratung allein ist Stückwerk. Was bringt dir der beste Befundbericht, wenn dein Team danach nicht weiterarbeiten kann? Deshalb steht hinter jeder Beratung der Viersprung: Beratung, Buch, Software, Training. Du bekommst nicht nur einen Bericht, sondern auch den Rahmen, um das Wissen zu konservieren, zu wiederholen und im Team weiterzugeben. Mehr dazu weiter unten — und in der Skizze, die das Modell zeigt.

Direkte Sprache statt Beratungsdeutsch

Kritische Befunde heißen kritisch. Wenn deine Token-Signing-Schlüssel ungeschützt im Server-Filesystem liegen, dann steht das genau so im Bericht — nicht als „Optimierungspotenzial im Bereich der kryptographischen Schlüsselverwaltung“. Auch unbequeme Wahrheiten gehören zum Job. Wer sie weglässt, betreibt keine Beratung, sondern Gefälligkeitskommunikation.

 

Praxis-Tipp: So merkst du, ob eine Beratung etwas taugt Frag den Berater am ersten Tag nach den drei häufigsten Fehlern, die er bei ADFS-Migrationen schon gesehen hat. Wenn die Antwort konkret und mit Beispielen kommt, sitzt jemand vor dir, der das Thema aus der Praxis kennt. Wenn die Antwort vage bleibt oder mit „Jedes Projekt ist anders“ abgewunken wird, ist Vorsicht angebracht. Praxis-Beratung hat Anekdoten. Folien-Beratung hat sie nicht.

Das Phasenmodell im Detail

Eine vollständige ADFS-Beratung — vom ersten Befund bis zum stabilen Endzustand — folgt einem Fünf-Phasen-Modell. Jede Phase hat ein klar definiertes Ergebnis, einen typischen Zeitrahmen und konkrete Beteiligte auf deiner Seite. Das gute daran: niemand muss alle fünf Phasen durchlaufen. Du steigst ein, wo du stehst, und steigst aus, wenn dein Team eigenständig weiterläuft.

Abb.: Das Fünf-Phasen-Modell für ADFS-Beratung. Von der Standortbestimmung bis zum laufenden Sparring — mit klaren Ergebnissen pro Phase.

Phase 1 — Standortbestimmung

Alles beginnt mit einer ehrlichen Bestandsaufnahme. Was läuft in deiner Umgebung tatsächlich? Wie viele Relying Parties hängen am ADFS, wie viele davon werden noch genutzt, wie viele sind seit Jahren tot und niemand hat sie je gelöscht? Welche Claim Rules sind im Einsatz, welche Zertifikate stehen zur Rotation, wie sieht die Sicherheits-Baseline aus?

Diese Phase dauert zwei bis fünf Tage, je nach Größe der Umgebung. Am Ende steht ein Befundbericht im 9-Kapitel-Format mit priorisiertem Aktions-Backlog. Mit diesem Dokument allein kannst du schon entscheiden, ob du weitermachen willst, was zuerst dran ist und was noch warten kann.

Phase 2 — Architektur und Migrationsplan

Wenn die Standortbestimmung Handlungsbedarf zeigt, geht es in die Plan-Phase. Hier wird die Soll-Architektur erarbeitet — sei es eine gehärtete ADFS-Farm, ein Migrationspfad zu Entra ID oder eine Mischform mit gestaffelter Ablösung. Hochverfügbarkeits-Konzept, WAP-Topologie, Zertifikats-Strategie, Conditional-Access-Mapping als Ablöse für Claim Rules, Wellenplanung der Relying-Party-Migration.

Diese Phase dauert ein bis drei Wochen, beteiligt typischerweise Architektur-Team, Security und App-Owner. Am Ende steht ein Architekturdokument mit konkretem Migrationsplan und Wellenreihenfolge.

Phase 3 — Pilot mit Härtung

Bevor produktiv migriert wird, kommt der Pilot. Eine kleine, kontrollierte Umgebung mit Tier-0-Härtung, HSM-Anbindung wo nötig, Audit-Logging ins SIEM, neuem Zertifikats-Konzept und Pilot-Migration einer ersten Relying Party. Hier wird ausprobiert, was später im Großen läuft. Hier wird auch der Rollback geprobt.

Diese Phase dauert zwei bis sechs Wochen. Am Ende steht eine produktionsreife Konfiguration plus Lessons-Learned plus ein Runbook für die Rollout-Phase.

Phase 4 — Rollout in Wellen

Jetzt geht es um die Breite. Relying Party für Relying Party wird umgezogen, immer mit Test-Cutover und Erfolgskontrolle. Conditional Access übernimmt die Logik, die früher in den Claim Rules saß. Microsoft 365 kommt zuletzt, weil es das größte Risiko bei einem Fehlschlag wäre. Nach der letzten Migration kommt eine stille Phase von vier bis sechs Wochen, in der niemand die ADFS-Farm anfasst. Wenn dann nichts mehr drauf zugreift, kann sie dekommissioniert werden.

Diese Phase dauert drei bis neun Monate, je nach Anzahl der Relying Parties und nach Komplexität. Am Ende ist die ADFS-Farm entweder Geschichte oder steht produktiv gehärtet im Betrieb.

Phase 5 — Sparring im Betrieb

Wenn die Migration durch ist oder die ADFS-Farm produktiv gehärtet weiterläuft, bleibt ein Bedarf an punktueller Begleitung. Das kann ein Quartals-Review sein, eine Cert-Rollover-Begleitung, eine Audit-Vorbereitung, ein Konfig-Drift-Check oder einfach ein Notfall-Kontakt für den Fall der Fälle. Diese Phase ist offen und bedarfsorientiert.

 

Info: Die Phasen sind ein Modell, kein Korsett In der Praxis verschmelzen Phasen, kommen kleine Schleifen vor, oder eine Phase wird übersprungen, weil der Vorbereitungsstand das hergibt. Das Modell ist eine Landkarte, nicht ein starrer Ablaufplan. Was wichtig ist: jeder Schritt hat ein klares Ergebnis, das auch ohne den Berater Bestand hat.

Welche Phase passt zu welcher Situation

In der Praxis kommen drei Konstellationen mit Abstand am häufigsten auf den Tisch. Jede hat einen typischen Einstiegspunkt im Phasenmodell — und die Beratungsbausteine richten sich danach.

Abb.: Die drei häufigsten Einstiegs-Konstellationen und ihre Zuordnung zum Phasenmodell. Wer den Einstieg verpasst, zahlt ihn doppelt im Akutfall.

Konstellation A: Geplante Migration zu Entra ID

Die Geschäftsführung will raus aus On-Prem, der CIO hat das im Strategiepapier stehen, das Identity-Team weiß aber, dass es deutlich komplizierter wird, als es klingt. Niemand traut sich an die ADFS-Farm — die Doku ist alt, die Relying Parties sind teilweise unbekannt, die Claim Rules sind in der Vergangenheit gewachsen. Hier ist das Vollprogramm angesagt: alle fünf Phasen über drei bis neun Monate. Mit klaren Meilensteinen, ohne Big-Bang-Risiko.

Konstellation B: Audit, Sicherheitsvorfall oder NIS2-Bewertung

Ein Audit-Befund liegt vor, oder es gab einen Sicherheitsvorfall, oder die NIS2-Bewertung steht ins Haus. Plötzlich wollen alle wissen, wie es um Token-Signing-Schutz, Tier-0-Trennung, Audit-Logging und Patch-Status steht. Hier reichen typischerweise Phase 1 (Befund) und Phase 3 (Härtung) — über vier bis zwölf Wochen, klar abgegrenzt. Wenn die Befunde anschließend eine Migration nahelegen, kann sich Phase 4 anschließen.

Konstellation C: Akutfall — es brennt

Tokens werden abgelehnt, der Token-Signing-Cert ist abgelaufen, der WAP-Trust ist gebrochen, oder die Federation mit einem wichtigen Partner steht still. Das ist Phase 3 in beschleunigter Form: zuerst Akut-Behebung, dann Dokumentation und Root-Cause. Anschließend ist eine kleine Standortbestimmung sinnvoll, um sicherzustellen, dass das nicht wieder passiert.

 

Warnung: Die Akut-Falle Akutfälle haben einen unangenehmen Nebeneffekt: Wenn das Feuer gelöscht ist, ist die Bereitschaft, in die Ursachen-Analyse und in präventive Maßnahmen zu investieren, oft schon wieder gesunken. „Läuft ja wieder“ ist die häufigste Ausrede, mit der dann der nächste Akutfall vorprogrammiert wird. Wer das vermeiden will, plant die Nachsorge gleich mit ein, wenn der erste Schmerz noch frisch ist.

Beratungsformate im Einzelnen

Aus den Phasen ergeben sich konkrete buchbare Bausteine. Hier eine Übersicht über die typischen Formate — Aufwand, Inhalt und Zielgruppe.

Quick-Health-Check

Aufwand: zwei Tage, davon ein Tag remote, ein Tag Bericht. Inhalt: Kurz-Inventar der Farm, oberflächliche Sicherheits-Bewertung, Top-5-Empfehlungen. Für wen: wer einen schnellen ersten Eindruck braucht, bevor größere Entscheidungen anstehen. Output: Kompaktbericht (10–15 Seiten), kein vollständiges 9-Kapitel-Format.

Vollständiges Health-Assessment

Aufwand: drei bis fünf Tage. Inhalt: Komplette Phase-1-Bestandsaufnahme mit Architektur, Konfiguration, Claim Rules, Zertifikatslandschaft, Relying-Party-Inventar, Sicherheits-Baseline, Drift-Erkennung. Für wen: wer fundiert entscheiden will, was zu tun ist. Output: Befundbericht im 9-Kapitel-Format mit priorisiertem Aktions-Backlog.

Sicherheits-Audit

Aufwand: drei bis fünf Tage. Inhalt: Tiefer Review nach Tier-0-Standard, Token-Signing-Schutz, HSM-Bewertung, Audit-Logging-Qualität, Privileged-Access-Konzept, Patching-Status, Golden-SAML-Exposition. Für wen: Audit-Vorbereitung, NIS2-Compliance, BSI-Grundschutz-Mapping. Output: Sicherheitsbericht mit Risikoklassen und Härtungsplan.

Migrations-Begleitung Entra ID

Aufwand: drei bis neun Monate, modular buchbar. Inhalt: Vom Relying-Party-Inventar bis zum letzten Cutover. Wellenplanung, Conditional-Access-Mapping, Pilot, Rollout, Dekommissionierung. Für wen: Organisationen, die ADFS planmäßig ablösen wollen. Output: Migrations-Plan, Begleitung pro Welle, finale Abschluss-Doku.

Architektur-Review

Aufwand: drei bis fünf Tage. Inhalt: Bewertung der bestehenden Architektur gegen aktuellen Stand der Technik. Sizing, Hochverfügbarkeit, WAP-Topologie, DR-Konzept, Backup-Strategie. Für wen: wer eine bestehende Farm modernisieren oder auf Wachstum vorbereiten will. Output: Architekturdokument mit Empfehlungen und Migrationspfad.

Notfall-Einsatz

Aufwand: Stunden bis wenige Tage. Inhalt: Akut-Behebung von Federation-Problemen, Token-Issues, Zertifikatsausfällen, WAP-Problemen. Remote oder vor Ort, kurzfristig. Für wen: wenn es brennt. Output: funktionierender Betrieb plus Kurzbericht zum Vorfall.

Trainings on the job

Aufwand: flexibel, typisch ein bis drei Tage. Inhalt: Workshops zu Claims Rules Language, Migration-Strategien, Sicherheit, Troubleshooting. Auch parallel zu laufender Beratung als Wissenstransfer ans interne Team. Für wen: Identity-Teams, die ADFS selbst betreiben oder ablösen wollen. Output: Befähigtes Team mit Beispielen, Skripten und Doku.

Das 9-Kapitel-Consulting-Format

Jeder Befundbericht — egal ob Health-Check, Audit oder Migrationsbericht — folgt derselben Struktur. Der Vorteil: Leser, die schon einmal ein Boddenberg-Dokument in der Hand hatten, finden sich sofort zurecht. Und Berichte sind innerhalb der eigenen Organisation vergleichbar.

Abb.: Das 9-Kapitel-Consulting-Format. Die orange markierten Kapitel 4, 5 und 6 sind das Herzstück — Hintergrund (Warum), Befunde (Was) und Aktionsplan (Wie).

Drei Kapitel sind besonders wichtig: Kapitel 4 (Technischer Hintergrund) beantwortet die Frage „Warum sieht das so aus, wie es aussieht?“ — mit echten SVG-Diagrammen, nicht mit ASCII-Skizzen oder Mermaid-Code. Kapitel 5 (Analysebefunde) sortiert die Funde nach kritisch, mittel und niedrig und nennt das Problem konkret beim Namen. Kapitel 6 (Aktionsplan) liefert für jede Maßnahme einen klaren Click-by-Click-Ablauf mit Erfolgskriterium und Rollback-Schritten — abarbeitbar auch von jemandem, der bei der Beratung nicht dabei war.

 

Info: Warum gerade neun Kapitel? Die Struktur hat sich aus dem Alltag herausgeschält. Acht Kapitel sind oft zu wenig, weil entweder der Anhang fehlt oder die offenen Punkte nicht sauber getrennt sind. Zehn Kapitel sind unnötig differenziert. Neun trifft den Punkt: Kontext (Kapitel 1–3), Tiefe (Kapitel 4–6), Folgen und Restpunkte (Kapitel 7–9). Wer das einmal so durchgemacht hat, will nicht mehr zurück zu freien Format-Wildwüchsen.

Der Viersprung als Wirkungsmodell

Eine Beratung, die nur einen Bericht hinterlässt, ist eine halbe Sache. Wenn das Wissen nach der Übergabe nirgendwo konserviert ist, wenn die Werkzeuge fehlen, um Folgeanalysen selbst zu machen, und wenn das Team keine Möglichkeit hat, das Wissen zu vertiefen, dann landet der schönste Bericht früher oder später im SharePoint-Archiv. Genau das soll der Viersprung verhindern.

Abb.: Der Viersprung — vier Säulen, die zusammen ein Wissens-Ökosystem bilden. Jede Säule für sich ist Stückwerk, zusammen tragen sie auch dann, wenn der Berater nicht da ist.

Die vier Säulen ergänzen sich gegenseitig: Die Beratung liefert die situative Lösung für dein konkretes Problem. Das Buch „ADFS in der Praxis“ konserviert das Wissen für alle Team-Mitglieder, die nicht an der Beratung teilnehmen konnten. Die Software — der ADFS-Diagnostiker — macht Analysen wiederholbar, sodass dein Team auch nach Monaten denselben Drift-Check durchführen kann wie der Berater am ersten Tag. Das Training befähigt das Team, eigenständig weiterzuarbeiten.

 

Praxis-Tipp: Den Viersprung gestaffelt nutzen Du musst nicht alle vier Säulen sofort und komplett buchen. Ein typisches Muster ist: Beratung als Einstieg (Phase 1 bis 3), parallel Bücher für die wichtigsten Team-Mitglieder zur Vertiefung, ADFS-Diagnostiker als laufendes Werkzeug, Trainings am Ende der Migrationsphase, wenn das Team den Betrieb übernimmt. So entsteht ein Wissensaufbau, der mit dem Projekt mitwächst — und nicht erst am Ende mit einer großen Schulungsmaßnahme nachgereicht wird.

Konditionen und Ablauf

Die meisten Bausteine werden als Pauschalen angeboten, weil das für beide Seiten fairer ist als Tagessatz-Abrechnung mit unklarem Endpunkt. Pauschalen geben dir Planungssicherheit beim Budget und mir Planungssicherheit bei der Auslastung. Größere Migrations-Begleitungen werden nach Aufwand abgerechnet, mit klaren Meilenstein-Definitionen. Reisekosten transparent. NDA ist Standard und kein Problem.

Der Ablauf bei einer typischen Beratung:

• Erstgespräch, kostenlos, etwa 30 Minuten. Bestandsaufnahme: was ihr habt, was ihr braucht, wie dringlich es ist.
• Schriftlicher Vorschlag mit Aufwand, Zeitplan und Kosten. Innerhalb von wenigen Werktagen.
• Vertrag und NDA wenn nötig. Zugangsdaten geklärt, Termin vereinbart.
• Beratungsphase mit täglichen Status-Updates per Mail oder Chat. Keine Wochen ohne Rückmeldung.
• Übergabe mit Bericht, Walkthrough mit dem Team, schriftlichen Antworten auf alle Rückfragen.
• Nachsorge für 30 Tage inklusive — Rückfragen zum Bericht und kleinere Klärungen ohne extra Rechnung.

So nimmst du Kontakt auf

E-Mail genügt. Bitte kurz mit dabei, was hilft, das Erstgespräch effizient zu machen:

• Größe der ADFS-Umgebung (Anzahl Server, ungefähre Anzahl Relying Parties, User-Volumen)
• Worum es konkret geht (Migration, Audit, Akutfall, Architektur-Review)
• Wie dringlich es ist (geplant, vorausschauend, akut)
• Falls schon konkrete Termine im Raum stehen, dein bevorzugter Zeitrahmen

Antwort kommt innerhalb eines Werktages mit einem Vorschlag fürs Erstgespräch. Kostenlos, unverbindlich, ohne Verkaufstour.