ADFS Claim Rules Leitfaden

boddenberg.de · Identity & Access Management

ADFS Claim Rules verstehen — der praktische Leitfaden

Pipeline, Rule Sets, Claim Rule Language und Praxisbeispiele — alles, was du an einem Vormittag brauchst.

 

★ Kurzfassung für Eilige (TL;DR) ADFS Claim Rules sind Regeln in PowerShell-naher Syntax, die steuern, welche Identitätsinformationen beim Single Sign-On in das ausgestellte Token wandern. Es gibt drei produktive Regelwerke: Acceptance Transform Rules am Claims Provider Trust nehmen Eingangs-Claims aus dem AD entgegen, Issuance Authorization Rules am Relying Party Trust entscheiden über Permit oder Deny, und Issuance Transform Rules am Relying Party Trust bestimmen, welche Claims final ins Token gehören. 90 Prozent aller Custom-Regeln, die du je schreibst, leben im dritten Set.

 

Was sind ADFS Claim Rules?

ADFS Claim Rules sind das Werkzeug, mit dem die Active Directory Federation Services entscheiden, welche Identitätsinformationen über einen Anwender in welchem Format an eine angebundene Anwendung weitergegeben werden. Ohne Claim Rules ist ein ADFS-Server eine Hülle ohne Inhalt — er kann zwar authentifizieren, weiß aber nicht, was er der Anwendung über den Anwender mitteilen soll.

Technisch betrachtet ist eine Claim Rule ein kleines Skript in der sogenannten Claim Rule Language. Diese Sprache sieht aus wie eine Mischung aus SQL und PowerShell, ist aber etwas Eigenständiges. Eine Regel besteht immer aus einer Bedingung („wenn ein Claim dieses Typs vorliegt“) und einer Aktion („dann erzeuge einen neuen Claim mit jenem Inhalt“). Mehrere Regeln werden in einem Rule Set zusammengefasst und der Reihe nach abgearbeitet.

ⓘ Warum heißt das eigentlich „Claim“? Ein Claim — wörtlich eine „Behauptung“ — ist eine signierte Aussage über einen Anwender. Statt ein Passwort zu prüfen, vertraut die Anwendung der Aussage des Identity Providers: „Dieser Anwender heißt Uli, gehört zur Gruppe Consulting-Admins und hat die E-Mail-Adresse uli@boddenberg.de.“ Solange das Token korrekt signiert ist, glaubt die Anwendung das. Claim Rules formen genau diese Aussagen.

Die ADFS Claim Pipeline — der Weg vom AD-Attribut zum Token

Bevor du auch nur eine einzige Regel schreibst, musst du verstehen, in welcher Reihenfolge ADFS Claims verarbeitet. Die sogenannte Claim Pipeline ist ein dreistufiger Prozess, der bei jedem Login durchlaufen wird. Stell dir das Ganze wie eine Förderbandstrecke vor — vorn kommen rohe Attribute aus dem Active Directory rein, hinten fällt ein signiertes SAML- oder JWT-Token heraus.

Abbildung 1: Die ADFS Claim Pipeline mit ihren drei Stationen und dem internen Claim Store

Der Claim Store in der Mitte ist der oft übersehene Held der Geschichte. Er ist kein Speicher im klassischen Sinn, sondern eine flüchtige Liste aller Claims, die während eines einzigen Logins existieren. Sobald das Token signiert und ausgeliefert ist, ist der Store wieder leer. Alle Rule Sets greifen lesend auf diesen Store zu und können neue Claims hinzufügen — das ist der zentrale Mechanismus, mit dem Daten zwischen den Phasen wandern.

✓ Merksatz für die Praxis Eingang ist links (Claims Provider Trust), Ausgang ist rechts (Relying Party Trust). Wenn ein Claim am rechten Ende fehlt, fängst du systematisch links an zu suchen. Diese Reihenfolge ist auch der rote Faden für jedes Troubleshooting — dazu später mehr.

Die drei Rule Sets im Detail — wer wohnt wo?

