Website-Suche

Single Sign-On und Azure AD Connect Pass-Through-Authentifizierung

In meinem vorherigen Blogbeitrag habe ich die Azure AD Connect Pass-Through Authentication (PTA) besprochen, wie sie funktioniert und wie sie konfiguriert werden kann. In diesem Blogbeitrag habe ich Single Sign-On (SSO) nicht aktiviert und das war auch der erste Kommentar, den ich innerhalb von ein oder zwei Tagen erhielt. Die Aktivierung von SSO und wie es funktioniert, ist das Thema dieses Blogposts.

Authentifizierungsablauf

Ich habe den Authentifizierungsablauf bei Verwendung von PTA bereits erklärt. Wenn Sie auf einen Dienst in Office 365 zugreifen, werden Sie zu Azure AD weitergeleitet, Sie geben Ihre Anmeldeinformationen ein und die Anmeldeinformationen werden im Azure Service Bus abgelegt. Der Azure AD Connect-Server ruft diese Anmeldeinformationen vom Service Bus ab und übermittelt sie dem lokalen Domänencontroller. Das Ergebnis wird an den Servicebus zurückgegeben und Ihnen wird der Zugriff gewährt oder natürlich verweigert, wenn etwas nicht stimmt.

Was passiert also, wenn Sie SSO im Azure AD Connect-Assistenten aktivieren? Um SSO zu aktivieren, müssen Sie lediglich das Kontrollkästchen Einzelanmeldung aktivieren im Azure AD Connect-Assistenten aktivieren:

Hinweis. Ich habe die meisten Konfigurationsschritte übersprungen, da dies mit den Konfigurationsschritten im vorherigen Blogbeitrag identisch ist.

Während des Azure AD Connect-Assistenten müssen Sie auch Ihre lokalen Administratoranmeldeinformationen eingeben. Diese werden benötigt, um Ihr lokales Active Directory für die Aktivierung von SSO mit PTA zu konfigurieren.

Fairerweise muss man sagen, dass es sich nicht um echtes SSO wie bei der Föderation (über ADFS) handelt, sondern um nahtloses Single-Sign-On (sSSO). Wenn Sie SSO im Azure AD Connect-Assistenten aktivieren, müssen Benutzer nur ihren Anmeldenamen eingeben, wenn sie auf Dienste in Office 365 zugreifen, beispielsweise mit Outlook Web App:

Wenn Sie sich auf einer Domänen-Arbeitsstation befinden, die Zugriff auf einen Domänencontroller hat, müssen Sie nur das entsprechende Benutzerkonto auswählen. Das Passwort wird automatisch an Azure AD zurückgegeben und wenn alles in Ordnung ist, erhalten Sie Zugriff auf Outlook Web App.

Wenn Sie keinen Anmeldenamen auswählen oder eingeben möchten, können Sie auch Domänenhinweise verwenden. In Kombination mit Outlook Web App würden Sie eine URL wie https://outlook.office.com/owa/contoso.com verwenden. Wenn Sie dies tun, werden Ihre aktuellen Anmeldeinformationen (wiederum auf einer Domänen-Arbeitsstation, die Zugriff auf einen Domänencontroller hat) automatisch weitergeleitet und Ihnen wird Zugriff gewährt.

Nahtloses Single-Sign-On unter der Haube

Doch wie funktioniert dieses sSSO eigentlich unter der Haube?

Wenn Sie SSO im Azure AD Connect-Assistenten aktivieren, müssen Sie Ihr lokales Domänenadministratorkonto eingeben. Dies wird verwendet, um ein zusätzliches Computerobjekt in Active Directory mit dem Namen AZUREADSSOACC zu erstellen.

Dieses Computerkonto wird zum Erstellen eines gemeinsamen Kerberos-Schlüssels zwischen Ihrem lokalen Active Directory und Azure Active Directory verwendet, der für die Erstellung des SSSO-Erlebnisses erforderlich ist.

Bei der Anmeldung in diesem Szenario erfolgen die folgenden 8 Schritte:

  1. Der Client greift über https://outlook.office.com/owa auf einen Dienst in der Microsoft-Cloud zu, beispielsweise OWA.
  2. Die Anfrage wird von Office 365 an Azure Active Directory umgeleitet.
  3. Der Zugriff wird verweigert und ein 401-Fehler wird an den Client zurückgegeben.
  4. Der Client greift auf einen lokalen Domänencontroller zu und fordert ein Kerberos-Token an.
  5. Ein Kerberos-Sitzungsticket wird an den Client zurückgegeben.
  6. Das Sitzungsticket wird Azure Active Directory vorgelegt. Da Azure Active Directory über ein gemeinsames Ticket mit Ihrem lokalen Active Directory verfügt, kann ein Kerberos-Token generiert werden, das der Client verwenden kann.
  7. Das Kerberos-Token wird an den Client zurückgegeben
  8. Das Kerberos-Token wird Office 365 vorgelegt und der Zugriff gewährt. Der Benutzer kann nun mit der Nutzung von OWA beginnen.

