Eingeschränkte Kerberos-Delegierung für einmaliges Anmelden (SSO) bei Ihren Apps mit dem Anwendungsproxy

Sie können einmaliges Anmelden für lokale Anwendungen bereitstellen, die über den Anwendungsproxy veröffentlicht und mit der integrierten Windows-Authentifizierung geschützt werden. Diese Anwendungen erfordern ein Kerberos-Ticket für den Zugriff. Der Anwendungsproxy verwendet die eingeschränkte Kerberos-Delegierung (KCD) zur Unterstützung dieser Anwendungen.

Weitere Informationen zum einmaligen Anmelden (SSO) finden Sie unter Worum handelt es sich beim einmaligen Anmelden?.

Sie können für Anwendungen, die die integrierte Windows-Authentifizierung (IWA) verwenden, einmaliges Anmelden wie folgt aktivieren: Erteilen Sie privaten Netzwerkconnectors in Active Directory die Berechtigung, die Identität von Benutzern anzunehmen. Die Connectors verwenden diese Berechtigung zum Senden und Empfangen von Token im Auftrag dieser.

So funktioniert das einmalige Anmelden mit KCD

Dieses Diagramm erläutert den Flow, der beim Zugriff eines Benutzers auf eine lokale Anwendung mit IWA abläuft.

1. Benutzer geben die URL ein, um über den Anwendungsproxy auf die lokale Anwendung zuzugreifen.
2. Der Anwendungsproxy leitet die Anforderung zur Vorauthentifizierung an Microsoft Entra-Authentifizierungsdienste weiter. Zu diesem Zeitpunkt wendet Microsoft Entra ID alle gültigen Authentifizierungs- und Autorisierungsrichtlinien an, wie z. B. Multi-Faktor-Authentifizierung. Nachdem der Benutzer überprüft wurde, erstellt Microsoft Entra ID ein Token und sendet es an den Benutzer.
3. Die Benutzer übergeben das Token an den Anwendungsproxy.
4. Der Anwendungsproxy überprüft das Token und ruft den Benutzerprinzipalnamen (UPN) daraus ab. Dann pullt der Connector den UPN und den Dienstprinzipalnamen (SPN) über einen zweifach authentifizierten, sicheren Kanal.
5. Der Connector führt eine KCD-Aushandlung (Kerberos Constrained Delegation, eingeschränkte Kerberos-Delegierung) mit der lokalen AD-Instanz durch und nimmt dabei die Identität des Benutzers an, um ein Kerberos-Token für die Anwendung zu erhalten.
6. Active Directory sendet das Kerberos-Token für die Anwendung an den Connector.
7. Der Connector sendet die ursprüngliche Anforderung an den Anwendungsserver und verwendet dabei das von AD empfangene Kerberos-Token.
8. Die Anwendung sendet die Antwort an den Connector, die dann an den Anwendungsproxydienst und schließlich an den Benutzer oder die Benutzerin zurückgegeben wird.

Voraussetzungen

Vergewissern Sie sich vor Ihren ersten Schritten mit dem einmaligen Anmelden für IWA-Anwendungen, dass Ihre Umgebung über folgende Einstellungen und Konfigurationen verfügt:

• Ihre Apps (beispielsweise SharePoint-Web-Apps) sind für die Verwendung der integrierten Windows-Authentifizierung konfiguriert. Weitere Informationen finden Sie unter Aktivieren der Unterstützung für die Kerberos-Authentifizierung. Weitere Informationen zu SharePoint finden Sie unter Planen der Kerberos-Authentifizierung in SharePoint 2013.
• Alle Ihre Apps verfügen über Dienstprinzipalnamen.
• Der Server, auf dem der Connector ausgeführt wird, und der Server, auf dem die App ausgeführt wird, gehören einer Domäne an und sind Teil der gleichen Domäne bzw. der vertrauenswürdigen Domänen. Weitere Informationen zum Domänenbeitritt finden Sie unter Hinzufügen eines Computers zu einer Domäne.
• Der Server, auf dem der Connector ausgeführt wird, verfügt über Lesezugriff auf das Attribut „TokenGroupsGlobalAndUniversal“ für Benutzer. Hierbei handelt es sich um eine Standardeinstellung, die unter Umständen im Rahmen einer Sicherheitshärtung für die Umgebung geändert wurde. Normalerweise wird dies durch Hinzufügen der Connectorserver zur „Windows-Autorisierungszugriffsgruppe“ erreicht.