ADFS unterscheidet je nach Trust-Typ zwischen verschiedenen Regelwerken. Am Claims Provider Trust gibt es genau ein Rule Set, am Relying Party Trust sind es zwei produktive Sets plus ein selten genutztes viertes. Die folgende Übersicht zeigt, was wo hingehört.

Abbildung 2: Die Rule Sets in ADFS — Aufteilung zwischen Claims Provider Trust und Relying Party Trust

Acceptance Transform Rules — der Türsteher am Eingang

Diese Regeln sitzen am Claims Provider Trust. Bei einem typischen on-premises ADFS-Setup ist das Active Directory selbst der einzige Claims Provider. Acceptance Transform Rules legen fest, welche Attribute aus dem AD als Claims in den Pipeline-Store übernommen werden. Im Standard-Setup steht hier nur eine einzige Pass-Through-Regel für den Windows Account Name — alles andere musst du explizit dazuholen.

In gemischten Szenarien, etwa wenn ADFS auch von einem externen IdP wie einem Partnerunternehmen oder Azure AD B2B Federation Claims entgegennimmt, werden die Acceptance Transform Rules richtig spannend. Hier wandelt man fremde Claim-Typen in das eigene Schema um, filtert unerwünschte Behauptungen weg und legt fest, wem man überhaupt was glaubt.

▶ Acceptance Transform Rule — Default // Standard-Acceptance-Regel: alle Windows-Account-Namen durchlassen c:[Type == "http://schemas.microsoft.com/ws/2008/06/identity/claims/windowsaccountname"] => issue(claim = c);

Issuance Authorization Rules — Permit oder Deny

Dieses Rule Set sitzt am Relying Party Trust und entscheidet vor der Token-Ausstellung eine simple Frage: Darf dieser konkrete Anwender diese konkrete Anwendung überhaupt nutzen? Die Antwort ist binär. Es gibt nur die Aktionen permit() und deny(). Im Default-Template steht hier eine Regel namens „Permit Access To All Users“, die jedem Authenticated User Zutritt gewährt.

⚠ Achtung: Deny gewinnt immer Anders als bei vielen anderen Berechtigungssystemen werden alle Regeln im Set abgearbeitet. Ein einzelner deny() trumpft jedes permit() — egal in welcher Reihenfolge die Regeln stehen. Wenn ein Anwender plötzlich nicht mehr in die Anwendung kommt, schau hier zuerst nach versteckten Deny-Regeln, bevor du anderswo suchst.

▶ Issuance Authorization Rules // Nur Mitglieder der AD-Gruppe „SAP-Users“ zulassen c:[Type == "http://schemas.microsoft.com/ws/2008/06/identity/claims/role", Value == "SAP-Users"] => permit();   // Externe Konten explizit aussperren c:[Type == "http://schemas.microsoft.com/ws/2008/06/identity/claims/role", Value == "Externe"] => deny();

Issuance Transform Rules — das Herzstück

Hier passiert die eigentliche Arbeit. Issuance Transform Rules am Relying Party Trust legen fest, welche Claims im Token landen, in welchem Format und unter welchem Type-URI. Wenn die Anwendung im SAP einen E-Mail-Claim unter dem Type „email“ erwartet, ADFS aber intern mit dem langen URI „http://schemas.xmlsoap.org/ws/2005/05/identity/claims/emailaddress“ hantiert, dann ist eine Issuance Transform Rule der Übersetzer dazwischen.

Die meisten Anwendungen kommen mit drei bis sieben Claims zurecht: ein Identifier (Anmeldename, UPN oder Object SID), ein bis zwei Anzeigeattribute (Vorname, Nachname, E-Mail) und mindestens ein Rollen- oder Gruppen-Claim für die Berechtigungssteuerung in der Anwendung selbst. Genau diese Übersetzungsarbeit erledigen die Issuance Transform Rules.

✓ Faustregel aus zwanzig Jahren ADFS-Consulting Wenn du dich fragst „wo soll ich diese Custom Rule hinschreiben?“, lautet die Antwort in neun von zehn Fällen: in die Issuance Transform Rules am Relying Party Trust. Acceptance und Authorization sind nur dann der richtige Ort, wenn du wirklich am Eingang filtern oder ganze Anwender aussperren willst.

