Zwei neue Microsoft Hybrid Services vereinfachen die Anbindung Ihres Active Directory an Azure erheblich

Microsoft hat kürzlich die öffentliche Vorschau auf zwei wichtige neue Funktionen angekündigt, die die Integration Ihres lokalen Active Directory in Azure AD erheblich vereinfachen werden. Dank der Passthrough-Authentifizierung (PTA) und des nahtlosen Single Sign-On (ich bezeichne dies hier als 3SO) können Ihre Benutzer problemlos auf Azure AD-Anwendungen wie Office 365 zugreifen, ohne dass Sie eine komplexe Active Directory Federation Services (AD FS)-Farm in Ihrem Rechenzentrum installieren oder Benutzer-Passwort-Hashes mit Azure AD synchronisieren müssen.

Oder in diesem Fall von 3SO, überhaupt etwas extra zu installieren.

Bisherige Möglichkeiten der hybriden Authentifizierung (und ihre Grenzen)

Die überwiegende Mehrheit der Unternehmen nutzt heute Active Directory als grundlegenden Identitätsdienst, und daran wird sich so schnell nichts ändern. Daher besteht eine grundlegende erste Aufgabe bei der Planung der Nutzung eines beliebigen Online-Dienstes von Microsoft darin, Ihr lokales Active Directory mit Azure AD zu integrieren, um zwei Funktionen zu nutzen. Zunächst müssen Sie AD-Konten und -Gruppen mithilfe von Azure AD Connect mit Azure AD synchronisieren. Zweitens müssen Sie, sobald sich die Konten in Azure AD befinden, festlegen, wie die Benutzer dort authentifiziert werden sollen. In diesem Beitrag konzentriere ich mich auf die Aspekte der Benutzerauthentifizierung.

Derzeit stehen Ihnen zwei Authentifizierungsoptionen von Microsoft zur Verfügung: AD FS, das Identitätsverbundfunktionen (sowie eine Reihe weiterer Funktionen) für SSO bereitstellt, und die Passwortsynchronisierung („PHS“ in den nachstehenden Diagrammen). Diese zweite Option, die unter Fachleuten als Passwort-Hash-Synchronisierung (daher das „H“) bekannt ist, bietet eine „Same Sign-On“-Funktion, bei der der Benutzer seine Anmeldedaten zwar ein zweites Mal eingeben muss, um sich bei Azure AD anzumelden, es sich dabei jedoch um dieselbe Benutzer-ID und dasselbe Passwort handelt, die er auch für Active Directory verwendet.

Ross Adams, Programmmanager für Passthrough-Authentifizierung bei Microsoft, stellt die Unterschiede zwischen diesen Lösungen in diesem cleveren Nutzen-Schmerz-Diagramm dar (Abbildung 1):

In aufsteigender Reihenfolge der Komplexität und des Wertes, haben wir

• Reine Cloud-Konten: Benutzerkonten werden in Azure AD verwaltet und authentifiziert. Da es in diesem Beitrag um Hybridlösungen geht, werden wir diesen Aspekt hier außer Acht lassen.
• AAD Connect / Cloud-Konten: Sie können Azure AD Connect verwenden, um Benutzerkonten mit Azure AD zu synchronisieren, sodass die Anmelde-ID (in der Regel die E-Mail-Adresse des Benutzers) identisch ist; die Benutzer müssen ihre Passwörter jedoch im Cloud-Dienst selbst verwalten. Ich habe noch niemanden gesehen, der dies tut.
• AAD Connect + PHS: Wenn Sie die optionale Funktion zur Synchronisierung von Kennwort-Hashes in Azure AD Connect aktivieren, werden die Kennwort-Hashes, die in Ihrem lokalen Active Directory gespeichert sind, mit Azure AD synchronisiert und ermöglichen so die gleiche Anmeldung.
• AAD Connect + AD FS: Die mit Abstand umfassendste und komplexeste Lösung. Diese Kombination bietet SSO zu Azure AD und authentifiziert sich anhand der Konten in Ihrem lokalen Active Directory.