Konfigurieren von Active Directory

Die Active Directory-Konfiguration variiert in Abhängigkeit davon, ob Ihr privater Netzwerkconnector und der Anwendungsserver sich in derselben Domäne befinden.

Connector und Anwendungsserver in der gleichen Domäne

1. Wechseln Sie in Active Directory zu Extras>Benutzer und Computer.

2. Wählen Sie den Server aus, der den Connector ausführt.

3. Klicken Sie mit der rechten Maustaste, und wählen Sie Eigenschaften>Delegierung aus.

4. Wählen Sie Computer nur bei Delegierungen angegebener Dienste vertrauen.

5. Wählen Sie die Option Beliebiges Authentifizierungsprotokoll verwenden aus.

6. Fügen Sie unter Dienste, für die dieses Konto delegierte Anmeldeinformationen verwenden kann den Wert für die Dienstprinzipalnamen-Identität (SPN) des Anwendungsservers hinzu. Auf diese Weise kann der private Netzwerkconnector die Identität von Benutzern in AD für die Anwendungen annehmen, die in der Liste definiert sind.

   

Connector und Anwendungsserver in unterschiedlichen Domänen

1. Eine Liste der Voraussetzungen für das domänenübergreifende Arbeiten mit KCD finden Sie unter Eingeschränkte Kerberos-Delegierung über Domänengrenzen hinweg.

2. Verwenden Sie die principalsallowedtodelegateto-Eigenschaft des Dienstkontos (Computerkonto oder dediziertes Domänenbenutzerkonto) der Webanwendung, um die Kerberos-Authentifizierungsdelegierung über den Anwendungsproxy (Connector) zu aktivieren. Der Anwendungsserver wird im Kontext webserviceaccount ausgeführt. Der delegierende Server ist connectorcomputeraccount. Führen Sie die folgenden Befehle auf einem Domänencontroller (mit Windows Server 2012 R2 oder einer höheren Version) in der Domäne webserviceaccount aus. Verwenden Sie für beide Konten Flatnames (keine UPNs).

   Ist webserviceaccount ein Computerkonto, verwenden Sie die folgenden Befehle:

   $connector= Get-ADComputer -Identity connectorcomputeraccount -server dc.connectordomain.com
   
   Set-ADComputer -Identity webserviceaccount -PrincipalsAllowedToDelegateToAccount $connector
   
   Get-ADComputer webserviceaccount -Properties PrincipalsAllowedToDelegateToAccount
   

   Ist webserviceaccount ein Benutzerkonto, verwenden Sie die folgenden Befehle:

   $connector= Get-ADComputer -Identity connectorcomputeraccount -server dc.connectordomain.com
   
   Set-ADUser -Identity webserviceaccount -PrincipalsAllowedToDelegateToAccount $connector
   
   Get-ADUser webserviceaccount -Properties PrincipalsAllowedToDelegateToAccount
   

Einmaliges Anmelden konfigurieren

1. Veröffentlichen Sie Ihre Anwendung entsprechend den Anweisungen unter Veröffentlichen von Anwendungen mit einem Anwendungsproxy. Stellen Sie sicher, dass Sie Microsoft Entra ID als Vorauthentifizierungsmethode auswählen.

2. Wenn Ihre Anwendung in der Liste der Unternehmensanwendungen angezeigt wird, wählen Sie sie aus, und klicken auf Einmaliges Anmelden.

3. Legen Sie den Modus für einmaliges Anmelden auf Integrierte Windows-Authentifizierung fest.