Delegation Authorization Rules — der seltene Sonderfall

Vollständigkeitshalber: Es gibt noch ein viertes Rule Set, die Delegation Authorization Rules. Sie regeln, ob ein Dienst im Namen eines Anwenders ein Token bei ADFS anfordern darf (sogenannte ActAs-Szenarien). In klassischen Web-SSO-Setups brauchst du das so gut wie nie. Wenn du gerade keine WCF-Backend-Service-Kette modellierst, kannst du dieses Set ignorieren.

Die Claim Rule Language — Syntax in zehn Minuten

Die Claim Rule Language ist eine kleine, deklarative DSL — also keine vollwertige Programmiersprache. Es gibt keine Schleifen, keine Funktionen, keine globalen Variablen. Was es gibt: Bedingungen, Variablenbindungen, Operatoren und genau drei Aktionen: issue, add und delete. Mehr brauchst du auch nicht. Die folgende Grafik zerlegt eine typische Regel in ihre Bestandteile.

Abbildung 3: Aufbau einer Claim Rule und die wichtigsten Operatoren der Claim Rule Language

issue, add und delete — der Unterschied

Das ist der Klassiker, an dem fast jeder beim Einstieg stolpert. Die drei Aktionen sehen ähnlich aus, machen aber Unterschiedliches. issue() fügt einen Claim in den Pipeline-Store ein UND schreibt ihn in das ausgehende Token. add() schreibt nur in den Store, nicht ins Token. delete() entfernt einen Claim aus dem Store.

Aktion	In den Claim Store?	Ins Token?	Wann benutzen?
issue(…)	ja	ja	Standard-Fall: Claim soll an die Anwendung
add(…)	ja	nein	Zwischenergebnis für Folge-Regeln
delete(…)	nein (entfernt)	nein	Aufräumen vor finaler Issuance

 

Konkretes Beispiel: Du willst die AD-Gruppen eines Anwenders einlesen, dann anhand der Gruppen einen einzigen kombinierten Rollen-Claim für die Anwendung berechnen — aber die einzelnen Gruppen sollen nicht im Token landen, weil dort sonst hundert Einträge stehen. Lösung: Die einzelnen Gruppen kommen per add() in den Store. Eine zweite Regel liest die add-Werte und gibt nur das gewünschte Endergebnis per issue() weiter.

Variablenbindung mit c: — der Pattern-Match

Wenn du in einer Regel auf Werte aus dem gematchten Claim zugreifen willst, musst du dem Pattern einen Namen geben. Das geht mit dem Präfix c: vor der eckigen Klammer. Im Aktionsteil hast du dann c.Value (der Wert des Claims), c.Type (der Typ) und c.Issuer (wer hat ihn ausgestellt) zur Verfügung. Ohne diese Bindung sieht ADFS zwar, dass die Regel matcht, gibt dir aber keinen Zugriff auf die konkreten Werte.

▶ Variablenbindung — falsch und richtig // Ohne Bindung: ADFS weiß nicht, was es weitergeben soll [Type == "…emailaddress"] => issue(Type = "email", Value = ???);   // Mit Bindung: c.Value enthält den E-Mail-String aus dem AD c:[Type == "http://schemas.xmlsoap.org/ws/2005/05/identity/claims/emailaddress"] => issue(Type = "email", Value = c.Value);

Acht praktische Beispiele aus dem Consulting-Alltag

Genug Theorie. Die folgenden Beispiele stammen aus echten Kundenprojekten — anonymisiert auf die drei fiktiven Firmen Musterwerk GmbH (mittelständischer Maschinenbau), Sparfuchs & Partner Steuerberatungs GmbH und Trendforge Digital GmbH. Jedes Beispiel zeigt eine wiederkehrende Aufgabe und die zugehörige Regel — direkt zum Übernehmen.

Beispiel 1 — Alle Windows-Account-Namen durchreichen

