Active Directory Federation Services (ADFS)

Im Enterprise Umfeld ist es heute weit verbreitet, ADFS zur Authentisierung von On-Premises Identities mit Office 365 zu nutzen. Dadurch erhalten die Benutzer ein wahres «Single Sign On» Erlebnis bei welchem Office 365 Anwendungen im Webbrowser ohne zusätzliches Login geöffnet und genutzt werden können. Authentisierung und Authorisierung geschehen dabei auf dem lokalen Active Directory – die IT hat volle Kontrolle.

ADFS hat zusäztlich den Vorteil, dass es nicht nur für die Microsoft Plattformen wie Office 365 und Azure, sondern mit On-Premises Webanwendungen und mit anderen Cloud Services verwendet werden kann, welche WS-Fed, SAML oder Oauth zur Authentisierung verwenden. Beispiele sind Google G-Suite, Workplace by Facebook, Atlassian Jira und Confluence, DropBox Business, Service Now etc.

Microsoft Passthrough authentication (PTA)

Seit der zweiten Hälfte 2018 bietet Microsoft Passthrough authentication (PTA) an. Der Service wurde 2017 an der Ignite angekündigt und war bis vor kurzem als Preview verfügbar. Durch PTA wird es möglich, dass ein Identity nicht in der Cloud wie mit Azure AD-Connect, sondern via On-Premises Infrastruktur authentisiert wird.

PTA funktioniert wie folgt: Ein Benutzer meldet sich via Webbrowser an Office 365 an. Die Credentials werden über das Login Fenster erfasst und dann in eine Queue in der Cloud gestellt. Der lokal installierte PTA Service fragt via HTTP Outbound die Queue ab und validiert die Credential.

Für PTA muss neben Azure AD-Connect für die Synchronisation der Identities, nur ein oder mehrere PTA-Agents im lokalen Netzwerk installiert werden, welcher via HTTP ins Internet kommunizieren kann. Das klingt erstmals verlockend einfach. Um PTA für die hohe Benutzeranzahl und Verfügbarkeit zu skalieren, werden einfach zusätzliche Agents installiert z.B. direkt auf dem Domain Controller. Die Leistungsfähigkeit von PTA ist aber begrenzt, da jede individuelle Authentisierungsanfrage an die Queue eine Latenz verursacht, was bei ADFS nicht der Fall ist. Insbesondere bei «Chatty Applications» wird die Latenz wahrgenommen.

Seamless Single-Sign-On

Alleine mit PTA kommt der Benutzer schon mal in den Genuss, dass er nur ein Login für sein Arbeitsgerät und für Office 365 benötigt. Eine ware Single-Sign-On Experience hat er dadurch aber noch nicht. Öffnet ein Benutzer Office 365 im Webbrowser, dann muss er sein Login (Benutzername und Passwort) eingeben. Das liegt daran, dass der Browser die Credentials nicht automatisch zwischen den Systemen hin- und her sendet. Hier bietet Microsoft eine weitere Lösung «Seamless Single Sign-On». Damit wird es möglich, dass Benutzer von Domain-Joined Devices ohne zusätzliches Login via Webbrowser auf Office 365 zugreifen können. Damit dieser Service auf dem Endgeräte funktioniert muss lediglich eine GPO erstellt werden, welche auf dem Office 365 Endpoint zwei Azure AD Urls in den Internet Zone Settings konfiguriert à https://autologon.microsoftazuread-sso.com und https://aadg.windows.net.nsatc.net

PTA hat weitere Einschränkungen:

Was empfiehlt AskMeWhy seinen Kunden?

Der Hauptvorteil von Passthrough Authentication und «Seamless Single-Sign-On» gegenüber ADFS liegt in der Einfachheit. Andererseits liegt der grösste Nachteil darin, dass PTA nur Microsoft Cloud Service unterstütz. Da es bei Enterprise Unternehmen oft wahrscheinlich ist, dass neben Office 365 andere interne Webapplikationen oder andere populäre Cloud Services mit Single-Sing-On angeboten werden sollen, empfehlen wir ADFS.

Falls Sie Fragen zu Identitymanagment für Office 365 und Azure, ADFS, ADDS, Azure AD, AD-Connect, Passthrough, Seamless Single-Sign-On oder ähnlichem haben, stehe ich Ihnen gerne zur Verfügung. Simon Feldkamp, 079 503 42 60, simon@askmewhy.com oder via Skype und MS Teams