Office 365 Multi Forest ADFS

Analog zur Identity-Verwaltung mit mehreren Forests und Tenants (Siehe Multi-Forest DirSync) gibt es natürlich auch bei der Authentifizierung per ADFS verschiedene Ansätze.

Zur Einrichtung von einem ADFS Server für mehrere UPN-Domains finden Sie auf der Seite ADFS mit mehreren UPN Domains weitergehende Informationen.

Authentifizierungsverfahren

Auf der Seite Auth Übersicht habe ich die drei wesentlichen Authentifizierungsverfahren im im Details beschrieben. Daher hier nur eine Kurzfassung, wie Anwender sich an der Cloud anmelden können:

  • Office 365 Kennwort
    Das Konto in der Cloud hat ein komplett eigenständiges Kennwort. Das ist eher was für ganz kleine Firmen ohne DirSync
  • DirSync repliziert Kennwort als Hash
    Der DirSync/ADSync kann das lokale Kennwort als Hashwert auch in der Cloud identisch halten. Die Anwender melden sich dann an Office 365-Diensten mit den gleichen Anmeldedaten (Username/Kennwort) an aber es gibt kein "Single SignOn)
  • ADFS-Service
    Die Cloud-Dienste leiten den Anwender anhand des UPN / Anmeldename auf einen ADFS-Service im unternehmen um, der Anwender holt sich ein Ticket und reicht dieses an die Cloud als Zugangscode durch.

Wir beschäftigen und hier nur mit der dritten Option, d.h. ADFS als Anmeldeverfahren mit einem oder mehreren Forests mit einem oder mehreren Tenants:

ADFS Szenarien mit Office 365

Analog zu den Szenarien für die Identity-Verwaltung auf Multi-Forest DirSync habe ich hier einmal die gängigen ADFS-Szenarien aufgelistet.

Die Bilder zeigen vereinfacht nur einen ADFS-Server. In Realität kann das natürlich auch eine Farm aus ADFS-Servern mit Loadbalancern sein, die aus dem Internet natürlich über ADFS-Proxy-Server o.ä. veröffentlicht sind.

Szenario Status Beschreibung

Single Forest, Single ADFS, Single UPN

Die ist quasi die Standardkonfiguration einer mittleren Firma, die einen Forest betreibt und per ADFS die Anmeldung an Office 365 absichert. Der Tenant wird so eingestellt, dass Anmeldungen für die gewünschten UPN-Domains zum ADFS-Server geleitet werden.

Das können natürlich auch mehrere UPNs sein.

Multi Forest mit eigenen ADFS-Servern

Wenn eine Firma mehrere Forests nutzt, was mittels ADSync problemlos gegen einen Tenant möglich ist (Siehe Multi-Forest DirSync), müssen Sie für jeden Forest einen eindeutigen UPN-Suffix definieren. An den UPN-Suffix ist die URL für den dazugehörigen ADFS-Service gebunden.

Multi Forest mit nicht eindeutigen UPNs

Wenn Sie aber den gleichen UPN-Suffix für mehrere Forests verwenden, dann können Sie dennoch nur den Verweis auf einen ADFS-Server lenken.

Diese Konfiguration ist daher nicht möglich.

Multi Forest mit Trust und Single ADFS-Service

Viele Firmen betreiben immer noch mehrere Forests. Sei es aus historischen Gründen oder in einer Umgebung mit Ressource Forests für Dienste wie Exchange und anderen Forests für die Anmeldedomänen.

Wer nun aber nicht für jeden Anmeldeforest einen eigenen ADFS-Service installieren möchte, kann die Funktion von ADFS über Trusts nutzen. Ein ADFS-Server kann zwar nur direkt einen Forest bedienen aber über einen Trust können auch Benutzer anderer Forests diesen Service nutzen.

Multi Forest mit einem ADFS-Server

Diese Konfiguration ist über den Weg der Claim Provider Trusts möglich. Ein ADFS-Service bedient per Default den Forest, in der auch der ADFS-Server Mitglied ist.

Aber der ADFS-Server kann derart konfiguriert werden, für bestimmte UPNs einen anderen ADFS-Server Forest direkt zu fragen.

Reverse Proxy als Weiche

Ohne Bild

Wenn Sie wirklich mehrere Forests unter einem ADFS-Namen ohne Trust erreichbar machen wollen, dann können Sie ggfls. mit einem Reverse Proxy eine Lösung schaffen. Natürlich brauchen Sie intern pro Forest einen ADFS-Server aber der Reverse Proxy könnte den UPN des Benutzers abfangen und die Anfrage dann zum "richtigen" ADFS-Server weiterleiten. Das ist aber ein sehr seltener Fall und geht nicht mit jedem Reverse Proxy.

