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

Artikel
10/13/2022
41 Minuten Lesedauer

Dieser Artikel hilft Ihnen, Probleme mit einmaligem Anmelden (Single Sign-On, SSO) mit Active Directory-Verbunddienste (AD FS) (AD FS) zu beheben.

Wählen Sie je nach Art des auftretenden Problems einen der folgenden Abschnitte aus.

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

NTLM- oder formularbasierte Authentifizierungsaufforderung

Wenn Benutzer bei der Behandlung von Problemen mit einmaligem Anmelden (Single Sign-On, SSO) mit Active Directory-Verbunddienste (AD FS) (AD FS) unerwartete NTLM- oder formularbasierte Authentifizierungsaufforderungen erhalten haben, führen Sie die Schritte in diesem Artikel aus, um dieses Problem zu beheben.

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

Um dieses Problem zu beheben, überprüfen Sie die Einstellungen für die integrierte 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.
Vergewissern Sie sich, dass sich die AD FS-URL in der Liste der Websites befindet, wenn Sie auf "LokaleSicherheitsintranetwebsites>>> erweitert" folgen.
Vergewissern Sie sich, dass nach der Benutzerdefinierten Stufe "Lokales Sicherheitsintranet >>" die Einstellung "Automatische Anmeldung nur in Der 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 WindowsIntegratedFallback-Einstellung

Ö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
```
Überprüfen Sie den Wert des WindowsIntegratedFallbackEnabled-Attributs .

Wenn der Wert "True" ist, 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 Einstellung "WIASupportedUsersAgents"

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 Benutzer-Agent-Zeichenfolgen, die der Befehl zurückgibt.

Ü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/ diesem Vorgang, der die Benutzer-Agent-Zeichenfolge Ihres Browsers erkennt und anzeigt.
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 die formularbasierte Authentifizierung als Authentifizierungsmethode angibt

Wenn es sich bei der Authentifizierungsanforderung um eine WS-Federation-Anforderung 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 Sie, ob es sich bei der Anwendung um Microsoft Online Services für Office 365

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

Wenn es sich bei der Anwendung um Microsoft Online Services handelt, wird die Erfahrung möglicherweise von der PromptLoginBehavior-Einstellung des vertrauenswürdigen Bereichsobjekts gesteuert. Diese Einstellung steuert, ob Azure AD-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 Einstellung für den Domänenverbund 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 lauten:
1. TranslateToFreshPasswordAuth: Azure AD 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: Es wird nichts an AD FS gesendet.

Weitere Informationen zum Befehl Set-MSOLDomainFederationSettings finden Sie unter Active Directory-Verbunddienste (AD FS) prompt=login-Parameterunterstützung.

Azure Active Directory (Azure AD)-Szenario

Wenn die an Azure AD 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, schließt Office 365 Anwendungen nicht den Parameter prompt=login in jede Authentifizierungsanforderung ein.

Nicht-Azure AD-Szenario

Für Anforderungsparameter wie WAUTH und RequestedAuthNContext in Authentifizierungsanforderungen können Authentifizierungsmethoden angegeben werden. Überprüfen Sie, ob andere Anforderungsparameter die unerwartete Authentifizierungsaufforderung erzwingen. Wenn ja, ändern Sie 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.

Aufforderung zur mehrstufigen Authentifizierung

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

Die mehrstufige Authentifizierung kann auf einem AD FS-Server, bei einer vertrauenden Partei oder in einem Authentifizierungsanforderungsparameter aktiviert werden. Überprüfen Sie die Konfigurationen, um festzustellen, ob sie richtig 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 weitergegeben 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.

Führen Sie den folgenden Befehl in einem Windows PowerShell Fenster aus, um die Konfiguration auf dem AD FS-Server zu überprüfen.
```
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
```
Hinweis

Wenn die Befehle nichts zurückgeben, sind die zusätzlichen Authentifizierungsregeln nicht konfiguriert. Überspringen Sie diesen Abschnitt.
Beachten Sie den konfigurierten Anspruchsregelsatz.

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

Ein Anspruchsregelsatz besteht aus den folgenden Abschnitten:

Die Bedingungsanweisung: C:[Type=``…,Value=…]
Die Issue-Anweisung: => issue (Type=``…,Value=…)

Wenn die Issue-Anweisung 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, für die die mehrstufige Authentifizierung für nicht am Arbeitsplatz eingebundene Geräte bzw. für den Extranetzugriff 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 erhält, nachdem er die erste Authentifizierung durchgeführt hat, ist es möglich, dass die antwortende Seite die mehrstufigen Authentifizierungsansprüche nicht an die Anwendung weitergibt. 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
```
Beachten Sie den in den Attributen "IssuanceAuthorizationRules" oder "IssuanceAuthorizationRulesFile" definierten Regelsatz.

