Seamless Single Sign On

Benutzer müssen für den Zugriff auf Dienste in Office 365 authentifiziert werden. AADConnect kann die Identitäten in der Cloud anhand eines lokalen AD verwalten und wenn sie keine Kennworte in die Cloud synchronisieren wollen oder ein Single-SignOn gefordert ist, dann war ADFS der Weg zum Ziel. Seit Anfang 2017 gibt es mit der Path-Through Authentifizierung aber einen weiteren Weg zur Anmeldung an der Cloud. Diese Lösung ist insbesondere für kleinere und mittlere Firmen eine interessante Option.

Was ist Seamless SSO?

Wer heute Office 365 nutzt und lokal ein Active Directory hat, ist fast immer gut damit beraten, den AADConnect-Prozess zu installieren und laufen zu lassen. AADConnect kann problemlos auch auf einem Domain Controller mit installiert werden, liest die lokalen Identitäten aus und führt die entsprechenden Identitäten in der Cloud nach. Nur für die Anmeldung war AADConnect bislang nicht nutzbar. AADConnect kann aber schon länger Hashwerte von Kennworten in die Cloud replizieren, so dass Anwender in Office 365 die gleichen Zugangsdaten verwenden konnten. Damit erreichen Sie aber nur einen "Same SignOn" aber kein "SingleSignOn (SSO)", da der Anwender immer wieder ein Kennwort eingeben muss. Die fortgeschrittene Variante ist die Bereitstellung von ADFS zur Anmeldung per SAML-Token. Nur jeder kann und will aber einen ADFS-Server samt ADFS-Proxy, statischer IP-Adresse, öffentlichem Zertifikat und Veröffentlichung im Internet installieren.

Seamless SSO verbessert dieses Verhalten nun zumindest für "Domain Joined" Clients, die Zugriff auf den das Kerberos Distribution Center (KDC) haben. Das gilt also für alle internen PCs, wobei VPN User und DirectAccess-Clients auch dazu gehören. Die Cloud bietet ihnen nämlich als Authentifizierungsverfahren nun auch "Negotiate" an und wenn ihr internes Setup korrekt ist, dann bekommt der Anwender automatisch ein Ticket und meldet sich an der Cloud an. Die Funktion ist seit AADConnect Dezember 2016 (Version 1.1.371.0) vorhanden und muss auf Windows 2012R23 oder höher installiert sein.

Clients, die AzureAD Joined oder AzureAD Hybrid Joined sind, nutzen das Primary Refresh Token (PRT)

SSO und Multi Tenants

Es gibt Umgebungen, in denen mehrere Firmen zwar den gleichen Active Directory Forest gemeinsam nutzen aber mit eigenen Domains für UPN und Mail-Adresse in unterschiedlichen Tenants arbeiten. Mit mehreren ADSync-Instanzen können Sie solche Umgebungen problemlos abbilden, wenn Sie ein AD-Objekt nur durch genau einen ADSync in einen Tenant replizieren lassen. Allerdings gibt es nicht nur hinsichtlich Exchange die Einschränkung, dass die On-Premises-Exchange-Topologie dieses Forest nur mit einem Tenant eine Hybrid-Konfiguration fahren kann. Auch SSO ist auf einen Tenant beschränkt.

“The single sign-on (SSO) option for password hash synchronization and pass-through authentication can be used with only one Azure AD tenant.”
Quelle: https://docs.microsoft.com/en-us/azure/active-directory/hybrid/plan-connect-topologies#each-object-only-once-in-an-azure-ad-tenant

Um auf der sicheren Seite zu sein, sollten Sie immer die "Supportet Topologies" kennen.

Use a supported Azure AD Connect topology: Ensure that you are using one of Azure AD Connect's supported topologies described here
Quelle: https://docs.microsoft.com/de-de/azure/active-directory/hybrid/how-to-connect-sso-quick-start