4. Geben Sie den Wert für Interner Anwendungs-SPN des Anwendungsservers ein. In diesem Beispiel ist der SPN für die veröffentlichte Anwendung http/www.contoso.com. Dieser SPN muss sich in der Liste mit Diensten befinden, an die der Connector delegierte Anmeldeinformationen ausgeben kann.

5. Wählen Sie die delegierte Identität für die Anmeldung für den zu verwendenden Connector im Auftrag Ihrer Benutzer. Weitere Informationen finden Sie unter Bereitstellen von einmaligem Anmelden bei Ihren Apps mit dem Anwendungsproxy.

   

SSO für Nicht-Windows-Apps

Der Kerberos-Delegierungsflow im Microsoft Entra-Anwendungsproxy beginnt, wenn Microsoft Entra den Benutzer in der Cloud authentifiziert. Nachdem die Anforderung lokal ankommt, gibt der private Microsoft Entra-Netzwerkconnector durch Interaktion mit dem lokalen Active Directory ein Kerberos-Ticket für den Benutzer aus. Dieser Prozess wird als Kerberos Constrained Delegation (KCD) bezeichnet.

In der nächsten Phase wird mit diesem Kerberos-Ticket eine Anforderung an die Back-End-Anwendung gesendet.

Es gibt mehrere Mechanismen, die definieren, wie das Kerberos-Ticket in solchen Anforderungen gesendet wird. Die meisten Nicht-Windows-Server erwarten, es in Form eines SPNEGO-Tokens zu erhalten. Dieser Mechanismus wird auf dem Microsoft Entra-Anwendungsproxy unterstützt, ist aber standardmäßig deaktiviert. Ein Connector kann für SPNEGO oder das standardmäßige Kerberos-Token konfiguriert werden, jedoch nicht für beide.

Wenn Sie einen Connectorcomputer für SPNEGO konfigurieren, stellen Sie sicher, dass alle anderen Connectors in dieser Connectorgruppe ebenfalls mit SPNEGO konfiguriert sind. Anwendungen, die ein standardmäßiges Kerberos-Token erwarten, sollten über andere Connectors weitergeleitet werden, die nicht für SPNEGO konfiguriert sind. Einige Webanwendungen akzeptieren beide Formate, ohne dass eine Änderung der Konfiguration erforderlich ist.

So aktivieren Sie SPNEGO:

1. Öffnen Sie eine Eingabeaufforderung, die mit Administratorrechten ausgeführt wird.

2. Führen Sie an der Eingabeaufforderung für die Connectorserver, die SPNEGO benötigen, die folgenden Befehle aus.

   REG ADD "HKLM\SOFTWARE\Microsoft\Microsoft Entra private network connector" /v UseSpnegoAuthentication /t REG_DWORD /d 1
   net stop WAPCSvc & net start WAPCSvc
   

Nicht-Windows-Apps verwenden normalerweise Benutzernamen oder Namen von SAM-Konten statt E-Mail-Adressen von Domänen. Wenn diese Situation auf Ihre Anwendungen zutrifft, müssen Sie das Feld „Delegierte Identität für Anmeldung“ konfigurieren, um Ihre Cloudidentitäten mit Ihren Anwendungsidentitäten zu verbinden.

Bereitstellen von einmaligem Anmelden bei Ihren Apps mit dem Anwendungsproxy

Der Anwendungsproxy geht davon aus, dass Benutzer in der Cloud dieselbe Identität wie lokal besitzen. In einigen Umgebungen müssen Organisationen jedoch aufgrund von Unternehmensrichtlinien oder Anwendungsabhängigkeiten möglicherweise alternative IDs für die Anmeldung verwenden. In solchen Fällen können Sie weiterhin KCD für das einmalige Anmelden verwenden. Konfigurieren Sie eine Delegierte Identität für Anmeldung für jede Anwendung, um anzugeben, welche Identität bei der Durchführung des einmaligen Anmeldens verwendet werden soll.

Diese Funktion ermöglicht vielen Organisationen mit unterschiedlichen lokalen Identitäten und Cloudidentitäten SSO aus der Cloud auf lokale Apps, ohne dass der Benutzer unterschiedliche Benutzernamen und Kennwörter eingeben muss. Hierzu gehören Organisationen mit folgenden Merkmalen:

