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

Artikel
02/19/2024

In diesem Artikel erfahren Sie, wie Sie Probleme mit dem einmaligen Anmelden (Single Sign-On, SSO) mit Active Directory-Verbunddienste (AD FS) (AD FS) beheben.

Wählen Sie je nach Problemtyp 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 dem einmaligen 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, die AD FS-Einstellungen und die Parameter für Authentifizierungsanforderungen.

Überprüfen des Clientbrowsers des Benutzers

Überprüfen Sie die folgenden Einstellungen unter Internetoptionen:

Stellen Sie auf der Registerkarte Erweitert sicher, dass die Einstellung Integrierte Windows-Authentifizierung aktivieren aktiviert ist.
Stellen Sie unter Sicherheit>LokaleIntranetwebsites>>erweitert sicher, dass die AD FS-URL in der Liste der Websites enthalten ist.
Stellen Sie unter Sicherheit > Lokales Intranet > Benutzerdefinierte Ebene sicher, dass die Einstellung Automatische Anmeldung nur in 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 ist, wird eine 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 ist, sollte die integrierte Windows-Authentifizierung erwartet werden.

Überprüfen Sie die Einstellung WIASupportedUsersAgents.

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

Überprüfen Sie, ob die Benutzer-Agent-Zeichenfolge Ihres Browsers in der Liste enthalten ist. Wenn dies nicht der Fehler ist, fügen Sie die Zeichenfolge des Benutzer-Agents hinzu, indem Sie die folgenden Schritte ausführen:

Wechseln Sie zu http://useragentstring.com/ , die 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 Parameter für die Authentifizierungsanforderung

Überprüfen Sie, 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 for 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.

Hinweis

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

Es wird empfohlen, zu Microsoft Graph PowerShell zu migrieren, um mit Microsoft Entra ID (früher Azure AD) zu interagieren. Häufig gestellte Fragen zur Migration finden Sie in den häufig gestellten Fragen zur Migration. Hinweis: Version 1.0.x von MSOnline kann nach dem 30. Juni 2024 unterbrochen werden.

Wenn es sich bei der Anwendung um Microsoft Online Services handelt, kann die Einstellung PromptLoginBehavior über das vertrauenswürdige Bereichsobjekt gesteuert werden. 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 PromptLoginBehavior-Parameter sind:
1. TranslateToFreshPasswordAuth: Microsoft Entra ID sendet wauth und wfresh anstelle von prompt=login an AD FS. Dies führt zu einer Authentifizierungsanforderung zur Verwendung der formularbasierten Authentifizierung.
2. NativeSupport: Der prompt=login-Parameter wird unverändert an AD FS gesendet.
3. Deaktiviert: Es wird nichts an AD FS gesendet.

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

Microsoft Entra Szenario

Wenn die an Microsoft Entra ID gesendete Authentifizierungsanforderung den parameter prompt=login enthält, deaktivieren Sie die Funktion prompt=login, 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 prompt=login-Parameter in jeder Authentifizierungsanforderung.

Szenario ohne Microsoft Entra

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 er die erwartete Authentifizierungsmethode verwendet.

Überprüfen, ob SSO deaktiviert ist

Wenn einmaliges Anmelden deaktiviert ist, aktivieren Sie es, und testen Sie, ob das Problem behoben wurde.

Eingabeaufforderung für die mehrstufige Authentifizierung

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 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 Ansprüche für die mehrstufige Authentifizierung 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 der vertrauenden 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 der vertrauenden Seite zu überprüfen:
```
Get-ADFSRelyingPartyTrust -TargetName RelyingParty | Select -ExpandProperty AdditionalAuthenticationRules
```
Hinweis

Wenn die Befehle nichts zurückgeben, werden 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"

Die folgenden Beispiele erfordern, dass die mehrstufige Authentifizierung für Geräte verwendet werden muss, die nicht in den Arbeitsbereich eingebunden sind, bzw. für Extranetzugriff:

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 nach der ersten Authentifizierung wiederholt Aufforderungen zur mehrstufigen Authentifizierung erhält, ist es möglich, dass die antwortende Partei die Ansprüche der mehrstufigen Authentifizierung 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 Regelsatz, der in den Attributen IssuanceAuthorizationRules oder IssuanceAuthorizationRulesFile definiert ist.

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