Und das "here" geht auf https://docs.microsoft.com/de-de/azure/active-directory/hybrid/plan-connect-topologies. Wer z.B. mehrere Tenants mit einem AD-Forest bereitstellen will oder im Rahmen einer Migration darf/muss, sollte den Abschnitt https://docs.microsoft.com/de-de/azure/active-directory/hybrid/plan-connect-topologies#multiple-azure-ad-tenants genau lesen, da hier auch die Einschränkungen dokumentiert sind z.B.

The single sign-on (SSO) option for password hash synchronization and pass-through authentication can be used with only one Azure AD tenant.
Quelle https://docs.microsoft.com/de-de/azure/active-directory/hybrid/plan-connect-topologies#multiple-azure-ad-tenants

Wie funktioniert Seamless SSO?

Eigentlich ganz einfach und ich frage mich, warum Microsoft das nicht schon früher so umgesetzt hat. Wenn ein interner Client auf einem internen WebServer zugreift und der WebServer einen "401 Auth required" liefert, dann liefert der Webserver auch die Authentifizierungsverfahren mit, die der WebServer unterstützt. Intern ist man gut beraten, wenn Sie NTLM und Kerberos unterstützen, damit die Anwender nicht immer wieder nach ihren Anmeldedaten gefragt werden.

Im "Internet" funktioniert diese Art der Anmeldung in der Regel aber nicht, denn WebServer eines Anbieters werden kaum ein Kerberos-Ticket ihres internen KDC decodieren können. Sie sind ja nicht in ihrer Domäne und haben auch kein Computerkonto. Zudem sind die DNS-Namen des Ziels in einer ganz anderen DNS-Domäne und jeder Browser betrachtet diese Hosts als "Internet". In der Zone ist "integrierte Authentifizierung" natürlich abgeschaltet. Das wäre ja noch zu schön, wenn eine böse Webseite ihnen einen NTLM-Hash V1 entlocken könnte und damit per Brute-Force ein Kennwort ermitteln kann, welches zu dem Hash führt und damit auch für andere Dienste gültig wäre.

Aber genau dieses "geht nicht" wird von Microsoft mit Office 365 doch möglich gemacht. Dazu passiert im wesentlichen folgendes:

  • Client im AD mit Zugriff zum DC
    Der Anwender muss natürlich auf einem PC arbeiten, der in der Domäne Mitglied ist und beim Einsatz auch mit dem KDC sprechen kann. Ein PC in einem anderen "unvertrauten" Forest oder Domain oder ihre HomeOffice Client kann kein Seamless SSO nutzen
  • Passender Browser
    Im wesentlichen geht es erst mal um Browser und auch hier hängt es schon etwas vom Windows Betriebssystem und dem verwendeten Browser ab. Windows 7-10 mit IE, Chrome, Firefox sollten funktionieren. MacOS-User müssen noch etwas nachkonfigurieren und der Edge Browser ist auch außen vor.
  • Computerkonto im AD
    Das Setup legt einen Computer mit dem Namen "AZUREADSSOACCT" an, und verpasst ihm einige SPNs. Damit können die Clients beim Zugriff auf die Office 365 URLs um ein Kerberos Ticket gebeten werden und finden dieses Computerkonto, dessen private Schlüssel durch AADConnect in die Cloud synchronisiert wird. So kann der Client mit dem enthaltenen Ticket den Cloud-Dienst ansprechen der die Gültigkeit des Tickets auch prüfen kann.
  • Service Endpunkte sind in der Browser "Intranet"-Zone
    Das ist natürlich knifflig, wenn Sie auf einem PC mehrere Office 365 Tenants ansprechen. Jedes Mal wird dann der Client "versuchen" ein Kerberos-Ticket zu bekommen bzw. sich mit ihrem aktuellen Benutzernamen anmelden wollen. Tipp: "Private Mode" der Browser nutzen, welche zugleich auch die automatische Anmeldung unterdrücken.