• Sie besitzen intern mehrere Domänen (joe@us.contoso.com, joe@eu.contoso.com) und eine einzelne Domäne in der Cloud (joe@contoso.com).
• Sie besitzen intern einen nicht routingfähigen Domänennamen (joe@contoso.usa) und einen zulässigen Namen in der Cloud.
• Sie verwenden intern keine Domänennamen (Joe).
• Sie verwenden lokal und in der Cloud unterschiedliche Aliase. Beispiel, joe-johns@contoso.com vs. joej@contoso.com

Mit dem Anwendungsproxy können Sie auswählen, welche Identität verwendet werden soll, um das Kerberos-Ticket zu erhalten. Diese Einstellung erfolgt pro Anwendung. Einige dieser Optionen eignen sich für Systeme, die kein E-Mail-Adressformat akzeptieren, andere sind auf eine alternative Anmeldung ausgelegt.

Bei Verwendung der Delegierten Identität für Anmeldung ist der Wert unter Umständen nicht für alle Domänen oder Gesamtstrukturen in Ihrer Organisation eindeutig. Sie können dieses Problem umgehen, indem Sie die Anwendung zweimal mit zwei unterschiedlichen Connectorgruppen veröffentlichen. Da jede Anwendung einen anderen Benutzerkreis aufweist, lassen sich die Connectors mit einer unterschiedlichen Domäne verknüpfen.

Wenn der lokale SAM-Kontoname als Anmeldeidentität verwendet wird, muss der Computer, auf dem der Connector gehostet wird, der Domäne hinzugefügt werden, in der sich das Benutzerkonto befindet.

Konfigurieren von SSO für verschiedene Identitäten

1. Konfigurieren Sie die Microsoft Entra Connect-Einstellungen so, dass die E-Mail-Adresse die Hauptidentität ist. Dies erfolgt als Teil des Anpassungsvorgangs durch Änderung des Benutzerprinzipalnamens in den Synchronisierungseinstellungen. Diese Einstellungen legen auch fest, wie sich Benutzer bei Microsoft 365, Windows-Computern und anderen Anwendungen anmelden, die Microsoft Entra ID als Identitätsspeicher verwenden.
   

2. Wählen Sie in den Anwendungskonfigurationseinstellungen für die zu modifizierende Anwendung die Delegierte Identität für Anmeldung aus:

   • Benutzerprinzipalname (z.B. joe@contoso.com)
   • Alternativer Benutzerprinzipalname (z.B. joed@contoso.local)
   • Benutzernamensteil des Benutzerprinzipalnamens (z. B. joe)
   • Benutzernamensteil des alternativen Benutzerprinzipalnamens (z. B. joed)
   • Lokaler SAM-Kontoname (je nach Konfiguration des lokalen Domänencontrollers)

Problembehandlung bei SSO für verschiedene Identitäten

Wenn im SSO-Prozess ein Fehler auftritt, wird dieser im Ereignisprotokoll des Connectorcomputers aufgeführt, wie unter Problembehandlungbeschrieben. In einigen Fällen wird die Anforderung jedoch erfolgreich an die Back-End-Anwendung gesendet, während die Anwendung mit verschiedenen anderen HTTP-Antworten reagiert. Die Problembehandlung beginnt in diesen Fällen zweckmäßigerweise mit der Untersuchung der Ereignisnummer 24029 auf dem Connectorcomputer im Sitzungsereignisprotokoll des Anwendungsproxys. Die Benutzeridentität, die für die Delegierung verwendet wurde, wird im Feld „Benutzer“ in den Ereignisdetails angezeigt. Wählen Sie zum Aktivieren des Sitzungsprotokolls im Menü „Ansicht“ der Ereignisanzeige die Option Analytische und Debugprotokolle einblenden aus.

Nächste Schritte

• Konfigurieren einer Anwendungsproxyanwendung zum Verwenden der eingeschränkten Kerberos-Delegierung
• Problembehandlung von Anwendungsproxys