Wie Sie sehen können, besteht eine große Lücke hinsichtlich der Komplexität der Bereitstellung, um echtes SSO in Ihrem Unternehmen zu realisieren. Lösungen von Drittanbietern wie Okta, Ping Identity, OneLogin, Centrify, OptimalIDM und anderen bieten einfachere Authentifizierungsmethoden, die diese Lücke schließen, und dies ist einer der Gründe für ihre Beliebtheit.

Domänenverbund Windows...und alles andere

Um zu verstehen, was diese beiden neuen Lösungen in der öffentlichen Vorschau bieten, ist es hilfreich, die Anwendungsfälle für die Authentifizierung in zwei Kategorien einzuteilen: Entweder verfügt der von Azure AD zu authentifizierende Client über ein Kerberos-Ticket, oder er verfügt nicht darüber.

Das erste Szenario ist das klassische Windows-Authentifizierungsszenario für Unternehmen, bekannt als „Integrated Windows Authentication“ (IWA). Ein Benutzer, der sich mit einem AD-Konto an seiner domänengebundenen Windows-Workstation im Unternehmensnetzwerk angemeldet hat (d. h., die Workstation kann einen „ domain controller “ finden) und daher über ein Kerberos-Ticket verfügt, erhält nahtlosen Zugriff auf AD-fähige Ressourcen, ohne zur Eingabe seines Passworts aufgefordert zu werden. Dieses Szenario gibt es bereits seit der Einführung von Active Directory.

Der zweite Eimer steht für die anderen Authentifizierungsszenarien, die sich seitdem entwickelt haben:

• Ein Arbeitsplatzrechner, der der Domäne beigetreten ist und versucht, sich von außerhalb des Netzwerks zu authentifizieren (das Notebook)
• Ein browserbasierter Client, unabhängig davon, ob es sich um einen Desktop- oder einen mobilen Client (den Webbrowser) handelt
• Ein API-basierter Client, wie z.B. eine Office-App (die mobile App)

Betrachten wir zunächst das Szenario einer domänenangeschlossenen Workstation und die elegante Lösung von Microsoft unter Verwendung von 3SO.

Was ist nahtloses Single Sign-On?

3SO ist für die Arbeit mit dem ersten Bucket konzipiert - dem domänenverbundenen PC im Unternehmensnetzwerk. Die Eleganz der 3SO-Lösung lässt sich in nur wenigen Worten zusammenfassen: Azure AD kann jetzt die Kerberos-Authentifizierung unterstützen.

Das ist es. Auf den Punkt gebracht besteht der Hauptzweck von AD FS darin, ein Kerberos-Ticket in ein modernes SAML- oder OAuth-Sicherheitstoken umzuwandeln, das eine vertrauende Partei wie Azure AD verwenden kann. Wenn Azure AD ein Kerberos-Ticket – insbesondere ein Dienstticket für eine Azure-Ressource – verstehen kann, benötigen Sie den AD FS-Vermittler nicht, um die Übersetzung vorzunehmen.

Abbildung 2 veranschaulicht, wie dies funktioniert. Azure AD wird in Ihrem lokalen AD lediglich als ein weiterer Computer dargestellt; das AD erkennt keinen Unterschied. Ein Computerkonto (AZUREADSSOACCT) wird Ihrem AD hinzugefügt, zusammen mit zwei SPNs (Service Principal Names), die die für die Authentifizierung erforderlichen URLs enthalten. Der geheime Kerberos-Schlüssel für das Workstation-Konto wird sicher an Azure AD weitergegeben. Von diesem Zeitpunkt an nutzen Clients IWA für den Zugriff auf Azure-Ressourcen, genauso wie sie auf einen IIS-Server in Ihrem lokalen Rechenzentrum zugreifen würden.

