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

Das Diagramm erläutert den Fluss, wenn ein Benutzer versucht, auf eine lokale Anwendung zuzugreifen, die IWA verwendet.

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.
• Stellen Sie sicher, dass der Connectorserver das TokenGroupsGlobalAndUniversal Attribut für Benutzer lesen kann. Die Sicherheitshärtung schränkt diesen Zugriff möglicherweise ein. Aktivieren Sie die Connectorserver, indem Sie sie der Windows-Autorisierungszugriffsgruppe hinzufügen.

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. Mit der Einstellung kann der private Netzwerkconnector als Benutzer im Active Directory agieren, um auf die in der Liste definierten Anwendungen zuzugreifen.

   

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. Um die Kerberos-Authentifizierungsdelegierung vom Anwendungsproxy (Connector) zu aktivieren, verwenden Sie die PrincipalsAllowedToDelegateTo Eigenschaft des Dienstkontos der Webanwendung (webserviceaccount). Der Anwendungsserver wird unter webserviceaccountausgeführt, und der delegierende Server ist connectorcomputeraccount. Führen Sie die folgenden Befehle auf einem Domänencontroller (Windows Server 2012 R2 oder höher) in derselben Domäne aus wie webserviceaccount. Verwenden Sie flache Namen (Nicht-UPN) für beide Konten.

   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. Nachdem Ihre Anwendung in der Liste der Unternehmensanwendungen angezeigt wird, wählen Sie sie aus, und wählen Sie einmaliges Anmelden aus.

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. Der SPN muss sich in der Diensteliste befinden, für die der Connector delegierte Anmeldeinformationen übermitteln 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. Der Prozess wird als Kerberos-Eingeschränkte Delegierung (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. Der Mechanismus wird auf dem Microsoft Entra-Anwendungsproxy unterstützt, ist jedoch 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 standardmäßiges Kerberos-Token erwarten, sollten über andere Connectors geleitet 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 die folgenden Befehle auf den Connectorservern aus, die SPNEGO benötigen.

   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 für Ihre Anwendungen gilt, müssen Sie das delegierte Anmeldeidentitätsfeld konfigurieren, um Ihre Cloudidentitäten mit Ihren Anwendungsidentitäten zu verbinden.

Bereitstellen von einmaligem Anmelden bei Ihren Apps mit dem Anwendungsproxy

Anwendungsproxy setzt voraus, dass Benutzer dieselbe Identität in der Cloud und lokal haben. Einige Organisationen müssen jedoch alternative IDs für die Anmeldung aufgrund von Unternehmensrichtlinien oder Anwendungsanforderungen verwenden. Sie können KCD weiterhin für einmaliges Anmelden aktivieren, indem Sie eine delegierte Anmeldeidentität für jede Anwendung konfigurieren. Diese Einstellung gibt an, welche Identität für einmaliges Anmelden verwendet werden soll.

Mit diesem Feature können Organisationen SSO aus der Cloud auf lokale Apps aktivieren, ohne dass Benutzer unterschiedliche Benutzernamen und Kennwörter verwalten müssen. Zu den häufigen Szenarios gehören:

• Verwenden mehrerer interner Domänen (z. B joe@us.contoso.com. , joe@eu.contoso.com) mit einer einzelnen Clouddomäne (z. B joe@contoso.com. ).
• Es gibt nicht routingfähige interne Domänennamen (z. B. joe@contoso.usa), während in der Cloud gültige Domänennamen verwendet werden.
• Wird ohne interne Domänennamen ausgeführt (z. B. joe).
• Zuweisen verschiedener Aliase für lokale Benutzer und in der Cloud (z. B joe-johns@contoso.com . vs. joej@contoso.com).

Mit dem Anwendungsproxy können Sie die Identität auswählen, die zum Abrufen des Kerberos-Tickets verwendet wird. Diese Einstellung ist pro Anwendung konfiguriert und unterstützt Systeme, die keine E-Mail-Formate oder alternative Anmeldemethoden erfordern.

Wenn delegierte Anmeldeidentität verwendet wird, ist der Wert möglicherweise 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 Name des lokalen SAM-Kontos für die 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. Die Konfiguration erfolgt im Rahmen des Anpassungsprozesses durch Ändern des Felds "Benutzerprinzipalname " 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 die Backend-Anwendung mit unerwarteten HTTP-Antworten rückmeldet, beginnen Sie die Problembehandlung, indem Sie das Ereignis 24029 bei der Anmeldungssitzung des Anwendung-Proxys auf dem Connector überprüfen. Das Feld "Benutzer" in den Ereignisdetails zeigt die identität an, die für die Delegierung verwendet wird. Um Sitzungsprotokolle zu aktivieren, wechseln Sie zur Ereignisanzeige, öffnen Sie das Menü "Ansicht ", und wählen Sie " Analyse- und Debugprotokolle anzeigen" aus.

Nächste Schritte

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