Sie möchten also einige Ihrer Anwendungen über einen Verbund verfügbar machen, haben aber mehrere Forests. Was können Sie tun? Nun, wenn Sie zweiseitige Vertrauensstellungen zwischen Ihren Forests haben, haben Sie Glück, denn AD FS funktioniert sehr gut, wenn Sie zweiseitige Vertrauensstellungen zwischen den Forests haben. Was aber, wenn Sie nur eine einseitige Vertrauensstellung zwischen den Forests haben? Was dann?
In diesem Szenario gehen wir davon aus, dass Sie SSO für mehrere Anwendungen für Benutzer aus zwei verschiedenen Forests bereitstellen möchten. Die Anwendungen können sich in der einen oder der anderen Forest befinden oder Cloud-basiert sein (und somit in keiner der beiden Forests).
Mit einer zweiseitigen Vertrauensstellung zwischen Ihren AD-Forests und Ihrem AD FS-Server in Forest "A" ist AD FS in der Lage, alle Benutzer aus beiden Forests zu authentifizieren und AD nach ihren Attributen abzufragen, indem es die zweiseitige Vertrauensstellung nutzt. Siehe Abbildung 1. Alle Benutzer können sich mithilfe des Verbunds bei den Verbundanwendungen anmelden.
Aber was ist, wenn die Benutzer in einem der Forests tatsächlich Partner- oder Kundenkonten sind und der Forest nicht vollständig vertrauenswürdig ist, so dass wir nur ein einseitiges Vertrauen haben? Wenn der AD FS-Server mit der Partner-Organisation verbunden ist, können sich die Partner-Benutzer bei der AD FS-Organisation authentifizieren und die AD FS-Organisation kann die AD der Partner nach deren Attributen abfragen. Außerdem können sich interne Benutzer aus der Mitarbeiter-Organisation über die einseitige Vertrauensstellung bei AD FS authentifizieren. Aber halt, wir haben ein Problem. In diesem Szenario kann AD FS die Mitarbeiter-Organisation nicht nach Benutzerattributen abfragen, da das Dienstkonto, unter dem AD FS in der Partner-Organisation ausgeführt wird, keine Berechtigung hat, AD in der Mitarbeiter-Organisation abzufragen. Die Authentifizierung funktioniert, aber AD FS kann keine zusätzlichen Informationen zum Auffüllen von Ansprüchen bereitstellen, sodass die Verbundanmeldung für die meisten Anwendungen fehlschlägt. Siehe Abbildung 2.
Sie denken vielleicht, dass die Antwort auf dieses Dilemma darin besteht, den AD FS-Server in der Mitarbeiter-Organisation zu platzieren, aber das bringt eine Reihe von Problemen mit sich. Die Platzierung des AD FS-Servers in der Mitarbeiter-Organisation würde es internen Benutzern aus der Mitarbeiter-Organisation ermöglichen, sich bei AD FS zu authentifizieren, und AD FS könnte die Mitarbeiter-Organisation nach Benutzerattributen abfragen, aber Benutzer aus der Partner-Organisation wären außen vor. Sie wären nicht in der Lage, sich beim AD FS zu authentifizieren, da die Richtung des Vertrauens bedeutet, dass die Anwendungen in der Mitarbeiter-Organisation den Benutzern aus der Partner-Organisation nicht vertrauen. Versuche, sich bei Verbundanwendungen für Partnerbenutzer anzumelden, würden fehlschlagen, bevor sie überhaupt begonnen haben.
Es gibt mindestens drei Möglichkeiten, dieses Dilemma zu lösen:
- Beschränken Sie sich darauf, nur bestimmte Attribute zu verwenden.
- Richten Sie für jeden Forest einen AD FS-Server ein.
- Stellen Sie den AD FS-Server in die Partnerstruktur, aber führen Sie ihn unter einem Konto in der Mitarbeiterstruktur aus.
Option 1 Beschränken Sie sich auf die Verwendung bestimmter Attribute
Es hat sich herausgestellt, dass Sie mit einem einseitigen Vertrauen tatsächlich einige Attribute für den Benutzer erhalten können. Solange Sie also nur versuchen, die Attribute zu verwenden, die in einem Szenario mit einseitigem Vertrauen bereitgestellt werden, können Sie ein einseitiges Vertrauen verwenden, um den Benutzer zu authentifizieren und die Verbundansprüche zu erstellen.
Zu den verfügbaren Attributen gehören:
- Name - in der Form DOMAIN\sAMAccountName
- Windows-Kontoname - in der Form DOMAIN\sAMA-Kontoname
- Primärgruppennummer - in Form einer Sicherheitskennung (SID) wie z. B. S-1-5-19
- Groupsid - eine Liste von Gruppen-SIDs, in denen der Benutzer Mitglied ist, zum Beispiel S-1-1-0, S-1-5-11
Option 2 Einrichten eines AD FS-Servers für jeden Forest
Aus Sicht der grundlegenden Funktionalität funktioniert Option 2 gut. Mit diesem Entwurf können sich Partnerbenutzer beim Partner-AD authentifizieren und das Partner-AD FS kann AD nach ihren Attributen abfragen; dasselbe gilt für Mitarbeiter und die Mitarbeiterstruktur. In diesem Fall ist jedoch nicht nur die doppelte Anzahl von AD FS-Servern erforderlich, sondern es tritt auch das Problem der Erkennung des Heimatbereichs zutage. Siehe Abbildung 3.
Der grundlegende Stolperstein bei dieser Option ist, dass, wenn ein Benutzer versucht, auf die interne Webanwendung 1 zuzugreifen (siehe Abbildung 3), diese Anwendung nicht weiß, ob sie den Benutzer zur Authentifizierung an den AD FS-Server für die Partner- oder Mitarbeiterforst schicken soll. Es gibt verschiedene Ansätze, um dieses Problem zu lösen, aber es kann ein sehr schwierig zu lösendes Problem sein. Standardmäßig fordert AD FS den Benutzer auf, auszuwählen, an welche Organisation oder welchen Bereich er gesendet werden soll (z. B. Mitarbeiter oder Partner). Siehe Abbildung 4.
Option 3 Stellen Sie den AD FS-Server in den Partnerwald, aber führen Sie ihn unter einem Konto im Mitarbeiterwald aus
Sehen wir uns nun Option 3 an: Der AD FS-Server befindet sich in der Partnerstruktur und arbeitet unter einem Dienstkonto der Mitarbeiterstruktur. Bei diesem Entwurf sind die Grundlagen abgedeckt. Benutzer aus der Partner-Organisation können sich bei der Partner-AD authentifizieren, und AD FS kann die Partner-AD nach den Attributen des Benutzers abfragen, da die einseitige AD-Vertrauensstellung es Benutzern aus der Mitarbeiter-Organisation ermöglicht, AD-Abfragen in der Partner-Organisation durchzuführen. Benutzer aus der Mitarbeiter-Organisation können sich beim Mitarbeiter-AD authentifizieren und AD FS kann das Mitarbeiter-AD nach den Attributen des Benutzers abfragen, da das Dienstkonto für AD FS ein Mitglied der Mitarbeiter-Organisation ist.
Da es in diesem Szenario nur einen AD FS-Server gibt, gibt es kein Problem bei der Erkennung des Heimatbereichs. Interne Anwendungen müssen die Benutzer nicht fragen, welcher AD FS-Server für ihre Authentifizierung verwendet werden soll, was die Benutzererfahrung vereinfacht. Und als zusätzlichen Bonus benötigen Sie nur halb so viele Server wie bei Option 2. Siehe Abbildung 5.
Damit Sie nicht denken, dass diese Option das Nonplusultra für alle unidirektionalen AD FS-Szenarien mit mehreren Forests ist, sollten Sie wissen, dass sie nicht funktioniert, wenn es mehr als zwei Forests gibt, die einander nicht vertrauen. AD FS kann nur als ein Dienstkonto ausgeführt werden, daher kann es nur eine nicht vertrauenswürdige Verbindung geben, damit diese Lösung funktioniert.
Zusammenfassung:
Wie aus der folgenden Tabelle hervorgeht, hat jede Option Vor- und Nachteile, so dass Sie diejenige wählen müssen, die Ihrer Situation am besten entspricht.
| Option | Waldstiftungen | Attribute | Startseite Realm Discovery Problem |
| 1 | Unterstützung mehrerer einseitiger Trusts | Begrenzt | Nein |
| 2 | Kein Vertrauen erforderlich | Alle | Ja |
| 3 | Ein einziges einseitiges Vertrauen unterstützt | Alle | Nein |
Referenzen:
- Ermöglichen Sie Ihren Active Directory-Benutzern den Zugriff auf Ihre anforderungsspezifischen Anwendungen und Dienste
https://technet.microsoft.com/en-us/library/dd807071%28WS.10%29.aspx
"Mitarbeiter mit Benutzerkonten irgendwo in Forests, denen dieser Forest vertraut (durch ein zweiseitiges Windows-Vertrauen)" - Active Directory-Verbunddienste (AD FS) 2.0
https://technet.microsoft.com/en-us/library/adfs2%28WS.10%29.aspx - HomeRealmDiscoveryPage Klassenübersicht
https://msdn.microsoft.com/en-us/library/ee895364.aspx
