SSO - Single, Same, Seamless
Wer auf nicht öffentlichen Informationen zugreift, sollte sich immer authentifizieren. Da niemand bei jedem Zugriff immer wieder Zugangsdaten eingeben will, was ja auch eine Angriffsmöglichkeit darstellt und hinderlich bei der täglichen Arbeit ist, müssen wir uns überlegen, dies besser zu lösen. Was ist aber der Unterschied zwischen Single SignOn, SameSignOn und Seamless SignOn.
Gegenüberstellung
Ich unterscheide drei Varianten:
| Modell | Beschreibung |
|
|---|---|---|
Same SignOn
|
Können Sie sich noch an die Zeiten erinnern, wenn Sie auf
mehreren Servern immer lokal eigene Benutzer angelegt haben?.
Das ist für Windows Administratoren schon seit der NT4-Domain
eigentlich Geschichte aber ich erlebe es immer wieder, dass es
Server oder Applikationen gibt, die eine eigene
Benutzerverwaltung haben. |
|
Single SignOn
|
Sobald mehrere Dienste aber ihre Identitätsverwaltung an ein anderes System abgeben und auch die Authentifizierung über dieses System erfolgt, können wir von einem "Single SignOn" sprechen. Der Anwender meldet sich an verschiedenen Systemen immer mit de gleichen Anmeldedaten an und wenn er durch Heirat umbenannt wird oder auch einfach nur sein Kennwort ändert, dann ist das eine Änderung in dem Authentifizierungssystem und alle damit verbundenen Server übernehmen dies. Diese Funktion stellt z.B. Active Directory bereit, an welches sich viele Dienste per LDAP, NTLM, Kerberos, Radius etc. ankoppeln können. Aber auch eine NetWare NDS oder früher bekannten "NIS/Yellow Pages" oder auch ein OpenLDAP-Service bei UNIX-Systemen sind solche Beispiele. Ein Beispiel ist der Zugriff eines Computers, der selbst nicht Domainmitglied ist und auf verschiedene Server einer Domain zugreifen muss. Für jede Verbindung muss sich der Anwender neu anmelden. Ein „gespeichertes Kennwort“ ist kein echtes SSO. |
|
Seamless Singe SignOn
|
Die ideale Lösung besteht dahin, dass ein Anwender sich auf
seinem Endgerät nur genau einmal anmeldet und diese Information
dann für den Zugriff auf möglichst viele andere Dienste genutzt
wird. Dazu zähle ich ich natürlich nicht die Funktion, pro Ziel die Zugangsdaten ein einem lokalen Credentialstore (Stichwort Windows Tresor) zu speichern und vom Betriebssystem an die verschiedenen Server zu senden. Ein "Seamless Single SignOn" ist aber in der Windows Welt mit Active Directory schon seit der Windows Domäne und der Domainmitgliedschaft von Clients gegeben. Der Client hat nach der Anmeldung des Benutzers als "DomainUser" z.B. den NTLM-Hash als auch ein Kerberos Granting Ticket (TGT) und kann sich per NTLM-Anmeldung oder Kerberos direkt an den Diensten in der Domain anmelden. Der Anwender bekommt idealerweise nie eine Kennwortrückfrage. In Verbindung mit Cloud-Diensten und SAML/OAUTH können sich Client entweder von einem lokalen ADFS-Server mittels NTLM/Kerberos oder Entra-ID mittels ADSync und Seamless Single Sign On ein SAML-Token besorgen, und damit ebenfalls eine einfache direkte Anmeldung ermöglichen. |
|
Ich hoffe, dass damit der Unterschied bei SingleSignOn etwas deutlicher geworden ist.
Anmeldung an EntraID
Die Nutzung von Cloud-Diensten gehört mittlerweile zum Standard aber ein Cloud-Service ist in der Regel nicht direkt mit einem lokalen Active Directory verbunden. Beim Zugriff auf Dienste von Microsoft 365 aber auch anderen Angeboten wie Confluence, SAP, Dropbox, Webex, Teamviewer und vielen anderen Programmen werden Sie im lokalen Active Directory sicherlich keine Computerkonten pro Dienst mit einem Kerberos SPN für diesen Dienst anlegen. In der Cloud sind SAML-Tokens üblich, die sich im Grunde mit Kerberos-Tickets vergleichen lassen. Das Kerberos-TGT ist ein Refresh-Token während das TGS dann dem SAML-Access Token vergleichbar ist.
In unserem Fall geht es um die Anmeldung an Entra ID mit einer vorhandenen lokalen Anmeldung Hierzu gibt es ebenfalls mehrere Möglichkeiten:
- Interaktiv mit Cloud Only
Wenn die Benutzer in EntraID ohne ADSync angelegt wurden, erfolgt eine Anmeldung immer an der Cloud. Hier gibt es kein "Single SignOn", es sei denn ihr Client ist ebenfalls Entra ID Joined und durch die Anmeldung am Clients bekommen sie schon ein Primary Refresh Token“ (PRT), mit dem der Client dann weitere Access Tokens anfordern kann. - Interaktiv mit ADFS
Wenn das Konto mit einem lokalen Active Directory verbunden ist, kann der Anwender gegenüber EntraID das gleiche Kennwort nutzen, welches er auch lokal verwendet. Beim Einsatz von ADFS bekommt der Client das Ticket vom lokalen ADFS-Service, welcher eine integrierte Anmeldung per NTLM/Kerberos erlaubt und damit dem Anwender eine erneute Eingabe des Kennworts erspart. - Interaktiv mit SSO und PTA/PHS
Beim Einsatz von PTA/PHS kann eine „SSO“-Option aktiviert werden. Wenn der Client lokal entsprechende „IE-Internetzonen“ hat und vom KDC ein Kerberos-Ticket bekommen kann, meldet sich der Anwender auch hier ohne weitere Eingabe von Zugangsdaten ab.
Alle SSO-Funktionen unterliegen dem Vorbehalt durch Conditional Access. Die Speicherung von Zugangsdaten im Windows Tresor oder als Cookies im Browser-Cache oder anderen Kennwortspeichern mit automatischem Ausfüllen ist kein echtes „Single SignOn“
Einschätzung
Die individuelle Pflege von Benutzernamen und Kennworten auf verschiedenen Systemen ist möglich aber für den Administrator aufwändig, für den Anwender unbequem und für das System unsicher. Die Unsicherheit kommt daher, dass der Anwender ohne SSO immer wieder das richtige Kennwort zum richtigen Dienst eingeben muss und jede Kennworteingabe nicht nur theoretisch ein Angriffsweg sein kann. Angreifer könnten die Eingabe, die Übertragung mitschneiden oder gleich ein Anmeldefenster simulieren und die Zugangsdaten so abgreifen.
Idealerweise meldet sich ein Anwender genau einmal am System an. Das kann eine Kombination aus Benutzernamen und langem Kennwort sein aber besser ist noch eine starke Authentifizierung mittels Passkey oder MFA-Lösungen. Dann aber sollte der an sich "vertrauenswürdige Client" den Benutzer kennen und bei allen weiteren Diensten automatisch anmelden, sei es per NTLM oder Kerberos in der lokalen Domäne oder über SAML-Tokens an entsprechend konfigurierte Cloud-Dienste.
