Azure AD Connect Pass-Through-Authentifizierung

Auf der Ignite 2017 wurde bekannt gegeben, dass Pass Through Authentication (PTA) die allgemeine Verfügbarkeit (GA) erreicht hat, sodass es sich nun um ein vollständig unterstütztes Szenario handelt.

Aber was ist PTA? Bei Office 365 gibt es Cloud-Identitäten, synchronisierte Identitäten und föderierte Identitäten. Die ersten beiden werden in Azure Active Directory authentifiziert, der letzte wird gegenüber lokalen Domänencontrollern authentifiziert. Dazu benötigen Sie eine ADFS-Infrastruktur, die aus mehreren internen ADFS-Servern und mehreren WAP-Servern (Windows Application Proxy) in der DMZ besteht, die als ADFS-Proxys fungieren. Oh, und alle Server müssen auch über einen Lastausgleich verfügen, um Redundanz und Skalierbarkeit zu gewährleisten.

PTA hingegen basiert auf Azure AD Connect und ist daher eine interessante Erweiterung der Synced Identities. PTA installiert einen Agenten auf dem Azure AD Connect-Server (AuthN-Agent), der Authentifizierungsanfragen von Azure AD entgegennimmt und diese an lokale Domänencontroller sendet. Der Vorteil der Authentifizierung gegenüber lokalen Domänencontrollern besteht darin, dass keine Passwörter (genauer gesagt Passwort-Hashes) in Azure Active Directory gespeichert werden.

Mein erster Gedanke war, wie ein Authentifizierungsmechanismus, der auf einem asynchronen Replikationstool basiert (Azure AD Connect synchronisiert Konten alle 30 Minuten und Kennwörter innerhalb von 2 Minuten), jemals eine zuverlässige und sichere Lösung sein könnte. Das Letzte, was Sie wollen, ist, dass Sie sich bei keinem Dienst in der Microsoft-Cloud authentifizieren können, weil Ihr Azure AD Connect-Server mit anderen Dingen beschäftigt ist (z. B. automatisch seine Engine aktualisieren).

Mein zweiter Gedanke war, wie sicher das sein könnte. Es gibt keine eingehende Verbindung zum Azure AD Connect-Server, es gibt nur eine ausgehende Verbindung auf den Ports 80 (wird nur für Sperrlisten für SSL-Zertifikate verwendet) und 443. Und auch die Kommunikation selbst sollte gesichert sein, also…. Aber jetzt, da PTA allgemein verfügbar ist, stehen mehr Informationen zur Verfügung und die Dinge werden klarer.

Authentifizierungsablauf

Für die Authentifizierung verwendet PTA einen „Service Bus“ in Azure. Der Service Bus ist eine Azure-Standardlösung, bei der Anwendungen Systemnachrichten im Service Bus speichern können und andere Anwendungen diese Systemnachrichten verwenden können. Mithilfe eines Servicebusses können Sie einen asynchronen, aber zuverlässigen Kommunikationsmechanismus erstellen.

Bei der Anmeldung bei einem Office 365-Dienst werden die Anmeldeinformationen von Azure Active Directory angefordert, hier gibt es nichts Neues. Die Anmeldeinformationen werden verschlüsselt und im Servicebus gespeichert. Der AuthN-Agent auf dem Azure AD Connect-Server verfügt über eine dauerhafte Verbindung zu Azure AD und zum Service Bus und ruft die verschlüsselten Anmeldeinformationen vom Service Bus ab, entschlüsselt sie und präsentiert sie dem lokalen Domänencontroller. Die Antwort des Domänencontrollers (Erfolg, Fehler, Kennwort abgelaufen oder Benutzer gesperrt) wird an den AuthN-Agenten zurückgegeben und auf dem Servicebus gespeichert. Azure AD nimmt diese Antwort auf und der Benutzer kann weiterarbeiten (oder natürlich auch nicht, abhängig von der Antwort des Domänencontrollers).

Wie funktioniert also die Verschlüsselung? Während der Installation generiert der Azure AD Connect-Server ein Schlüsselpaar. Der öffentliche Schlüssel wird an Azure AD gesendet und ein Zertifikat erstellt. Dieses Zertifikat wird an den Azure AD Connect-Server zurückgegeben und mit dem privaten Schlüssel kombiniert. Der öffentliche Schlüssel wird zum Verschlüsseln der Anmeldeinformationen des Benutzers verwendet, und der Azure AD Connect-Server ist der einzige, der über den privaten Schlüssel zum Entschlüsseln des Schlüsselpaars verfügt. Voila