Der einfachste Fall: An die Anwendung soll der Domain-qualifizierte Anmeldename gehen (BODDENBERG\uli). Diese Regel ist im Standard-Acceptance-Set bereits enthalten, ich zeige sie hier zur Vollständigkeit. Sie steht am Claims Provider Trust.

▶ Acceptance Transform — Pass Through c:[Type == "http://schemas.microsoft.com/ws/2008/06/identity/claims/windowsaccountname"] => issue(claim = c);

Beispiel 2 — UPN und E-Mail aus dem AD ziehen

Die meisten modernen Anwendungen wollen statt des alten DOMAIN\user-Formats lieber den UPN (Uli@boddenberg.de) und eine separate Mail-Adresse. Beide Werte holen wir aus dem AD und schreiben sie ins Token. Diese Regel gehört in die Issuance Transform Rules am Relying Party Trust.

▶ Issuance Transform — AD-Attribute auslesen // Greift den Windows-Account-Namen und macht daraus eine LDAP-Query c:[Type == "http://schemas.microsoft.com/ws/2008/06/identity/claims/windowsaccountname"] => issue(store = "Active Directory", types = ("http://schemas.xmlsoap.org/ws/2005/05/identity/claims/upn", "http://schemas.xmlsoap.org/ws/2005/05/identity/claims/emailaddress"), query = ";userPrincipalName,mail;{0}", param = c.Value);

ⓘ Die Query-Syntax entschlüsselt Das Format der LDAP-Query bei store = "Active Directory" lautet: ;<LDAP-Attribut1>,<LDAP-Attribut2>,…;{0}. Das {0} wird durch den Wert in param ersetzt. Die Reihenfolge der Attribute in der Query muss zur Reihenfolge der Type-URIs in types = (…) passen — sonst landet die E-Mail im UPN-Claim und umgekehrt.

Beispiel 3 — AD-Gruppen als Rollen-Claims

Klassiker Nummer eins: Du brauchst die Gruppenmitgliedschaften als Role-Claims, damit die Anwendung darauf Berechtigungen aufbaut. Das memberOf-Attribut des Anwenders enthält die DNs aller Gruppen, in denen er Mitglied ist. Die folgende Regel macht aus jeder Gruppenmitgliedschaft einen eigenen Rollen-Claim.

▶ AD-Gruppen → Role-Claims c:[Type == "http://schemas.microsoft.com/ws/2008/06/identity/claims/windowsaccountname"] => issue(store = "Active Directory", types = ("http://schemas.microsoft.com/ws/2008/06/identity/claims/role"), query = ";memberOf;{0}", param = c.Value);

⚠ Vorsicht bei großen Gruppenstrukturen memberOf liefert die DNs der direkten Gruppenmitgliedschaften (DN, nicht der CN). Bei großen Konzernverzeichnissen können das mehrere hundert Einträge pro Anwender sein. Ein SAML-Token mit 400 Role-Claims ist nicht nur unhandlich, sondern überschreitet schnell die maximale URL-Länge bei POST-Bindings. Filtere mit einer zweiten Regel oder nutze tokenGroups für transitiv aufgelöste, gefilterte Gruppen.

Beispiel 4 — Rollen filtern und auf Klarnamen mappen

Aufbauend auf Beispiel 3 wollen wir nur eine bestimmte Gruppe als Rolle übernehmen und sie gleichzeitig auf einen sprechenden Namen ummappen. Aus „CN=SAP-Power-Users,OU=Apps,DC=boddenberg,DC=de“ wird im Token einfach „PowerUser“.

▶ Filter + Mapping in zwei Schritten // 1. Schritt: Gruppen per add() in den Store legen (nicht ins Token) c:[Type == "http://schemas.microsoft.com/ws/2008/06/identity/claims/windowsaccountname"] => add(store = "Active Directory", types = ("http://temp/groups"), query = ";memberOf;{0}", param = c.Value);   // 2. Schritt: Wenn die Power-Users-Gruppe drin ist, sauberen Role-Claim ausstellen c:[Type == "http://temp/groups", Value =~ "^CN=SAP-Power-Users"] => issue(Type = "http://schemas.microsoft.com/ws/2008/06/identity/claims/role", Value = "PowerUser");

