Inside Microsoft.comVerwenden von Active Directory Federation Services

Jim Guthrie

Microsoft bietet ein Extranet, damit Geschäftspartner Zugriff auf wichtige interne Ressourcen erhalten. Die Architektur des Extranet erfordert, dass jeder Teilnehmer außerhalb des Unternehmens über ein einmaliges Domänenkonto für diesen Bereich verfügt. Dieses Konto wird nicht von den Partnern selbst, sondern von Microsoft-Mitarbeitern erstellt und verwaltet.

Die Gründe dafür liegen auf der Hand. Dies ist zwar praktisch, aber u. U. nicht sonderlich benutzerfreundlich. Außerdem ist die Verwaltung all dieser Partnerkonten für Microsoft ziemlich ressourcenintensiv.

So funktioniert das aktuelle Extranet: Wenn ein Kunde oder Partner sich für eine Sitzung anmeldet, muss er seine Anmeldeinformationen angeben. Wenn ein Benutzer während derselben Sitzung entscheidet, auf eine andere Ressource zuzugreifen, wird er erneut nach seinen Anmeldeinformationen gefragt. Dies setzt sich beim Wechsel von einer Ressource zur nächsten fort. Wenn der Benutzer sich bei einer einzelnen Anwendung anmeldet, die mehrere Ressourcen verwendet, z. B. eine Buchhaltungsdatenbank, muss er sich für jede Ressource gesondert authentifizieren. Für den Benutzer ist dies mühsam und lästig.

Glücklicherweise kann das Problem mehrfacher Authentifizierungen mithilfe der Active Directory® Federation Services (ADFS) relativ einfach gelöst werden. ADFS ist eine Windows Server® 2003 R2-Komponente, die Vertrauen zwischen zwei oder mehr Unternehmen schafft, um die gemeinsame Verwendung mehrerer Ressourcen zu ermöglichen. Dabei verwaltet jedes Unternehmen weiterhin seinen eigenen Satz an Benutzern. Dieser Artikel soll veranschaulichen, wie Microsoft in Zukunft ADFS zur Lösung des Problems mehrerer Ressourcen im Extranet einsetzt. Gleichzeitig erhalten Sie die für die Implementierung einer ähnlichen Lösung notwendigen Informationen. Bevor ich jedoch ins Detail gehe, sollten Sie sich mithilfe von Abbildung 1 mit der grundlegenden ADFS-Terminologie vertraut machen.

Figure 1 ADFS-Terminologie

Eine Lösung mit ADFS

Wenn ein Benutzer auf eine ADFS-fähige Anwendung zugreift, wird der Browser zur Bereichserkennung an Federation Service Resource (FS-R) geleitet. Hier wählt der Benutzer aus, welcher Satz Anmeldeinformationen für die Dauer der Sitzung verwendet werden soll. Basierend auf dem vom Kunden gewählten Bereich erfolgt eine Weiterleitung zum Federation Service Accounts (FS-A)-Server. Auf diesem Server wird ein gültiger Token (in Form eines Cookies) für das Konto ausgegeben, und zwar auf Grundlage der Anmeldeinformationen, die der Benutzer in Form einer Windows Live™ ID (zuvor ein Passport-Konto), einer Windows-integrierten Authentifizierung oder einer SSL-Authentifizierung eingegeben hat (siehe Abbildung 2). In diesem Modell müssen die einzelnen Unternehmen ihren eigenen Kontenverbundserver verwalten. Im Fall der Microsoft-Partnerserver ist Microsoft.com somit von der Aufgabe befreit, jedes Konto in der Umgebung zu verwalten. Wenn Sie diesen Grad an Verantwortung implementieren, müssen Sie die Verbundpartner natürlich sorgfältig aussuchen und sicherstellen, dass diese alle Kontoinformationen aktiv verwalten.

Abbildung 2** ADFS-Fluss **(Klicken Sie zum Vergrößern auf das Bild)

Der nächste Stopp auf der Route ist wieder der FS-R-Server, wo der Kontotoken gegen einen Ressourcentoken ausgetauscht wird. In unserer Konfiguration enthält dieser Token eine vollständige Liste der Berechtigungen, die dem Benutzer über einen auf dem FS-R durchgeführten Anspruchszuordnungsprozess gewährt wurden. Nach Empfang des Tokens erhält der Benutzer die einmalige Anmeldefunktion (SSO) auf ADFS-fähigen Anwendungen für die Dauer der Sitzung oder standardmäßig bis zu 24 Stunden (dieses Fenster ist konfigurierbar). Auf diese Weise aktivieren Sie SSO für diese ADFS-fähigen Anwendungen, was Benutzerfreundlichkeit und Sicherheit erhöht. Eine vollständige Beschreibung des ADFS-Authentifizierungsprozesses finden Sie in Matt Steeles Artikel der Juliausgabe 2006 des TechNet Magazins mit dem Titel Einfacheres einmaliges Anmelden mittels ADFS.