Konfigurieren der Passthrough-Authentifizierung

Sie aktivieren PTA mit Azure AD Connect. Früher war das Synchronisierungstool das, was sein Name andeutete, aber mit Azure AD Connect ähnelt es eher einem Verwaltungstool, mit dem Sie alle Arten von Identitätsoptionen verwalten.

Damit PTA auf dem Azure AD Connect-Server aktiviert werden kann, gelten die folgenden Anforderungen:

Azure AD Connect Version 1.1.557.0 oder höher muss unter Windows 2012 R2 ausgeführt werden.
Der ausgehende Port 80/443 muss geöffnet werden

Hinweis: Sie können die neueste Version von Azure AD Connect hier herunterladen: https://www.microsoft.com/en-us/download/details.aspx?id=47594. Als ich den Blogbeitrag schrieb, war die neueste Version von Azure AD Connect 1.1.647.0

In meiner Umgebung hatte ich Azure AD Connect bereits eingerichtet (mit Passwort-Hash-Synchronisierung), sodass ich nur noch die Konfiguration ändern musste.

Starten Sie Azure AD Connect, wählen Sie Konfigurieren und dann Benutzeranmeldung ändern.

Klicken Sie auf Weiter und geben Sie die Anmeldeinformationen des Mandantenadministrators ein. Diese Anmeldeinformationen werden benötigt, um sich bei Azure Active Directory anzumelden, PTA in Azure AD zu aktivieren und das Zertifikat zu erstellen.

Klicken Sie auf Weiter, um zur Benutzeranmeldeseite zu gelangen. Hier haben Sie vier Möglichkeiten:

Passwortsynchronisierung (falscher Name, sollte Passwort-Hash-Synchronisierung lauten).
Pass-Through-Authentifizierung (das Thema dieses Blogs).
Föderation mit AD FS (zukünftiger Blog).
Nicht konfigurieren (bei Verwendung einer Verbundlösung eines Drittanbieters wie Okta).

Über die Checkbox kann Single Sign-On aktiviert werden.

Wählen Sie Passthrough-Authentifizierung und klicken Sie auf Weiter, um fortzufahren. Beachten Sie die Empfehlung am Ende der Seite. Das macht Sinn. Denken Sie daran, dass die Einstellung von PTA eine mandantenweite Einstellung ist, sodass alle Konten in Ihrem Mandanten gezwungen sind, PTA zu verwenden. Wenn in Ihrem Netzwerk etwas schief geht und keiner der AuthN-Agenten verfügbar ist, kann sich niemand mehr anmelden. Daher benötigen Sie ein reines Cloud-Administratorkonto mit einem @.onmicrosoft.com-Benutzernamen.

Wenn Sie auf Weiter klicken, sucht der Azure AD Connect-Assistent nach installierten Komponenten und wenn alles gut gelaufen ist, können Sie mit dem Konfigurationsprozess beginnen.

Klicken Sie auf Konfigurieren, um die Konfiguration zu starten. In meinem Fall wechsle ich von der Passwortsynchronisierung zur Passthrough-Authentifizierung, sodass keine Änderungen an der Synchronisierung vorgenommen werden müssen. Andernfalls deaktivieren Sie das Kontrollkästchen Synchronisierungsprozess starten, wenn die Konfiguration abgeschlossen ist, um Änderungen an der Synchronisierung vorzunehmen, bevor sie stattfindet. Nach wenigen Augenblicken sollten die Änderungen abgeschlossen sein.

Klicken Sie auf Beenden, um den Assistenten zu beenden.

Wenn Sie sich beim Azure-Portal anmelden, wählen Sie Azure Active Directory aus und klicken Sie auf die Kachel „Azure AD Connect“. Sie sehen, dass die Passthrough-Authentifizierung jetzt aktiviert ist:

Was sehen Sie also, wenn Sie sich beispielsweise bei Outlook Web App in Exchange Online anmelden? Nichts Besonderes, Sie sehen die Standard-Azure AD-Anmeldeseite (über https://login.microsoftonline.com) und können nach Eingabe Ihrer Anmeldeinformationen auf Ihr Exchange Online-Postfach zugreifen.

Wenn Sie das Sicherheitsereignisprotokoll auf dem Azure AD Connect-Server öffnen, können Sie nach Ereignis 4624 suchen. Dies zeigt Ihnen, dass das Benutzerkonto tatsächlich gegenüber einem lokalen Domänencontroller authentifiziert wurde:

Dies ist (mir bekannt) einer der wenigen Orte, an denen Sie tatsächlich PTA-Authentifizierungskonten überprüfen können.

Azure AD Connect-Agent nicht verfügbar

Was passiert, wenn der Azure AD Connect-Agent nicht verfügbar ist? Die Benutzer können sich nicht mehr anmelden. Um dies zu simulieren, können Sie den Microsoft Azure AD Connect-Authentifizierungsagenten im Dienst-MMC-Snap-In stoppen.

Wenn Sie beispielsweise versuchen, sich bei OWA anzumelden, geben Sie die Anmeldeinformationen im Microsoft Online-Anmeldeportal ein und nach einigen Sekunden wird eine nicht beschreibende Fehlermeldung angezeigt:

Redundanz bei der Pass-Through-Authentifizierung

Um dieses Problem zu beheben, können Sie den AuthN-Agenten auf mehreren Computern installieren. Persönlich empfehle ich nicht, dies auf Domänencontrollern zu installieren, sondern sollte nur auf einem normalen Windows 2012 R2-Server oder höher installiert werden.

Wenn Sie am Server angemeldet sind, öffnen Sie das Azure-Portal (https://portal.azure.com), wählen Sie Azure Active Directory aus, klicken Sie auf die Kachel Azure AD Connect und klicken Sie auf Passthrough-Authentifizierung.

Klicken Sie auf Bedingungen akzeptieren und herunterladen, um den Download zu starten. Nach dem Herunterladen installieren Sie einfach den Agenten, geben bei Aufforderung die Anmeldeinformationen des Mandantenadministrators ein und nach weniger als einer Minute ist der Agent installiert.

Wie viele Instanzen benötigen Sie? Wenn Sie über eine größere Umgebung verfügen, werden drei Instanzen empfohlen. Zwei können ausreichen, aber wenn einer gerade automatisch aktualisiert wird und dies fehlschlägt, reicht ein verbleibender Server möglicherweise nicht aus, wenn eine große Anzahl von Authentifizierungsanfragen bearbeitet wird.

Unterstützte Kunden

Wenn es um Clients und unterstützte Szenarien geht, wird Folgendes unterstützt:

Melden Sie sich bei allen webbrowserbasierten Anwendungen an.
Office 2013 und Office 2016, die moderne Authentifizierung unterstützen.
Mit Windows 10 Azure AD verbundene Geräte.
Exchange ActiveSync.

Die folgenden Clients und Szenarios werden nicht unterstützt:

Ältere Office-Clientanwendungen (2010/2013 ohne moderne Authentifizierung).
Skype for Business-Clientanwendungen (einschließlich SfB 2016-Client!).
PowerShell 1.0.
Azure AD-Domänendienste.
App-Passwörter für MFA.
Erkennung von Benutzern mit geleakten Anmeldeinformationen.

Mit Ausnahme der Skype for Business-Clients ist diese Liste jedoch nicht überraschend. Stand der Liste ist Oktober 2017.

Zusammenfassung

Die Passthrough-Authentifizierung ist ab Ignite 2017 allgemein verfügbar. Dabei handelt es sich um einen Authentifizierungsmechanismus, bei dem keine Passwort-Hashes in Azure AD gespeichert werden. Es ist außerdem viel leichter als ADFS, weniger komplex und einfacher zu verwalten.

Wird es ADFS ersetzen? Nicht kurzfristig. Derzeit werden moderne Microsoft-Anwendungen unterstützt, die den Azure Service Bus und verwandte Lösungen nutzen können. Andere Drittanbieteranwendungen (Tausende davon), die im App Store verfügbar sind, sind immer noch auf ADFS angewiesen und werden dies auch noch einige Zeit tun.

Weitere Informationen finden Sie unter https://docs.microsoft.com/en-us/azure/active-directory/connect/active-directory-aadconnect-pass-through-authentication-quick-start