Von den anderen Single Sign On (SSO) können sie neben Seamless SSO aber nur noch den PasswordSync gleichzeitig nutzen. Ein Parallelbetrieb mit ADFS ist nicht möglich.

Einrichtung mit AADConnect

Die Nutzung von Pass-Through Authentifizierung wird schon beim Setup von AADConnect konfiguriert. Microsoft hat das sehr umfangreich mit Bildern auf folgender Seite beschrieben.

Wenn Sie AADConnect aber schon installiert haben, dann müssen sie die Option "Change User Sign-in" aufrufen:

Im folgenden Fenster können Sie dann eine der von AADConnect angebotenen Anmeldeoptionen auswählen. Das "Single SignOn" ist mit Pass-Through Authentifizierung (PTA) oder mit Office 365 Password Sync möglich. Bei ADFS übernimmt der ADFS-Server die automatische Anmeldung.

Die Warnung sollten Sie ernst nehmen, dass das Admin-Konto besser ein "Cloud Only"-Konto ist und nicht im Rahmen des DirSync provisioniert wird.

Ich habe hier bei meinem Test-Tenant von dem vormals konfigurierten "Password Synchronization" nun auf Pass-through authentication umgestellt. Zudem kann man mitterlweile auch ein "Enable Single-Sign-on" aktivieren. Dazu muss man aber einmal die Anmeldedaten eines Administrators zur Konfiguration eingeben.

Eine Zusammenfassung zeigt an, was als nächstes getan wird.

Kontrolle im AD

Bei der Beschreibung, wie Seamless SSO funktioniert, haben sie von einem neuen Computerkonto gelesen. Wenn ihr interner Client auf eine gewisse URL zugreift, dann muss die andere Seite auch "Kerberos" als Authentifizierungsverfahren anbieten, damit ihre Client überhaupt den lokalen KDC nach einem Ticket fragt. Der lokale KDC muss dann im Active Directory ein passendes Objekt suchen, dessen ServicePrincipalName (Kerberos SPN) auf die geforderte Ressource passt, damit er ein Ticket hierfür ausstellen kann.

Entsprechend muss es in ihrem lokalen Active Directory auch ein Objekt mit dem passenden SPN geben, welches Sie einfach per Active Directory Benutzer und Computern suchen können. Tipp: Der Name ist immer AZUREADSSOACC. Die Kurzform von Azure AD SingleSignOnAccount.

Tipp:
Addieren Sie eine Beschreibung, damit Kollegen das Konto nicht löschen, verschieben Sie es in eine geeignete OU und setzen Sie die Checkbox bei "Objekt vor zufälligen Löschen schützen": Wenn das Konto "verschwindet", dann funktioniert SSO mit Kerberos gegen Office 365 nicht mehr.

In den Eigenschaften ist insbesondere das Feld "ServicePrincipalName" interessant.

Hier tauchen also gar nicht alle Office 365 URLs auf, sondern "nur" die Services, die die Authentifizierung des Anwenders übernehmen und dann ein Office 365 Ticket für die weiteren Dienste ausstellen.

Kontrolle im Azure AD

Die Aktivierung von SSO wird aber auch im AzureAD hinterlegt. Unter der folgenden URL finden Sie die aktuelle Konfiguration

Unter "Azure AD Connect" wird "Seamless single sign-on" angezeigt:

Das Ausrufezeichen hier ist ein Hinweis, dass das Kerberos Kennwort schon länger nicht mehr getauscht wurde.

Einrichtung im Tenant: Modern Auth

Wer seinen Tenant erst im November 2017 oder später angelegt hat, muss keine weiteren Schritte unternehmen, da hier die Standardeinstellung für OAUTH schon hinterlegt ist. Wer einen älteren Tenant hat, muss ggfls. die folgende Einstellung in der Exchange Online Powershell noch vornehmen:

Set-rganizationConfig -OAuth2ClientProfileEnabled $true