Um die Sicherheit von Microsoft-Unternehmensressourcen zu gewährleisten, haben wir den über das Internet bereitgestellten Bereich des Extranets von der Unternehmensseite getrennt, was bedeutet, dass jeder Server potenziell doppelt verwaltet wird. Wir gewähren internen Unternehmensbenutzern eine unidirektionale Vertrauensstellung und bieten über unsere Server den notwendigen Schutz. Außerdem verfügen wir über eine separate Domäne für den Extranetbereich, in dem wir externen Benutzern Zugriff auf die erforderlichen Ressourcen bieten.

Zwei wichtige Bereiche, die es während der Implementierung zu berücksichtigen galt, waren der Lastenausgleich und die ADFS-Richtliniendateiänderungen. Der Lastenausgleich war eine Herausforderung sowohl auf globaler als auch auf lokaler Ebene. Zunächst wird in der Produktion für zwei Bereiche der Front-End-Webservercluster der globale Lastenausgleich von unseren Content Delivery Network (CDN)-Partnern Akamai oder Savvis verwendet. Dies stellt die Verfügbarkeit des Systems für Endbenutzer selbst für den unwahrscheinlichen Fall sicher, dass ein regionales Serverpaar offline geht. Erreicht wird dies über Failover-Automatisierung basierend auf Server-Systemdiagnosediensten des CDN. Weiterhin können wir in Zukunft auf einfache Weise mehr Cluster hinzufügen. Aus Kostengründen haben sich unsere Präproduktions-Bereitstellungsteams gegen eine Verwendung des CDN-Diensts entschieden.

Auf regionaler Ebene haben wir die Server für lokales Failover über Netzwerklastenausgleich (NLB)-Clustering paarweise zusammengestellt. Dabei werden keine besonderen Lastenausgleichsfunktionen eingesetzt, also hätte dies ebenso gut mit Hardware erreicht werden können. Zur Kostenersparnis wird jedoch wiederum NLB verwendet. Diese Konfiguration bietet die Stabilität, um eine Betriebszeit von mehr als 99,9 Prozent in allen unterstützten Umgebungen sicherzustellen.

Als weitere Herausforderung musste sichergestellt werden, dass die ADFS-Richtliniendatei, das Rückgrat von ADFS, korrekt über die Umgebung hinweg verteilt war und dass Änderungen daran ebenso repliziert wurden. Zu diesem Zweck wurde eine weitere integrierte Funktion von Windows Server 2003 R2 eingesetzt, nämlich die Verteilte Dateisystemreplikation (Distributed File System Replication, DFS-R), ein neues statusbasiertes Multimasterreplikationsmodul. Auf jedem der Back-End-Server wurde eine DFS-R-Gruppenmitgliedschaft mit einer vollständigen 24-Stunden-Replikation aktiviert. Eine Änderung an der Richtliniendatei wird nun an alle Server verteilt, unhängig davon, wo sie vorgenommen wird. Solange überwacht wird, wer die Datei ändern kann, liegt jetzt ein stabiler, hochgradig verfügbarer Dienst vor.

Alle Änderungen sollten über das ADFS-Snap-In vorgenommen werden. In der Praxis haben wir jedoch festgestellt, dass diese Datei gelegentlich manuell aktualisiert werden muss. Bei der manuellen Aktualisierung muss beachtet werden, dass ADFS die Version dieser Datei nachverfolgt. Daher müssen Sie der Datei eine erhöhte Priorität zuweisen, sodass die Änderungen in der Umgebung berücksichtigt werden:

<TrustPolicyEntryUri>urn:federation:parttestint</TrustPolicyEntryUri> 
<TrustPolicyVersion>127
</TrustPolicyVersion> 

Außerdem muss beachtet werden, dass die Richtlinien-XML-Datei (wie alle XMLs) zwischen Groß- und Kleinschreibung unterscheidet. In der Richtlinien-XML-Datei gibt es zahlreiche Verweise auf Anwendungen oder sonstige ADFS-Server, und diese müssen alle genau von Server zu Server kopiert werden. Bei den folgenden allgemeinen Beispielen wurde das erste, RevocationCheckFlags, manuell eingegeben. Das zweite ist eine vertrauenswürdige, aus der Benutzeroberfläche geänderte Anwendungs-URL:

<RevocationCheckFlags>None
</RevocationCheckFlags>
<TrustPolicyEntryUri>https://adfstest.parttest.extranettest.microsoft.com/NTApp/
</TrustPolicyEntryUri>

Zur zusätzlichen Sicherheit wird eine weitere Komponente von ADFS, der Verbunddienstproxy (Federation Service Proxy, FS-P) eingesetzt, der sicherstellt, dass die FS-Rs eine Ebene vom direkten Zugriff eingehender Internetanforderungen entfernt bleiben. Eine einmalige Methode, mit der Proxys bei Microsoft.com bereitgestellt wurden, ist die Verwendung eines einzelnen Satzes von Proxys zum Hosten mehrerer ADFS-Umgebungen im Präproduktionsbereich. Interessanterweise haben wir während der anfänglichen Technologieauswahl festgestellt, dass hierfür eine einfache Registrierungsschlüsseländerung durchgeführt werden musste. Der Schlüssel befindet sich unter HKLM\Software\Microsoft\WebSSO. Eine einfache Änderung des Werts des anfänglichen Verzeichnisses in diesem Schlüssel ermöglicht die Verwendung des Proxys für mehrere Umgebungen. Der Standard war:

[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\WebSSO]
“InitialDirectory”=”E:\\\\ADFS\\\\parttestint”

Zum Wechseln von Umgebungen änderte sich der Schlüssel folgendermaßen:

[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\WebSSO]
“InitialDirectory”=”E:\\\\ADFS\\\\parttest”

Die Erstellung einer Batchdatei kann die Verwaltung dieses Prozesses vereinfachen. Leider unterstützt die aktuelle Version des MMC-Snap-In für ADFS nicht das Umschalten zwischen Umgebungen, da eine Eins-zu-Eins-Beziehung zwischen dem Proxy und der Ressource oder dem Kontoserver vorhanden ist. Dies ist die einzige Möglichkeit, die Verwendung der Proxyserver zu maximieren. Das Endergebnis ist eine erhebliche Kosteneinsparung, da die Anzahl erforderlicher physischer Server eingeschränkt wird, und zwar unabhängig davon, wie viele unterschiedliche Umgebungen gehostet werden sollen.

Im Hinblick auf die Architektur wird die Präproduktionsumgebung mit virtuellen Computern ausgeführt, eine weitere Kostenersparnis. Es besteht also keine Notwendigkeit mehr, sechs zusätzliche Server zu erwerben und zu unterhalten. Bis heute waren dabei keinerlei Leistungsprobleme zu verzeichnen. Um jedoch der erheblich höheren Nachfrage in einer Produktionsumgebung gerecht zu werden, haben wir uns entschlossen, leistungsstärkere physische Computer einzusetzen.

Nicht nur für Active Directory

Microsoft.com verwendet nicht nur Active Directory-Konten für die Authentifizierung, sondern hat auch Windows Live ID-Konten erfolgreich integriert. Durch den Einsatz von Windows Live ID (WLID) 4.5 wurde offensichtlich, dass das Windows Live ID-Konto eines Benutzers für eine Zugriffsdelegation auf Microsoft-Ressourcen verwendet werden kann. Dies erfolgt mithilfe einer benutzerdefinierten Anspruchstransformation. So wird die SSO-Authentifizierung entscheidend vereinfacht, da kein Domänenkonto mehr erforderlich ist.

Weitere Herausforderungen

Die derzeit größte Herausforderung für Microsoft ist die Verwaltung von ADFS für die gemeinsame Nutzung von Tokensignaturzertifikaten. Wir verwenden Standardzertifikate, die normalerweise ein Jahr gültig sind und dann erneuert werden müssen. Zum Zeitpunkt der Erneuerung müssen die jeweiligen Server entsprechend aktualisiert werden, was sich erheblich auf die FS-Rs auswirkt. Eine begrenzte Verwaltung mit 15 oder 20 Verbundpartnern liegt zwar im Rahmen des Möglichen, aber Microsoft hat potenziell Hunderte, wenn nicht Tausende von Partnern. Für die Verwaltung von SSL-Zertifikaten für eine einzelne Umgebung müsste also Vollzeitpersonal abgestellt werden. Zurzeit beschäftigen sich mehrere Teams mit den besten Methoden zur Automatisierung dieser Lösung. Wir haben uns jedoch noch nicht für eine bestimmte Vorgehensweise entschieden.

Eine weitere Herausforderung ist, dass nicht alle Anwendungen automatisch ADFS-fähig sind. Um ADFS richtig zu nutzen, werden daher Programmierarbeiten für die Sites erforderlich sein. Wir arbeiten eng mit dem Microsoft® Office SharePoint® Services-Team zusammen, damit die nächste Generation von SharePoint eine Implementierung für ADFS unterstützt.

Schlussbemerkung

Es gibt eine Reihe von Faktoren, die bei einer Entscheidung für ein ADFS-Modell berücksichtigt werden müssen. Ein Faktor dabei ist die Anzahl der Ressourcen, auf die Kunden zugreifen werden. Das Aufstellen, Überprüfen und Ausführen akzeptabler Vertrauensrichtlinien innerhalb eines Unternehmensverbunds kann eine banale Aufgabe sein, nimmt jedoch Zeit und Energie in Anspruch. Wenn Ihre Kunden also nur auf eine Ressource zugreifen, lohnt sich der Aufwand u. U. nicht. Mit steigender Anzahl von Ressourcen erhöhen sich jedoch die Vorteile.

Weitere Informationen finden Sie in der ADFS-Übersicht und unter Active Directory Federation Services: Möglichkeiten für Verbundidentität und Zugriffsverwaltung.

Jim Guthriearbeitet im Microsoft.com Operations-Team. Zusätzlich zu seiner Arbeit für ADFS ist er Systems Engineer beim Enterprise Portal Platform Support-Team.

© 2008 Microsoft Corporation und CMP Media, LLC. Alle Rechte vorbehalten. Die nicht genehmigte teilweise oder vollständige Vervielfältigung ist nicht zulässig.