1. Ein Benutzer versucht, auf eine Azure AD-Ressource wie Office 365 zuzugreifen. Azure AD fordert den Benutzer auf, ein Kerberos-Service-Ticket bereitzustellen.
2. Der Client übermittelt seinem domain controller sein TGT (Ticket-Granting-Ticket) sowie die SPN des Zielservers (in diesem Fall eine Azure AD-URL).
3. Der Ticket Granting Service (TGS) innerhalb des Schlüsselverteilungszentrums (KDC) von „ domain controller “ erstellt ein Service-Ticket für die Azure AD-Ressource und gibt es an den Client zurück.
4. Der Client legt Azure AD das Service-Ticket vor. Unter der Annahme, dass das Ticket gültig ist, wird der Benutzer authentifiziert.

Bitte beachten Sie, dass dieser Vorgang nicht bedeutet, dass der Benutzer zum Zugriff auf die Ressource berechtigt ist, sondern lediglich, dass er seine Identität bestätigt hat. Das Ergebnis ist, dass ein Windows-Benutzer innerhalb des Unternehmensnetzwerks nicht zur Eingabe eines Passworts aufgefordert wird, um auf Azure AD-Ressourcen zuzugreifen, und dass AD FS nicht erforderlich ist. Ziemlich raffiniert, nicht wahr?

Die Installation von 3SO könnte kaum einfacher sein; Sie müssen lediglich das Kontrollkästchen „Single Sign-On aktivieren“ in der benutzerdefinierten Konfiguration der neuesten Version von AD Connect aktivieren.

Unterstützte Kunden