Beispiel 5 — Statischer Mandanten-Claim für SAP

Die Musterwerk GmbH betreibt einen SAP-Mandanten für die Hauptgesellschaft und einen für die Tochter Trendforge Digital GmbH. Beide hängen am selben ADFS. Du brauchst einen statischen Claim, der jedem Trendforge-User die Mandanten-Nummer mitgibt — unabhängig vom AD-Attribut, einfach hart verdrahtet.

▶ Statischer Mandanten-Claim // Wenn der Anwender im Trendforge-OU sitzt, statischen Claim ausstellen c:[Type == "http://schemas.microsoft.com/ws/2008/06/identity/claims/windowsaccountname"] && c2:[Type == "http://temp/dn"] && c2.Value =~ "OU=Trendforge" => issue(Type = "http://sap.com/mandant", Value = "200");

Beispiel 6 — MFA-Status weiterreichen

Manche Anwendungen wollen wissen, ob der aktuelle Login mit Multi-Factor Authentication erfolgt ist, um z.B. nur dann administrative Aktionen zuzulassen. ADFS schreibt bei MFA-Logins automatisch einen authenticationmethod-Claim in den Store — du musst ihn nur ins Token durchschleifen.

▶ MFA-Indikator ins Token c:[Type == "http://schemas.microsoft.com/claims/authnmethodsreferences"] => issue(claim = c);   // Alternativ: nur, wenn MFA wirklich verwendet wurde c:[Type == "http://schemas.microsoft.com/claims/authnmethodsreferences", Value == "http://schemas.microsoft.com/claims/multipleauthn"] => issue(Type = "http://temp/mfa", Value = "true");

Beispiel 7 — Zugriff nur aus dem internen Netz

Die Issuance Authorization Rules eignen sich hervorragend für Standort-basierte Einschränkungen. Hat der Login die WebApplicationProxy passiert (also kommt von extern), gilt eine andere Regel als beim Direktzugriff im LAN. ADFS markiert externe Logins mit einem speziellen InsideCorporateNetwork-Claim.

▶ Standortbasierte Authorization // Externe Logins für die Buchhaltungs-App generell ablehnen c:[Type == "http://schemas.microsoft.com/2012/01/requestcontext/claims/x-ms-forwarded-client-ip"] => deny();   // Saubere Variante: positiv per InsideCorporateNetwork-Claim c:[Type == "http://schemas.microsoft.com/2012/01/requestcontext/claims/insidecorporatenetwork", Value == "true"] => permit();

Beispiel 8 — Custom Attribute Store für externe Daten

Manchmal liegen die benötigten Informationen nicht im AD, sondern in einer SQL-Datenbank, einer Personalverwaltung oder einem Custom Identity Store. ADFS unterstützt eigene Attribute Stores, die in der ADFS-Konfiguration registriert werden. In der Claim Rule referenzierst du sie über den store-Parameter.

▶ Custom Attribute Store — SQL-Beispiel // Personalnummer aus dem HR-SQL-Server ziehen c:[Type == "http://schemas.xmlsoap.org/ws/2005/05/identity/claims/upn"] => issue(store = "HR-SQL", types = ("http://muster.com/personalnummer"), query = "SELECT PersNr FROM Mitarbeiter WHERE Upn=@upn", param = c.Value);

✓ Performance-Hinweis Jeder Custom-Store-Aufruf passiert pro Login einmal. Bei tausend Logins am Morgen sind das tausend SQL-Queries — sorge für einen Index auf der Upn-Spalte. Wenn die Daten sich kaum ändern, denke über einen Cache (z.B. SQL-View mit täglichem Snapshot) statt direkter Abfrage nach.

Best Practices — was sich in zwanzig Jahren bewährt hat

Die folgenden Regeln sind nicht in der Microsoft-Doku zu finden, sondern destilliert aus etlichen Kundenprojekten zwischen Mittelstand und Konzern. Wer sich daran hält, vermeidet 80 Prozent der späteren Schmerzen.

