AD FS-Problembehandlung – Microsoft Entra ID
Mit dem Wachstum der Cloud sind viele Unternehmen dazu übergegangen, Microsoft Entra ID für ihre verschiedenen Apps und Dienste zu nutzen. Die Einrichtung eines Verbunds mit Microsoft Entra ID ist in vielen Organisationen mittlerweile gängige Praxis. In diesem Dokument werden verschiedene Aspekte zur Behebung von Problemen behandelt, die im Zusammenhang mit diesem Verbund auftreten können. Einige der Themen im Dokument zur allgemeinen Problembehandlung gelten auch für den Verbund mit Azure, daher konzentriert sich das vorliegende Dokument nur auf die Besonderheiten der Interaktion mit Microsoft Entra ID und AD FS.
Umleitung zu AD FS
Eine Umleitung erfolgt, wenn Sie sich bei einer Anwendung wie Office 365 anmelden und zur Anmeldung an die AD FS-Server Ihres Unternehmens weitergeleitet werden.
Punkte, die zuerst überprüft werden müssen
Wenn die Umleitung nicht funktioniert, sollten Sie einige Dinge überprüfen.
Stellen Sie sicher, dass Ihr Microsoft Entra-Mandant für den Verbund aktiviert ist, indem Sie sich im Azure-Portal anmelden und dies unter „Microsoft Entra Connect“ überprüfen.
Stellen Sie sicher, dass Ihre benutzerdefinierte Domäne verifiziert wurde, indem Sie im Azure-Portal auf die Domäne neben „Verbund“ klicken.
Schließlich sollten Sie den DNS überprüfen und sicherstellen, dass Ihre AD FS-Server oder WAP-Server aus dem Internet aufgelöst werden. Vergewissern Sie sich, dass die Auflösung erfolgreich ist und sie zu den Servern navigieren können.
Sie können auch das PowerShell-Cmdlet
Get-MgDomainverwenden, um diese Informationen abzurufen.
Anzeige des Fehlers „Unbekannte Authentifizierungsmethode“
Bei der Umleitung von Azure kann der Fehler „Unbekannte Authentifizierungsmethode“ auftreten, der darauf hinweist, dass „AuthnContext“ auf AD FS- oder STS-Ebene nicht unterstützt wird.
Dies ist meistens der Fall, wenn Microsoft Entra für die Umleitung zu AD FS oder STS einen Parameter verwendet, der eine Authentifizierungsmethode erzwingt.
Verwenden Sie zum Erzwingen einer Authentifizierungsmethode eine der folgenden Methoden:
Verwenden Sie für den WS-Verbund einen WAUTH-Abfragezeichenfolge, um eine bevorzugte Authentifizierungsmethode zu erzwingen.
Verwenden Sie für SAML 2.0 Folgendes:
<saml:AuthnContext> <saml:AuthnContextClassRef> urn:oasis:names:tc:SAML:2.0:ac:classes:PasswordProtectedTransport </saml:AuthnContextClassRef> </saml:AuthnContext>Wenn die erzwungene Authentifizierungsmethode mit einem falschen Wert gesendet wird, oder wenn diese Authentifizierungsmethode von AD DS oder STS nicht unterstützt wird, erhalten Sie vor der Authentifizierung eine Fehlermeldung.
| Gewünschte Authentifizierungsmethode | wauth-URI |
|---|---|
| Benutzernamen- und Kennwortauthentifizierung | urn:oasis:names:tc:SAML:1.0:am:password |
| SSL-Clientauthentifizierung | urn:ietf:rfc:2246 |
| Integrierte Windows-Authentifizierung | urn:federation:authentication:windows |
Unterstützte SAML-Authentifizierungskontextklassen
| Authentifizierungsmethode | URI der Authentifizierungskontextklasse |
|---|---|
| Benutzername und Kennwort | urn:oasis:names:tc:SAML:2.0:ac:classes:Password |
| Kennwortgeschützter Transport | urn:oasis:names:tc:SAML:2.0:ac:classes:PasswordProtectedTransport |
| TLS-Client (Transport Layer Security) | urn:oasis:names:tc:SAML:2.0:ac:classes:TLSClient |
| X.509-Zertifikat | urn:oasis:names:tc:SAML:2.0:ac:classes:X509 |
| Integrierte Windows-Authentifizierung | urn:federation:authentication:windows |
| Kerberos | urn:oasis:names:tc:SAML:2.0:ac:classes:Kerberos |
Überprüfen Sie Folgendes, um sicherzustellen, dass die Authentifizierungsmethode auf AD FS-Ebene unterstützt wird.
AD FS 2.0
Stellen Sie unter /adfs/ls/web.configsicher, dass der Eintrag für den Authentifizierungstyp vorhanden ist.
<microsoft.identityServer.web>
<localAuthenticationTypes>
<add name="Forms" page="FormsSignIn.aspx" />
<add name="Integrated" page="auth/integrated/" />
<add name="TlsClient" page="auth/sslclient/" />
<add name="Basic" page="auth/basic/" />
</localAuthenticationTypes>
AD FS 2012 R2
Klicken Sie im AD FS-Snap-In unter AD FS-Verwaltung auf Authentifizierungsrichtlinien.
Klicken Sie im Abschnitt Primäre Authentifizierung neben „Globale Einstellungen“ auf „Bearbeiten“. Sie können auch mit der rechten Maustaste auf „Authentifizierungsrichtlinien“ klicken und dann „Globale primäre Authentifizierung bearbeiten“ auswählen. Alternativ können Sie im Bereich „Aktionen“ die Option „Globale primäre Authentifizierung bearbeiten“ auswählen.
Im Fenster „Globale Authentifizierungsrichtlinie bearbeiten“ können Sie auf der Registerkarte „Primär“ Einstellungen als Teil der globalen Authentifizierungsrichtlinie konfigurieren. Beispielsweise können Sie für die primäre Authentifizierung unter „Extranet“ und „Intranet“ eine verfügbare Authentifizierungsmethode auswählen.
**Stellen Sie sicher, dass das Kontrollkästchen für die erforderliche Authentifizierungsmethode aktiviert ist.
AD FS 2016
Klicken Sie im AD FS-Snap-In unter AD FS-Verwaltung auf Dienst und dann auf Authentifizierungsmethoden.
Klicken Sie im Abschnitt Primäre Authentifizierung auf „Bearbeiten“.
Im Fenster Globale Authentifizierungsrichtlinie bearbeiten können Sie auf der Registerkarte „Primär“ Einstellungen als Teil der globalen Authentifizierungsrichtlinie konfigurieren.
Von AD FS ausgestellte Token
Microsoft Entra ID löst nach der Tokenausstellung einen Fehler aus.
Möglicherweise löst Microsoft Entra ID nach der Tokenausstellung durch AD FS einen Fehler aus. Überprüfen Sie in diesem Fall auf die folgenden Probleme:
- Die von AD FS in einem Token ausgestellten Ansprüche sollten mit den jeweiligen Attributen des Benutzers in Microsoft Entra ID übereinstimmen.
- Das Token für Microsoft Entra ID sollte die folgenden erforderlichen Ansprüche enthalten:
- WSFED:
- UPN: Der Wert dieses Anspruchs sollte mit dem UPN der Benutzer in Microsoft Entra ID übereinstimmen.
- ImmutableID: Der Wert dieses Anspruchs sollte mit dem sourceAnchor- oder ImmutableID-Wert des Benutzers in Microsoft Entra ID übereinstimmen.
- WSFED:
Führen Sie die folgende Befehlszeile aus, um den Wert des Benutzerattributs in Microsoft Entra ID abzurufen: Get-AzureADUser –UserPrincipalName <UPN>
- SAML 2.0:
- IDPEmail: Der Wert dieses Anspruchs sollte mit dem Benutzerprinzipalnamen der Benutzer in Microsoft Entra ID übereinstimmen.
- NAMEID: Der Wert dieses Anspruchs sollte mit dem sourceAnchor- oder ImmutableID-Wert des Benutzers in Microsoft Entra ID übereinstimmen.
Weitere Informationen finden Sie unter Verwenden eines SAML 2.0-Identitätsanbieters zum Implementieren des einmaligen Anmeldens.
Nicht übereinstimmendes Token-signierendes Zertifikat zwischen AD FS und Microsoft Entra ID
AD FS verwendet das Tokensignaturzertifikat, um das an den Benutzer oder die Anwendung gesendete Token zu signieren. Die Vertrauensstellung zwischen AD FS und Microsoft Entra ID ist eine Verbundvertrauensstellung, die auf diesem Tokensignaturzertifikat basiert.
Wenn das Tokensignaturzertifikat jedoch aufseiten von AD FS aufgrund eines automatischen Zertifikatrollovers oder durch einen anderen Eingriff geändert wird, müssen die Details zum neuen Zertifikat aufseiten von Microsoft Entra ID für die Verbunddomäne aktualisiert werden. Wenn sich das primäre Zertifikat für die Token-Signatur in AD FS von Microsoft Entra ID unterscheidet, wird das vom AD FS ausgestellte Token von Microsoft Entra ID nicht als vertrauenswürdig eingestuft. Aus diesem Grund kann sich der Verbundbenutzer nicht anmelden.
Um dieses Problem zu beheben, können Sie die in Erneuern von Verbundzertifikaten für Office 365 und Microsoft Entra ID beschriebenen Schritte ausführen.
Weitere allgemeine Punkte, die überprüft werden müssen
Im Folgenden finden Sie eine kurze Liste der Punkte, die Sie überprüfen sollten, wenn Probleme bei der Interaktion zwischen AD FS und Microsoft Entra vorliegen.
- Veraltete oder zwischengespeicherte Anmeldeinformationen in der Windows-Anmeldeinformationsverwaltung
- Der für die Vertrauensstellung der vertrauenden Seite für Office 365 konfigurierte sichere Hashalgorithmus ist auf SHA1 festgelegt