Wenn es sich bei der Authentifizierungsanforderung um eine WS-Federation-Anforderung handelt, überprüfen Sie, ob die Anforderung enthält 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 for Office 365

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

Rufen Sie die aktuelle Domänenverbundeinstellung SupportsMFA 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 einmaliges Anmelden deaktiviert ist, aktivieren Sie es, und testen Sie, ob das Problem behoben wurde.

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 wie "Ein Fehler ist 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 von dem Problem betroffen sind und ob die Benutzer auf alle vertrauenden Seiten zugreifen können.

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

Überprüfen wir die interne Anmeldefunktion mithilfe von IdpInitiatedSignOn. Verwenden Sie dazu die Seite IdpInititatedSignOn, um zu überprüfen, ob der AD FS-Dienst ausgeführt wird und die Authentifizierungsfunktionalität ordnungsgemäß funktioniert. Führen Sie die folgenden Schritte aus, um die Seite IdpInitiatedSignOn zu öffnen:

Aktivieren Sie die Seite IdpInitiatedSignOn, indem Sie den folgenden Befehl auf dem AD FS-Server ausführen:
```
Set-AdfsProperties -EnableIdPInitiatedSignonPage $true
```
Besuchen Sie auf 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 Extras>Dienste.
Überprüfen Sie, ob der Status von Active Directory-Verbunddienste (AD FS)Wird ausgeführt lautet.

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

Aktivieren Sie die Seite IdpInitiatedSignOn, 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 Proxyvertrauensstellung.

Wenn die Anmeldung erfolgreich ist, setzen Sie die Problembehandlung mit den Schritten unter Alle Benutzer sind von dem Problem betroffen fort, und der Benutzer kann auf einige der vertrauenden Seiten 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)Wird ausgeführt lautet.

Ü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 die status der Endpunkte zu überprüfen:

Öffnen Sie auf dem AD FS-Server die AD FS-Verwaltungskonsole.
Erweitern SieDienstendpunkte>.
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, was die SSL-Zertifikatverwaltung vereinfacht.

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 zugegriffen wird, die nicht in die Domäne eingebunden sind, empfiehlt es sich, ein SSL-Zertifikat von einer vertrauenswürdigen Stammzertifizierungsstelle eines Drittanbieters wie DigiCert, VeriSign usw. zu verwenden. Wenn das SSL-Zertifikat nicht von einer vertrauenswürdigen Stammzertifizierungsstelle stammt, kann die SSL-Kommunikation unterbrochen 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. Führen Sie den folgenden Befehl auf dem primären AD FS-Server aus, um den Namen des Verbunddiensts abzurufen:
Get-AdfsProperties | select hostname
Das Zertifikat wird nicht widerrufen.

Überprüfen Sie die Zertifikatsperrung. Wenn das Zertifikat widerrufen wird, kann die SSL-Verbindung nicht als vertrauenswürdig eingestuft werden 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, Microsoft Entra Connect zu verwenden, was die SSL-Zertifikatverwaltung vereinfacht. Weitere Informationen finden Sie unter Aktualisieren des TLS/SSL-Zertifikats für eine Active Directory-Verbunddienste (AD FS)-Farm (AD FS).

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 . PFX-Datei des Zertifikats, und befolgen Sie den 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 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.

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

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 Sie, 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 dann 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 das Zertifikat-Snap-In für das lokale Computerkonto der 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, und klicken Sie auf Alle Aufgaben>Private Schlüssel verwalten.
4. Überprüfen Sie, ob adfssrv unter Gruppen- und Benutzernamen mit der Berechtigung Lesen aufgeführt ist.
Wenn adfssrv nicht aufgeführt ist, erteilen Sie dem AD FS-Dienst die Berechtigung Lesen 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 Geben Sie die auszuwählenden Objektnamen ein, geben Sie nt service\adfssrv ein, klicken Sie auf Namen überprüfen, und klicken Sie dann auf OK.
  Wenn Sie AD FS mit 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 und fabrikam.comvorhanden sind, muss das Zertifikat und enterpriseregistration.fabrikma.com als alternative Antragstellernamen (Subject Alternative Names, SANs) aufweisenenterpriseregistration.contoso.com.

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

