AD Connect oder ADFS? Eine Designüberlegung

Spätestens in der erweiterten Testphase und allerspätestens dann, wenn man seinen Endbenutzern nicht zumuten möchte, sich zwei verschiedene Logins merken zu müssen, steht eine Entscheidung an. Technisch ist die Benutzerverwaltung im Office 365 über das Azure AD gelöst, welches grundsätzlich nichts mit dem normal On-Prem Active Directory zu tun hat.

Der Administrator steht nun also vor der Wahl: Synchronisierung der Benutzeraccount mittels AD Connect — oder Bereitstellung einer eigenen Anmelde-Infrastruktur via ADFS. Beide Varianten haben sicher Vor- und Nachteile. Ich möchte in diesem Artikel beide Seiten aufzeigen und hoffe, dass somit die eigene Entscheidung leichter fällt. Es gibt nämlich keine allgemeingültige Aussage für oder gegen eine der beiden Lösungen.

AD Connect

Das Tool (auch bekannt als DirSync) synchronisiert mein gesamtes Active Directory (eine oder mehrere Domains, auswählbar). Selbstverständlich kann ich über diverse Filtermöglichkeiten die Gesamtmenge einschränken und somit kontrolliert nur bestimmte Benutzer synchronisieren. Die Filtermechanismen sind mittlerweile sehr vielfältig - von einer einfachen Sicherheitsgruppe bis hin zu komplexen Regeln im Sync-Flow durch Manipulation des Connectors ist (fast) alles möglich und ich kenne niemanden, der seine Anforderungen nicht umsetzen konnte.

Wie bereits geschrieben reden wir über eine reine Synchronisierung, d.h. die Benutzer sind sowohl im lokalen Active Directory (welches immer das führende System bleiben sollte) als auch im Azure AD (Office 365) vorhanden. Zwar sind diese über den AD Connect miteinander verbunden, jedoch existieren die Benutzer zunächst einmal komplett unabhängig voneinander. Ich erhalte also eine eigenständige Kopie meiner Benutzeraccounts mit synchronisierten Attributen.

Bezüglich der Kennwortsynchronisierung (vom lokalen AD ins Azure AD) scheiden sich die Geister. Das ist m.E. der größte Knackpunkt am AD Connect, denn es gibt kein richtiges Single Sign-On (SSO). Laut Aussage von Microsoft werden die Kennwörter lokal aus dem AD augelesen, gehashed und nur der Hash-Wert wird in die Cloud übertragen. Bei der Eingabe eines Passwortes im Browser wird der Hashwert der Eingabe gegen den im Azure AD gespeicherten Hashwert geprüft und die Anmeldung durchgeführt. Da wir von zwei verschiedenen Entitäten reden (zur Erinnerung: im Azure AD liegt nur eine Kopie des AD-Benutzers) existiert kein Token o.ä., der ein Single Sign-On-Erlebnis ermöglichen könnte.

Zusammengefasst ist das AD Connect schon ein gutes Tool für den Anfang mit geringem Einrichtungsaufwand. Einzige Voraussetzungen: gut gepflegtes AD, UPN-Suffix entspricht der im Office 365 hinzugefügten Domain, Port 443 für die Kommunikation freigeschaltet, Member-Server und Service-User und ab geht’s. Alle Voraussetzungen im Detail gibt es bei Microsoft (Link).

AD FS (Federation Services)

Nun also zum „großen Bruder“ mit echtem Single Sign-On. Mit ADFS wird eure Domain mit Microsoft „federated“. Das führt dazu, dass der Benutzer, der sich anmelden möchte, sich nicht am Azure AD authentifiziert (wie beim AD Connect), sondern umgeleitet wird auf eine Anmeldeseite, die bei Euch im Rechenzentrum auf einem ADFS-Server bereitgestellt wird. Damit dies funktioniert, muss der Benutzer-Account aber trotzdem im Azure AD vorhanden sein — allerdings kann dann die Kennwortübertragung deaktiviert werden.

Ein klassischen Konstrukt im eigenen Rechenzentrum sieht dann so aus: zwei WAP-Server (ADFS-Proxy), die in der DMZ installiert und von außen erreichbar sind. Diese fungieren als Vermittler zwischen dem Internet/Microsoft und dem internen Netz. Denn im lokalen Netzwerk stehen zwei ADFS-Server, die den Service an sich bereitstellen und auf Anfragen von intern und extern antworten.

Über dieses Konstrukt lässt sich nun tatsächlich ein Single Sign-On realisieren, da der ADFS-Service ja direkt mit dem lokalen AD verbunden ist. Es wird also unterschieden, ob ein Benutzer sich innerhalb des lokalen Netzwerkes befindet oder außerhalb — und danach richtet sich auch die Art der Anmeldung. Ein klassischer Benutzer, der an einem PC im lokalen Netzwerk arbeitet und am PC mit seinem Domänenaccount angemeldet ist, wird sich bestenfalls während seiner Tour durch’s Office 365-Universum nicht ein einziges Mal anmelden müssen. Durch die Anmeldung an der Domäne ist er auf seinem PC mit einem Token unterwegs, der über den ADFS-Dienst einfach an Office 365 weitergereicht wird.

Meldet sich dieser Benutzer aus dem HomeOffice und somit aus dem Internet heraus an, muss er selbstverständlich sein Passwort eingeben. Allerdings auch hier nicht, um sich am Azure AD zu authentifizieren, sondern auf einer Anmeldeseite, die im Unternehmens-RZ bereitgestellt wird. Sämtliche Kennwörter bleiben also lokal.

ADFS ist somit generell eine gute Sache, wenn man seinen Benutzern einen schlanken Anmeldeprozess bereitstellen möchte. Allerdings ist der Aufwand nicht zu unterschätzen: neben der Bereitstellung der Infrastruktur ist auch der Einrichtungsaufwand deutlich größer im Vergleich zum AD Connect. Ebenso schafft man sich einen Single Point of Failure: wenn Microsoft die ADFS-Struktur im Unternehmens-RZ nicht erreichen kann (z.B. wenn die WAN-Anbindung gestört ist), dann kann sich kein Benutzer mehr am Office 365 anmelden.

 

Ich empfehle, mit einer AD Connect-Installation zu starten und ADFS zunächst nicht zu implementieren. ADFS benötigt eine einwandfreie AD-Connect-Installation, insofern ist dies keine unnötige Arbeit. Sollte sich herausstellen, dass man auch ohne ADFS auskommt, dann hat man sich eine Menge Arbeit gespart. Falls ein SSO-Erlebnis allerdings Voraussetzung ist, kann man eine ADFS-Instanz immer noch "drüberlegen".

 


Print