Behandeln von SSO-Problemen mit Active Directory-Verbunddienste (AD FS) (AD FS)

2025-01-15

In diesem Artikel können Sie SSO-Probleme (Single Sign-On) mit Active Directory-Verbunddienste (AD FS) (AD FS) beheben.

Wählen Sie einen der folgenden Abschnitte entsprechend der Art des Auftretens eines Problems aus.

Gilt für: Active Directory-Verbunddienste (AD FS)
Ursprüngliche KB-Nummer: 4034932

NTLM- oder formularbasierte Authentifizierungsaufforderung

Wenn Benutzer unerwartete NTLM- oder formularbasierte Authentifizierungsaufforderungen erhalten haben, führen Sie während der Problembehandlung Probleme mit einmaligem Anmelden (Single Sign-On, SSO) mit Active Directory-Verbunddienste (AD FS) (AD FS) aus, wenn Benutzer unerwartete NTLM- oder formularbasierte Authentifizierungsaufforderungen erhalten haben.

Überprüfen der Einstellungen für die integrierte Windows-Authentifizierung

Um dieses Problem zu beheben, überprüfen Sie die Einstellungen der integrierten Windows-Authentifizierung im Clientbrowser, ad FS-Einstellungen und Authentifizierungsanforderungsparameter.

Überprüfen des Clientbrowsers des Benutzers

Überprüfen Sie die folgenden Einstellungen in den Internetoptionen:

Stellen Sie auf der Registerkarte "Erweitert " sicher, dass die Einstellung "Integrierte Windows-Authentifizierung aktivieren" aktiviert ist.
Stellen Sie sicher, dass sich die AD FS-URL im Anschluss an lokale Intranetwebsites>> in der Liste der Websites befindet.>
Stellen Sie nach der benutzerdefinierten Sicherheitsebene > für das lokale Intranet > sicher, dass die Einstellung "Automatische Anmeldung" nur in der Einstellung "Intranetzone" ausgewählt ist.

Wenn Sie Firefox, Chrome oder Safari verwenden, stellen Sie sicher, dass die entsprechenden Einstellungen in diesen Browsern aktiviert sind.

Überprüfen der AD FS-Einstellungen

Überprüfen der Einstellung "WindowsIntegratedFallback"

Öffnen Sie Windows PowerShell mit der Option Als Administrator ausführen .
Rufen Sie die globale Authentifizierungsrichtlinie ab, indem Sie den folgenden Befehl ausführen:
```
Get-ADFSGlobalAuthenticationPolicy | fl WindowsIntegratedFallbackEnabled
```
Untersuchen Sie den Wert des WindowsIntegratedFallbackEnabled-Attributs .

Wenn der Wert "True" lautet, wird die formularbasierte Authentifizierung erwartet. Dies bedeutet, dass die Authentifizierungsanforderung von einem Browser stammt, der die integrierte Windows-Authentifizierung nicht unterstützt. Im nächsten Abschnitt erfahren Sie, wie Sie Ihren Browser unterstützen.

Wenn der Wert "False" lautet, sollte die integrierte Windows-Authentifizierung erwartet werden.

Überprüfen der WIASupportedUsersAgents-Einstellung

Rufen Sie die Liste der unterstützten Benutzer-Agents ab, indem Sie den folgenden Befehl ausführen:
```
Get-ADFSProperties | Select -ExpandProperty WIASupportedUserAgents
```
Überprüfen Sie die Liste der vom Befehl zurückgegebenen Benutzer-Agent-Zeichenfolgen.

Überprüfen Sie, ob sich die Benutzer-Agent-Zeichenfolge Ihres Browsers in der Liste befindet. Wenn nicht, fügen Sie die Benutzer-Agent-Zeichenfolge hinzu, indem Sie die folgenden Schritte ausführen:

Wechseln Sie zu http://useragentstring.com/ dieser Erkennung und zeigt Ihnen die Benutzer-Agent-Zeichenfolge Ihres Browsers an.
Rufen Sie die Liste der unterstützten Benutzer-Agents ab, indem Sie den folgenden Befehl ausführen:
```
$wiaStrings = Get-ADFSProperties | Select -ExpandProperty WIASupportedUserAgents
```
Fügen Sie die Benutzer-Agent-Zeichenfolge Ihres Browsers hinzu, indem Sie den folgenden Befehl ausführen:
```
$wiaStrings = $wiaStrings+"NewUAString"
```
Beispiel:
```
$wiaStrings = $wiaStrings+" =~Windows\s*NT.*Edge"+"Mozilla/5.0"
```
Aktualisieren Sie die EINSTELLUNG WIASupportedUserAgents, indem Sie den folgenden Befehl ausführen:
```
Set-ADFSProperties -WIASupportedUserAgents $wiaStrings
```

Überprüfen der Authentifizierungsanforderungsparameter

Überprüfen, ob die Authentifizierungsanforderung formularbasierte Authentifizierung als Authentifizierungsmethode angibt

Wenn es sich bei der Authentifizierungsanforderung um eine WS-Verbundanforderung handelt, überprüfen Sie, ob die Anforderung "wauth= urn:oasis:names:tc:SAML:1.0:am:password" enthält.
Wenn es sich bei der Authentifizierungsanforderung um eine SAML-Anforderung handelt, überprüfen Sie, ob die Anforderung ein samlp:AuthnContextClassRef-Element mit dem Wert urn:oasis:names:tc:SAML:2.0:ac:classes:Password enthält.

Weitere Informationen finden Sie unter Übersicht über Authentifizierungshandler von AD FS-Anmeldeseiten.

Überprüfen, ob die Anwendung Microsoft Online Services für Office 365 ist

Wenn es sich bei der Anwendung, auf die Sie zugreifen möchten, nicht um Microsoft Online Services handelt, wird erwartet und von der eingehenden Authentifizierungsanforderung gesteuert. Arbeiten Sie mit dem Anwendungsbesitzer zusammen, um das Verhalten zu ändern.

Notiz

Azure AD- und MSOnline PowerShell-Module sind ab dem 30. März 2024 veraltet. Weitere Informationen finden Sie im Update zur Unterstützungseinstellung. Nach diesem Datum wird die Unterstützung für diese Module auf die Migrationsunterstützung für das Microsoft Graph PowerShell-SDK und Sicherheitskorrekturen beschränkt. Die veralteten Module funktionieren weiterhin bis zum 30. März 2025.

Es wird empfohlen, für die Interaktion mit Microsoft Entra ID (früher Azure AD) zu Microsoft Graph PowerShell zu migrieren. Informationen zu allgemeinen Migrationsfragen finden Sie in den häufig gestellten Fragen zur Migration. Hinweis: Bei der Version 1.0.x von MSOnline können nach dem 30. Juni 2024 Unterbrechungen auftreten.

Wenn es sich bei der Anwendung um Microsoft Online Services handelt, wird möglicherweise die Einstellung "PromptLoginBehavior " aus dem vertrauenswürdigen Bereichsobjekt gesteuert. Diese Einstellung steuert, ob Microsoft Entra-Mandanten prompt=login an AD FS senden. Führen Sie die folgenden Schritte aus, um die Einstellung "PromptLoginBehavior " festzulegen:

Öffnen Sie Windows PowerShell mit der Option "Als Administrator ausführen".
Rufen Sie die vorhandene Domänenverbundeinstellung ab, indem Sie den folgenden Befehl ausführen:
```
Get-MSOLDomainFederationSettings -DomainName DomainName | FL *
```
Legen Sie die Einstellung "PromptLoginBehavior" fest, indem Sie den folgenden Befehl ausführen:
```
Set-MSOLDomainFederationSettings -DomainName DomainName -PromptLoginBehavior <TranslateToFreshPasswordAuth|NativeSupport|Disabled> -SupportsMFA <$TRUE|$FALSE> -PreferredAuthenticationProtocol <WsFed|SAMLP>
```
Die Werte für den Parameter PromptLoginBehavior sind:
1. TranslateToFreshPasswordAuth: Microsoft Entra ID sendet wauth und wfresh an AD FS anstelle von prompt=login. Dies führt zu einer Authentifizierungsanforderung zur Verwendung der formularbasierten Authentifizierung.
2. NativeSupport: Der Parameter prompt=login wird wie an AD FS gesendet.
3. Deaktiviert: An AD FS wird nichts gesendet.

Weitere Informationen zum Befehl "Set-MSOLDomainFederationSettings" finden Sie unter Active Directory-Verbunddienste (AD FS) prompt=login parameter support.

Microsoft Entra-Szenario

Wenn die an die Microsoft Entra-ID gesendete Authentifizierungsanforderung den Parameter prompt=login enthält, deaktivieren Sie die Prompt=Login-Funktion, indem Sie den folgenden Befehl ausführen:

Set-MsolDomainFederationSettings –DomainName DomainName -PromptLoginBehavior Disabled

Nachdem Sie diesen Befehl ausgeführt haben, enthalten Office 365-Anwendungen nicht den Parameter "prompt=login" in jeder Authentifizierungsanforderung.

Nicht microsoft Entra-Szenario

Anforderungsparameter wie WAUTH und RequestedAuthNContext in Authentifizierungsanforderungen können Authentifizierungsmethoden angegeben haben. Überprüfen Sie, ob andere Anforderungsparameter die unerwartete Authentifizierungsaufforderung erzwingen. Ändern Sie in diesem Falls den Anforderungsparameter so, dass die erwartete Authentifizierungsmethode verwendet wird.

Überprüfen, ob SSO deaktiviert ist

Wenn SSO deaktiviert ist, aktivieren Sie es, und testen Sie, ob das Problem behoben ist.

Mehrstufige Authentifizierungsaufforderung

Um dieses Problem zu beheben, überprüfen Sie, ob die Anspruchsregeln in der vertrauenden Seite ordnungsgemäß für die mehrstufige Authentifizierung festgelegt sind.

Die mehrstufige Authentifizierung kann auf einem AD FS-Server, bei einer vertrauenden Seite oder in einem Authentifizierungsanforderungsparameter angegeben werden. Überprüfen Sie die Konfigurationen, um festzustellen, ob sie ordnungsgemäß festgelegt sind. Wenn die mehrstufige Authentifizierung erwartet wird, Sie aber wiederholt dazu aufgefordert werden, überprüfen Sie die Ausstellungsregeln der vertrauenden Seite, um festzustellen, ob mehrstufige Authentifizierungsansprüche an die Anwendung übergeben werden.

Weitere Informationen zur mehrstufigen Authentifizierung in AD FS finden Sie in den folgenden Artikeln:

Überprüfen der Konfiguration auf dem AD FS-Server und der vertrauenden Seite

Um die Konfiguration auf dem AD FS-Server zu überprüfen, überprüfen Sie die globalen zusätzlichen Authentifizierungsregeln. Um die Konfiguration für die vertrauende Seite zu überprüfen, überprüfen Sie die zusätzlichen Authentifizierungsregeln für die Vertrauensstellung der vertrauenden Seite.

Um die Konfiguration auf dem AD FS-Server zu überprüfen, führen Sie den folgenden Befehl in einem Windows PowerShell-Fenster aus.
```
Get-ADFSAdditionalAuthenticationRule
```
Führen Sie den folgenden Befehl aus, um die Konfiguration für die vertrauende Seite zu überprüfen:
```
Get-ADFSRelyingPartyTrust -TargetName RelyingParty | Select -ExpandProperty AdditionalAuthenticationRules
```
Notiz

Wenn die Befehle nichts zurückgeben, werden die zusätzlichen Authentifizierungsregeln nicht konfiguriert. Überspringen Sie diesen Abschnitt.
Beachten Sie, dass der Anspruchsregelsatz konfiguriert ist.

