Sean Deuby

Microsoft hat vor kurzem die öffentliche Vorschau von zwei wichtigen neuen Funktionen angekündigt, die die Integration Ihres lokalen Active Directory in Azure AD sehr viel einfacher machen werden. Passthrough-Authentifizierung (PTA) und Seamless Single Sign-On (ich nenne es 3SO) ermöglichen Ihren Benutzern den einfachen Zugriff auf Azure AD-Anwendungen wie Office 365, ohne dass Sie eine komplizierte Active Directory Federation Services (AD FS)-Farm in Ihrem Rechenzentrum installieren oder die Kennwort-Hashes der Benutzer 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 verwendet heute Active Directory als Identitätsdienst, und das wird auch so schnell nicht verschwinden. Wenn Sie also planen, einen der Online-Dienste von Microsoft zu nutzen, müssen Sie zunächst Ihr lokales Active Directory mit Azure AD integrieren, um zwei Funktionen zu nutzen. Erstens müssen Sie die AD-Konten und -Gruppen mit Azure AD über Azure AD Connect 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 Benutzerauthentifizierung.

Heute stehen Ihnen zwei Authentifizierungsmöglichkeiten von Microsoft zur Verfügung: AD FS, das Identitätsverbund (und eine Reihe anderer Funktionen) für SSO bietet, und die Kennwortsynchronisierung ("PHS" in den Tabellen unten). Diese zweite Option, die den Digerati als Kennwort-Hash-Synchronisierung (daher das "H") bekannt ist, ermöglicht eine "gleiche Anmeldung", bei der der Benutzer seine Anmeldedaten ein zweites Mal eingeben muss, um sich bei Azure AD anzumelden, wobei es sich jedoch um dieselbe Benutzerkennung und dasselbe Kennwort handelt, das er 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):

Abbildung 1: Legacy Azure AD Authentifizierungsmöglichkeiten (Microsoft)
Abbildung 1: Legacy Azure AD Authentifizierungsmöglichkeiten (Microsoft)

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

  • Nur Cloud-Konten: Benutzerkonten werden in Azure AD verwaltet und authentifiziert. Da wir in diesem Beitrag über hybride Lösungen sprechen, lassen wir dies beiseite.
  • AAD Connect / Cloud-Konten: Sie können Azure AD Connect verwenden, um Benutzerkonten mit Azure AD zu synchronisieren, so dass die Anmelde-ID (in der Regel die E-Mail-Adresse des Benutzers) dieselbe ist, aber die Benutzer müssen ihre eigenen Kennwörter im Cloud-Dienst verwalten. Ich sehe niemanden, 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, klafft eine große Lücke in der Komplexität der Implementierung, um echtes SSO in Ihrem Unternehmen einzuführen. Lösungen von Drittanbietern wie Okta, Ping Identity, OneLogin, Centrify, OptimalIDM und anderen bieten einfachere Authentifizierungsmethoden, die in diese Lücke passen, und das 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 Gruppen einzuteilen: Der Client, der von Azure AD authentifiziert werden soll, hat ein Kerberos-Ticket oder er hat keins.

Das erste ist das klassische Windows-Unternehmensauthentifizierungsszenario, bekannt als Integrierte Windows-Authentifizierung (IWA). Ein Benutzer, der mit einem AD-Konto an seinem der Domäne angeschlossenen Windows-Arbeitsplatzrechner im Unternehmensnetzwerk angemeldet ist (d.h. der Arbeitsplatzrechner kann einen Domänencontroller 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, seit Active Directory erfunden wurde.

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, egal 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)

Schauen wir uns zunächst das Szenario der domänenverbundenen Workstations an und die elegante Lösung von Microsoft mit 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 war's schon. Auf das Wesentliche reduziert, 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 verstehen kann - insbesondere ein Service-Ticket für eine Azure-Ressource - brauchen Sie den AD FS-Mittelsmann nicht, um die Übersetzung vorzunehmen.

Abbildung 2 zeigt, wie das gemacht wird. Azure AD wird in Ihrem lokalen AD einfach als ein weiterer Computer dargestellt; AD kennt den Unterschied nicht. Ein Computerkonto (AZUREADSSOACCT) wird zu Ihrem AD hinzugefügt und mit ihm zwei SPNs (Service Principal Names), die URLs enthalten, die zur Durchführung der Authentifizierung benötigt werden. Der geheime Kerberos-Schlüssel für das Workstation-Konto wird sicher mit Azure AD geteilt. Von nun an verwenden Clients IWA, um auf Azure-Ressourcen zuzugreifen, genauso wie sie auf einen IIS-Server in Ihrem lokalen Rechenzentrum zugreifen würden.