Die gleiche Einstellung müssen Sie auch in Skype for Business Online dann ändern

Einrichtung auf den Clients: Intranetzone

Damit das funktioniert, müssen Sie im Browser natürlich diese Adressen als "Intranet" addieren oder in einer Zone betreiben, in der eine Anmeldung per Kerberos möglich ist.

  • aadg.windows.net.nsatc.net
  • autologon.microsoftazuread-sso.com

Diese beiden Hosts müssen in das "Lokale Intranet"

Die Zonen stellen sie natürlich am besten per Gruppenrichtlinien ein.

Umgekehrt ist nun aber auch klar, dass Clients ohne entsprechende Unterstützung diese Art der Anmeldung gar nicht anbieten können. Dazu zählt als auch ein mobiler Client, private Computer, die nicht in der Domäne sind, Domänenmitglieder, die aber von unterwegs keine Verbindung zu einem KDC haben. Insofern sind VPN, AutoVPN oder auch Direct Access hier zu beachten. Da ein interner KDC in der Regel keine gesonderte Authentifizierung erfordert, weil der Anwender ja schon am Client selbst angemeldet ist, gibt es auch keine direkte Unterstützung für einen zweiten Faktor, d.h. eine starke Authentifizierung ist Aufgabe des Client Betriebssystems.

Client: Office, Edge und Co

Auch Office 2013 und ggfls. 2016 müssen für ModernAuth noch aktiviert werden.

Allerdings könnten Anwender durch ein Verhalten des Microsoft Edge Browser verwirrt werden. Nachdem sich die Anwender automatisch anmelden können, wird auch Edge diese Funktion gerne aktivieren und die Synchronisation von Favoriten, Verlauf, Kennwort und anderen Browserdaten in die Cloud empfehlen.

Ihre Anwender können das gerne machen aber sie sollten Sie auf diese Dialogbox vorbereiten, ehe Sie viele Support-Tickets bekommen oder die Konfiguration per Gruppenrichtlinien vorgeben.

Anmeldung testen

Um die Funktion zu testen muss ist also einen Client nutzen, der in der Domäne ist und an dem der Benutzer angemeldet ist, der auch auf Office 365 zugreifen will. Mit den richtigen Zoneneinstellungen sollte der Client dann die Office 365 Web-Dienste ansprechen und passenden zu den Hosts auch ein Kerberos-Ticket von internen KDC anfordern, weiterreichen und authentifiziert sein. Aktuell funktioniert das wohl mit allen Clients, die "Modern Authentication" unterstützen. Ausgerechnet der Edge ist hier noch nicht dabei:

Ich habe also den Internet Explorer auf einem Windows 10 System gestartet, der Mitglied der Domäne ist. Beim Zugriff auf portal.office365.com wurde ich natürlich nach dem Usernamen gefragt. Diese erste Eingabe muss ich im Browser wohl noch machen. Ich habe aber das Kennwort "leer" gelassen und einfach Anmelden geklickt.

Im Fiddler-Trace ist dann das Paket 46 interessant. Hier lehnt Office 365 die Anmeldung mit einem 401 ab aber liefert mir "Negotiate" als mögliches Anmeldeverfahren:

Das ist für den Client natürlich das Startsignal, sich von dem lokalen KDC ein Ticket zu besorgen, wenn die URL in der richtigen Intranet-Zone aufgenommen wurde. Die Abfrage des Kerberos-Tickets könnten Sie mit Wireshark mitschneiden oder mit KLIST anzeigen

Im Pakete 47, welches die gleiche URL anspricht, wird diesmal ein Kerberos-Ticket mitgeliefert:

Nach der erfolgreichen Anmeldung wird von dem Authentifizierungsserver natürlich ein Token erstellt, welches dann vom Browser zukünftig weiter verwendet wird. Das sind dann die Pakete 48 und folgende, bis bei 61 der eigentliche Zugriff auf OWA erfolgt.