Ein ADFS für mehrere Tenants

Auch das ist möglich, wenn es für jeden Tenant einen eindeutigen UPN gibt und ADSync nur die entsprechenden Benutzer in den Tenant überträgt. Allerdings muss der ADFS-Server hier eben auch mehrere Domains unterstützen, auch wenn diese von unterschiedlichen Tenants kommen.

Dies sind Einige aber sicher nicht alle Konstellationen.

ADFS in Firmen

ADFS wird aber nicht nur für die Anmeldung an Office 365 genutzt. Natürlich können Sie auch interne Anwendungen, z.B. SharePoint oder CRM mit ADFS authentifizieren. Solange Sie sich hier innerhalb des gleichen Forests bewegen, ist alles ziemlich einfach. Interessant wird es, wenn Sie mehrere Forests haben. hier gibt es dann auch zwei Ansätze:

Ein ADFS-Server mit Trusts

Ein ADFS-Server kann auch Tickets für "Trusted Domain" ausstellen. Wenn die Benutzer zur Anmeldung also auf einem  anderem Forest sind, dann muss ein klassischer Windows Trust (Cross Forest)

Mehrere ADFS-Server

Wenn die Applikation dies unterstützt, können Sie vergleichbar zu Office 365 auch mehrere ADFS-Server einbinden. In der Regel muss die Applikation dann den UPN des Anwenders abfragen oder z.B. per Cookie vorbelegt übermittelt bekommen und den Client zum "richtigen" ADFS-Server weiter vermitteln. So arbeitet z. B. Office 365, welches abhängig vom UPN den Client zum passenden ADFS-Server verweist

ADFS Kasade

Ein Problem von Applikationen mit ADFS besteht immer dann, wenn die Applikation nur genau einen ADFS-Server unterstützt.

Ich hatte mir vorgestellt, dass ich dann diese Applikation einfach zu einem ADFS-Server sendet, der aber die Authentifizierung seinerseits gegen einen anderen ADFS-Server durchreicht oder alternativ den Client ebenfalls per Redirect zum weiteren ADFS-Server sendet.

Beides geht aber nicht. Zum Einen kann ADFS1 das nicht und selbst wenn, dann würde die Applikation ja nicht einem Token vertrauen, welches von einem anderen unbekannten ADFS-Server stammt.

Was aktuell möglich ist, dass ein Service den Client zu immer dem gleichen ADFS-Server verweist und erst dort nach UPN unterschieden und verschiedene Claim Provider genutzt werden. Wobei es erste Zeichen gibt, dass z. B. ADFS 4.09 so etwas können soll.

Damit könnten dann aber neben neben mehreren Forests auch andere Anmeldediense, z.B. LDAP-Provider, SAP, SQL etc. genutzt werden. Vielleicht irgendwann auch mal externe Identitätsdienste wie Facebook, Twitter, Microsoft-ID, Google etc.

Wenn Sie andere Deployment-Optionen können und umgesetzt haben, würde ich mich über entsprechende Informationen freuen. 

ADFS Hints

Gerade wenn sie mehrere Forests haben, dann wissen alle Forests über den Trust natürlich, wo welche UPN-Domain genutzt wird. Sie können aber ADFS auch einen "Hint" geben. Unter den AdfsClaimsProviderTrust gibt es ja das Verzeichnis "Active Directory". Über die PowerShell kann diese Partnerschaft angepasst werden

Set-AdfsClaimsProviderTrust `
   -TargetName "Active Directory" `
   -AlternateLoginID userPrincipalName * 
   -LookupForests msxfaq.de,uclabor.de,netatwork.de

Es gibt noch viel mehr Parameter, von denen nur ganz wenige per GUI erreichbar sind. Interessant ist der Wert "LookupForests" für mehrere Domains. Es ist ein String-Array und teilt der Konfiguration mit, in welchem Forests ADFS nach alternativen LoginIDs suchen soll

Specifies the forest DNS names that can be used to look up the AlternateLoginID.
Quelle https://docs.microsoft.com/en-us/powershell/module/adfs/set-adfsclaimsprovidertrust?view=win10-ps

Wenn Sie als Alternate Login ID hier den UPN vorgeben, können Sie so in vielen Forests suchen lassen

Weitere Links