Überprüfen, ob die mehrstufige Authentifizierung im Anspruchsregelsatz aktiviert ist

Ein Anspruchsregelsatz besteht aus den folgenden Abschnitten:

Die Bedingungsanweisung: C:[Type=``…,Value=…]
Die Ausgabeerklärung: => issue (Type=``…,Value=…)

Wenn die Problemausweisung den folgenden Anspruch enthält, wird die mehrstufige Authentifizierung angegeben.
Type = "http://schemas.microsoft.com/ws/2008/06/identity/claims/authenticationmethod", Value = "http://schemas.microsoft.com/claims/multipleauthn"

Hier sind Beispiele, die eine mehrstufige Authentifizierung erfordern, die für Nicht-Arbeitsplatz-verbundene Geräte und für extranetbasierten Zugriff verwendet werden muss:

c:[Type == "http://schemas.microsoft.com/2012/01/devicecontext/claims/isregistereduser", Value == "false"] => issue(Type = "http://schemas.microsoft.com/ws/2008/06/identity/claims/authenticationmethod", Value = "http://schemas.microsoft.com/claims/multipleauthn")
c:[Type == "http://schemas.microsoft.com/ws/2012/01/insidecorporatenetwork", Value == "false"] => issue(Type = "http://schemas.microsoft.com/ws/2008/06/identity/claims/authenticationmethod", Value = "http://schemas.microsoft.com/claims/multipleauthn")

Überprüfen der Ausstellungsregeln der vertrauenden Seite

Wenn der Benutzer wiederholt mehrstufige Authentifizierungsaufforderungen empfängt, nachdem er die erste Authentifizierung ausgeführt hat, ist es möglich, dass der Antwortende nicht die mehrstufigen Authentifizierungsansprüche an die Anwendung übergibt. Führen Sie die folgenden Schritte aus, um zu überprüfen, ob die Authentifizierungsansprüche übergeben werden:

Führen Sie den folgenden Befehl in Windows PowerShell aus:
```
Get-ADFSRelyingPartyTrust -TargetName ClaimApp
```
Beobachten Sie den in den Attributen "IssuanceAuthorizationRules" oder "IssuanceAuthorizationRulesFile" definierten Regelsatz.

