Aufgabe der Active Directory Verbunddienste (AD Federation Services, ADFS) ist es, mittels einer Verbundvertrauensstellung Zugriff auf eine andere Umgebung herzustellen. Häufiges Szenario ist Office 365, aber auch andere Zielumgebungen oder Anwendungen sind gängig: SharePoint, Salesforce oder Google, um nur ein paar zu nennen. Wichtig dabei ist, dass beide Seiten sich kennen. Dies wird beim Einrichten der Vertrauensstellung über Zertifikate sichergestellt. Im heimischen Active Directory sorgt dann der ADFS-Server dafür, dass für den Anwender, der auf den angebundenen Dienst zugreifen möchte, ein SAML-Token bereitgestellt wird, das zum Zugriff auf der Gegenseite dient. Meist kommt noch ein WAP-Server (Web Application Proxy, deutsch: Webanwendungsproxy) in der DMZ ins Spiel, der seinen ADFS-Server im benachbarten Active Directory kennt und Zugriffe aus dem Internet regelt.
Für den Endanwender bedeutet dies, dass er sich mit seiner gewohnten Benutzerkennung beim Zugriff auf den anderen Dienst nicht erneut durch Passworteingabe anmelden muss. Der so erworbene Single Sign-on ist für den Anwender transparent und bequem. Im Hintergrund sind aber eine Menge Elemente für einen reibungslosen Ablauf verantwortlich. Dies ruft vielschichtige Fehlerquellen hervor und verlangt vom Administrator eine ausgefeilte Überwachung auf verschiedenen Ebenen. Denn stellt der ADFS-Server aus irgendeinem Grund keine Token mehr aus, ist schlagartig kein Zugriff mehr möglich. Für Office 365 bedeutet dies beispielsweise, dass kein Benutzer mit Outlook mehr auf sein Postfach zugreifen kann. Auch fällt die Telefonie aus, wenn Sie Skype for Business aus dem Office-365-Portfolio einsetzen.
ADFS basiert auf unterschiedlichen Abhängigkeiten. Da ist zum einen das Active Directory mit dem Dienstkonto, in dessen Kontext ADFS läuft. Zwar besitzt es keine weitreichenden Rechte, aber wenn
...Der komplette Artikel ist nur für Abonnenten des ADMIN Archiv-Abos verfügbar.