Abbildung 2: Nahtloses SSO zu Azure AD (Microsoft)
Abbildung 2: Nahtloses SSO zu Azure AD (Microsoft)
  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 legt seinem Domänencontroller sein TGT (Ticket-Gewährungsticket) und den SPN des Zielservers (in diesem Fall eine Azure AD URL) vor.
  3. Der Ticket Granting Service (TGS) im Key Distribution Center (KDC) des Domain Controllers erstellt ein Service-Ticket für die Azure AD-Ressource und sendet 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.

Beachten Sie, dass dieser Vorgang nicht bedeutet, dass der Benutzer zum Zugriff auf die Ressource berechtigt ist, sondern nur, dass er sich authentifiziert hat. Das Ergebnis ist, dass ein Windows-Benutzer im Netzwerk nicht aufgefordert wird, ein Passwort einzugeben, um auf Azure AD-Ressourcen zuzugreifen, und AD FS ist nicht erforderlich. Ziemlich raffiniert, oder?

Die Installation von 3SO ist denkbar einfach: Sie aktivieren einfach das Kontrollkästchen "Single Sign On aktivieren" in der benutzerdefinierten Konfiguration der neuesten Version von AD Connect.

Unterstützte Kunden

Es gibt eine Reihe von unterstützten Konfigurationen für 3SO. Erstens muss es sich um einen Client handeln, der Kerberos unterstützt, z. B. Windows. Zweitens funktioniert es für den Zugriff auf Azure AD-Ressourcen über einen Browser (z.B. https://outlook. office.com) oder von einem Office-Client aus, der moderne Authentifizierung unterstützt. Sie können die Liste der unterstützten Clients einsehen, aber im Wesentlichen wird es von allen gängigen Browsern (IE, Chrome, Firefox) außer Edge und allen unterstützten Microsoft Client-Betriebssystemen unterstützt. Microsoft empfiehlt, 3SO für alle Clients zu aktivieren. Wenn sich der Benutzer in einer nicht unterstützten Konfiguration befindet, wird er schlimmstenfalls eine Passwortabfrage erhalten.

Was ist Passthrough-Authentifizierung?

PTA wurde für den Anwendungsfall entwickelt, in dem der Client kein Kerberos-Ticket besitzt, entweder weil der Kerberos-Client keinen DC erreichen kann (z.B. wenn ein Mitarbeiter von zu Hause aus an seinem Firmen-Notebook arbeitet) oder weil der Client Kerberos nicht unterstützt (z.B. ein mobiler Browser oder eine App, die keine moderne Authentifizierung unterstützt).

Ich werde hier nicht auf die Installation von PTA eingehen, aber im Wesentlichen stellen Sie einen oder mehrere leichtgewichtige Konnektoren vor Ort, ähnlich wie den Azure AD Application Proxy-Konnektor, auf domänenverbundenen Servern bereit, wo sie mit einem DC 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).

Abbildung 3: Prozessablauf der Passthrough-Authentifizierung (Microsoft)
Abbildung 3: Prozessablauf der Passthrough-Authentifizierung (Microsoft)
  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 Connector, der 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 sind keine Zertifikate zu verwalten.

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
  • Die Sicherheitsrichtlinien Ihres Unternehmens verlangen, dass Passwörter immer in den Räumlichkeiten verbleiben (im Gegensatz zu AD FS wird das Passwort des Benutzers in PTA in Azure AD eingegeben, bevor es in die Räumlichkeiten gelangt).
  • 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 müssen Sie AD FS haben, wenn Sie lokal vertrauenswürdige Parteien für SSO konfiguriert haben, die Sie nicht zu Azure AD verschieben 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):

Abbildung 4: Möglichkeiten der Azure AD-Authentifizierung (Microsoft)
Abbildung 4: Möglichkeiten der Azure AD-Authentifizierung (Microsoft)

Die ursprünglichen Optionen sind nach wie vor verfügbar, aber Sie können jetzt einen großen Nutzen mit sehr wenig zusätzlicher Komplexität erzielen. Wenn Sie die Kennwortsynchronisierung verwenden, beseitigt das Hinzufügen von 3SO die Kennwortherausforderungen für Ihre Unternehmensnutzer im Netzwerk. Wenn Sie stattdessen PTA zusammen mit 3SO aktivieren, haben Sie praktisch den gleichen Wert wie AD FS für den speziellen Anwendungsfall der Azure AD-Authentifizierung.

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

Und falls es noch nicht klar ist: Das alles ist kostenlos. Microsoft hat seine Zukunft auf seine Azure-Cloud-Dienste gesetzt. Das Unternehmen möchte die Nutzung dieser Dienste so einfach wie möglich machen, und in der heutigen Active Directory-zentrierten Welt bedeutet das, dass die AD-Integration mit Azure AD schnell und schmerzlos erfolgen muss. Es hat ewig gedauert, diese Funktionen ans Tageslicht zu bringen, aber ich sage voraus, dass sie schnell zur beliebtesten Identitätsbrücke zwischen der Microsoft-Identität vor Ort und der Microsoft-Identität in der Cloud werden.