WWenn der Client aber kein Kerberos-Ticket bekommt, z.B. weil Sie das Konto gar nicht korrekt angelegt oder wieder gelöscht haben oder der Client außerhalb ihres Netzwerks sich befindet und den KDC daher nicht erreichen kann oder der Client unterstützt Kerberos nicht, dann bleibt weiterhin die Anmeldung mit Benutzername und Kennwort. Das ganze funktioniert sogar mit Multi Faktor Authentifizierung. Ich erspare dem Anwender also einfach die Eingabe des Kennwort, wenn er auf einem internem PC arbeitet und kein ADFS hat.

AZUREADSSOACC Konto Rollover

Der AzureAD-Health-Agent meldet natürlich auch den lokalen Status in die Cloud. Entsprechend finden wir hier auch die Domains, für die SSO aktiviert ist.

Allerdings sehen wir dann auch die Warnungen, wenn aus Sicht von Microsoft das Konto des AzureADSSOACC-Kontos schon länger nicht mehr geändert wurde.

Der "Learn More"-Link geht dabei auf https://aka.ms/dsso-key-rollover mit Weiterleitung auf Microsoft Docs.

Eine Empfehlung von Microsoft geht in der Beschreibung schon fast unter und leider gibt es von Microsoft auch kein Automatismus. Auf der FAQ-Seite zu SSO steht folgender Satz:

It is important to frequently roll over the Kerberos decryption key of the AZUREADSSOACC computer account (which represents Azure AD) created in your On-Premises AD forest
Quelle https://docs.microsoft.com/en-us/azure/active-directory/hybrid/how-to-connect-sso-faq#how-can-i-roll-over-the-kerberos-decryption-key-of-the-azureadssoacc-computer-account

ih bin nicht sicher, ob Sie das noch machen müssen, denn auf GitHub gibt es ein Kommentar, dass ADSync selbst diese weiter beschriebenen Aktionen macht

The ey roll over is an important part in Seamless single-sign on. The seamless single sign-on depends on the AZUREADSSOACC account that we create in On-premise active directory. The AZUREADSSOACC account is designated as a machine account. As per default policy in on-premise AD, a machine account resets its own password after every 30 days . And if you have azure AD sync working properly using Azure AD connect then everything is well and good, you may never see the warning "Key is older than 30 days. We recommend that you roll over this key." on the portal.
Quelle: https://GitHub.com/MicrosoftDocs/azure-docs/issues/40727#issuecomment-544221641

Auf einer anderen Seite wird aber ein Jahr später auch aufgezeigt, wie das Kennwort zu ändern ist und bei meinem AzureADSSOACC-Konto ist das Feld "pwdLastSet" auch seit der initialen Einrichtung noch nie aktualisiert worden

Auf der Seite wird auch beschrieben, wie dies über die AzureAD Powershell umzusetzen ist, die natürlich zu erst zu installieren ist. Die Anleitung ist etwas ausführlich, da Sie zuerst auch alle Domänen ermittelt und interaktiv nach Anmeldedaten fragt:

#Import Module on the AADConnect Server
Import-Module 'C:\Program Files\Microsoft Azure Active Directory Connect\AzureADSSO.psd1'

# List avaibale commands

get-command -Module azureadsso

CommandType     Name                                               Version    Source
-----------     ----                                               -------    ------
Cmdlet          Disable-AzureADSSOForest                           1.0        AzureADSSO
Cmdlet          Enable-AzureADSSO                                  1.0        AzureADSSO
Cmdlet          Enable-AzureADSSOForest                            1.0        AzureADSSO
Cmdlet          Get-AzureADSSOComputerAcccountInformation          1.0        AzureADSSO
Cmdlet          Get-AzureADSSOStatus                               1.0        AzureADSSO
Cmdlet          New-AzureADSSOAuthenticationContext                1.0        AzureADSSO
Cmdlet          Update-AzureADSSOForest                            1.0        AzureADSSO

