ADFS, Office 365 und Subdomains
Wer ADFS für die Authentifizierung mit Office 365 nutzt, ist eigentlich von den Automatismen und Assistenten, die die Einrichtung und Konfiguration der zu den Diensten gehörenden Parameter übernehmen, sehr verwöhnt. Um so schlimmer, wenn das dann mal genau nicht funktioniert – wie in einem meiner letzten Projekte geschehen, und zwar in Verbindung mit der Authentifizierung in einer Subdomain.
Ich habe einen Kunden, der für seine verschiedenen Ländergesellschaften Subdomains im Active Directory pflegt. Die übergeordnete Domäne heißt dann etwa contoso.com, die deutsche Subdomain de.contoso.com, die frankzösische fr.contoso.com und so weiter. Demnach lauten dann auch die UPN der Mitarbeiter etwa klaus.deutsch@de.contoso.com oder henry.blanc@fr.contoso.com. In Office 365 haben wir entsprechend die Root Domain, als auch die zugehörigen Subdomains eingerichtet, so dass wir die Mitarbeiter der verschiedenen Gesellschaften auch alle über einen Tenant verwalten können. Da es sich um eine gemeinsame Struktur handelt, haben wir auch eine gemeinsame ADFS-Infrastruktur.
Beim Einrichten der Federation kommt nun schon die erste Abweichung zum normalen vorgehen: Anstatt jede Domain einzeln auf Federation umzustellen (PowerShell: Convert-MsolDomainToFederated), konvertiert man nur die Root Domain – die restlichen Subdomains erben die Einstellung und werden automatisch mit umgestellt. Ansonsten funktioniert die Einrichtung von DirSync, ADFS und Co. weitestgehend ähnlich. Beim ersten Test der Anmeldung mit einem Benutzer einer Subdomain stellte sich allerdings das folgende Problem ein:
Leider können wir Sie nicht anmelden. Es wurde eine ungültige Anmeldung empfangen.
AADSTS50107: Requested federation realm object ‘http://de.contoso.com/adfs/services/trust/’ does not exist.
Trotz gültiger Anmeldedaten und erfolgreicher Authentifizierung klappte die Anmeldung an Office 365 mit o.g. Fehlermeldung nicht. Nach einiger Recherche stellte sich heraus, dass es wohl daran liegt, dass der ADFS Service aus dem Anmeldenamen (UPN) des Users versucht, die föderierte Domain in Office 365 zu errechnen – bei Subdomains leider nicht ganz erfolgreich. Da die Subdomain selbst nicht explizit in Office 365 als “federated” markiert ist, sondern über die Root Domain, darf der ADFS Service als Federation Realm nicht etwa de.contoso.com zurückgeben, sonder die Root Domain contoso.com. Glücklicherweise gibt es ja Leute, die Ihre Probleme und deren Lösung online veröffentlichen 😛 , somit fand ich dann diesen Beitrag hier.
Klang alles ganz einleuchtend und einfach, hab also im ADFS den beschriebenen Eintrag in ADFS gesetzt (ja, auch die Anführungszeichen korrigiert usw.), auf Ok geklickt und … eine Fehlermeldung erhalten?!? Sinngemäß hieß es, dass die Syntax des regulären Ausdrucks nicht korrekt sein. Hmm … der Beitrag von Shane Jackson verwies als Referenz auf diesen Technet Artikel von Abizer, der in seinem Artikel unter anderem zeigt, wie man den regulären Ausdruck per PowerShell testen kann. Und dieser Test hat auch funktioniert.
Also hat mal wieder jemand reguläre Ausdrücke etwas anders implementiert, als die anderen … typisch. Nun habe ich versucht, für meinen ADFS Server (Windows Server 2012 R2), der nun mal den fertigen Regex Ausdruck nicht haben wollte, mit einem neuen zu füttern. Glücklicherweise gibt es ein Online Tool von Derek Slager, mit dem man genau die richtigen regulären Ausdrücke testen kann. Nach etwas Gefummel kam dann folgender Ausdruck heraus, der (bei mir zumindest) einwandfrei funktioniert:
c:[Type == "http://schemas.xmlsoap.org/claims/UPN"]
=> issue(Type = "http://schemas.microsoft.com/ws/2008/06/identity/claims/issuerid", Value = regexreplace(c.Value, ".+[@]([^.]*[.])*(?<domain>[^.]+[.][^.]+)$", "http://${domain}/adfs/services/trust/"));
Im Endeffekt extrahiert der Ausdruck “.+@*(?<domain>[^.]+[.][^.]+)$” aus einer E-Mail Adresse die letzten beiden, durch “.” getrennten Zeichenfolgen – also die Root Domain.
Also wieder einmal ein Phänomen, das man nur durch Praxis am lebenden Objekt finden und lösen kann, aber wohl in keiner Schulungsunterlage, sei sie noch so gut, antreffen wird. Deshalb die Devise: Ran an den Mann und Keine Angst vorm Feind 😉