Wie Sie sehen, funktioniert dies nur für domänengebundene Clients, die Zugriff auf einen lokalen Domänencontroller haben. Wenn sie keinen Zugriff auf einen lokalen Domänencontroller haben, wird der reguläre PTA-Prozess befolgt, wie am Anfang dieses Blogposts (und des vorherigen Blogposts) gezeigt.

Notiz. Damit der Client die Anmeldeinformationen automatisch weitergibt, müssen sich die Azure AD-Endpunkte in der Intranetzone befinden

  • https://autologon.microsoftazuread-sso.com
  • https://aadg.windows.net.nsatc.net

Tipp. Verwenden Sie GPO, um dies für alle Clients in Ihrem Netzwerk zu ändern.

Wenn Sie Ihren Browser verwenden und zu Exchange Online navigieren, werden Sie weiterhin aufgefordert, Ihren Benutzernamen einzugeben (oder einen Benutzernamen auszuwählen, wenn Sie ihn zuvor verwendet haben), aber Sie müssen Ihr Passwort nicht eingeben:

Wenn Sie in Ihrer URL einen Domänenhinweis wie https://outlook.office.com/owa/inframan.nl verwenden, wird das Konto automatisch angemeldet. Ein kleiner, aber seltsamer Hinweis: Dies wird vom Microsoft Internet Explorer unterstützt, nicht jedoch vom Microsoft Edge-Browser (zumindest nicht zum Zeitpunkt des Schreibens, Anfang November 2017). Dies könnte sich jedoch in Zukunft ändern.

Damit dies mit Outlook 2016 (oder vollständig gepatchtem Outlook 2013, das moderne Authentifizierung unterstützt) funktioniert, müssen wir OAuth auf Mandantenebene aktivieren. Um dies zu erreichen, melden Sie sich mit Remote PowerShell in Exchange Online mit den folgenden Befehlen an:

$Cred= Get-Credential 'administrator@contoso.onmicrosoft.com'
$Session= New-PSSession -ConfigurationName Microsoft.Exchange -ConnectionUri https://outlook.office365.com/PowerShell-LiveID -Credential $Cred -Authentication Basic -AllowRedirection
Import-PSSession -Session $Session

Und wenn Sie angemeldet sind, geben Sie den folgenden Befehl ein:

Set-OrganizationConfig -OAuth2ClientProfileEnabled:$TRUE

Wenn Sie Outlook das nächste Mal starten, werden Sie feststellen, dass es sich automatisch bei Exchange Online anmeldet (was jedoch nicht der Fall war, als OAuth nicht aktiviert war).

Hinweis. Wie weiter oben in diesem Beitrag beschrieben, gibt es einen gemeinsamen Schlüssel zwischen dem Computerkonto in Ihrem lokalen Active Directory und Azure Active Directory. Es wird dringend empfohlen, diese Schlüssel alle 30 Tage zu übertragen. Weitere Informationen finden Sie in den Microsoft-FAQs zu diesem Thema: https://docs.microsoft.com/en-us/azure/active-directory/connect/active-directory-aadconnect-sso-faq

Zusammenfassung

Sie können die Passthrough-Authentifizierung verwenden, wenn Sie alle Benutzerkennwörter lokal aufbewahren (und sie daher nicht in der Microsoft-Cloud speichern müssen). Bei Verwendung der Pass-Through-Authentifizierung können Sie auch nahtloses Single-Sign-On oder sSSO aktivieren. Auf diese Weise können in die Domäne eingebundene Clients (die Zugriff auf einen Domänencontroller haben) die Kerberos-Authentifizierung verwenden, um auf Dienste in der Microsoft-Cloud zuzugreifen.

Eine Reihe von Problemen, die Sie beachten sollten: Nicht alle Clients unterstützen PTA oder sSSO, wie in diesem Artikel beschrieben. Beispielsweise wird dies vom Internet Explorer unterstützt, vom Edge-Browser jedoch nicht. Outlook 2013/2016 unterstützt dies (moderne Authentifizierung), Outlook 2010 jedoch nicht. Außerdem wird dies von Lync/Skype für Geschäftskunden überhaupt nicht unterstützt. Ich gehe davon aus, dass sich dies in (naher) Zukunft ändern wird, und wenn dies der Fall ist, werde ich diesen Artikel aktualisieren.

Mehr Informationen

Nahtloses einmaliges Anmelden bei Azure Active Directory: Häufig gestellte Fragen - https://docs.microsoft.com/en-us/azure/active-directory/connect/active-directory-aadconnect-sso-faq

Verwandte Artikel