# Get Cloud Credentials. Can be read from files
# See https://www.msxfaq.de/code/powershell/pspasswort.htm
$cloudcred = get-credential admin@<tenantname>.onmicrosoft.com

#Initialize Cloud Connection
New-AzureADSSOAuthenticationContext -CloudCredentials $cloudcred

# Get current Information from Cloud
Get-AzureADSSOStatus
{"Enable":true,"Exists":true,"Domains":["accountdom.local","uclabor.de"],"IsSuccessful":true,"ErrorMessage":""}

# Get On-Prem Credentials. Must be Domain\User-Format
$OnPremCred = Get-Credential domain\Administrator
Get-AzureADSSOComputerAcccountInformation -OnPremCredentials $onpremcred
CN=AZUREADSSOACC,CN=Computers,DC=uclabor,DC=de

Maßgeblich ist aber nur das Commandlet Update-AzureADSSOForest mit der entsprechenden Ausgabe:

Update-AzureADSSOForest -OnPremCredentials $OnPremCred
[18:02:01.829] [  7] [INFORMATIONAL] UpdateComputerAccount: Locating SSO computer account in carius...
[18:02:01.876] [  7] [INFORMATIONAL] UpdateComputerAccount: Found SSO computer account at CN=AZUREADSSOACC,CN=Computers,DC=uclabor,DC=de. Updating its properties...
[18:02:02.173] [  7] [INFORMATIONAL] UpdateComputerAccount: Successfully updated SSO computer account properties.
The operation completed successfully

Diesen Befehl dürfen Sie laut Microsoft aber nur einmal innerhalb der Zeitspanne machen, in denen ein Kerberos-Ticket verfällt. Es handelt sich ja ein Key Rollover, bei dem der aktuelle von vorherige Key akzeptiert werden. Es gibt keine Fehler- oder Warnung, wenn Sie den Befehl mehrfach aufrufen.

Hinweis: Sie können die Abfolge natürlich automatisieren. Allerdings muss der Task auf dem AADConnect-Server mit der AzureAD-PowerShell laufen und sie benötigen sowohl lokale als auch Office 365 Credentials, die sie entsprechend "sicher" speichern sollten. Siehe auch PS Passwort / Kennwort

Einschätzung

Die Anmeldung mit Kerberos an der Cloud dürfte für viele Administratoren erst einmal ungewöhnlich sein. Schließlich waren wir bisher immer davon überzeugt, dass Kerberos doch nur innerhalb einer Domäne möglich ist. Das stimmte natürlich noch nie. Allerdings muss es für das Zielsystem ein Computer- oder Benutzer-Konto in ihrer Domäne geben, damit der KDC Auch ein Ticket ausstellen kann und das Ziel muss das Ticket entschlüsseln können. Das geht natürlich nur, wenn das Konto in ihrem AD einen Schlüssel (vergleichbar einem Public-Key) hinterlegt bekommen hat, zu dem das Ziel das Gegenstück hat. Was für die Einbindung von UNIX-Systemen mit KEYTAB und anderen möglich ist, nimmt Microsoft ihnen relativ einfach ab.

Aus meiner Sicht ist diese Lösung sehr pfiffig für kleinere Firmen, die auf den Betrieb eines ADFS-Servers verzichten wollen und dennoch zumindest für interne Clients ein "Single SignOn" ermöglichen wollen. Ich gehe davon aus, dass diese elegante und bequemen Anmeldung für all diese Firmen zukünftig zum Standard wird. Die Einrichtung ist auch sehr schnell erfolgt, da neben einer Checkbox bei der Installation von AADConnect nur noch die Zoneneinstellungen des Internet Explorer anzupassen sind.

Weitere Links

BRK3015 Deep-dive: Azure Active Directory Authentication and Single-Sign-On
https://www.youtube.com/watch?v=6RHbDriZRVc