Der Regelsatz sollte die folgende Ausstellungsregel enthalten, um die mehrstufigen Authentifizierungsansprüche zu durchlaufen:
C:[Type==http://schemas.microsoft.com/ws/2008/06/identity/claims/authenticationmethod, Value==" http://schemas.microsoft.com/claims/multipleauthn"]=>issue(claim = c)

Überprüfen des Authentifizierungsanforderungsparameters

Überprüfen Sie, ob die Authentifizierungsanforderung die mehrstufige Authentifizierung als Authentifizierungsmethode angibt.

Wenn es sich bei der Authentifizierungsanforderung um eine WS-Verbundanforderung handelt, überprüfen Sie, ob die Anforderung enthalten ist wauth= http://schemas.microsoft.com/claims/multipleauthn.
Wenn es sich bei der Authentifizierungsanforderung um eine SAML-Anforderung handelt, überprüfen Sie, ob die Anforderung ein samlp:AuthnContextClassRef-Element mit dem Wert http://schemas.microsoft.com/claims/multipleauthnenthält.

Weitere Informationen finden Sie unter Übersicht über Authentifizierungshandler von AD FS-Anmeldeseiten.

Überprüfen, ob die Anwendung Microsoft Online Services für Office 365 ist

Wenn die Anwendung, auf die Sie zugreifen möchten, Microsoft Online Services für Office 365 ist, überprüfen Sie die Einstellung "SupportsMFA-Domänenverbund".

Rufen Sie die aktuelle SupportsMFA-Domänenverbundeinstellung ab, indem Sie den folgenden Befehl ausführen:
```
Get-MSOLDomainFederationSettings -DomainName DomainName | FL *
```
Wenn die SupportsMFA-Einstellung FALSE ist, legen Sie sie auf TRUE fest, indem Sie den folgenden Befehl ausführen:
```
Set-MSOLDomainFederationSettings -DomainName DomainName -SupportsMFA $TRUE
```

Überprüfen, ob SSO deaktiviert ist

Wenn SSO deaktiviert ist, aktivieren Sie es, und testen Sie, ob das Problem behoben ist.

Benutzer können sich nicht bei der Zielwebsite oder dem Zieldienst anmelden.

Dieses Problem kann auf der AD FS-Anmeldeseite oder auf der Anwendungsseite auftreten.

Wenn das Problem auf der AD FS-Anmeldeseite auftritt, erhalten Sie "Fehler aufgetreten", "HTTP 503-Dienst ist nicht verfügbar" oder eine andere Fehlermeldung. Die URL der Fehlerseite zeigt den AD FS-Dienstnamen an, z fs.contoso.com. B. .

Wenn das Problem auf der Anwendungsseite auftritt, zeigt die URL der Fehlerseite die IP-Adresse oder den Websitenamen des Zieldiensts an.

Führen Sie die Schritte im folgenden Abschnitt entsprechend dem Auftreten dieses Problems aus.

Um dieses Problem zu beheben, überprüfen Sie, ob alle Benutzer vom Problem betroffen sind und ob die Benutzer auf alle vertrauenden Parteien zugreifen können.

Alle Benutzer sind von dem Problem betroffen, und der Benutzer kann nicht auf eine der vertrauenden Parteien zugreifen.

Überprüfen wir die interne Anmeldefunktionalität mithilfe von IdpInitiatedSignOn. Verwenden Sie dazu die Seite "IdpInititatedSignOn", um zu überprüfen, ob der AD FS-Dienst aktiv ist und die Authentifizierungsfunktion ordnungsgemäß funktioniert. Führen Sie die folgenden Schritte aus, um die IdpInitiatedSignOn-Seite zu öffnen:

Aktivieren Sie die IdpInitiatedSignOn-Seite, indem Sie den folgenden Befehl auf dem AD FS-Server ausführen:
```
Set-AdfsProperties -EnableIdPInitiatedSignonPage $true
```
Besuchen Sie von einem Computer, der sich in Ihrem Netzwerk befindet, die folgende Seite:
https://<FederationInstance>/adfs/ls/idpinitiatedsignon.aspx
Geben Sie die richtigen Anmeldeinformationen eines gültigen Benutzers auf der Anmeldeseite ein.

Wenn die Anmeldung erfolgreich ist, überprüfen Sie, ob der AD FS-Dienststatus ausgeführt wird.

Öffnen Sie auf dem AD FS-Server Server-Manager.
Klicken Sie im Server-Manager auf "Tools>Services".
Überprüfen Sie, ob der Status von Active Directory-Verbunddienste (AD FS) ausgeführt wird.

Überprüfen Sie dann die externe Anmeldefunktionalität mithilfe von IdpInitiatedSignOn. Verwenden Sie die Seite "IdpInititatedSignOn", um schnell zu überprüfen, ob der AD FS-Dienst aktiv ist und die Authentifizierungsfunktionalität ordnungsgemäß funktioniert. Führen Sie die folgenden Schritte aus, um die IdpInitiatedSignOn-Seite zu öffnen:

Aktivieren Sie die IdpInitiatedSignOn-Seite, indem Sie den folgenden Befehl auf dem AD FS-Server ausführen:
```
Set-AdfsProperties -EnableIdPInitiatedSignonPage $true
```
Besuchen Sie von einem Computer, der sich außerhalb Ihres Netzwerks befindet, die folgende Seite:
https://<FederationInstance>/adfs/ls/idpinitiatedsignon.aspx
Geben Sie die richtigen Anmeldeinformationen eines gültigen Benutzers auf der Anmeldeseite ein.

Wenn die Anmeldung nicht erfolgreich ist, lesen Sie die AD FS-bezogenen Komponenten und Dienste , und überprüfen Sie die Proxyvertrauensstellung.

Wenn die Anmeldung erfolgreich ist, fahren Sie mit der Problembehandlung mit den Schritten in "Alle Benutzer" fort, die von dem Problem betroffen sind, und der Benutzer kann auf einige der vertrauenden Parteien zugreifen.

Wenn die Anmeldung nicht erfolgreich ist, überprüfen Sie die zugehörigen AD FS-Komponenten und -Dienste.

Überprüfen Sie, ob der AD FS-Dienststatus ausgeführt wird.

Öffnen Sie auf dem AD FS-Server Server-Manager.
Klicken Sie im Server-Manager auf "Tools>Services".
Überprüfen Sie, ob der Status von Active Directory-Verbunddienste (AD FS) ausgeführt wird.

Überprüfen Sie, ob die Endpunkte aktiviert sind. AD FS bietet verschiedene Endpunkte für verschiedene Funktionen und Szenarien. Nicht alle Endpunkte sind standardmäßig aktiviert. Führen Sie die folgenden Schritte aus, um den Status der Endpunkte zu überprüfen:

Öffnen Sie auf dem AD FS-Server die AD FS-Verwaltungskonsole.
Erweitern Sie Dienstendpunkte>.
Suchen Sie die Endpunkte, und überprüfen Sie, ob die Status in der Spalte "Aktiviert " aktiviert sind.

Überprüfen Sie dann, ob Microsoft Entra Connect installiert ist. Es wird empfohlen, Microsoft Entra Connect zu verwenden, wodurch die VERWALTUNG von SSL-Zertifikaten vereinfacht wird.

Wenn Microsoft Entra Connect installiert ist, stellen Sie sicher, dass Sie es zum Verwalten und Aktualisieren von SSL-Zertifikaten verwenden.

Wenn Microsoft Entra Connect nicht installiert ist, überprüfen Sie, ob das SSL-Zertifikat die folgenden AD FS-Anforderungen erfüllt:

Das Zertifikat stammt von einer vertrauenswürdigen Stammzertifizierungsstelle.

AD FS erfordert, dass SSL-Zertifikate von einer vertrauenswürdigen Stammzertifizierungsstelle stammen. Wenn auf AD FS von Computern, die nicht einer Domäne angehören, zugegriffen wird, empfehlen wir, ein SSL-Zertifikat von einer vertrauenswürdigen Stammzertifizierungsstelle von Drittanbietern wie DigiCert, VeriSign usw. zu verwenden. Wenn das SSL-Zertifikat nicht von einer vertrauenswürdigen Stammzertifizierungsstelle stammt, kann die SSL-Kommunikation unterbrechen.
Der Antragstellername des Zertifikats ist gültig.

Der Antragstellername sollte mit dem Namen des Verbunddiensts übereinstimmen, nicht mit dem AD FS-Servernamen oder einem anderen Namen. Führen Sie zum Abrufen des Verbunddienstnamens den folgenden Befehl auf dem primären AD FS-Server aus:
Get-AdfsProperties | select hostname
Das Zertifikat wird nicht widerrufen.

Überprüfen auf Zertifikatswiderruf. Wenn das Zertifikat widerrufen wird, kann die SSL-Verbindung nicht vertrauenswürdig sein und wird von Clients blockiert.

Wenn das SSL-Zertifikat diese Anforderungen nicht erfüllt, versuchen Sie, ein qualifiziertes Zertifikat für die SSL-Kommunikation zu erhalten. Es wird empfohlen, Microsoft Entra Connect zu verwenden, wodurch die VERWALTUNG von SSL-Zertifikaten vereinfacht wird. Siehe Aktualisieren des TLS/SSL-Zertifikats für eine Active Directory-Verbunddienste (AD FS) (AD FS)-Farm.

Wenn das SSL-Zertifikat diese Anforderungen erfüllt, überprüfen Sie die folgenden Konfigurationen des SSL-Zertifikats.

Überprüfen, ob das SSL-Zertifikat ordnungsgemäß installiert ist

Das SSL-Zertifikat sollte im persönlichen Speicher für den lokalen Computer auf jedem Verbundserver in Ihrer Farm installiert werden. Um das Zertifikat zu installieren, doppelklicken Sie auf die . PFX-Datei des Zertifikats und folgen Sie dem Assistenten.

Führen Sie die folgenden Schritte aus, um zu überprüfen, ob das Zertifikat an der richtigen Stelle installiert ist:

Listen Sie die Zertifikate auf, die sich im persönlichen Speicher für den lokalen Computer befinden, indem Sie den folgenden Befehl ausführen:
dir Cert:\LocalMachine\My
Überprüfen Sie, ob sich das Zertifikat in der Liste befindet.

Überprüfen, ob das richtige SSL-Zertifikat verwendet wird

Rufen Sie den Fingerabdruck des Zertifikats ab, das für die SSL-Kommunikation verwendet wird, und überprüfen Sie, ob der Fingerabdruck mit dem erwarteten Zertifikatfingerabdruck übereinstimmt.

Um den Fingerabdruck des verwendeten Zertifikats abzurufen, führen Sie den folgenden Befehl in Windows PowerShell aus:

Get-AdfsSslCertificate

Wenn das falsche Zertifikat verwendet wird, legen Sie das richtige Zertifikat fest, indem Sie den folgenden Befehl ausführen:

Set-AdfsSslCertificate –Thumbprint CorrectThumprint

Überprüfen, ob das SSL-Zertifikat als Dienstkommunikationszertifikat festgelegt ist

Das SSL-Zertifikat muss als Dienstkommunikationszertifikat in Ihrer AD FS-Farm festgelegt werden. Dies geschieht nicht automatisch. Führen Sie die folgenden Schritte aus, um zu überprüfen, ob das richtige Zertifikat festgelegt ist:

Erweitern Sie in der AD FS-Verwaltungskonsole Dienstzertifikate>.
Überprüfen Sie, ob das unter Dienstkommunikation aufgeführte Zertifikat das erwartete Zertifikat ist.

Wenn das falsche Zertifikat aufgeführt ist, legen Sie das richtige Zertifikat fest, und erteilen Sie dem AD FS-Dienst die Leseberechtigung für das Zertifikat. Gehen Sie dazu wie folgt vor:

Legen Sie das richtige Zertifikat fest:
1. Klicken Sie mit der rechten Maustaste auf Zertifikate, und klicken Sie dann auf "Dienstkommunikationszertifikat festlegen".
2. Wählen Sie das richtige Zertifikat aus.
Überprüfen Sie, ob der AD FS-Dienst über die Berechtigung "Lesen " für das Zertifikat verfügt:
1. Fügen Sie das Zertifikat-Snap-In für das lokale Computerkonto zur Microsoft Management Console (MMC) hinzu.
2. Erweitern Sie Zertifikate (lokaler Computer)>Persönlich>Zertifikate.
3. Klicken Sie mit der rechten Maustaste auf das SSL-Zertifikat, klicken Sie auf "Alle Aufgaben>verwalten private Schlüssel".
4. Überprüfen Sie, ob adfssrv unter "Gruppe" und "Benutzernamen " mit der Berechtigung "Lesen " aufgeführt ist.
Wenn adfssrv nicht aufgeführt ist, erteilen Sie dem AD FS-Dienst die Leseberechtigung für das Zertifikat:
1. Klicken Sie auf "Hinzufügen", klicken Sie auf "Speicherorte", klicken Sie auf den Server, und klicken Sie dann auf "OK".
2. Geben Sie unter "Objektnamen eingeben", "nt service\adfssrv" ein, klicken Sie auf "Namen überprüfen", und klicken Sie dann auf "OK".
  Wenn Sie AD FS mit dem Geräteregistrierungsdienst (Device Registration Service, DRS) verwenden, geben Sie stattdessen nt service\drs ein.
3. Erteilen Sie die Leseberechtigung , und klicken Sie dann auf "OK".

Überprüfen, ob der Geräteregistrierungsdienst (Device Registration Service, DRS) in AD FS konfiguriert ist

Wenn Sie AD FS mit DRS konfiguriert haben, stellen Sie sicher, dass das SSL-Zertifikat auch für RDS ordnungsgemäß konfiguriert ist. Wenn beispielsweise zwei UPN-Suffixe contoso.com vorhanden sind, fabrikam.commuss das Zertifikat und enterpriseregistration.fabrikma.com als alternative Antragstellernamen (SUBJECT Alternative Names, SANs) verfügenenterpriseregistration.contoso.com.

Führen Sie die folgenden Schritte aus, um zu überprüfen, ob das SSL-Zertifikat über die richtigen SANs verfügt:

Auflisten aller UPN-Suffixe, die in der Organisation verwendet werden, indem Sie den folgenden Befehl ausführen:
```
Get-AdfsDeviceRegistratrionUpnSuffix
```
Überprüfen Sie, ob das SSL-Zertifikat die erforderlichen SANs konfiguriert hat.
Wenn das SSL-Zertifikat nicht über die richtigen DRS-Namen als SANs verfügt, rufen Sie ein neues SSL-Zertifikat ab, das über die richtigen SANs für DRS verfügt, und verwenden Sie es dann als SSL-Zertifikat für AD FS.

Überprüfen Sie dann die Zertifikatkonfiguration auf WAP-Servern und die Fallbackbindungen:

Überprüfen Sie, ob das richtige SSL-Zertifikat auf allen WAP-Servern festgelegt ist.
1. Stellen Sie sicher, dass das SSL-Zertifikat im persönlichen Speicher für den lokalen Computer auf jedem WAP-Server installiert ist.
2. Rufen Sie das von WAP verwendete SSL-Zertifikat ab, indem Sie den folgenden Befehl ausführen:
```
Get-WebApplicationProxySslCertificate
```
3. Wenn das SSL-Zertifikat falsch ist, legen Sie das richtige SSL-Zertifikat fest, indem Sie den folgenden Befehl ausführen:
```
Set-WebApplicationProxySslCertificate -Thumbprint Thumbprint
```
Überprüfen Sie die Zertifikatbindungen, und aktualisieren Sie sie bei Bedarf.

Um Nicht-SNI-Fälle zu unterstützen, können Administratoren Fallbackbindungen angeben. Suchen Sie abgesehen von der standardmäßigen Federationservicename:443-Bindung unter den folgenden Anwendungs-IDs nach Fallbackbindungen:
- {5d89a20c-beab-4389-9447-324788eb944a}: Dies ist die Anwendungs-ID für AD FS.
- {f955c070-e044-456c-ac00-e9e4275b3f04}: Dies ist die Anwendungs-ID für Web-Anwendungsproxy.
Wenn beispielsweise das SSL-Zertifikat für eine Fallbackbindung wie 0.0.0.0.0:443 angegeben ist, stellen Sie sicher, dass die Bindung entsprechend aktualisiert wird, wenn das SSL-Zertifikat aktualisiert wird.

Alle Benutzer sind von dem Problem betroffen, und der Benutzer kann auf einige der vertrauenden Parteien zugreifen.

Zunächst erhalten wir die Clientinformationen der vertrauenden Seite und des OAuth-Clients. Wenn Sie eine herkömmliche vertrauende Seite verwenden, führen Sie die folgenden Schritte aus:

Öffnen Sie auf dem primären AD FS-Server Windows PowerShell mit der Option "Als Administrator ausführen".
Fügen Sie die AD FS 2.0-Komponente zu Windows PowerShell hinzu, indem Sie den folgenden Befehl ausführen:
```
Add-PSSnapin Microsoft.Adfs.PowerShell
```
Rufen Sie die Informationen der vertrauenden Seite ab, indem Sie den folgenden Befehl ausführen:
```
$rp = Get-AdfsRelyingPartyTrust RPName
```
Rufen Sie die OAuth-Clientinformationen ab, indem Sie den folgenden Befehl ausführen:
```
$client = Get-AdfsClient ClientName
```

Wenn Sie das Feature "Anwendungsgruppe" in Windows Server 2016 verwenden, führen Sie die folgenden Schritte aus:

Öffnen Sie auf dem primären AD FS-Server Windows PowerShell mit der Option "Als Administrator ausführen".
Rufen Sie die Informationen der vertrauenden Seite ab, indem Sie den folgenden Befehl ausführen:
$rp = Get-AdfsWebApiApplication ResourceID
Wenn der OAuth-Client öffentlich ist, rufen Sie die Clientinformationen ab, indem Sie den folgenden Befehl ausführen:
```
$client = Get-AdfsNativeClientApplication ClientName
```
Wenn der Client vertraulich ist, rufen Sie die Clientinformationen ab, indem Sie den folgenden Befehl ausführen:
```
$client = Get-AdfsServerApplication ClientName
```

Fahren Sie nun mit den folgenden Problembehandlungsmethoden fort.

Überprüfen der Einstellungen der vertrauenden Seite und des Clients

Der Bezeichner, die Client-ID und der Umleitungs-URI der vertrauenden Seite sollten vom Besitzer der Anwendung und des Clients bereitgestellt werden. Es könnte jedoch noch ein Konflikt zwischen dem, was der Besitzer bereitstellt, und dem, was in AD FS konfiguriert ist, bestehen. Beispielsweise kann ein Konflikt durch einen Tippfehler verursacht werden. Überprüfen Sie, ob die vom Besitzer bereitgestellten Einstellungen den in AD FS konfigurierten Einstellungen entsprechen. Die Schritte auf der vorherigen Seite erhalten Sie über PowerShell konfigurierte Einstellungen in AD FS.

Vom Besitzer bereitgestellte Einstellungen	In AD FS konfigurierte Einstellungen
ID der vertrauenden Seite	$rp. Bezeichner
Umleitungs-URI der vertrauenden Seite	Eine Präfix- oder Wildcard-Übereinstimmung von $rp. WSFedEndpoint für eine WS-Fed vertrauende Partei $rp. SamlEndpoints für eine SAML-vertrauende Seite
Client-ID	$client. ClientId
Clientumleitungs-URI	Eine Präfix-Übereinstimmung von $client. RedirectUri

Wenn Elemente in der Tabelle übereinstimmen, überprüfen Sie zusätzlich, ob diese Einstellungen in der an AD FS gesendeten Authentifizierungsanforderung übereinstimmen und was in AD FS konfiguriert ist. Versuchen Sie, das Problem zu reproduzieren, bei dem Sie eine Fiddler-Ablaufverfolgung für die von der Anwendung an AD FS gesendete Authentifizierungsanforderung erfassen. Überprüfen Sie die Anforderungsparameter, um die folgenden Prüfungen abhängig vom Anforderungstyp durchzuführen.

OAuth-Anforderungen

Eine OAuth-Anforderung sieht wie folgt aus:

https://sts.contoso.com/adfs/oauth2/authorize?response_type=code&client_id=ClientID&redirect_uri=https://www.TestApp.com&resource=https://www.TestApp.com

Überprüfen Sie, ob die Anforderungsparameter den in AD FS konfigurierten Einstellungen entsprechen.

Anforderungsparameter	In AD FS konfigurierte Einstellungen
client_id	$client. ClientId
redirect_uri	Eine Präfix-Übereinstimmung von @client_RedirectUri

Der Parameter "resource" sollte eine gültige vertrauende Seite in AD FS darstellen. Rufen Sie die Informationen der vertrauenden Seite ab, indem Sie einen der folgenden Befehle ausführen.

Wenn Sie eine herkömmliche vertrauende Seite verwenden, führen Sie den folgenden Befehl aus:
Get-AdfsRelyingPartyTrust -Identifier "ValueOfTheResourceParameter"
Wenn Sie das Feature "Anwendungsgruppe" in Windows Server 2016 verwenden, führen Sie den folgenden Befehl aus:
Get-AdfsWebApiApplication "ValueOfTheResourceParameter"

WS-Fed-Anforderungen

Eine WS-Fed-Anforderung sieht wie folgt aus:

https://fs.contoso.com/adfs/ls/?wa=wsignin1.0&wtrealm=https://claimsweb.contoso.com&wctx=rm=0&id=passive&ru=/&wct=2014-10-21T22:15:42Z

Überprüfen Sie, ob die Anforderungsparameter den in AD FS konfigurierten Einstellungen entsprechen:

Anforderungsparameter	In AD FS konfigurierte Einstellungen
wtrealm	$rp. Bezeichner
wreply	Eine Präfix-Übereinstimmung oder Eine Wildcard-Übereinstimmung von $rp. WSFedEndpoint

SAML-Anforderungen

Eine SAML-Anforderung sieht wie folgt aus:

https://sts.contoso.com/adfs/ls/?SAMLRequest=EncodedValue&RelayState=cookie:29002348&SigAlg=http://www.w3.org/2000/09/Fxmldsig#rsa-sha1&Signature=Signature

Decodieren Sie den Wert des SAMLRequest-Parameters mithilfe der Option "From DeflatedSAML" im Fiddler-Text-Assistenten. Der decodierte Wert sieht wie folgt aus:

<samlp:AuthnRequest ID="ID" Version="2.0" IssueInstant="2017-04-28T01:02:22.664Z" Destination="https://TestClaimProvider-Samlp-Only/adfs/ls" Consent="urn:oasis:names:tc:SAML:2.0:consent:unspecified" ForceAuthn="true" xmlns:samlp="urn:oasis:names:tc:SAML:2.0:protocol"><Issuer xmlns="urn:oasis:names:tc:SAML:2.0:assertion">http://fs.contoso.com/adfs/services/trust</Issuer><samlp:NameIDPolicy Format="urn:oasis:names:tc:SAML:1.1:nameid-format:unspecified" AllowCreate="true" /></samlp:AuthnRequest>

Führen Sie die folgenden Überprüfungen innerhalb des decodierten Werts aus:

Überprüfen Sie, ob der Hostname im Wert des Ziels mit dem AD FS-Hostnamen übereinstimmt.
Überprüfen Sie, ob der Wert des Ausstellers übereinstimmt $rp.Identifier.

Zusätzliche Hinweise für SAML:

$rp. SamlEndpoints: Zeigt alle Arten von SAML-Endpunkten an. Die Antwort von AD FS wird an die entsprechenden URLs gesendet, die in den Endpunkten konfiguriert sind. Ein SAML-Endpunkt kann Umleitungs-, Post- oder Artefaktbindungen für die Nachrichtenübertragung verwenden. Alle diese URLs können in AD FS konfiguriert werden.
$rp. SignedSamlRequestsRequired: Wenn der Wert festgelegt ist, muss die von der vertrauenden Seite gesendete SAML-Anforderung signiert werden. Die Parameter "SigAlg" und "Signature" müssen in der Anforderung vorhanden sein.
$rp. RequestSigningCertificate: Dies ist das Signaturzertifikat, das zum Generieren der Signatur in der SAML-Anforderung verwendet wird. Stellen Sie sicher, dass das Zertifikat gültig ist, und bitten Sie den Anwendungsbesitzer, dem Zertifikat zu entsprechen.

Überprüfen des Verschlüsselungszertifikats

Wenn $rp.EncryptClaims "Aktiviert" zurückgegeben wird, ist die Verschlüsselung der vertrauenden Seite aktiviert. AD FS verwendet das Verschlüsselungszertifikat, um die Ansprüche zu verschlüsseln. Führen Sie die folgenden Prüfungen aus:

$rp. EncryptionCertificate: Verwenden Sie diesen Befehl, um das Zertifikat abzurufen und zu überprüfen, ob es gültig ist.
$rp. EncryptionCertificateRevocationCheck: Verwenden Sie diesen Befehl, um zu überprüfen, ob das Zertifikat die Sperrüberprüfungsanforderungen erfüllt.

Die beiden vorherigen Methoden funktionieren nicht

Informationen zum Fortsetzen der Problembehandlung finden Sie unter Verwenden der Dumptoken-App.

Nicht alle Benutzer sind von dem Problem betroffen, und der Benutzer kann nicht auf eine der vertrauenden Parteien zugreifen.

Führen Sie in diesem Szenario die folgenden Prüfungen aus.

Überprüfen, ob der Benutzer deaktiviert ist

Überprüfen Sie den Benutzerstatus in Windows PowerShell oder auf der Benutzeroberfläche. Wenn der Benutzer deaktiviert ist, aktivieren Sie den Benutzer.

Überprüfen des Benutzerstatus mit Windows PowerShell

Melden Sie sich bei einem der Domänencontroller an.
Öffnen Sie Windows PowerShell.
Überprüfen Sie den Benutzerstatus, indem Sie den folgenden Befehl ausführen:
```
Get-ADUser -Identity <samaccountname of the user> | Select Enabled
```

Überprüfen des Benutzerstatus in der Benutzeroberfläche

Melden Sie sich bei einem der Domänencontroller an.
Öffnen Sie die Active Directory-Benutzer und -Computer Verwaltungskonsole.
Klicken Sie auf den Knoten "Benutzer", klicken Sie im rechten Bereich mit der rechten Maustaste auf den Benutzer, und klicken Sie dann auf "Eigenschaften".
Klicken Sie auf die Registerkarte Konto.
Überprüfen Sie unter "Kontooptionen", ob "Konto" deaktiviert ist.
Wenn die Option aktiviert ist, deaktivieren Sie sie.

Überprüfen, ob die Benutzereigenschaften kürzlich aktualisiert wurden

Wenn eine Eigenschaft des Benutzers in Active Directory aktualisiert wird, führt sie zu einer Änderung der Metadaten des Benutzerobjekts. Überprüfen Sie das Benutzermetadatenobjekt, um zu sehen, welche Eigenschaften kürzlich aktualisiert wurden. Wenn Änderungen gefunden werden, stellen Sie sicher, dass sie von den zugehörigen Diensten aufgenommen werden. Führen Sie die folgenden Schritte aus, um zu überprüfen, ob eigenschaftenänderungen an einem Benutzer vorgenommen wurden:

Melden Sie sich bei einem Domänencontroller an.
Öffnen Sie Windows PowerShell.
Rufen Sie die Metadaten des Benutzerobjekts ab, indem Sie den folgenden Befehl ausführen:
repadmin /showobjmeta <destination DC> "user DN"

Ein Beispiel für den Befehl ist:
repadmin /showobjmeta localhost "CN=test user,CN=Users,DC=fabidentity,DC=com"
Überprüfen Sie in den Metadaten die Spalte "Uhrzeit/Datum" für jedes Attribut, um hinweise auf eine Änderung zu geben. Im folgenden Beispiel akzeptiert das Attribut "userPrincipleName" ein neueres Datum als die anderen Attribute, die eine Änderung an den Metadaten des Benutzerobjekts darstellen.

Überprüfen der Gesamtstrukturvertrauensstellung, wenn der Benutzer zu einer anderen Gesamtstruktur gehört

In einer AD FS-Umgebung mit mehreren Gesamtstrukturen ist eine bidirektionale Gesamtstrukturvertrauensstellung zwischen der Gesamtstruktur erforderlich, in der AD FS bereitgestellt wird, und den anderen Gesamtstrukturen, die die AD FS-Bereitstellung für die Authentifizierung verwenden. Führen Sie die folgenden Schritte aus, um zu überprüfen, ob die Vertrauensstellung zwischen den Gesamtstrukturen wie erwartet funktioniert:

Melden Sie sich bei einem Domänencontroller in der Gesamtstruktur an, in der AD FS bereitgestellt wird.
Öffnen Sie die Active Directory-Domäne und vertrauen Sie Verwaltungskonsole.
Klicken Sie im Verwaltungskonsole mit der rechten Maustaste auf die Domäne, die die zu überprüfende Vertrauensstellung enthält, und klicken Sie dann auf "Eigenschaften".
Klicken Sie auf die Registerkarte Vertrauensstellungen.
Klicken Sie unter Domänen, die von dieser Domäne als vertrauenswürdig eingestuft werden (ausgehende Vertrauensstellungen) oder Domänen, die dieser Domäne vertrauen (eingehende Vertrauensstellungen) auf die zu überprüfende Vertrauensstellung, und klicken Sie dann auf Eigenschaften.
Klicken Sie auf Überprüfen.
Wählen Sie im Dialogfeld Active Directory-Domäne Dienste eine der Optionen aus.
- Wenn Sie "Nein" auswählen, empfehlen wir, dasselbe Verfahren für die gegenseitige Domäne zu wiederholen.
- Wenn Sie "Ja" auswählen, geben Sie eine Administratorbenutzeranmeldeinformationen für die gegenseitige Domäne an. Es ist nicht erforderlich, dasselbe Verfahren für die gegenseitige Domäne auszuführen.

Wenn Ihnen diese Schritte nicht bei der Behebung des Problems helfen, fahren Sie mit der Problembehandlung mit den Schritten in " Nicht alle Benutzer sind vom Problem betroffen" fort, und der Benutzer kann auf einige der Abschnitte der vertrauenden Parteien zugreifen.

Nicht alle Benutzer sind vom Problem betroffen, und der Benutzer kann auf einige der vertrauenden Parteien zugreifen.

Überprüfen Sie in diesem Szenario, ob dieses Problem in einem Microsoft Entra-Szenario auftritt. Führen Sie in diesem Fall diese Überprüfungen aus, um dieses Problem zu beheben. Wenn dies nicht der Fall ist, lesen Sie die Verwendung der Dumptoken-App zur Problembehandlung.

Überprüfen, ob der Benutzer mit der Microsoft Entra-ID synchronisiert wird

Wenn ein Benutzer versucht, sich bei der Microsoft Entra-ID anzumelden, wird er zur Authentifizierung für eine Verbunddomäne an AD FS umgeleitet. Einer der möglichen Gründe für eine fehlgeschlagene Anmeldung ist, dass der Benutzer noch nicht mit der Microsoft Entra-ID synchronisiert wird. Möglicherweise wird nach dem ersten Authentifizierungsversuch bei AD FS eine Schleife von Microsoft Entra ID zu Active Directory FS angezeigt. Führen Sie die folgenden Schritte aus, um zu ermitteln, ob der Benutzer mit der Microsoft Entra-ID synchronisiert wird:

Laden Sie das Azure AD PowerShell-Modul für Windows PowerShell herunter , und installieren Sie es.
Öffnen Sie Windows PowerShell mit der Option "Als Administrator ausführen".
Initiieren Sie eine Verbindung mit der Microsoft Entra-ID, indem Sie den folgenden Befehl ausführen:
Connect-MsolService
Geben Sie die Anmeldeinformationen des globalen Administrators für die Verbindung an.
Rufen Sie die Liste der Benutzer in der Microsoft Entra-ID ab, indem Sie den folgenden Befehl ausführen:
Get-MsolUser
Überprüfen Sie, ob sich der Benutzer in der Liste befindet.

Wenn sich der Benutzer nicht in der Liste befindet, synchronisieren Sie den Benutzer mit der Microsoft Entra-ID.

Überprüfen der unveränderlichen ID und des UPN in ausstellungsanspruchsregel

Microsoft Entra-ID erfordert unveränderliche ID und den UPN des Benutzers, um den Benutzer zu authentifizieren.

Notiz

immutableID wird auch als sourceAnchor in den folgenden Tools bezeichnet:

Azure AD Sync
Azure Active Directory-Synchronisierung (DirSync)

Administratoren können Microsoft Entra Connect für die automatische Verwaltung der AD FS-Vertrauensstellung mit Microsoft Entra ID verwenden. Wenn Sie die Vertrauensstellung nicht über Microsoft Entra Connect verwalten, empfehlen wir Ihnen, dies zu tun, indem Sie Microsoft Entra Connect Microsoft Entra Connect herunterladen, die automatische Verwaltung von Anspruchsregeln basierend auf den Synchronisierungseinstellungen ermöglicht.

Führen Sie die folgenden Schritte aus, um zu überprüfen, ob die Anspruchsregeln für unveränderliche ID und UPN in AD FS mit der Von Microsoft Entra-ID übereinstimmen:

Rufen Sie sourceAnchor und UPN in Microsoft Entra Connect ab.
1. Öffnen Sie Microsoft Entra Connect.
2. Klicken Sie auf " Aktuelle Konfiguration anzeigen".
3. Notieren Sie sich auf der Seite "Ihre Lösung überprüfen" die Werte von SOURCE ANCHOR und USER PRINCIPAL NAME.
Überprüfen Sie die Werte von immutableID (sourceAnchor) und UPN in der entsprechenden Anspruchsregel, die im AD FS-Server konfiguriert ist.
1. Öffnen Sie auf dem AD FS-Server die AD FS-Verwaltungskonsole.
2. Klicken Sie auf Vertrauensstellungen der vertrauenden Seite.
3. Klicken Sie mit der rechten Maustaste auf die Vertrauensstellung der vertrauenden Seite mit der Microsoft Entra-ID, und klicken Sie dann auf " Anspruchsausstellungsrichtlinie bearbeiten".
4. Öffnen Sie die Anspruchsregel für unveränderliche ID und UPN.
5. Überprüfen Sie, ob die variablen, die für Werte von unveränderlicher ID und UPN abgefragt wurden, identisch mit denen sind, die in Microsoft Entra Connect angezeigt werden.
Wenn ein Unterschied besteht, verwenden Sie eine der folgenden Methoden:
- Wenn AD FS von Microsoft Entra Connect verwaltet wird, setzen Sie die Vertrauensstellung der vertrauenden Seite mithilfe von Microsoft Entra Connect zurück.
- Wenn AD FS nicht von Microsoft Entra Connect verwaltet wird, korrigieren Sie die Ansprüche mit den richtigen Attributen.

Wenn diese Überprüfungen Ihnen nicht bei der Behebung des Problems helfen, lesen Sie die Verwendung der Dumptoken-App zur Problembehandlung.

Dieses Problem tritt auf der Anwendungsseite auf.

Wenn das Tokensignaturzertifikat kürzlich von AD FS erneuert wurde, überprüfen Sie, ob das neue Zertifikat vom Partnerverbund aufgenommen wird. Falls AD FS ein Token-Entschlüsselungszertifikat verwendet, das kürzlich ebenfalls erneuert wurde, führen Sie auch die gleiche Überprüfung durch. Führen Sie die folgenden Schritte aus, um zu überprüfen, ob das aktuelle AD FS-Tokensignaturzertifikat auf AD FS mit dem Zertifikat des Partnerverbunds übereinstimmt:

Rufen Sie das aktuelle Tokensignaturzertifikat auf AD FS ab, indem Sie den folgenden Befehl ausführen:
```
Get-ADFSCertificate -CertificateType token-signing
```
Suchen Sie in der Liste der zurückgegebenen Zertifikate das mit IsPrimary = TRUE, und notieren Sie sich den Fingerabdruck.
Rufen Sie den Fingerabdruck des aktuellen Tokensignaturzertifikats auf dem Partnerverbund ab. Der Anwendungsbesitzer muss Ihnen dies bereitstellen.
Vergleichen Sie die Fingerabdrucke der beiden Zertifikate.

Führen Sie dieselbe Überprüfung aus, wenn AD FS ein erneuertes Tokenentschlüsselungszertifikat verwendet, mit der Ausnahme, dass der Befehl zum Abrufen des Tokenentschlüsselungszertifikats auf AD FS wie folgt lautet:

Get-ADFSCertificate -CertificateType token-decrypting

Die Fingerabdruck der beiden Zertifikate stimmen überein

Wenn die Fingerabdruckabdrücke übereinstimmen, stellen Sie sicher, dass die Partner die neuen AD FS-Zertifikate verwenden.

Wenn es übereinstimmungen mit Zertifikaten gibt, stellen Sie sicher, dass die Partner die neuen Zertifikate verwenden. Zertifikate sind in den vom AD FS-Server veröffentlichten Verbundmetadaten enthalten.

Notiz

Die Partner beziehen sich auf alle Partner Ihrer Ressourcenorganisation oder Kontoorganisation, die in Ihrem AD FS durch vertrauensbasierte Vertrauensstellungen und Anspruchsanbietervertrauensstellungen dargestellt werden.

Die Partner können auf die Verbundmetadaten zugreifen.

Wenn die Partner auf die Verbundmetadaten zugreifen können, bitten Sie die Partner, die neuen Zertifikate zu verwenden.
Die Partner können nicht auf die Verbundmetadaten zugreifen.

In diesem Fall müssen Sie den Partnern manuell die öffentlichen Schlüssel der neuen Zertifikate senden. Gehen Sie dazu wie folgt vor:
1. Exportieren Sie die öffentlichen Schlüssel als ZERTIFIKATdateien oder als P7B-Dateien, um die gesamten Zertifikatketten einzuschließen.
2. Senden Sie die öffentlichen Schlüssel an die Partner.
3. Bitten Sie die Partner, die neuen Zertifikate zu verwenden.

Die Fingerabdruck der beiden Zertifikate stimmen nicht überein.

Überprüfen Sie dann, ob ein Tokensignaturalgorithmus nicht übereinstimmen kann. Gehen Sie dazu wie folgt vor:

Bestimmen Sie den algorithmus, der von der vertrauenden Seite verwendet wird, indem Sie den folgenden Befehl ausführen:
```
Get-ADFSRelyingPartyTrust -Name RPName | FL SignatureAlgorithm
```
Die möglichen Werte sind SHA1 oder SHA256.
Wenden Sie sich an den Anwendungsbesitzer für den Algorithmus, der auf der Anwendungsseite verwendet wird.
Überprüfen Sie, ob die beiden Algorithmen übereinstimmen.

Wenn die beiden Algorithmen übereinstimmen, überprüfen Sie, ob das Namens-ID-Format den Anforderungen der Anwendung entspricht.

Führen Sie auf dem AD FS-Server die Ausstellungstransformationsregeln ab, indem Sie den folgenden Befehl ausführen:
```
(Get-AdfsRelyingPartyTrust -Name RPName).IssuanceTransformRules
```
Suchen Sie die Regel, die den NameIdentifier-Anspruch ausgibt. Wenn eine solche Regel nicht vorhanden ist, überspringen Sie diesen Schritt.

Hier ist ein Beispiel für die Regel:

c:[Type == "http://schemas.microsoft.com/LiveID/Federation/2008/05/ImmutableID"] => issue(Type = "http://schemas.xmlsoap.org/ws/2005/05/identity/claims/nameidentifier", Value = c.Value, Properties["http://schemas.xmlsoap.org/ws/2005/05/identity/claimproperties/format"] = "urn:oasis:names:tc:SAML:1.1:nameid-format:unspecified");

Beachten Sie das NameIdentifier-Format in der folgenden Syntax:

Properties["Property-type-URI"] = "ValueURI"

Die möglichen Formate sind unten aufgeführt. Das erste Format ist die Standardeinstellung.
- urn:oasis:names:tc:SAML:1.1:nameid-format:unspecifie.
- urn:oasis:names:tc:SAML:1.1:nameid-format:emailAddress
- urn:oasis:names:tc:SAML:2.0:nameid-format:persistent
- urn:oasis:names:tc:SAML:2.0:nameid-format:transient
Bitten Sie den Anwendungsbesitzer um das für die Anwendung erforderliche NameIdentifier-Format.
Überprüfen Sie, ob die beiden NameIdentifier-Formate übereinstimmen.
Wenn die Formate nicht übereinstimmen, konfigurieren Sie den NameIdentifier-Anspruch so, dass das von der Anwendung benötigte Format verwendet wird. Gehen Sie dazu wie folgt vor:
1. Öffnen Sie die AD FS-Verwaltungskonsole.
2. Klicken Sie auf Vertrauensstellungen der vertrauenden Seite, wählen Sie den entsprechenden Partnerverbund aus, und klicken Sie dann im Bereich "Aktionen" auf "Anspruchsausstellungsrichtlinie bearbeiten".
3. Fügen Sie eine neue Regel hinzu, wenn keine Regel vorhanden ist, um den Anspruch "NameIdentifier" auszugeben oder eine vorhandene Regel zu aktualisieren. Wählen Sie die Namens-ID für den Typ "Eingehender Anspruch" aus, und geben Sie dann das format an, das die Anwendung benötigt.

Wenn die beiden Algorithmen nicht übereinstimmen, aktualisieren Sie den Signaturalgorithmus, der von der Vertrauensstellung der vertrauenden Seite verwendet wird.

Öffnen Sie die AD FS-Verwaltungskonsole.
Klicken Sie mit der rechten Maustaste auf die Vertrauensstellung der vertrauenden Seite, und klicken Sie dann auf Eigenschaften.
Wählen Sie auf der Registerkarte "Erweitert " den Algorithmus aus, um den Anforderungen der Anwendung zu entsprechen.

Informationen zur automatischen Zertifikatverlängerung

Wenn das Tokensignaturzertifikat oder das Tokenentschlüsselungszertifikat selbstsigniert sind, ist AutoCertificateRollover in diesen Zertifikaten standardmäßig aktiviert, und AD FS verwaltet die automatische Verlängerung der Zertifikate, wenn sie nah am Ablauf sind.

Führen Sie die folgenden Schritte aus, um festzustellen, ob Sie selbstsignierte Zertifikate verwenden:

Führen Sie den folgenden Befehl aus:

Get-ADFSCerticate -CertificateType "token-signing"

Führen Sie das Cmdlet Get-ADFSCerticate, Zertifikattyptokensignierung aus.

Überprüfen Sie die Zertifikatattribute.

Wenn die Attribute "Subject" und "Issuer" beide mit "CN=ADFS Signing..." beginnen, wird das Zertifikat selbstsigniert und von AutoCertRollover verwaltet.

Führen Sie die folgenden Schritte aus, um zu bestätigen, ob die Zertifikate automatisch verlängert werden:

Führen Sie den folgenden Befehl aus:

Get-ADFSProperties | FL AutoCertificateRollover

Führen Sie das Cmdlet Get-ADFSProperties aus, um zu bestätigen, ob die Zertifikate automatisch erneuert werden.

Überprüfen Sie das AutoCertificateRollover-Attribut.
- Wenn AutoCertificateRollover = TRUE, generiert AD FS automatisch neue Zertifikate (30 Tage vor ablaufen standardmäßig) und legt sie als primäre Zertifikate (25 Tage vor Ablauf) fest.
- Wenn AutoCertificateRollover = FALSE, müssen Sie die Zertifikate manuell ersetzen.

In diesem Artikel wird erläutert, wie Sie die ADFS-bezogenen Komponenten und Dienste überprüfen. Diese Schritte können beim Beheben von SSO-Problemen (Sign-On) mit Active Directory-Verbunddienste (AD FS) (ADFS) helfen.

DNS überprüfen

Der Zugriff auf ADFS sollte direkt auf einen der WAP-Server (Web Anwendungsproxy) oder den Lastenausgleich vor den WAP-Servern verweisen. Führen Sie die folgenden Prüfungen aus:

Pingen des Verbunddienstnamens (z. B. fs.contoso.com). Bestätigen Sie, ob die IP-Adresse, zu der der Ping aufgelöst wird, eines der WAP-Server oder des Lastenausgleichs der WAP-Server ist.
Überprüfen Sie, ob ein A-Eintrag für den Verbunddienst auf dem DNS-Server vorhanden ist. Der A-Eintrag sollte auf einen der WAP-Server oder auf den Lastenausgleich der WAP-Server verweisen.

Wenn WAP nicht in Ihrem Szenario für den externen Zugriff implementiert ist, überprüfen Sie, ob der Zugriff auf ADFS-Punkte direkt auf einen der ADFS-Server oder das Lastenausgleichsmodul vor den ADFS-Servern erfolgt:

Pingen des Verbunddienstnamens (z. B. fs.contoso.com). Vergewissern Sie sich, ob die IP-Adresse, die Sie erhalten, zu einem der ADFS-Server oder zum Lastenausgleich der ADFS-Server aufgelöst wird.
Überprüfen Sie, ob ein A-Eintrag für den Verbunddienst auf dem DNS-Server vorhanden ist. Der A-Eintrag sollte auf einen der ADFS-Server oder auf den Lastenausgleich der ADFS-Server verweisen.

Überprüfen des Lastenausgleichs, wenn er verwendet wird

Überprüfen Sie, ob die Firewall datenverkehr zwischen:

Der ADFS-Server und der Lastenausgleich.
Der WAP-Server (Web Anwendungsproxy) und der Lastenausgleichsmodul, wenn WAP verwendet wird.

Wenn der Prüfpunkt für den Lastenausgleich aktiviert ist, überprüfen Sie Folgendes:

Wenn Sie Windows Server 2012 R2 ausführen, stellen Sie sicher, dass das Updaterollup august 2014 installiert ist.
Überprüfen Sie, ob Port 80 in der Firewall auf den WAP-Servern und ADFS-Servern aktiviert ist.
Stellen Sie sicher, dass der Prüfpunkt für Port 80 und für den Endpunkt /adfs/probe festgelegt ist.

Überprüfen der Firewalleinstellungen

Überprüfen Sie, ob eingehender Datenverkehr über TCP-Port 443 aktiviert ist:

die Firewall zwischen dem Web-Anwendungsproxy-Server und der Verbundserverfarm.
die Firewall zwischen den Clients und dem Web-Anwendungsproxy-Server.

Überprüfen Sie, ob eingehender Datenverkehr über TCP-Port 49443 auf der Firewall zwischen den Clients und dem Web-Anwendungsproxy-Server aktiviert ist, wenn die folgenden Bedingungen erfüllt sind:

Die TLS-Clientauthentifizierung mit X.509-Zertifikat ist aktiviert.
Sie verwenden ADFS unter Windows Server 2012 R2.

Notiz

Die Konfiguration ist für die Firewall zwischen dem Web-Anwendungsproxy-Server und den Verbundservern nicht erforderlich.

Überprüfen, ob der Endpunkt auf dem Proxy aktiviert ist

ADFS bietet verschiedene Endpunkte für verschiedene Funktionen und Szenarien. Nicht alle Endpunkte sind standardmäßig aktiviert. Führen Sie die folgenden Schritte aus, um zu überprüfen, ob der Endpunkt auf dem Proxy aktiviert ist:

Öffnen Sie auf dem ADFS-Server die ADFS-Verwaltungskonsole.
Erweitern Sie Dienstendpunkte>.
Suchen Sie den Endpunkt, und überprüfen Sie, ob der Status in der Spalte "Proxy aktiviert " aktiviert ist.

Überprüfen der Proxyvertrauensstellung

Wenn Web Anwendungsproxy (WAP) bereitgestellt wird, muss die Proxyvertrauensstellung zwischen dem WAP-Server und dem AD FS-Server eingerichtet werden. Überprüfen Sie, ob die Proxyvertrauensstellung eingerichtet ist oder zu einem bestimmten Zeitpunkt fehlschlägt.

Notiz

Informationen auf dieser Seite gelten für AD FS 2012 R2 und höher.

Hintergrundinformationen

Die Proxyvertrauensstellung ist clientzertifikatbasiert. Wenn Sie den Assistenten für die Web-Anwendungsproxy nach der Installation ausführen, generiert der Assistent ein selbstsigniertes Clientzertifikat mithilfe der im Assistenten angegebenen Anmeldeinformationen. Anschließend fügt der Assistent das Zertifikat in die AD FS-Konfigurationsdatenbank ein und fügt es dem Zertifikatspeicher "AdfsTrustedDevices" auf dem AD FS-Server hinzu.

Für jede SSL-Kommunikation verwendet http.sys die folgende Prioritätsreihenfolge für SSL-Zertifikatbindungen, um einem Zertifikat zu entsprechen:

Priority	Name	Parameter	Beschreibung
1	IP	IP:Port	Genaue IP- und Port-Übereinstimmung
2	SNI	Hostname:port	Genaue Hostnamen-Übereinstimmung (Verbindung muss SNI angeben)
3	CCS	Port	Aufrufen des zentralen Zertifikatspeichers
4	IPv6-Wildcard	Port	IPv6-Wildcard-Übereinstimmung (Verbindung muss IPv6 sein)
5	IP-Wildcard	Port	IP-Wildcard-Übereinstimmung (Verbindung kann IPv4 oder IPv6 sein)

AD FS 2012 R2 und höher sind unabhängig von Internetinformationsdienste (IIS) und werden als Dienst über http.sys ausgeführt. hostname:port SSL-Zertifikatbindungen werden von AD FS verwendet. Während der Clientzertifikatauthentifizierung sendet AD FS eine Zertifikatvertrauensliste (Certificate Trust List, CTL) basierend auf den Zertifikaten im AdfsTrustedDevices-Speicher. Wenn eine SSL-Zertifikatbindung für Ihren AD FS-Server IP:port verwendet oder der CTL-Speicher keine AdfsTrustedDevices ist, wird die Proxyvertrauensstellung möglicherweise nicht hergestellt.

Abrufen der SSL-Zertifikatbindungen für AD FS

Führen Sie auf dem AD FS-Server den folgenden Befehl in Windows PowerShell aus:
netsh http show sslcert

Suchen Sie in der Liste der zurückgegebenen Bindungen nach denen mit der Anwendungs-ID von 5d89a20c-beab-4389-9447-324788eb944a. Hier ist ein Beispiel für eine fehlerfreie Bindung. Notieren Sie sich die Zeile "Ctl Store Name".

Hostname:port : adfs.contoso.com:443
Certificate Hash : 3638de9b03a488341dfe32fc3ae5c480ee687793
Application ID : {5d89a20c-beab-4389-9447-324788eb944a}
Certificate Store Name : MY
Verify Client Certificate Revocation : Enabled
Verify Revocation Using Cached Client Certificate Only : Disabled
Usage Check : Enabled
Revocation Freshness Time : 0
URL Retrieval Timeout : 0
Ctl Identifier : (null)  
Ctl Store Name : AdfsTrustedDevices
DS Mapper Usage : Disabled
Negotiate Client Certificate : Disabled

Ausführen eines Skripts zum automatischen Erkennen von Problemen

Führen Sie das folgende Skript aus, um Probleme mit der Proxyvertrauensstellung automatisch zu erkennen. Basierend auf dem erkannten Problem ergreifen Sie die Aktion entsprechend.

param
(
  [switch]$syncproxytrustcerts
)
function checkhttpsyscertbindings()
{
Write-Host; Write-Host("1 – Checking http.sys certificate bindings for potential issues")
$httpsslcertoutput = netsh http show sslcert
$adfsservicefqdn = (Get-AdfsProperties).HostName
$i = 1
$certbindingissuedetected = $false
While($i -lt $httpsslcertoutput.count)
{
        $ipport = $false
        $hostnameport = $false
        if ( ( $httpsslcertoutput[$i] -match "IP:port" ) ) { $ipport = $true }
        elseif ( ( $httpsslcertoutput[$i] -match "Hostname:port" ) ) { $hostnameport = $true }
        ## Check for IP specific certificate bindings
        if ( ( $ipport -eq $true ) )
        {
            $httpsslcertoutput[$i]
            $ipbindingparsed = $httpsslcertoutput[$i].split(":")
            if ( ( $ipbindingparsed[2].trim() -ne "0.0.0.0" ) -and ( $ipbindingparsed[3].trim() -eq "443") )
            {
                $warning = "There is an IP specific binding on IP " + $ipbindingparsed[2].trim() + " which may conflict with the AD FS port 443 cert binding." | Write-Warning
                $certbindingissuedetected = $true
            }
            $i = $i + 14
            continue
        }
        ## check that CTL Store is set for ADFS service binding
        elseif ( $hostnameport -eq $true )
        {
            $httpsslcertoutput[$i]
            $ipbindingparsed = $httpsslcertoutput[$i].split(":")
            If ( ( $ipbindingparsed[2].trim() -eq $adfsservicefqdn ) -and ( $ipbindingparsed[3].trim() -eq "443") -and ( $httpsslcertoutput[$i+10].split(":")[1].trim() -ne "AdfsTrustedDevices" ) )
            {
                Write-Warning "ADFS Service binding does not have CTL Store Name set to AdfsTrustedDevices"
                $certbindingissuedetected = $true
            }
        $i = $i + 14
        continue
        }
    $i++
}
If ( $certbindingissuedetected -eq $false ) { Write-Host "Check Passed: No certificate binding issues detected" }
}
function checkadfstrusteddevicesstore()
{
## check for CA issued (non-self signed) certs in the AdfsTrustedDevices cert store
Write-Host; Write-Host "2 – Checking AdfsTrustedDevices cert store for non-self signed certificates"
$certlist = Get-Childitem cert:\LocalMachine\AdfsTrustedDevices -recurse | Where-Object {$_.Issuer -ne $_.Subject}
If ( $certlist.count -gt 0 )
{
    Write-Warning "The following non-self signed certificates are present in the AdfsTrustedDevices store and should be removed"
    $certlist | Format-List Subject
}
Else { Write-Host "Check Passed: No non-self signed certs present in AdfsTrustedDevices cert store" }
}
function checkproxytrustcerts
{
    Param ([bool]$repair=$false)
    Write-Host; Write-Host("3 – Checking AdfsTrustedDevices cert store is in sync with ADFS Proxy Trust config")
    $doc = new-object Xml
    $doc.Load("$env:windir\ADFS\Microsoft.IdentityServer.Servicehost.exe.config")
    $connString = $doc.configuration.'microsoft.identityServer.service'.policystore.connectionString
    $command = "Select ServiceSettingsData from [IdentityServerPolicy].[ServiceSettings]"
    $cli = new-object System.Data.SqlClient.SqlConnection
    $cli.ConnectionString = $connString
    $cmd = new-object System.Data.SqlClient.SqlCommand
    $cmd.CommandText = $command
    $cmd.Connection = $cli
    $cli.Open()
    $configString = $cmd.ExecuteScalar()
    $configXml = new-object XML
    $configXml.LoadXml($configString)
    $rawCerts = $configXml.ServiceSettingsData.SecurityTokenService.ProxyTrustConfiguration._subjectNameIndex.KeyValueOfstringArrayOfX509Certificate29zVOn6VQ.Value.X509Certificate2
    #$ctl = dir cert:\LocalMachine\ADFSTrustedDevices
    $store = new-object System.Security.Cryptography.X509Certificates.X509Store("ADFSTrustedDevices","LocalMachine")
    $store.open("MaxAllowed")
    $atLeastOneMismatch = $false
    $badCerts = @()
    foreach($rawCert in $rawCerts)
    {   
        $rawCertBytes = [System.Convert]::FromBase64String($rawCert.RawData.'#text')
        $cert=New-Object System.Security.Cryptography.X509Certificates.X509Certificate2(,$rawCertBytes)
        $now = Get-Date
        if ( ($cert.NotBefore -lt $now) -and ($cert.NotAfter -gt $now))
        {
            $certThumbprint = $cert.Thumbprint
         $certSubject = $cert.Subject
         $ctlMatch = dir cert:\localmachine\ADFSTrustedDevices\$certThumbprint -ErrorAction SilentlyContinue
         if ($ctlMatch -eq $null)
         {
       $atLeastOneMismatch = $true
          Write-Warning "This cert is NOT in the CTL: $certThumbprint – $certSubject"
       if ($repair -eq $true)
       {
        write-Warning "Attempting to repair"
        $store.Add($cert)
        Write-Warning "Repair successful"
       }
                else
                {
                    Write-Warning ("Please install KB.2964735 or re-run script with -syncproxytrustcerts switch to add missing Proxy Trust certs to AdfsTrustedDevices cert store")
                }
         }
        }
    }
    $store.Close()
    if ($atLeastOneMismatch -eq $false)
    {
     Write-Host("Check Passed: No mismatched certs found. CTL is in sync with DB content")
    }
}
checkhttpsyscertbindings
checkadfstrusteddevicesstore
checkproxytrustcerts($syncproxytrustcerts)
Write-Host; Write-Host("All checks completed.")

Problem 1: Es gibt eine IP-spezifische Bindung

Die Bindung kann mit der AD FS-Zertifikatbindung an Port 443 in Konflikt geraten.

Die IP:port-Bindung hat die höchste Priorität. Wenn sich eine IP:Port-Bindung in den AD FS-SSL-Zertifikatbindungen befindet, verwendet http.sys immer das Zertifikat für die Bindung für die SSL-Kommunikation. Verwenden Sie die folgenden Methoden, um dieses Problem zu lösen.

Entfernen der IP:Port-Bindung

Beachten Sie, dass die IP:Port-Bindung nach dem Entfernen wieder zurückkommt. Eine anwendung, die mit dieser IP:port-Bindung konfiguriert ist, kann sie z. B. automatisch beim nächsten Dienststart neu erstellen.
Verwenden einer anderen IP-Adresse für die AD FS-SSL-Kommunikation

Wenn die IP:Port-Bindung erforderlich ist, lösen Sie den FQDN des ADFS-Diensts in eine andere IP-Adresse auf, die nicht in Bindungen verwendet wird. Auf diese Weise verwendet http.sys die Hostname:port-Bindung für die SSL-Kommunikation.
Festlegen von AdfsTrustedDevices als CTL Store für die IP:port-Bindung

Dies ist die letzte Möglichkeit, wenn Sie die oben genannten Methoden nicht verwenden können. Es ist jedoch besser, die folgenden Bedingungen zu verstehen, bevor Sie den Standard-CTL-Speicher in AdfsTrustedDevices ändern:
- Warum die IP:Port-Bindung vorhanden ist.
- Wenn die Bindung vom standardmäßigen CTL-Speicher für die Clientzertifikatauthentifizierung abhängt.

Problem 2: Die AD FS-Zertifikatbindung hat keinen CTL Store-Namen auf AdfsTrustedDevices festgelegt.

Wenn Microsoft Entra Connect installiert ist, verwenden Sie Microsoft Entra Connect, um den CTL Store-Namen für die SSL-Zertifikatbindungen auf allen AD FS-Servern auf AdfsTrustedDevices festzulegen. Wenn Microsoft Entra Connect nicht installiert ist, generieren Sie die AD FS-Zertifikatbindungen neu, indem Sie den folgenden Befehl auf allen AD FS-Servern ausführen.

Set-AdfsSslCertificate -Thumbprint Thumbprint

Problem 3: Ein Zertifikat, das nicht selbstsigniert ist, ist im AdfsTrustedDevices-Zertifikatspeicher vorhanden.

Wenn sich ein von einer Zertifizierungsstelle ausgestelltes Zertifikat in einem Zertifikatspeicher befindet, in dem normalerweise nur selbstsignierte Zertifikate vorhanden wären, würde die aus dem Speicher generierte CTL nur das ausgestellte Zertifikat der Zertifizierungsstelle enthalten. Der AdfsTrustedDevices-Zertifikatspeicher ist ein solcher Speicher, der nur über selbstsignierte Zertifikate verfügen soll. Diese Zertifikate sind:

MS-Organization-Access: Das selbstsignierte Zertifikat, das für die Ausstellung von Workplace Join-Zertifikaten verwendet wird.
ADFS-Proxyvertrauensstellung: Die Zertifikate für jeden Web-Anwendungsproxy-Server.

Die Zertifikate für jeden Web-Anwendungsproxy-Server.

Löschen Sie daher alle zertifizierungsstellen ausgestellten Zertifikate aus dem Zertifikatspeicher von AdfsTrustedDevices.

Problem 4: Installieren KB2964735 oder erneutes Ausführen des Skripts mit -syncproxytrustcerts

Wenn eine Proxyvertrauensstellung mit einem AD FS-Server eingerichtet wird, wird das Clientzertifikat in die AD FS-Konfigurationsdatenbank geschrieben und dem AdfsTrustedDevices-Zertifikatspeicher auf dem AD FS-Server hinzugefügt. Für eine AD FS-Farmbereitstellung wird erwartet, dass das Clientzertifikat mit den anderen AD FS-Servern synchronisiert wird. Wenn die Synchronisierung aus irgendeinem Grund nicht erfolgt, funktioniert eine Proxyvertrauensstellung nur mit dem AD FS-Server, mit dem die Vertrauensstellung eingerichtet wurde, aber nicht für die anderen AD FS-Server.

Verwenden Sie eine der folgenden Methoden, um dieses Problem zu lösen.

Methode 1

Installieren Sie das in KB 2964735 dokumentierte Update auf allen AD FS-Servern. Nach der Installation des Updates wird erwartet, dass automatisch eine Synchronisierung des Clientzertifikats erfolgt.

Methode 2

Führen Sie das Skript mit dem Switch "- syncproxytrustcerts" aus, um die Clientzertifikate manuell aus der AD FS-Konfigurationsdatenbank mit dem Zertifikatspeicher "AdfsTrustedDevices" zu synchronisieren. Das Skript sollte auf allen AD FS-Servern in der Farm ausgeführt werden.

Notiz

Dies ist keine dauerhafte Lösung, da die Clientzertifikate regelmäßig erneuert werden.

Problem 5: Alle Prüfungen werden bestanden. Das Problem bleibt jedoch bestehen.

Überprüfen Sie, ob die Zeitzone nicht übereinstimmen kann. Wenn die Zeit stimmt, die Zeitzone aber nicht, schlägt auch die Proxyvertrauensbeziehung fehl.

Überprüfen, ob zwischen dem AD FS-Server und dem WAP-Server SSL-Beendigung vorhanden ist

Wenn die SSL-Beendigung auf einem Netzwerkgerät zwischen AD FS-Servern und dem WAP-Server erfolgt, wird die Kommunikation zwischen AD FS und WAP abgebrochen, da die Kommunikation auf dem Clientzertifikat basiert.

Deaktivieren Sie die SSL-Beendigung auf dem Netzwerkgerät zwischen den AD FS- und WAP-Servern.

Verwenden der Dumptoken-App

Die Dumptoken-App ist hilfreich beim Debuggen von Problemen mit Ihrem Verbunddienst sowie beim Überprüfen von benutzerdefinierten Anspruchsregeln. Es handelt sich nicht um eine offizielle Lösung, sondern um eine gute unabhängige Debuglösung, die für die Problembehandlung empfohlen wird.

Bevor Sie die Dumptoken-App verwenden

Bevor Sie die Dumptoken-App verwenden, müssen Sie Folgendes ausführen:

Rufen Sie die Informationen der vertrauenden Seite für die Anwendung ab, auf die Sie zugreifen möchten. Wenn die OAuth-Authentifizierung implementiert ist, rufen Sie auch die OAuth-Clientinformationen ab.
Richten Sie die Dumptoken-App ein.

Abrufen der Clientinformationen der vertrauenden Seite und des OAuth-Clients

Wenn Sie eine herkömmliche vertrauende Seite verwenden, führen Sie die folgenden Schritte aus:

Öffnen Sie auf dem AD FS-Server Windows PowerShell mit der Option "Als Administrator ausführen".
Fügen Sie die AD FS 2.0-Komponente zu Windows PowerShell hinzu, indem Sie den folgenden Befehl ausführen:
```
Add-PSSnapin Microsoft.Adfs.PowerShell
```
Rufen Sie die Informationen der vertrauenden Seite ab, indem Sie den folgenden Befehl ausführen:
```
$rp = Get-AdfsRelyingPartyTrust RPName
```
Rufen Sie die OAuth-Clientinformationen ab, indem Sie den folgenden Befehl ausführen:
```
$client = Get-AdfsClient ClientName
```

Wenn Sie das Feature "Anwendungsgruppe" in Windows Server 2016 verwenden, führen Sie die folgenden Schritte aus:

Öffnen Sie auf dem AD FS-Server Windows PowerShell mit der Option "Als Administrator ausführen".
Rufen Sie die Informationen der vertrauenden Seite ab, indem Sie den folgenden Befehl ausführen:
```
$rp = Get-AdfsWebApiApplication ResourceID
```
Wenn der OAuth-Client öffentlich ist, rufen Sie die Clientinformationen ab, indem Sie den folgenden Befehl ausführen:
```
$client = Get-AdfsNativeClientApplication ClientName
```
Wenn der OAuth-Client vertraulich ist, rufen Sie die Clientinformationen ab, indem Sie den folgenden Befehl ausführen:
```
$client = Get-AdfsServerApplication ClientName
```

Einrichten der Dumptoken-App

Führen Sie zum Einrichten der Dumptoken-App die folgenden Befehle im Windows PowerShell-Fenster aus:

$authzRules = "=>issue(Type = `"http://schemas.microsoft.com/authorization/claims/permit`", Value = `"true`");"
$issuanceRules = "x:[]=>issue(claim=x);"
$redirectUrl = "https://dumptoken.azurewebsites.net/default.aspx"
$samlEndpoint = New-AdfsSamlEndpoint -Binding POST -Protocol SAMLAssertionConsumer -Uri $redirectUrl
Add-ADFSRelyingPartyTrust -Name "urn:dumptoken" -Identifier "urn:dumptoken" -IssuanceAuthorizationRules $authzRules -IssuanceTransformRules $issuanceRules -WSFedEndpoint $redirectUrl -SamlEndpoint $samlEndpoint

Fahren Sie nun mit den folgenden Problembehandlungsmethoden fort. Sehen Sie am Ende jeder Methode, ob das Problem gelöst ist. Wenn nicht, verwenden Sie eine andere Methode.

Methoden zur Problembehandlung

Überprüfen Sie die Autorisierungsrichtlinie, um festzustellen, ob der Benutzer betroffen ist.

Bei dieser Methode erhalten Sie zunächst die Richtliniendetails, und verwenden Sie dann die Dumptoken-App, um die Richtlinie zu diagnostizieren, um festzustellen, ob der Benutzer betroffen ist.

Abrufen der Richtliniendetails

$rp. "IssuanceAuthorizationRules" zeigt die Autorisierungsregeln der vertrauenden Seite an.

In Windows Server 2016 und höheren Versionen können Sie $rp verwenden. AccessControlPolicyName zum Konfigurieren der Authentifizierungs- und Autorisierungsrichtlinie. Wenn $rp. AccessControlPolicyName hat einen Wert, eine Zugriffssteuerungsrichtlinie ist vorhanden, die die Autorisierungsrichtlinie steuert. In diesem Fall $rp. AusstellungsauthorizationRules ist leer. Verwenden Sie $rp. ResultantPolicy, um Details zur Zugriffssteuerungsrichtlinie zu erfahren.

Wenn $rp. ResultantPolicy verfügt nicht über die Details zur Richtlinie, schauen Sie sich die tatsächlichen Anspruchsregeln an. Führen Sie die folgenden Schritte aus, um die Anspruchsregeln abzurufen:

Legen Sie die Zugriffssteuerungsrichtlinie auf $null fest, indem Sie den folgenden Befehl ausführen:
Set-AdfsRelyingPartyTrust -TargetRelyingParty $rp -AccessControlPolicyName $null
Rufen Sie die Informationen der vertrauenden Seite ab, indem Sie den folgenden Befehl ausführen:
$rp = Get-AdfsRelyingPartyTrust RPName
Überprüfen $rp.IssuanceAuthorizationRules und $rp. AdditionalAuthenticationRules.

Verwenden der Dumptoken-App zum Diagnostizieren der Autorisierungsrichtlinie

Legen Sie die Authentifizierungsrichtlinie für Dumptoken so fest, dass sie mit der fehlerhaften vertrauenden Seite übereinstimmt.
Lassen Sie den Benutzer einen der folgenden Links öffnen, je nachdem, welche Authentifizierungsrichtlinie Sie festgelegt haben.
- WS-Fed: https://FederationInstance/adfs/ls?wa=wsignin1.0&wtrealm=urn:dumptoken
- SAML-P: https://FederationInstance/adfs/ls/IdpInitiatedSignOn?LoginToRP=urn:dumptoken
- Mehrstufige Authentifizierung erzwingen: https://FederationInstance/adfs/ls?wa=wsignin1.0&wtrealm=urn:dumptoken&wauth=http://schemas.microsoft.com/claims/multipleauthn
Melden Sie sich auf der Anmeldeseite an.

Was Sie erhalten, ist der Satz von Ansprüchen des Benutzers. Überprüfen Sie, ob in der Autorisierungsrichtlinie etwas vorhanden ist, das den Benutzer basierend auf diesen Ansprüchen explizit verweigert oder zulässt.

Überprüfen, ob fehlende oder unerwartete Ansprüche den Zugriff auf die Ressource verweigern

Konfigurieren Sie die Anspruchsregeln in der Dumptoken-App so, dass sie mit den Anspruchsregeln der fehlerhaften vertrauenden Seite identisch sind.
Konfigurieren Sie die Authentifizierungsrichtlinie für Dumptoken so, dass sie mit der fehlerhaften vertrauenden Seite übereinstimmt.
Lassen Sie den Benutzer einen der folgenden Links öffnen, je nachdem, welche Authentifizierungsrichtlinie Sie festgelegt haben.
- WS-Fed: https://FederationInstance/adfs/ls?wa=wsignin1.0&wtrealm=urn:dumptoken
- SAML-P: https://FederationInstance/adfs/ls/IdpInitiatedSignOn?LoginToRP=urn:dumptoken
- Mehrstufige Authentifizierung erzwingen: https://FederationInstance/adfs/ls?wa=wsignin1.0&wtrealm=urn:dumptoken&wauth=http://schemas.microsoft.com/claims/multipleauthn
Melden Sie sich auf der Anmeldeseite an.

Dies ist die Gruppe von Ansprüchen, die die vertrauende Seite für den Benutzer abrufen wird. Wenn ansprüche fehlen oder unerwartet sind, schauen Sie sich die Ausstellungsrichtlinie an, um den Grund zu ermitteln.

Wenn alle Ansprüche vorhanden sind, wenden Sie sich an den Anwendungsbesitzer, um festzustellen, welcher Anspruch fehlt oder unerwartet ist.

Überprüfen, ob ein Gerätestatus erforderlich ist

Wenn die Autorisierungsregeln auf Geräteansprüche überprüfen, überprüfen Sie, ob eines dieser Geräteansprüche in der Liste der Ansprüche fehlt, die Sie aus der Dumptoken-App erhalten. Die fehlenden Ansprüche könnten die Geräteauthentifizierung blockieren. Um die Ansprüche aus der Dumptoken-App abzurufen, führen Sie die Schritte in der App "Verwenden der Dumptoken-App" aus, um den Abschnitt "Autorisierungsrichtlinie überprüfen" zu diagnostizieren, wenn sich der Benutzer auf die Methode auswirkte .

Nachfolgend sind die Geräteansprüche aufgeführt. Die Autorisierungsregeln können einige davon verwenden.

http://schemas.microsoft.com/2012/01/devicecontext/claims/registrationid
http://schemas.microsoft.com/2012/01/devicecontext/claims/displayname
http://schemas.microsoft.com/2012/01/devicecontext/claims/identifier
http://schemas.microsoft.com/2012/01/devicecontext/claims/ostype
http://schemas.microsoft.com/2012/01/devicecontext/claims/osversion
http://schemas.microsoft.com/2012/01/devicecontext/claims/ismanaged
http://schemas.microsoft.com/2012/01/devicecontext/claims/isregistereduser
http://schemas.microsoft.com/2014/02/devicecontext/claims/isknown
http://schemas.microsoft.com/2014/02/deviceusagetime
http://schemas.microsoft.com/2014/09/devicecontext/claims/iscompliant
http://schemas.microsoft.com/2014/09/devicecontext/claims/trusttype

Wenn ein Anspruch fehlt, führen Sie die Schritte unter Konfigurieren des lokalen bedingten Zugriffs mithilfe registrierter Geräte aus, um sicherzustellen, dass die Umgebung für die Geräteauthentifizierung eingerichtet ist.

Wenn alle Ansprüche vorhanden sind, überprüfen Sie, ob die Werte der Ansprüche aus der Dumptoken-App den in der Autorisierungsrichtlinie erforderlichen Werten entsprechen.

Freigeben über

Behandeln von SSO-Problemen mit Active Directory-Verbunddienste (AD FS) (AD FS)

NTLM- oder formularbasierte Authentifizierungsaufforderung

Überprüfen der Einstellungen für die integrierte Windows-Authentifizierung

Überprüfen des Clientbrowsers des Benutzers

Überprüfen der AD FS-Einstellungen

Überprüfen der Einstellung "WindowsIntegratedFallback"

Überprüfen der WIASupportedUsersAgents-Einstellung

Überprüfen der Authentifizierungsanforderungsparameter

Überprüfen, ob die Authentifizierungsanforderung formularbasierte Authentifizierung als Authentifizierungsmethode angibt

Überprüfen, ob die Anwendung Microsoft Online Services für Office 365 ist

Microsoft Entra-Szenario

Nicht microsoft Entra-Szenario

Überprüfen, ob SSO deaktiviert ist

Mehrstufige Authentifizierungsaufforderung

Überprüfen der Konfiguration auf dem AD FS-Server und der vertrauenden Seite

Überprüfen, ob die mehrstufige Authentifizierung im Anspruchsregelsatz aktiviert ist

Überprüfen der Ausstellungsregeln der vertrauenden Seite

Überprüfen des Authentifizierungsanforderungsparameters

Überprüfen Sie, ob die Authentifizierungsanforderung die mehrstufige Authentifizierung als Authentifizierungsmethode angibt.

Überprüfen, ob die Anwendung Microsoft Online Services für Office 365 ist

Überprüfen, ob SSO deaktiviert ist

Benutzer können sich nicht bei der Zielwebsite oder dem Zieldienst anmelden.

Dieses Problem tritt auf der AD FS-Anmeldeseite auf.

Alle Benutzer sind von dem Problem betroffen, und der Benutzer kann nicht auf eine der vertrauenden Parteien zugreifen.

Die Anmeldung ist erfolgreich.

Die Anmeldung ist nicht erfolgreich.

Überprüfen, ob das SSL-Zertifikat ordnungsgemäß installiert ist

Überprüfen, ob das richtige SSL-Zertifikat verwendet wird

Überprüfen, ob das SSL-Zertifikat als Dienstkommunikationszertifikat festgelegt ist

Überprüfen, ob der Geräteregistrierungsdienst (Device Registration Service, DRS) in AD FS konfiguriert ist

Alle Benutzer sind von dem Problem betroffen, und der Benutzer kann auf einige der vertrauenden Parteien zugreifen.

Überprüfen der Einstellungen der vertrauenden Seite und des Clients

OAuth-Anforderungen

WS-Fed-Anforderungen

SAML-Anforderungen

Überprüfen des Verschlüsselungszertifikats

Die beiden vorherigen Methoden funktionieren nicht

Nicht alle Benutzer sind von dem Problem betroffen, und der Benutzer kann nicht auf eine der vertrauenden Parteien zugreifen.

Überprüfen, ob der Benutzer deaktiviert ist

Überprüfen des Benutzerstatus mit Windows PowerShell

Überprüfen des Benutzerstatus in der Benutzeroberfläche

Überprüfen, ob die Benutzereigenschaften kürzlich aktualisiert wurden

Überprüfen der Gesamtstrukturvertrauensstellung, wenn der Benutzer zu einer anderen Gesamtstruktur gehört

Nicht alle Benutzer sind vom Problem betroffen, und der Benutzer kann auf einige der vertrauenden Parteien zugreifen.

Überprüfen, ob der Benutzer mit der Microsoft Entra-ID synchronisiert wird

Überprüfen der unveränderlichen ID und des UPN in ausstellungsanspruchsregel

Dieses Problem tritt auf der Anwendungsseite auf.

Die Fingerabdruck der beiden Zertifikate stimmen überein

Die Fingerabdruck der beiden Zertifikate stimmen nicht überein.

Informationen zur automatischen Zertifikatverlängerung

Überprüfen der ADFS-bezogenen Komponenten und Dienste

DNS überprüfen

Überprüfen des Lastenausgleichs, wenn er verwendet wird

Überprüfen der Firewalleinstellungen

Überprüfen, ob der Endpunkt auf dem Proxy aktiviert ist

Überprüfen der Proxyvertrauensstellung

Hintergrundinformationen

Ausführen eines Skripts zum automatischen Erkennen von Problemen

Problem 1: Es gibt eine IP-spezifische Bindung

Problem 2: Die AD FS-Zertifikatbindung hat keinen CTL Store-Namen auf AdfsTrustedDevices festgelegt.

Problem 3: Ein Zertifikat, das nicht selbstsigniert ist, ist im AdfsTrustedDevices-Zertifikatspeicher vorhanden.

Problem 4: Installieren KB2964735 oder erneutes Ausführen des Skripts mit -syncproxytrustcerts

Methode 1

Methode 2

Problem 5: Alle Prüfungen werden bestanden. Das Problem bleibt jedoch bestehen.

Verwenden der Dumptoken-App

Bevor Sie die Dumptoken-App verwenden

Abrufen der Clientinformationen der vertrauenden Seite und des OAuth-Clients

Einrichten der Dumptoken-App

Methoden zur Problembehandlung

Überprüfen Sie die Autorisierungsrichtlinie, um festzustellen, ob der Benutzer betroffen ist.

Abrufen der Richtliniendetails

Verwenden der Dumptoken-App zum Diagnostizieren der Autorisierungsrichtlinie

Überprüfen, ob fehlende oder unerwartete Ansprüche den Zugriff auf die Ressource verweigern

Überprüfen, ob ein Gerätestatus erforderlich ist

Feedback

Zusätzliche Ressourcen