Der Regelsatz sollte die folgende Ausstellungsregel enthalten, um die Ansprüche für die mehrstufige Authentifizierung 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, ob die Authentifizierungsanforderung die mehrstufige Authentifizierung als Authentifizierungsmethode angibt

Wenn die Authentifizierungsanforderung eine WS-Federation Anforderung ist, ü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 Sie, ob es sich bei der Anwendung um Microsoft Online Services für Office 365

Wenn es sich bei der Anwendung, auf die Sie zugreifen möchten, um Microsoft Online Services für Office 365 handelt, überprüfen Sie die Einstellung für den Domänenverbund "SupportsMFA".

Rufen Sie die aktuelle SupportsMFA-Domänenverbundeinstellung ab, indem Sie den folgenden Befehl ausführen:
```
Get-MSOLDomainFederationSettings -DomainName DomainName | FL *
```
Wenn die Einstellung "SupportsMFA" auf "FALSE" festgelegt 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 eine "Fehlermeldung", "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 Problem aus.

Um dieses Problem zu beheben, überprüfen Sie, ob alle Benutzer von dem 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.

Sehen wir uns die interne Anmeldefunktion mithilfe von IdpInitiatedSignOn an. Verwenden Sie dazu die IdpInititatedSignOn-Seite, um zu überprüfen, ob der AD FS-Dienst ausgeführt wird 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 auf einem Computer in Ihrem Netzwerk 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 "Extras Dienste">.
Überprüfen Sie, ob der Status von Active Directory-Verbunddienste (AD FS)ausgeführt wird.

Überprüfen Sie dann die externe Anmeldefunktion mithilfe von IdpInitiatedSignOn. Verwenden Sie die IdpInititatedSignOn-Seite, um schnell zu überprüfen, ob der AD FS-Dienst ausgeführt wird 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 auf einem Computer außerhalb Ihres Netzwerks 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 "Überprüfen der AD FS-bezogenen Komponenten und Dienste" und "Überprüfen der Proxyvertrauensbeziehung".

Wenn die Anmeldung erfolgreich ist, setzen Sie die 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 AD FS-bezogenen 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 "Extras Dienste">.
Ü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 unterschiedliche 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.
>Dienstendpunkte erweitern.
Suchen Sie die Endpunkte, und überprüfen Sie, ob die Status in der Spalte "Aktiviert" aktiviert sind.

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

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

Wenn Azure AD 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 Nicht-Domänencomputern aus zugegriffen wird, empfehlen wir, dass Sie ein SSL-Zertifikat von einer vertrauenswürdigen Stammzertifizierungsstelle eines Drittanbieters wie DigiCert, VeriSign usw. verwenden. Wenn das SSL-Zertifikat nicht von einer vertrauenswürdigen Stammzertifizierungsstelle stammt, kann die SSL-Kommunikation getrennt werden.
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. Um den Namen des Verbunddiensts abzurufen, führen Sie den folgenden Befehl auf dem primären AD FS-Server aus:
Get-AdfsProperties | select hostname
Das Zertifikat wird nicht widerrufen.

Überprüfen Sie die Zertifikatsperrung. 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 abzurufen. Es wird empfohlen, Azure AD 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. Doppelklicken Sie auf die Schaltfläche , um das Zertifikat zu installieren. 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:

Führen Sie den folgenden Befehl aus, um die Zertifikate auflisten, die sich im persönlichen Speicher für den lokalen Computer befinden:
dir Cert:\LocalMachine\My
Überprüfen Sie, ob das Zertifikat in der Liste enthalten ist.

Ü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-VerwaltungskonsoleDienstzertifikate>.
Ü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 Leseberechtigung für das Zertifikat verfügt:
1. Fügen Sie der Microsoft Management Console (MMC) das Zertifikat-Snap-In für das konto des lokalen Computers hinzu.
2. Erweitern Sie Zertifikate (lokaler Computer)>Persönlich>Zertifikate.
3. Klicken Sie mit der rechten Maustaste auf das SSL-Zertifikat, und 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", dann auf " Speicherorte", dann auf den Server und dann auf "OK".
2. Geben Sie unter "Geben Sie die auszuwählenden Objektnamen ein"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 ordnungsgemäß für RDS konfiguriert ist. Wenn z. B. zwei UPN-Suffixe contoso.com vorhanden sind und fabrikam.comdas Zertifikat über und enterpriseregistration.fabrikma.com als alternative Antragstellernamen (Subject Alternative Names, SANs) verfügen mussenterpriseregistration.contoso.com.

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

Führen Sie den folgenden Befehl aus, um alle upn-Suffixe aufzulisten, die in der Organisation verwendet werden:
```
Get-AdfsDeviceRegistratrionUpnSuffix
```
Überprüfen Sie, ob für das SSL-Zertifikat die erforderlichen SANs konfiguriert sind.
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.