Niemals die Default-Templates direkt überschreiben. Lege immer eigene Regeln an und kommentiere sie mit Datum und Ticket-Nummer. So weißt du in drei Jahren noch, warum die Regel da steht.

Custom Type-URIs unter einer eigenen Domain. Nutze etwas wie http://boddenberg.de/claims/personalnummer statt http://temp/persnr. Das verhindert Kollisionen mit Microsoft-URIs und macht den Ursprung klar.

Pass-Through-Regeln nur dort, wo du sie brauchst. Jeder durchgereichte Claim ist potenzielle Information Disclosure. Pflege eine bewusste Liste der Claims, die eine Anwendung wirklich braucht — und nur die schickst du raus.

Issuance Authorization niemals leer lassen. Ein leeres Rule Set verweigert ALLEN Zugriff. Klingt offensichtlich, ist aber der häufigste Selbstmord beim Übernehmen einer ADFS-Umgebung.

Regeln in PowerShell pflegen, nicht in der GUI. Die GUI ist gut fürs Verstehen, aber bei mehr als drei Regeln pro Trust wird sie unhandlich. PowerShell-Skripte versionierst du in Git und rollst sie reproduzierbar auf alle Farm-Knoten aus.

Test-Anwender pro Anwendung. Lege je Anwendung einen dedizierten Service-User-AD-Account an, der gezielt die Berechtigungen hat, die die Anwendung sehen soll. Damit kannst du Claims testen, ohne deinen Admin-Account zu nutzen.

 

Troubleshooting — wenn das Token nicht enthält, was es soll

Irgendwann passiert es jedem: Die Anwendung sagt „User has no role assigned“, aber im AD steht alles richtig. Statt blind in den Logs zu wühlen, lohnt sich ein systematischer Durchlauf der Pipeline von vorn nach hinten. Die folgende Grafik zeigt den Entscheidungsbaum, den ich seit Jahren bei jedem ADFS-Ticket abarbeite.

Abbildung 4: Systematischer Entscheidungsbaum für ADFS-Claim-Probleme

Den ETL-Trace richtig nutzen

Wenn nach den PowerShell-Checks immer noch nichts klar ist, hilft nur der ETL-Trace. ADFS schreibt im Verbose-Modus jeden einzelnen Verarbeitungsschritt mit — inklusive aller Claims, die durch die Pipeline laufen. Vorbereitung:

▶ ETL-Trace aktivieren # Verbose-Logging aktivieren (auf jedem ADFS-Knoten ausführen!) Set-AdfsProperties -LogLevel ($null,'Verbose','Information','Warning','Error','SuccessAudits','FailureAudits')   # Auditing-Komponente aktivieren — sonst kommt im EventViewer nichts an auditpol.exe /set /subcategory:'Application Generated' /failure:enable /success:enable   # Im EventViewer dann nach Event-ID 1000 / 500 / 501 unter Applications and Services Logs → AD FS → Admin suchen

⚠ Verbose-Logging nicht dauerhaft anlassen Auf produktiven ADFS-Farmen erzeugt der Verbose-Modus Gigabytes an Event-Log-Einträgen pro Tag. Aktivieren, reproduzieren, deaktivieren — und nie für mehr als die Fehlersuche eingeschaltet lassen. Sonst sind die Disk-Caches voll und die ADFS-Performance bricht ein.

Häufige Fragen zu ADFS Claim Rules

Die folgenden Fragen tauchen in jedem ADFS-Workshop mindestens einmal auf. Knappe, direkte Antworten — perfekt, um sie an Kollegen weiterzuschicken.

Was ist der Unterschied zwischen issue und add?

issue() schreibt einen Claim sowohl in den internen Claim Store als auch in das Ausgangs-Token. add() schreibt ihn nur in den Store. add nutzt du immer dann, wenn der Claim nur als Zwischenergebnis für eine spätere Regel dient und nicht in der Anwendung landen soll.

Warum kommt mein neuer Claim nicht im Token an?