Listen Sie alle UPN-Suffixe auf, die im organization verwendet werden, indem Sie den folgenden Befehl ausführen:
```
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.

Um Nicht-SNI-Fälle zu unterstützen, können Administratoren Fallbackbindungen angeben. Abgesehen von der Standardbindung federationservicename:443 suchen Sie 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 das SSL-Zertifikat beispielsweise 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.

Zunächst rufen wir die Informationen zur vertrauenden Seite und zum OAuth-Client ab. 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 die Anwendungsgruppenfunktion 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 kann jedoch immer 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 mit den in AD FS konfigurierten Einstellungen übereinstimmen. Mit den Schritten auf der vorherigen Seite erhalten Sie die einstellungen, die in AD FS über PowerShell konfiguriert wurden.

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 Seite $rp. SamlEndpoints für eine saml-vertrauende Seite
Client-ID	$client. Clientid
Clientumleitungs-URI	Eine Präfix-Übereinstimmung mit $client. RedirectUri

Wenn Elemente in der Tabelle übereinstimmen, überprüfen Sie außerdem, ob diese Einstellungen zwischen dem, was in der an AD FS gesendeten Authentifizierungsanforderung angezeigt wird, und den in AD FS konfigurierten Einstellungen übereinstimmen. 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 Überprü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 mit den in AD FS konfigurierten Einstellungen übereinstimmen.

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 die Anwendungsgruppenfunktion 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 mit den in AD FS konfigurierten Einstellungen übereinstimmen:

Anforderungsparameter	In AD FS konfigurierte Einstellungen
wtrealm	$rp. Bezeichner
wreply	Eine Präfix- oder 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 von Destination mit dem AD FS-Hostnamen übereinstimmt.
Überprüfen Sie, ob der Wert von Issuer mit übereinstimmt $rp.Identifier.

Zusätzliche Hinweise für SAML:

$rp. SamlEndpoints: Zeigt alle Typen 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.EncryptClaimsAktiviert 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 Ü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 an die Sperrprüfung erfüllt.

Die beiden vorherigen Methoden funktionieren nicht

Informationen zum Fortsetzen der Problembehandlung finden Sie unter Verwenden der App "Speicherabbildtoken".

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

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

Überprüfen, ob der Benutzer deaktiviert ist

Überprüfen Sie die status des Benutzers in Windows PowerShell oder der Benutzeroberfläche. Wenn der Benutzer deaktiviert ist, aktivieren Sie den Benutzer.

Überprüfen der benutzer status mit Windows PowerShell

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

Überprüfen der benutzer status 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 in 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 eigenschaftenänderungen für einen 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 Time/Date für jedes Attribut auf Hinweise auf eine Änderung. Im folgenden Beispiel akzeptiert das userPrincipleName-Attribut ein neueres Datum als die anderen Attribute, die eine Änderung der Benutzerobjektmetadaten 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, in der AD FS bereitgestellt wird, und den anderen Gesamtstrukturen erforderlich, die die AD FS-Bereitstellung für die Authentifizierung nutzen. 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-Verwaltungskonsole Domänen und Vertrauensstellungen.
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 Domain Services eine der Optionen aus.
- Wenn Sie Nein auswählen, empfiehlt es sich, das gleiche Verfahren für die gegenseitige Domäne zu wiederholen.
- Wenn Sie Ja auswählen, geben Sie anmeldeinformationen für Administratoren für die gegenseitige Domäne an. Es ist nicht erforderlich, das gleiche Verfahren für die gegenseitige Domäne auszuführen.

Wenn Ihnen diese Schritte nicht bei der Behebung des Problems helfen, setzen Sie die Problembehandlung mit den Schritten im Abschnitt Nicht alle Benutzer sind von dem Problem betroffen fort, und der Benutzer kann auf einige der vertrauenden Seiten zugreifen .

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

Überprüfen Sie in diesem Szenario, ob dieses Problem in einem Microsoft Entra Szenario auftritt. Wenn dies der Fall ist, führen Sie diese Überprüfungen aus, um dieses Problem zu beheben. Wenn dies nicht der Fall ist, finden Sie weitere Informationen unter Verwenden der Sicherungstoken-App , um dieses Problem zu beheben.

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

Wenn ein Benutzer versucht, sich bei 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 Microsoft Entra ID synchronisiert wurde. Nach dem ersten Authentifizierungsversuch bei AD FS wird möglicherweise eine Schleife von Microsoft Entra ID zu Active Directory FS angezeigt. Führen Sie die folgenden Schritte aus, um zu bestimmen, ob der Benutzer mit 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 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 im Microsoft Entra ID ab, indem Sie den folgenden Befehl ausführen:
Get-MsolUser
Überprüfen Sie, ob der Benutzer in der Liste enthalten ist.

Wenn der Benutzer nicht in der Liste enthalten ist, synchronisieren Sie den Benutzer mit Microsoft Entra ID.

Überprüfen von immutableID und UPN in der Ausstellungsanspruchsregel

Microsoft Entra ID 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 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 aktiviert die automatische Verwaltung von Anspruchsregeln basierend auf den Synchronisierungseinstellungen.

Führen Sie die folgenden Schritte aus, um zu überprüfen, ob die Anspruchsregeln für immutableID und UPN in AD FS mit dem übereinstimmen, was Microsoft Entra ID verwendet:

Rufen Sie sourceAnchor und UPN in Microsoft Entra Connect ab.
1. Öffnen Sie Microsoft Entra Verbinden.
2. Klicken Sie auf Aktuelle Konfiguration anzeigen.
3. Notieren Sie sich auf der Seite Projektmappe ü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 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 nach den Werten immutableID und UPN abgefragten Variablen mit denen in Microsoft Entra Connect übereinstimmen.
Wenn es einen Unterschied gibt, 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 geholfen haben, finden Sie weitere Informationen unter Verwenden der Speicherabbildtoken-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 Verbundpartner abgerufen wird. Falls AD FS ein Tokenentschlüsselungszertifikat verwendet, das ebenfalls vor kurzem erneuert wurde, führen Sie die gleiche Überprüfung aus. Führen Sie die folgenden Schritte aus, um zu überprüfen, ob das aktuelle AD FS-Tokensignaturzertifikat in AD FS mit dem Zertifikat des Verbundpartners übereinstimmt:

Rufen Sie das aktuelle Tokensignaturzertifikat in AD FS ab, indem Sie den folgenden Befehl ausführen:
```
Get-ADFSCertificate -CertificateType token-signing
```
Suchen Sie in der Liste der zurückgegebenen Zertifikate nach dem Zertifikat mit IsPrimary = TRUE, und notieren Sie sich den Fingerabdruck.
Rufen Sie den Fingerabdruck des aktuellen Tokensignaturzertifikats auf dem Verbundpartner ab. Dies muss vom Anwendungsbesitzer bereitgestellt werden.
Vergleichen Sie die Fingerabdrücke der beiden Zertifikate.

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

Get-ADFSCertificate -CertificateType token-decrypting

Die Fingerabdrücke der beiden Zertifikate stimmen überein

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

Wenn Zertifikatkonflikte 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 beziehen sich auf alle Ressourcen organization oder Konto organization Partner, die in Ad FS durch Vertrauensstellungen der vertrauenden Seite und Anspruchsanbieter-Vertrauensstellungen 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 die öffentlichen Schlüssel der neuen Zertifikate manuell 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 Fingerabdrücke der beiden Zertifikate stimmen nicht überein.

Überprüfen Sie dann, ob ein Tokensignaturalgorithmus nicht stimmt. 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.
Wenden Sie sich an den Anwendungsbesitzer, um den auf der Anwendungsseite verwendeten Algorithmus zu ermitteln.
Überprüfen Sie, ob die beiden Algorithmen übereinstimmen.

Wenn die beiden Algorithmen übereinstimmen, überprüfen Sie, ob das Format der Namens-ID dem entspricht, was die Anwendung benötigt.

Sichern Sie die Ausstellungstransformationsregeln auf dem AD FS-Server, 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 sehen Sie 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
Fragen Sie den Anwendungsbesitzer nach dem für die Anwendung erforderlichen NameIdentifier-Format.
Überprüfen Sie, ob die beiden NameIdentifier-Formate übereinstimmen.
Wenn die Formate nicht übereinstimmen, konfigurieren Sie den NameIdentifier-Anspruch so, dass das Format verwendet wird, das die Anwendung benötigt. 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 Verbundpartner aus, und klicken Sie dann im Bereich Aktionen auf Anspruchsausstellungsrichtlinie bearbeiten.
3. Fügen Sie eine neue Regel hinzu, wenn keine Regel zum Ausstellen des NameIdentifier-Anspruchs vorhanden ist, oder aktualisieren Sie eine vorhandene Regel. Wählen Sie Name ID für eingehenden Anspruchstyp 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, der den Anforderungen der Anwendung entspricht.

Informationen zur automatischen Zertifikaterneuerung

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

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

Führen Sie den folgenden Befehl aus:

Get-ADFSCerticate -CertificateType "token-signing"

Führen Sie das Get-ADFSCerticate-Cmdlet Zertifikattyptokensignatur aus.

Untersuchen 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 überprüfen, 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 fest (25 Tage vor Ablauf).
- Wenn AutoCertificateRollover = FALSE ist, müssen Sie die Zertifikate manuell ersetzen.

In diesem Artikel erfahren Sie, wie Sie die AD FS-bezogenen Komponenten und Dienste überprüfen. Diese Schritte können hilfreich sein, wenn Sie Probleme mit der Anmeldung (Sign-On, SSO) mit Active Directory-Verbunddienste (AD FS) (AD FS) behandeln.

Dns überprüfen

Der Zugriff auf AD FS 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 stammt.
Überprüfen Sie, ob auf dem DNS-Server ein A-Eintrag für den Verbunddienst 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 AD FS direkt auf einen der AD FS-Server oder den Lastenausgleich vor den AD FS-Servern verweist:

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

Überprüfen Des Lastenausgleichs, ob er verwendet wird

Überprüfen Sie, ob die Firewall Datenverkehr zwischen den folgenden Blockiert:

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

Wenn der Test 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 AD FS-Servern aktiviert ist.
Stellen Sie sicher, dass der Test 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 zutreffen:

Die TLS-Clientauthentifizierung mit X.509-Zertifikat ist aktiviert.
Sie verwenden AD FS auf Windows Server 2012 R2.

Hinweis

Die Konfiguration ist in der Firewall zwischen dem Web-Anwendungsproxy-Server und den Verbundservern nicht erforderlich.

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

AD FS 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 auf dem Proxy aktiviert ist:

Öffnen Sie auf dem AD FS-Server die AD FS-Verwaltungskonsole.
Erweitern SieDienstendpunkte>.
Suchen Sie den Endpunkt, und überprüfen Sie, ob der status in der Spalte Proxy 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 wurde oder zu einem bestimmten Zeitpunkt fehlschlägt.

Hinweis

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

Hintergrundinformationen

Die Proxyvertrauensstellung basiert auf einem Clientzertifikat. Wenn Sie den Web-Anwendungsproxy-Assistenten nach der Installation ausführen, generiert der Assistent ein selbstsigniertes Clientzertifikat mit den Anmeldeinformationen, die Sie im Assistenten angegeben haben. 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-Wildcard	Port	IPv6-Wildcard-Übereinstimmung (Verbindung muss IPv6 sein)
5	IP-Wildcard	Port	IP-Wildcard-Übereinstimmung (Die Verbindung kann IPv4 oder IPv6 sein)

AD FS 2012 R2 und höher sind unabhängig von Internetinformationsdiensten (IIS) und werden zusätzlich zu http.sys als Dienst 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 Proxyvertrauensstellung eingerichtet.

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 solchen mit der Anwendungs-ID 5d89a20c-beab-4389-9447-324788eb944a. Hier sehen Sie 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. Führen Sie basierend auf dem erkannten Problem die entsprechende Aktion 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 mit der AD FS-Zertifikatbindung an Port 443 in Konflikt geraten.

Die IP:port-Bindung hat die höchste Priorität. Wenn eine IP:Port-Bindung in den AD FS-SSL-Zertifikatbindungen vorhanden ist, 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 möglicherweise wieder angezeigt wird. Beispielsweise kann eine Anwendung, die mit dieser IP:Port-Bindung konfiguriert ist, diese 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, lösen Sie den FQDN des AD FS-Diensts in eine andere IP-Adresse auf, die nicht in Bindungen verwendet wird. Auf diese Weise verwenden http.sys die Hostname:port-Bindung für die SSL-Kommunikation.
Festlegen von AdfsTrustedDevices als CTL-Speicher für die IP:Port-Bindung

Dies ist der letzte Ausweg, 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 den Standard-CTL-Speicher für die Clientzertifikatauthentifizierung verwendet.

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

Wenn Microsoft Entra Connect installiert ist, verwenden Sie Microsoft Entra Connect, um den CTL-Speichernamen 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 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 der 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 von der Zertifizierungsstelle ausgestellte Zertifikat 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 zum Ausstellen von Arbeitsplatzbeitrittszertifikaten verwendet wird.
AD FS-Proxyvertrauensstellung: Die Zertifikate für jeden Web Anwendungsproxy Server.

Die Zertifikate für jeden Web Anwendungsproxy Server.

Löschen Sie daher jedes von der Zertifizierungsstelle ausgestellte Zertifikat aus dem AdfsTrustedDevices-Zertifikatspeicher.

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. 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 Proxy-Vertrauensstellung 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. Nach der Installation des Updates wird erwartet, dass automatisch eine Synchronisierung des Clientzertifikats erfolgt.

Methode 2

Führen Sie das Skript mit dem Schalter – 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 Überprüfungen werden bestanden. Das Problem besteht jedoch weiterhin.

Überprüfen Sie, ob ein Zeit- oder Zeitzonenkonflikt vorliegt. Wenn die Zeit übereinstimmt, die Zeitzone jedoch nicht, kann auch keine Proxyvertrauensstellung eingerichtet werden.

Überprüfen Sie, ob zwischen dem AD FS-Server und dem WAP-Server eine SSL-Terminierung 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 unterbrochen, da die Kommunikation auf einem Clientzertifikat basiert.

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

Verwenden der App "Speichertoken"

Die App "Sicherungstoken" ist hilfreich, wenn Sie Probleme mit Ihrem Verbunddienst debuggen und benutzerdefinierte Anspruchsregeln überprüfen. Es handelt sich nicht um eine offizielle Lösung, sondern um eine gute unabhängige Debuglösung, die für die Problembehandlung empfohlen wird.

Vor der Verwendung der App "Speichertoken"

Bevor Sie die App "Speichertoken" verwenden können, 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 App "DumpToken" ein.

Abrufen der Informationen zur vertrauenden Seite und zum OAuth-Client

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 die Anwendungsgruppenfunktion 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 App "DumpToken"

Führen Sie die folgenden Befehle im fenster Windows PowerShell aus, um die App "Speichertoken" einzurichten:

$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. Verwenden Sie andernfalls eine andere Methode.

Problembehandlungsmethoden

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

Bei dieser Methode erhalten Sie zunächst die Richtliniendetails und verwenden dann die App "Token sichern", 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 den Wert. Es ist eine Zugriffssteuerungsrichtlinie vorhanden, die die Autorisierungsrichtlinie steuert. In diesem Fall $rp. IssuanceAuthorizationRules ist leer. Verwenden Sie $rp. ResultantPolicy, um Details zur Zugriffssteuerungsrichtlinie zu ermitteln.

Wenn $rp. ResultantPolicy enthält nicht die Details zur Richtlinie. Sehen 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 Sie $rp.IssuanceAuthorizationRules und $rp. AdditionalAuthenticationRules.

Verwenden der App "Speichertoken" zum Diagnostizieren der Autorisierungsrichtlinie

Legen Sie die Authentifizierungsrichtlinie des Sicherungstokens auf die gleiche Wie bei der fehlerhaften vertrauenden Seite fest.
Lassen Sie den Benutzer je nach festgelegter Authentifizierungsrichtlinie einen der folgenden Links öffnen.
- WS-Fed: https://FederationInstance/adfs/ls?wa=wsignin1.0&wtrealm=urn:dumptoken
- SAML-P: https://FederationInstance/adfs/ls/IdpInitiatedSignOn?LoginToRP=urn:dumptoken
- Erzwingen der mehrstufigen Authentifizierung: https://FederationInstance/adfs/ls?wa=wsignin1.0&wtrealm=urn:dumptoken&wauth=http://schemas.microsoft.com/claims/multipleauthn
Melden Sie sich auf der Seite Sign-In an.

Sie erhalten den 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 Sie, ob ein fehlender oder unerwarteter Anspruch dazu führt, dass der Zugriff auf die Ressource verweigert wird.

Konfigurieren Sie die Anspruchsregeln in der App dump token so, dass sie mit den Anspruchsregeln der fehlerhaften vertrauenden Seite übereinstimmen.
Konfigurieren Sie die Authentifizierungsrichtlinie des Sicherungstokens so, dass sie mit der fehlerhaften vertrauenden Seite identisch ist.
Lassen Sie den Benutzer je nach festgelegter Authentifizierungsrichtlinie einen der folgenden Links öffnen.
- WS-Fed: https://FederationInstance/adfs/ls?wa=wsignin1.0&wtrealm=urn:dumptoken
- SAML-P: https://FederationInstance/adfs/ls/IdpInitiatedSignOn?LoginToRP=urn:dumptoken
- Erzwingen der mehrstufigen Authentifizierung: https://FederationInstance/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 erhält. Wenn Ansprüche fehlen oder unerwartet sind, sehen Sie sich die Ausstellungsrichtlinie an, um den Grund zu ermitteln.

Wenn alle Ansprüche vorhanden sind, erkundigen Sie sich beim Anwendungsbesitzer, welcher Anspruch fehlt oder unerwartet ist.

Überprüfen, ob ein Gerätezustand 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 Dump Token-App erhalten. Die fehlenden Ansprüche können die Geräteauthentifizierung blockieren. Führen Sie die Schritte im Abschnitt Verwenden der Sicherungstoken-App zur Diagnose der Autorisierungsrichtlinie in der Methode Überprüfen der Autorisierungsrichtlinie, ob der Benutzer betroffen war , aus, um die Ansprüche aus der App "Speicherabbildtoken" abzurufen.

Im Folgenden 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 App "Dump Token" 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 Einstellung "WindowsIntegratedFallback"

Überprüfen Sie die Einstellung WIASupportedUsersAgents.

Überprüfen der Parameter für die Authentifizierungsanforderung

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

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

Microsoft Entra Szenario

Szenario ohne Microsoft Entra

Überprüfen, ob SSO deaktiviert ist

Eingabeaufforderung für die mehrstufige 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 Sie, ob die Authentifizierungsanforderung die mehrstufige Authentifizierung als Authentifizierungsmethode angibt.

Überprüfen Sie, ob es sich bei der Anwendung um Microsoft Online Services for 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 Seiten 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 Sie, 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 Seiten zugreifen.

Überprüfen, ob der Benutzer deaktiviert ist

Überprüfen der benutzer status mit Windows PowerShell

Überprüfen der benutzer status 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 Seiten zugreifen.

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

Überprüfen von immutableID und UPN in der Ausstellungsanspruchsregel

Dieses Problem tritt auf der Anwendungsseite auf.

Die Fingerabdrücke der beiden Zertifikate stimmen überein

Die Fingerabdrücke der beiden Zertifikate stimmen nicht überein.

Informationen zur automatischen Zertifikaterneuerung

Überprüfen der AD FS-bezogenen Komponenten und Dienste

Dns überprüfen

Überprüfen Des Lastenausgleichs, ob 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: 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 KB2964735 oder erneutes Ausführen des Skripts mit -syncproxytrustcerts

Methode 1

Methode 2

Problem 5: Alle Überprüfungen werden bestanden. Das Problem besteht jedoch weiterhin.

Verwenden der App "Speichertoken"

Vor der Verwendung der App "Speichertoken"

Abrufen der Informationen zur vertrauenden Seite und zum OAuth-Client

Einrichten der App "DumpToken"

Problembehandlungsmethoden

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

Abrufen der Richtliniendetails

Verwenden der App "Speichertoken" zum Diagnostizieren der Autorisierungsrichtlinie

Überprüfen Sie, ob ein fehlender oder unerwarteter Anspruch dazu führt, dass der Zugriff auf die Ressource verweigert wird.

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

Feedback

Feedback

Zusätzliche Ressourcen