Als ich begann, mich mit Entra ID (damals noch Azure AD) auseinanderzusetzen, war meine größte Herausforderung – neben den scheinbar endlosen Umbenennungen der Produkte in M365/Azure – dass „SSO“ (= Single Sign-On) fast schon ein Buzzword geworden ist.
Wenn man gerade auf der Suche nach Möglichkeiten ist, die Anmeldung zu vereinheitlichen und Benutzer seltener für Logins in der Arbeit zu unterbrechen, wird man mit grundverschiedenen Technologien bombardiert, die auf den ersten Blick schwer auseinanderzuhalten sind. Deshalb habe ich es mir zur Aufgabe gemacht, alle Kernkonzepte zu sammeln und darzustellen, wann man sie benötigt.
Von hier aus kann man dann weiter in die Dokumentation und andere Artikel eintauchen, was umzusetzen ist, welche Details man beachten muss, usw.
Meine Definition von SSO umfasst nicht nur die Nutzung derselben Benutzerinformationen, sondern vielmehr, dass sich ein Benutzer nur einmal anmelden muss und anschließend ohne weitere Interaktionen Zugang zu anderen Applikationen erhält
Ebenfalls außerhalb des Umfangs: Virtual Desktop Infrastructure (VDI), da die Möglichkeiten herstellerabhängig stark variieren. So unterstützen beispielsweise Azure Virtual Desktop und Windows 365 Entra ID SSO, bei Citrix ist eine Lösung auf der Roadmap.
Wenn ich mich einmal in Entra ID angemeldet habe, muss mein Endgerät die Möglichkeit haben, diesen Login an andere Applikationen weiterzugeben. Unter Windows ist dies direkt im Betriebssystem eingebaut. Hoffentlich wenig überraschend haben aber andere Hersteller nicht unbedingt Interesse daran, von Haus aus Microsoft-Mechanismen zu unterstützen.
Der Login nimmt technisch in der Regel die Form eines PRTs (Primary) Refresh Token, Access Token von Jonas Bøgvad, oder aus der Windows Praxis von Frank Carius.
Die Entra ID Authentifizierung basiert auf Webprotokollen, wobei die Sitzungsinformationen im Webbrowser gespeichert werden. Ohne einen gemeinsamen Browser zu nutzen, ist kein SSO zwischen verschiedenen Anwendungen möglich. Idealerweise sollten also Apps den Standardbrowser des Betriebssystems verwenden, dies ist jedoch oft nicht der Fall.
Um dieses Problem zu lösen, können das Intune Company Portal und der Microsoft Authenticator als „Broker-Apps“, oder auch Vermittler, dienen. Sie speichern die aktuellen Anmeldesitzungen eines Benutzers und ermöglichen es, diese zwischen Applikationen zu teilen. Leider sind diese Funktionen nicht Teil des Betriebssystems selbst, weshalb Applikationen in der Lage sein müssen, mit diesen Brokern zu kommunizieren. Dies wird in der Regel mit der Microsoft Authentication Library (MSAL) verwirklicht. MSAL erleichtert Entwicklern die Implementierung von Authentifizierungsprotokollen und integriert standardmäßig auch Broker-Applikationen von Microsoft.
Weiteres Lesematerial
Was für Android gilt, trifft ebenfalls auf macOS und iOS zu – mit dem kleinen Unterschied, dass auf iOS ausschließlich der Microsoft Authenticator als Broker fungieren kann, während auf macOS das Intune Company Portal diese Rolle exklusiv übernimmt.
Zusätzlich kann der Broker direkt in das Betriebssystem integriert werden – Apple bietet in seinen Betriebssystemen das sogenannte “Authentication Service Framework”, in das der Microsoft Broker-Dienst als Plug-In eingebunden werden kann. Durch entsprechende Konfigurationen können auch Authentifizierungsprozesse von Apps, die nicht die MSAL nutzen, an die Broker weitergeleitet und somit der SSO erweitert werden.Unter macOS beinhaltet dies Login am Endgerät mit Platform SSO, ähnlich wie Hello for Business unter Windows.
Ich hatte eingangs erwähnt, dass die SSO-Mechanismen unter Windows direkt ins Betriebssystem integriert sind. Allerdings erfolgt das nicht ganz eigenständig, und genau hier liegt auch die größte Falle hinsichtlich der Verständlichkeit.
Seamless SSO umfasst zwei Aspekte: Einerseits bezeichnet Microsoft damit den Authentifizierungsmechanismus für Geräte, die ausschließlich Entra ID beigetreten sind und auf Ressourcen in „traditionellen“ Active Directory-Domänen zugreifen. Gleichzeitig deckt es den umgekehrten Fall ab: den Login von Clients, die nur in „traditionellen“ Active Directory-Domänen registriert sind, zu Entra ID geschützten Ressourcen oder Applikationen.
Der Einsatz von Seamless SSO an Entra ID ist besonders wichtig zu Beginn der Transformation einer Organisation in Richtung hybrider Infrastruktur, oder wenn Terminalserver in einer Umgebung vorhanden sind. So können bereits frühzeitig die Vorteile einer Anbindung an Entra ID zumindest teilweise genutzt werden. Dazu wird ein Computerkonto in die On-Premises Domäne integriert, das Kerberos-Tickets für Entra ID ausstellt. Es muss jedoch klar sein, dass nie MFA in diesem SSO enthalten sein kann, da Kerberos standardmäßig kein MFA im Protokoll unterstützt. Man bleibt also in der Regel auf IP- oder Geräteausnahmen bei MFA sitzen.
Beim Seamless SSO zu On-Premises bzw. Active Directory-Ressourcen übernimmt Windows selbst den Großteil der Arbeit. Wenn ein Login aus einer Domäne angefordert wird, die als mit Entra ID synchronisiert erkannt wird, kann Windows das Passwort und den synchronisierten On-Premises-Benutzernamen präsentieren, ohne erneute Benutzerinteraktion. Wer mitgedacht hat wird sich vielleicht Fragen: Was wenn Windows mein Kennwort aktuell nicht gespeichert hat? Hat der Benutzer beim Windows Login kein Passwort eingegeben (z.B. weil er Hello for Business nutzt) stellt Entra ID mit entsprechender Konfiguration ein Kerberos-Ticket aus, das On-Premises genutzt werden kann.
In beiden Szenarien spielt der Entra Connect Sync eine zentrale Rolle: Die zwei Seiten müssen wissen, welche Objekte in Entra ID und dem Active Directory zusammengehören. Zusätzlich werden über die Connector PowerShell Cmdlets die Active Directory-Objekte und zugehörige Secrets verwaltet, die im Authentifizierungsprozess genutzt werden. Es ist auch unumgänglich, dass Verbindung mit dem Active Directory möglich ist – man ist also doch leider von einem VPN abhängig.
Unser Client hat nun Zugriff auf einen geteilten Login – jetzt benötigen wir noch Abnehmer der Authentifizierung. Einige Aspekte haben wir bereits bei Android und iOS angerissen – z.B. die Microsoft Authentication Library (MSAL), wenn die App primär auf dem Endgerät läuft. Doch wie steht es um Infrastrukturkomponenten und server- bzw. webbasierte Applikationen? Natürlich ist eine Grundvoraussetzung, dass die Applikation nicht ausschließlich Authentifizierung mit Benutzername und Kennwort aus der eigenen Datenbank unterstützt. Solche Apps werden in der Regel entweder veraltet sein oder ihre Entwicklung lässt zu wünschen übrig (Apps, bei denen SSO ein kostenpflichtiges Feature ist mal ausgenommen) und es sollte überlegt werden, sie abzulösen.
Die derzeitigen Goldstandards der webbasierten Authentifizierung sind SAML und OIDC. SAML ist, vermutlich aufgrund seines Alters, am weitesten verbreitet. OIDC baut aber immer weiter Fahrt auf – vor allem wegen laufender Weiterentwicklung und der Vorteile einer tokenbasierten Authentifizierung. Beide Standards werden natürlich auch von Entra ID unterstützt.
Als vollständig offene Standards ist es sehr wahrscheinlich, dass die eine oder andere Software in ihrem Arsenal bereits eines der Protokolle unterstützt und überhaupt nicht den Benutzer unterbrechen müsste, um seine Identität und Zugriffsrechte zu ermitteln. Nicht nur die Nutzererfahrung kann so verbessert werden; oftmals ermöglicht der Einsatz eines Identity Providers wie Entra ID auch, dass innerhalb der Applikation keine Anwenderinformationen oder Berechtigungen verwaltet werden müssen. Somit kann auch Administratoren das Leben erleichtert werden.
Prüfen Sie also noch heute, ob Ihre Applikation vielleicht sogar bereits im Entra ID Katalog vorhanden ist. Nicht alle Applikationen, die SAML und OIDC unterstützen, sind hier aufgeführt. Entra ID spezifische Anleitungen und Vorkonfigurationen vereinfachen aber die Implementierung.
Ist die Applikation zu alt für moderne Protokolle, ist noch nicht alle Hoffnung verloren – auch die gängigsten “Legacy“-Authentifizierungsmethoden können angebunden werden. Ein vorgeschalteter Dienst kann die alten Protokolle, die nicht für das Internet geeignet sind, in moderne Mechanismen übersetzen. So können mit dem Entra ID Hausmittel “Application Proxy” Authentifizierungen über HTTP Header, SAML, Kerberos (= Integrated Windows Authentication) und passwortbasierter Applikationen übermittelt werden.
Wichtig ist, dass die Microsoft Lösung Anfragen aus Entra ID abholt, und nie direkt im Internet erreichbar ist.
Die gleiche technische Komponente wird auch von Microsofts neuer Lösung “Entra Private Access” genutzt. Diese soll in Zukunft auch UDP und beliebige TCP Verbindungen unterstützten – zusätzlich zu erweiterten Steuerungsmöglichkeiten. Ob Microsoft die Strategie verfolgen wird, das „kostenlose Sample“ „Application Proxy“ irgendwann einzustellen, bleibt abzuwarten.
Die Rolle des Übersetzers können auch 3rd Party Proxy-Systemen wie F5 BIG-IP oder Citrix NetScaler übernehmen, um mehr Kontrolle über Traffic und Performance zu wahren.
Auch bereits bestehende Identity Provider (IdPs) lassen sich anbinden – die meisten IdPs können die Rolle des Relying Party bzw. Service Provider übernehmen – sie fungieren also effektiv wie eine an Entra ID angebundene Applikation. Je nach Konfiguration und IdP können so relativ nahtlos SSO-Sitzungen an Systeme übertragen werden, die vielleicht nicht direkt mit Entra ID verknüpft sind.
Häufig ist man sich gar nicht bewusst, dass man einen anderen IdP im Einsatz hat – Middleware-Lösungen wie SiteMinder, die vor einem Webserver installiert werden, um Authentifizierung zu zentralisieren, können auch als IdPs gesehen werden. Durch deren Anbindung können also durch Microsoft optimierte Login-Prozesse auf weitere Systeme ausgedehnt werden.
Oftmals bringen Applikationen zudem auch ihren eigenen IdP mit. Shibboleth und KeyCloak werden gerne genutzt, um dieselbe Funktion wie die MSAL zu erfüllen – ein separater Provider, der Authentifizierung übernimmt, damit Entwickler es nicht selbst implementieren müssen.
Entra ID kann auch als die abnehmende Komponente konfiguriert werden – die Authentifizierung erfolgt über einen anderen IdP, dem Entra ID dann vertraut – hier spricht Microsoft von “Federation“. In dieser Konstellation gehen aber oftmals Vorteile von Entra ID Authentifizierung verloren, vorzugsweise geht mal also die andere Richtung.
SiteMinder: Neuen SAML IdP hinzufügen
Langfristig: Applikationen unmittelbar zu Entra Auth migrieren
In der Regel besser von den 3rd Party IdPs Dokumentiert
Brian Reid: Beispielhafte Herausforderung bei der Nutzung anderer IdP: Conditional Access
Wir sehen, dass eine Vielzahl von Technologien und Konfigurationen auf dem Weg zum SSO beachtet und genutzt werden müssen. Jede birgt ihre eigenen Tücken und Feinheiten, die jeweils eigene Artikel füllen könnten – aber hiermit kennen wir zumindest die Wege, auf die wir uns begeben können.
Ich hoffe, ich konnte dem einen oder anderen Leser eine Idee vermitteln, wie das Anwendererlebnis verbessert werden kann oder ein wenig Orientierung für die erste Wanderung liefern
Sollten Sie einen Sherpa auf ihrem Pfad zum ultimativen Single Sign-On benötigen, sind wir nur eine Email entfernt.
Ihr persönlicher Ansprechpartner
Bei welchem Projekt oder welcher Herausforderung dürfen wir Sie unterstützen? Wir sind gerne für Sie da.
MICHAEL WILDGRUBER | Team Lead Digital Workplace – Cloud Productivity