Drei Standard-Verdächtige: Erstens, die Regel steht im falschen Rule Set (typischerweise in den Acceptance Rules statt in den Issuance Transform Rules). Zweitens, die Bedingung matcht nie — z.B. wegen Tippfehler im Type-URI. Drittens, der zugrunde liegende Wert ist im AD leer. Den ETL-Trace einschalten klärt alle drei Fälle innerhalb einer Stunde.

Welche Anwendungen erwarten welche Claim-Typen?

Jede Anwendung dokumentiert das in ihrem SAML- oder OIDC-Setup-Guide. SAP NetWeaver erwartet typischerweise einen NameID-Claim plus eine Mitarbeiter-ID. ServiceNow will UPN und role. Atlassian Cloud nutzt email und displayName. Im Zweifel: SAML-Tracer (Browser-Plugin) zwischen IdP und Anwendung schalten und schauen, was die Anwendung beim ersten gescheiterten Versuch genau bemängelt.

Kann ich Claim Rules zwischen Trusts kopieren?

Ja, sehr leicht sogar. Get-AdfsRelyingPartyTrust -Name 'AppA' | Select -ExpandProperty IssuanceTransformRules liefert dir die kompletten Regeln als String. Den kannst du via Set-AdfsRelyingPartyTrust -TargetName 'AppB' -IssuanceTransformRules $rules auf einem anderen Trust setzen. Vorsicht: Die Type-URIs müssen zum Schema der Ziel-Anwendung passen — blind kopieren ist riskant.

ADFS 2016 vs. 2019 vs. 2022 — gibt es Unterschiede bei Claim Rules?

Bei der Claim Rule Language selbst seit Jahren keine. Die Sprache und ihre Operatoren sind über alle Versionen seit ADFS 2.0 (2010!) praktisch identisch geblieben. Was sich ändert, sind die verfügbaren Standard-Claim-Typen (insbesondere rund um MFA und Device Registration) und die PowerShell-Cmdlets drumherum. Regeln, die du heute schreibst, laufen auch auf 2016 und sind aufwärtskompatibel.

Sollte ich überhaupt noch neue Anwendungen an ADFS anbinden?

Ehrliche Antwort: Wenn du frei wählen kannst, nimm Entra ID. Microsoft positioniert ADFS seit Jahren als Legacy-Komponente, neue Features landen primär in der Cloud. Aber: Solange du on-premises Anwendungen hast, die kein OAuth/OIDC können (etliche SAP-Module, älteres Atlassian-Datacenter, viele Mittelstands-Apps), bleibt ADFS produktiv relevant. Plane Migrations-Roadmaps in Jahren, nicht in Quartalen — und schreibe Claim Rules so, dass die Mapping-Logik leicht nach Entra ID exportierbar ist.

Wie geht es weiter?

ADFS Claim Rules sind eines dieser Themen, bei denen die ersten zwanzig Minuten ein bisschen wehtun und der Rest dann erstaunlich angenehm verläuft. Wer die Pipeline einmal verinnerlicht hat und die drei Rule Sets sicher zuordnet, schreibt selbst komplexe Regeln im Schlaf.

Wenn dir dieser Artikel beim Einstieg geholfen hat: Auf boddenberg.de findest du tiefer gehende Beiträge zu ADFS-Migrationen, Entra-ID-Integration, Token-Signaturen, dem Wechsel zu OAuth 2.0 sowie das ausführliche ADFS-Buch mit knapp 1.000 Seiten Praxiswissen — von der ersten Farm-Installation bis zum kontrollierten Abschalten zugunsten von Entra ID.

★ Über den Autor Uli Boddenberg ist seit fast drei Jahrzehnten als selbstständiger IT-Consultant für Microsoft-Enterprise-Umgebungen im DACH-Raum unterwegs. Schwerpunkte: Active Directory, ADFS, Entra ID, Exchange, SharePoint, SQL Server, PKI/ADCS sowie Microsoft Copilot und KI-Governance. Veröffentlicht eigene Bücher und Werkzeuge unter dem Dach von boddenberg.de — darunter ADFS Diagnostiker, das umfangreiche ADFS-Buch und die Software-Familie CosyTrack. Findet komplexe Themen nur dann nützlich, wenn sie verständlich erklärt sind.