Es gibt einige unterstützte Konfigurationen für 3SO. Erstens muss es sich um einen Client handeln, der Kerberos unterstützt, wie beispielsweise Windows. Zweitens funktioniert es für den Zugriff auf Azure AD-Ressourcen über einen Browser (beispielsweise https://outlook.office.com) oder über einen Office-Client, der die moderne Authentifizierung unterstützt. Sie können die Liste der unterstützten Clients einsehen, im Wesentlichen wird 3SO jedoch von allen gängigen Browsern (IE, Chrome, Firefox) mit Ausnahme von Edge sowie von allen unterstützten Microsoft-Client-Betriebssystemen unterstützt. Microsoft empfiehlt, 3SO für alle Clients zu aktivieren; sollte sich der Benutzer in einer nicht unterstützten Konfiguration befinden, wird im schlimmsten Fall eine Aufforderung zur Eingabe des Passworts angezeigt.

Was ist Passthrough-Authentifizierung?

PTA ist für den Anwendungsfall konzipiert, in dem der Client über kein Kerberos-Ticket verfügt – entweder, weil der Kerberos-Client keinen Zugriff auf einen Domänencontroller hat (beispielsweise wenn ein Mitarbeiter von zu Hause aus auf seinem Firmen-Notebook arbeitet) oder weil der Client Kerberos nicht unterstützt (beispielsweise ein mobiler Browser oder eine App, die keine moderne Authentifizierung unterstützt).

Ich werde hier nicht darauf eingehen, wie PTA installiert wird, aber im Wesentlichen stellen Sie einen oder mehrere lokale „Lightweight Connectors“ bereit – ähnlich wie den Azure AD Application Proxy-Connector – auf Servern, die einer Domäne angehören, sodass diese mit einem Domänencontroller kommunizieren können.

Im Großen und Ganzen ähnelt der PTA-Authentifizierungsprozess dem AD FS-Authentifizierungsprozess: Azure AD erkennt, dass die Authentifizierungsanfrage über einen Proxy an ein lokales Active Directory delegiert wird. Für AD FS fungiert es als Proxy. Bei PTA fungieren die Konnektoren als Proxy (Abbildung 3).

1. Azure AD fordert den Benutzer auf, sich zu authentifizieren, und der Benutzer gibt seine E-Mail-Adresse und sein Passwort ein.
2. Azure AD stellt fest, dass die Domäne des Benutzers für PTA konfiguriert ist; Azure AD benachrichtigt den Konnektor, der daraufhin die Anmeldedaten abruft.
3. Der Connector authentifiziert den Benutzer gegenüber AD mit der gleichen Windows-API, die auch AD FS verwendet.
4. Die Antwort wird an den Connector zurückgesendet.
5. Der Connector leitet die Antwort an Azure AD weiter.
6. Azure AD gibt ein Token an den Benutzer aus.

Sie sehen, dass dies viele Vorteile gegenüber AD FS hat:

• Konnektoren können auf bestehenden, mit der Domäne verbundenen Servern oder DCs installiert werden.
• Wenn mehrere Konnektoren installiert sind (empfohlen), sorgt PTA automatisch für einen Lastausgleich zwischen ihnen.
• Alle Azure-Verbindungen sind ausgehend, und keine nicht authentifizierten Endpunkte sind dem Internet ausgesetzt.
• Die Verwaltung über das Azure-Portal ist sehr einfach, und es müssen keine Zertifikate verwaltet werden

Wann würden Sie AD FS noch verwenden wollen?

Täuschen Sie sich nicht: AD FS wurde keineswegs beiseite geschoben. PTA ist ein sehr spezieller Pfeil für ein einziges Ziel: Es ermöglicht Azure AD die Authentifizierung von Active Directory-Benutzern gegenüber ihrem Unternehmens-AD, Punkt. Sie brauchen AD FS immer noch, wenn

• Sie möchten Smartcards für die Authentifizierung verwenden
• Sie möchten MFA-Anbieter von Drittanbietern verwenden
• Ihre Unternehmenssicherheits policy n erfordern, dass Passwörter stets vor Ort verbleiben (im Gegensatz zu AD FS wird bei PTA das Passwort des Benutzers zunächst in Azure AD eingegeben, bevor es vor Ort übertragen wird).
• Sie verwenden zusätzliche AD FS-Authentifizierungsregeln, um den bedingten Zugriff zu erzwingen
• Sie verwenden vor Ort Windows 10 bedingten Zugriff basierend auf dem Gerät

Und natürlich benötigen Sie AD FS, wenn Sie lokal konfigurierte vertrauende Parteien haben, die SSO bereitstellen und die Sie nicht zu Azure AD migrieren möchten.

AD FS 2016 bietet auch neue Funktionen wie die integrierte Azure MFA-Unterstützung. Wenn Sie eine bestehende AD FS-Installation haben, sollten Sie Ihre zukünftigen Anforderungen und die Möglichkeiten von AD FS sehr sorgfältig prüfen, bevor Sie es als Kosteneinsparungsmaßnahme abschaffen.

Hybride Authentifizierungsmöglichkeiten jetzt

Microsoft bietet jetzt ein viel umfassenderes Angebot an hybriden Authentifizierungsoptionen (Abbildung 4):

Die ursprünglichen Optionen stehen weiterhin zur Verfügung, doch können Sie nun mit nur geringem zusätzlichem Aufwand einen hohen Nutzen erzielen. Wenn Sie die Passwortsynchronisierung nutzen, beseitigt die Aktivierung von 3SO Passwortprobleme für Ihre Unternehmensbenutzer im Netzwerk. Wenn Sie stattdessen PTA zusammen mit 3SO aktivieren, erzielen Sie für den spezifischen Anwendungsfall der Azure AD-Authentifizierung praktisch denselben Nutzen wie mit AD FS.

Mit der öffentlichen Vorschau auf 3SO und die Passthrough-Authentifizierung hat Microsoft die Hürden für die Einführung einer hybriden Identitätsstrategie unter Verwendung der nativen Tools des Unternehmens erheblich gesenkt. Tatsächlich sind diese Tools sogar einfacher zu bedienen als Angebote von Drittanbietern, die sich bisher die Komplexität von AD FS zunutze gemacht haben.

Und falls es noch nicht klar sein sollte: All dies ist kostenlos. Microsoft hat seine Zukunft auf seine Azure-Clouddienste gesetzt. Das Unternehmen möchte die Einführung dieser Dienste so einfach wie möglich gestalten, und in der heutigen, auf Active Directory ausgerichteten Welt bedeutet dies, die Integration von AD mit Azure AD schnell und reibungslos zu gestalten. Es hat ewig gedauert, bis diese Funktionen das Licht der Welt erblickten, aber ich gehe davon aus, dass sie sich rasch zur beliebtesten Identitätsbrücke zwischen lokalen Microsoft-Identitäten und Microsoft-Identitäten in der Cloud entwickeln werden.