Zur Unterstützung von Nicht-SNI-Fällen können Administratoren Fallbackbindungen angeben. Suchen Sie außer der standard federationservicename:443-Bindung nach Fallbackbindungen unter den folgenden Anwendungs-IDs:
- {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: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.

Zuerst rufen wir die Informationen der vertrauenden Seite und des OAuth-Clients ab. Wenn Sie eine herkömmliche vertrauende Partei 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 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 Methoden zur Problembehandlung fort.

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

Der Bezeichner der vertrauenden Seite, die Client-ID und der Umleitungs-URI sollten vom Besitzer der Anwendung und vom Client bereitgestellt werden. Es könnte jedoch immer noch ein Konflikt zwischen dem, was der Besitzer bereitstellt, und dem, was in AD FS konfiguriert ist, bestehen. Ein Konflikt kann z. B. durch einen Tippfehler verursacht werden. Überprüfen Sie, ob die vom Besitzer bereitgestellten Einstellungen mit den in AD FS konfigurierten übereinstimmen. Mit den Schritten auf der vorherigen Seite erhalten Sie die Einstellungen, die in AD FS über PowerShell konfiguriert sind.

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

Wenn Elemente in der Tabelle übereinstimmen, überprüfen Sie zusätzlich, ob diese Einstellungen zwischen dem übereinstimmen, was in der an AD FS gesendeten Authentifizierungsanforderung angezeigt wird, und dem, was in AD FS konfiguriert ist. Versuchen Sie, das Problem zu reproduzieren, bei dem Sie eine Fiddler-Ablaufverfolgung für die Authentifizierungsanforderung erfassen, die von der Anwendung an AD FS gesendet wird. Überprüfen Sie die Anforderungsparameter, um je nach Anforderungstyp die folgenden Überprüfungen 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 mit den in AD FS konfigurierten Einstellungen übereinstimmen.

Anforderungsparameter	In AD FS konfigurierte Einstellungen
client_id	$client. Clientid
redirect_uri	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	Präfixübereinstimmung oder Platzhalterü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 von "Destination" mit dem AD FS-Hostnamen übereinstimmt.
Überprüfen Sie, ob der Wert des Ausstellers $rp.Identifierübereinstimmt.

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 für die 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 zum Verschlüsseln der Ansprüche. Führen Sie die folgenden Überprü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 Anforderungen für die Sperrüberprüfung 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 Überprüfungen aus.

Überprüfen, ob der Benutzer deaktiviert ist

Überprüfen Sie den Benutzerstatus in Windows PowerShell oder 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 auf 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 im Active Directory aktualisiert wird, führt dies 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 übernommen werden. Führen Sie die folgenden Schritte aus, um zu überprüfen, ob an einem Benutzer Eigenschaftsänderungen 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 auf Hinweise auf eine Änderung. Im folgenden Beispiel verwendet das Attribut "userPrincipleName" ein neueres Datum als die anderen Attribute, das eine Änderung der Metadaten des Benutzerobjekts darstellt.

Ü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, in der AD FS bereitgestellt wird, und den anderen Gesamtstrukturen erforderlich, 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 Verwaltungskonsole für Active Directory-Domänen und -Vertrauensstellungen .
Klicken Sie in der 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 vertrauenswürdig sind (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 Domain Services eine der Optionen aus.
- Wenn Sie "Nein" auswählen, wird empfohlen, dasselbe Verfahren für die gegenseitige Domäne zu wiederholen.
- Wenn Sie "Ja" auswählen, geben Sie eine administratorliche Benutzeranmeldeinformationen für die reziproke Domäne an. Es ist nicht erforderlich, dasselbe Verfahren für die reziproke Domäne auszuführen.

Wenn Ihnen diese Schritte nicht bei der Lösung des Problems geholfen haben, setzen Sie die Problembehandlung mit den Schritten im Abschnitt "Nicht alle Benutzer sind von dem Problem betroffen" fort, und der Benutzer kann auf einen Teil des Abschnitts der vertrauenden Parteien zugreifen .

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

Überprüfen Sie in diesem Szenario, ob dieses Problem in einem Azure AD-Szenario auftritt. Wenn ja, führen Sie diese Überprüfungen aus, um dieses Problem zu beheben. Wenn nicht, lesen Sie "Verwenden der Dumptoken-App ", um dieses Problem zu beheben.

Überprüfen, ob der Benutzer mit Azure AD synchronisiert ist

Wenn ein Benutzer versucht, sich bei Azure AD anzumelden, wird er zur Authentifizierung für eine Verbunddomäne zu AD FS umgeleitet. Einer der möglichen Gründe für eine fehlgeschlagene Anmeldung ist, dass der Benutzer noch nicht mit Azure AD synchronisiert ist. Möglicherweise wird nach dem ersten Authentifizierungsversuch bei AD FS eine Schleife von Azure AD zu AD FS angezeigt. Führen Sie die folgenden Schritte aus, um festzustellen, ob der Benutzer mit Azure AD 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 Azure AD, 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 Azure AD ab, indem Sie den folgenden Befehl ausführen:
Get-MsolUser
Überprüfen Sie, ob sich der Benutzer in der Liste befindet.

Wenn der Benutzer nicht in der Liste enthalten ist, synchronisieren Sie den Benutzer mit Azure AD.

Überprüfen von "immutableID" und "UPN" in der Ausstellungsanspruchsregel

Azure AD erfordert "immutableID" und den UPN des Benutzers, um den Benutzer zu authentifizieren.

Hinweis

immutableID wird in den folgenden Tools auch als "sourceAnchor" bezeichnet:

Azure AD Sync
Azure Active Directory-Synchronisierung (DirSync)

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

Führen Sie die folgenden Schritte aus, um zu überprüfen, ob die Anspruchsregeln für "immutableID" und "UPN" in AD FS den von Azure AD verwendeten Bedingungen entsprechen:

Abrufen von "sourceAnchor" und "UPN" in Azure AD Connect.
1. Öffnen Sie Azure AD 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 auf dem 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 Azure AD, 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 für Werte von "immutableID" und "UPN" abgefragten Variablen mit denen in Azure AD Connect übereinstimmen.
Wenn ein Unterschied besteht, verwenden Sie eine der folgenden Methoden:
- Wenn AD FS von Azure AD Connect verwaltet wird, setzen Sie die Vertrauensstellung der vertrauenden Seite mithilfe von Azure AD Connect zurück.
- Wenn AD FS nicht von Azure AD Connect verwaltet wird, korrigieren Sie die Ansprüche mit den richtigen Attributen.

Wenn Ihnen diese Überprüfungen nicht bei der Lösung des Problems geholfen haben, lesen Sie "Verwenden der Dumptoken-App zum Beheben dieses Problems".

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 Partner des Verbunds übernommen wurde. Falls AD FS ein Token-Entschlüsselungszertifikat verwendet, das kürzlich ebenfalls erneuert wurde, führen Sie 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 auf dem Partnerverbund ü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 Zertifikat 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 Fingerabdrucks der beiden Zertifikate.

Führen Sie die gleiche Überprüfung aus, ob AD FS ein erneuertes Tokenentschlüsselungszertifikat verwendet, mit der Ausnahme, dass der Befehl zum Abrufen des Zertifikats zum Entschlüsseln des Tokens auf AD FS wie folgt lautet:

Get-ADFSCertificate -CertificateType token-decrypting

Die Fingerabdrucks der beiden Zertifikate stimmen überein

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

Wenn zertifikatskonflikte vorliegen, stellen Sie sicher, dass die Partner die neuen Zertifikate verwenden. Zertifikate sind in den vom AD FS-Server veröffentlichten Verbundmetadaten enthalten.

Hinweis

Die Partner verweisen auf alle Partner Ihrer Ressourcenorganisation oder Kontoorganisation, die in Ihrem AD FS durch Vertrauensstellungen der vertrauenden Seite und Vertrauensstellungen von Anspruchsanbietern 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 CERT-Dateien 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 Fingerabdrucks der beiden Zertifikate stimmen nicht überein

Überprüfen Sie dann, ob ein Nichtübereinstimmung mit dem Tokensignaturalgorithmus vorliegt. Gehen Sie dazu wie folgt vor:

Ermitteln 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.
Erkundigen Sie sich beim Anwendungsbesitzer nach dem 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 dem entspricht, was die Anwendung benötigt.

Dumpen Sie auf dem AD FS-Server die Ausstellungstransformationsregeln, 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 das Standardformat.
- 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 nameIdentifier-Format, das von der Anwendung benötigt wird.
Überprüfen Sie, ob die beiden NameIdentifier-Formate übereinstimmen.
Wenn die Formate nicht übereinstimmen, konfigurieren Sie den NameIdentifier-Anspruch so, dass er das format verwendet, das die Anwendung benötigt. Gehen Sie dazu wie folgt vor:
1. Öffnen Sie die AD FS-Verwaltungskonsole.
2. Klicken Sie auf Vertrauensstellungen vertrauender Parteien, wählen Sie den entsprechenden Partner aus, und klicken Sie dann im Bereich "Aktionen" auf "Anspruchsveröffentlichungsrichtlinie bearbeiten".
3. Fügen Sie eine neue Regel hinzu, wenn keine Regel vorhanden ist, um den NameIdentifier-Anspruch 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 dem zu entsprechen, was die Anwendung benötigt.

Informationen zur automatischen Verlängerung des Zertifikats

Wenn das Tokensignaturzertifikat oder das Tokenentschlüsselungszertifikat selbstsigniert sind, ist AutoCertificateRollover für diese Zertifikate standardmäßig aktiviert, und AD FS verwaltet die automatische Erneuerung der Zertifikate, wenn sie kurz vor dem Ablauf stehen.

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 Zertifikattyp-Tokensignatur 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 verlängert werden.

Untersuchen Sie das AutoCertificateRollover-Attribut.
- Wenn AutoCertificateRollover = TRUE ist, generiert AD FS automatisch neue Zertifikate (standardmäßig 30 Tage vor Ablauf) und legt sie als primäre Zertifikate (25 Tage vor Ablauf) fest.
- Wenn AutoCertificateRollover = FALSE ist, 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 bei der Behandlung von Anmeldeproblemen (Sign-On, SSO) mit Active Directory-Verbunddienste (AD FS) (ADFS) hilfreich sein.

Überprüfen von DNS

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 Überprüfungen aus:

Pingen Sie den Namen des Verbunddiensts (z. B. fs.contoso.com). Überprüfen Sie, ob die IP-Adresse, in die der Ping aufgelöst wird, von einem der WAP-Server oder des Lastenausgleichs der WAP-Server ist.
Überprüfen Sie, ob ein A-Eintrag für den Verbunddienst im DNS-Server vorhanden ist. Der A-Eintrag sollte auf einen der WAP-Server oder auf den Lastenausgleich der WAP-Server verweisen.

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

Pingen Sie den Namen des Verbunddiensts (z. B. fs.contoso.com). Überprüfen Sie, ob die ip-Adresse, die Sie erhalten, auf einen der ADFS-Server oder den Lastenausgleich der ADFS-Server aufgelöst wird.
Überprüfen Sie, ob ein A-Eintrag für den Verbunddienst im 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 den Datenverkehr zwischen folgenden Vorgängen blockiert:

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

Wenn die Sonde für den Lastenausgleich aktiviert ist, überprüfen Sie Folgendes:

Wenn Sie Windows Server 2012 R2 ausführen, stellen Sie sicher, dass das Updaterollup vom 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 in 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 auf Windows Server 2012 R2.

Hinweis

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

Überprüfen, ob der Endpunkt für den Proxy aktiviert ist

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

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

Überprüfen der Proxyvertrauensbeziehung

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

Hinweis

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

Hintergrundinformationen

Die Proxyvertrauensbeziehung basiert auf dem Clientzertifikat. Wenn Sie den Web-Anwendungsproxy Assistenten nach der Installation ausführen, generiert der Assistent ein selbstsigniertes Clientzertifikat mit den im Assistenten angegebenen Anmeldeinformationen. Anschließend fügt der Assistent das Zertifikat in die AD FS-Konfigurationsdatenbank ein und fügt es dem AdfsTrustedDevices-Zertifikatspeicher 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:

Priorität	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-Platzhalter	Port	IPv6-Platzhalter-Übereinstimmung (Verbindung muss IPv6 sein)
5	IP-Platzhalter	Port	IP-Platzhalter-Übereinstimmung (Verbindung kann IPv4 oder IPv6 sein)

AD FS 2012 R2 und höher sind unabhängig von Internetinformationsdiensten (Internet Information Services, 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 nicht AdfsTrustedDevices ist, wird möglicherweise keine Proxyvertrauensbeziehung 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 Bindungen mit der Anwendungs-ID 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 Proxyvertrauensbeziehung automatisch zu erkennen. Führen Sie die Aktion basierend auf dem erkannten Problem entsprechend aus.

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 einen Konflikt mit der AD FS-Zertifikatbindung an Port 443 verursachen.

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 möglicherweise wieder auftritt, nachdem Sie sie entfernt haben. Beispielsweise kann eine Anwendung, die mit dieser IP:Port-Bindung konfiguriert ist, sie beim nächsten Dienststart automatisch neu erstellen.
Verwenden einer anderen IP-Adresse für die AD FS SSL-Kommunikation

Wenn die IP:port-Bindung erforderlich ist, auflösen Sie den FQDN des ADFS-Diensts in eine andere IP-Adresse, die in keiner Bindung 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 das letzte Mittel, 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 auf dem Standardmäßigen CTL-Speicher für die Clientzertifikatauthentifizierung basiert.

Problem 2: Für die AD FS-Zertifikatbindung ist der CTL-Speichername nicht auf AdfsTrustedDevices festgelegt.

Wenn Azure AD Connect installiert ist, verwenden Sie AAD Connect, um den CTL-Speichernamen auf AdfsTrustedDevices für die SSL-Zertifikatbindungen auf allen AD FS-Servern festzulegen. Wenn Azure AD Connect nicht installiert ist, generieren Sie die AD FS-Zertifikatbindungen erneut, 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 sind, enthält die aus dem Speicher generierte CTL nur das von der Zertifizierungsstelle ausgestellte Zertifikat. Der AdfsTrustedDevices-Zertifikatspeicher ist ein solcher Speicher, der nur selbstsignierte Zertifikate enthalten soll. Diese Zertifikate sind:

MS-Organization-Access: Das selbstsignierte Zertifikat, das zum Ausstellen von Workplace Join-Zertifikaten verwendet wird.
ADFS-Proxyvertrauensstellung: Die Zertifikate für jeden Webserver Anwendungsproxy.

Die Zertifikate für jeden Webserver Anwendungsproxy.

Löschen Sie daher alle von der Zertifizierungsstelle ausgestellten Zertifikate aus dem AdfsTrustedDevices-Zertifikatspeicher.

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

Wenn eine Proxyvertrauensbeziehung mit einem AD FS-Server hergestellt wird, wird das Clientzertifikat in die AD FS-Konfigurationsdatenbank geschrieben und dem AdfsTrustedDevices-Zertifikatspeicher auf dem AD FS-Server hinzugefügt. Bei einer 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 Proxyvertrauensbeziehung nur für den 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. Nachdem das Update installiert wurde, wird erwartet, dass eine Synchronisierung des Clientzertifikats automatisch erfolgt.

Methode 2

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

Hinweis

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 ein Zeit- oder Zeitzonenkonflikt vorliegt. Wenn die Zeit übereinstimmt, die Zeitzone jedoch nicht, kann auch keine Proxyvertrauensbeziehung hergestellt werden.

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

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 aufgehoben, 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, wenn Sie Probleme mit Ihrem Verbunddienst debuggen und benutzerdefinierte Anspruchsregeln überprüfen. Es ist keine offizielle Lösung, sondern eine gute unabhängige Debuglösung, die für die Problembehandlung empfohlen wird.

Vor der Verwendung der DumpToken-App

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 Informationen der vertrauenden Seite und des OAuth-Clients

Wenn Sie eine herkömmliche vertrauende Partei 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 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 fenster Windows PowerShell 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 Methoden zur Problembehandlung fort. Überprüfen Sie am Ende jeder Methode, ob das Problem gelöst ist. Wenn nicht, verwenden Sie eine andere Methode.

Problembehandlungsmethoden

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

Bei dieser Methode rufen Sie zunächst die Richtliniendetails ab und verwenden 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 regelt. In diesem Fall $rp. IssuanceAuthorizationRules ist leer. Verwenden Sie $rp. ResultantPolicy, um Details zur Zugriffssteuerungsrichtlinie zu erfahren.

Wenn $rp. ResultantPolicy enthält keine 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 Speicherabbildtoken-Authentifizierungsrichtlinie so fest, dass sie der fehlerhaften vertrauenden Seite entspricht.
Lassen Sie den Benutzer je nach festgelegter Authentifizierungsrichtlinie einen der folgenden Links öffnen.
- WS-Fed: https://FerderationInstance/adfs/ls?wa=wsignin1.0&wtrealm=urn:dumptoken
- SAML-P: https://FerderationInstance/adfs/ls/IdpInitiatedSignOn?LoginToRP=urn:dumptoken
- Mehrstufige Authentifizierung erzwingen: https://FerderationInstance/adfs/ls?wa=wsignin1.0&wtrealm=urn:dumptoken&wauth=http://schemas.microsoft.com/claims/multipleauthn
Melden Sie sich auf der Seite Sign-In an.

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

Überprüfen, ob ein fehlender oder unerwarteter Anspruch den Zugriff auf die Ressource verweigert

Konfigurieren Sie die Anspruchsregeln in der DumpToken-App so, dass sie den Anspruchsregeln der fehlerhaften vertrauenden Seite entsprechen.
Konfigurieren Sie die Speicherabbildtoken-Authentifizierungsrichtlinie so, dass sie der fehlerhaften vertrauenden Seite entspricht.
Lassen Sie den Benutzer je nach festgelegter Authentifizierungsrichtlinie einen der folgenden Links öffnen.
- WS-Fed: https://FerderationInstance/adfs/ls?wa=wsignin1.0&wtrealm=urn:dumptoken
- SAML-P: https://FerderationInstance/adfs/ls/IdpInitiatedSignOn?LoginToRP=urn:dumptoken
- Mehrstufige Authentifizierung erzwingen: https://FerderationInstance/adfs/ls?wa=wsignin1.0&wtrealm=urn:dumptoken&wauth=http://schemas.microsoft.com/claims/multipleauthn
Melden Sie sich auf der Seite Sign-In an.

Dies ist der Satz von Ansprüchen, die die vertrauende Seite für den Benutzer erhalten wird. Wenn Ansprüche fehlen oder unerwartet sind, sehen Sie sich die Ausstellungsrichtlinie an, um den Grund herauszufinden.

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 einer dieser Geräteansprüche in der Liste der Ansprüche fehlt, die Sie von der DumpToken-App erhalten. Die fehlenden Ansprüche können die Geräteauthentifizierung blockieren. Um die Ansprüche aus der DumpToken-App abzurufen, führen Sie die Schritte in der App "Speicherabbildtoken" aus, um den Autorisierungsrichtlinienabschnitt in der Autorisierungsrichtlinie überprüfen zu diagnostizieren , ob der Benutzer von der Methode betroffen war .

Im Folgenden sind die Geräteansprüche dargestellt. 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 mit den in der Autorisierungsrichtlinie erforderlichen Werten übereinstimmen.

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 WindowsIntegratedFallback-Einstellung

Überprüfen der Einstellung "WIASupportedUsersAgents"

Überprüfen der Authentifizierungsanforderungsparameter

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

Überprüfen Sie, ob es sich bei der Anwendung um Microsoft Online Services für Office 365

Azure Active Directory (Azure AD)-Szenario

Nicht-Azure AD-Szenario

Überprüfen, ob SSO deaktiviert ist

Aufforderung zur mehrstufigen Authentifizierung

Ü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, ob die Authentifizierungsanforderung die mehrstufige Authentifizierung als Authentifizierungsmethode angibt

Überprüfen Sie, ob es sich bei der Anwendung um Microsoft Online Services für Office 365

Ü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 auf 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 von dem Problem betroffen, und der Benutzer kann auf einige der vertrauenden Parteien zugreifen.

Überprüfen, ob der Benutzer mit Azure AD synchronisiert ist

Überprüfen von "immutableID" und "UPN" in der Ausstellungsanspruchsregel

Dieses Problem tritt auf der Anwendungsseite auf.

Die Fingerabdrucks der beiden Zertifikate stimmen überein

Die Fingerabdrucks der beiden Zertifikate stimmen nicht überein

Informationen zur automatischen Verlängerung des Zertifikats

Überprüfen der ADFS-bezogenen Komponenten und Dienste

Überprüfen von DNS

Überprüfen des Lastenausgleichs, wenn er verwendet wird

Überprüfen der Firewalleinstellungen

Überprüfen, ob der Endpunkt für den Proxy aktiviert ist

Überprüfen der Proxyvertrauensbeziehung

Hintergrundinformationen

Ausführen eines Skripts zum automatischen Erkennen von Problemen

Problem 1: Es gibt eine IP-spezifische Bindung.

Problem 2: Für die AD FS-Zertifikatbindung ist der CTL-Speichername nicht auf AdfsTrustedDevices festgelegt.

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

Problem 4: Installieren von 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

Vor der Verwendung der DumpToken-App

Abrufen der Informationen der vertrauenden Seite und des OAuth-Clients

Einrichten der Dumptoken-App

Problembehandlungsmethoden

Ü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 ein fehlender oder unerwarteter Anspruch den Zugriff auf die Ressource verweigert

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

Zusätzliche Ressourcen

Zusätzliche Ressourcen