Verwenden von Microsoft Entra MFA mit einem externen Anbieter (Vorschau)

In diesem Artikel wird beschrieben, wie ein externer Authentifizierungsanbieter eine Verbindung mit der mehrstufigen Authentifizierung (MFA) von Microsoft Entra herstellt.

Wenn sich ein Benutzer anmeldet, werden die Mandantenrichtlinien ausgewertet. Die Authentifizierungsanforderungen werden basierend auf der Ressource bestimmt, auf die der Benutzer zugreifen möchte.

Je nach Ihren Parametern gelten möglicherweise mehrere Richtlinien für die Anmeldung. Zu diesen Parametern gehören Benutzer und Gruppen, Anwendungen, die Plattform, das Anmelderisikoniveau und vieles mehr.

Basierend auf den Authentifizierungsanforderungen muss sich der Benutzer möglicherweise mit einem anderen Faktor anmelden, um die MFA-Anforderung zu erfüllen. Die Art des zweiten Faktors muss die Art des ersten Faktors ergänzen.

Der Mandantenadministrator fügt der Microsoft Entra-ID externe Authentifizierungsmethoden hinzu. Wenn ein Mandant eine externe Authentifizierungsmethode für MFA erfordert, gilt die Anmeldung als erfüllt die MFA-Anforderung, nachdem die Microsoft Entra-ID beide überprüft hat:

• Der erste Faktor wurde mit der Microsoft Entra-ID abgeschlossen.
• Der zweite Faktor wurde mit der externen Authentifizierungsmethode abgeschlossen.

Diese Überprüfung erfüllt die MFA-Anforderung für zwei oder mehr Methodentypen:

• Etwas, das Sie wissen (Wissen)
• Etwas, das Sie haben (Besitz)
• Etwas, das Sie sind (Inhärenz)

Externe Authentifizierungsmethoden werden über OpenID Connect (OIDC) implementiert. Diese Implementierung erfordert mindestens drei öffentlich zugängliche Endpunkte, um eine externe Authentifizierungsmethode zu implementieren:

• Ein OIDC Discovery-Endpunkt, wie in Ermittlung der Metadaten des Anbieters beschrieben.
• Ein gültiger OIDC-Authentifizierungsendpunkt
• Eine URL, in der die öffentlichen Zertifikate des Anbieters veröffentlicht werden

So funktioniert die Anmeldung mit einer externen Authentifizierungsmethode:

1. Ein Benutzer versucht, sich mit einem ersten Faktor, z. B. einem Kennwort, bei einer Anwendung anzumelden, die durch Microsoft Entra ID geschützt ist.

2. Die Microsoft Entra-ID bestimmt, dass ein weiterer Faktor erfüllt werden muss (z. B. wenn eine Richtlinie für bedingten Zugriff MFA erfordert).

3. Der Benutzer wählt die externe Authentifizierungsmethode als zweiten Faktor aus.

4. Die Microsoft Entra-ID leitet die Browsersitzung des Benutzers an die URL der externen Authentifizierungsmethode weiter.

   Diese URL wird aus der Ermittlungs-URL ermittelt, die ein Administrator beim Erstellen der externen Authentifizierungsmethode bereitgestellt hat.

   Die Anwendung stellt ein abgelaufenes oder fast abgelaufenes Token bereit, das Informationen zum Identifizieren des Benutzers und des Mandanten enthält.

5. Der externe Authentifizierungsanbieter überprüft, ob das Token von Microsoft Entra ID stammt, und überprüft den Inhalt des Tokens.

6. Möglicherweise ruft der externe Authentifizierungsanbieter Microsoft Graph auf, um zusätzliche Informationen über den Benutzer abzurufen.

7. Der externe Authentifizierungsanbieter führt alle erforderlichen Aktionen aus, z. B. die Authentifizierung des Benutzers mit anmeldeinformationen.

8. Der externe Authentifizierungsanbieter leitet den Benutzer zurück zur Microsoft Entra-ID mit einem gültigen Token, einschließlich aller erforderlichen Ansprüche.

9. Microsoft Entra ID überprüft, ob die Signatur des Tokens vom konfigurierten externen Authentifizierungsanbieter stammt, und überprüft dann den Inhalt des Tokens.

10. Microsoft Entra ID überprüft das Token anhand der Anforderungen.

11. Wenn die Überprüfung erfolgreich ist, bedeutet dies, dass der Benutzer die MFA-Anforderung erfüllt hat. Möglicherweise muss der Benutzer auch andere Richtlinienanforderungen erfüllen.

Konfigurieren eines neuen externen Authentifizierungsanbieters mit Microsoft Entra-ID

Um id_token_hint auszustellen, benötigen externe Authentifizierungsmethoden eine Anwendung, die die Integration unterstützt. Sie können die Anwendung auf zwei Arten erstellen:

• Bei jedem Mandanten, der den externen Dienstanbieter verwendet.
• Als eine mehrinstanzenfähige Anwendung. Um die Integration für ihren Mandanten zu aktivieren, müssen Privilegierte Rollenadministratoren die Zustimmung erteilen.

Die Nutzung einer mehrinstanzenfähigen Anwendung kann die Wahrscheinlichkeit von Fehlkonfigurationen bei einzelnen Mandanten verringern. Anbieter können auch Änderungen an Metadaten vornehmen (z. B. Antwort-URLs an einer Zentralen Stelle), anstatt dass jeder Mandant die Änderungen vornehmen muss.

Um eine mehrinstanzenfähige Anwendung zu konfigurieren, muss der Anbieteradministrator zuerst:

1. Erstellen Sie einen Microsoft Entra ID-Mandanten (sofern sie noch keinen besitzen).

2. Registrieren Sie eine Anwendung im Mandanten.

3. Wählen Sie in der Anwendung unter Unterstützte Kontotypen die Option Konten in einem beliebigen Organisationsverzeichnis (Beliebiger Microsoft Entra ID-Mandant - Multitenant) aus.

4. Fügen Sie die delegierten Berechtigungen openid und profile Werte für Microsoft Graph hinzu.

5. Veröffentlichen Sie keine Bereiche in dieser Anwendung.

6. Fügen Sie die gültigen authorization_endpoint URLs des externen Identitätsanbieters als Antwort-URLs zu dieser Anwendung hinzu.

   Hinweis

   Fügen Sie in der Anwendungsregistrierung den authorization_endpoint im Discoverydokument des Anbieters bereitgestellten Wert als Umleitungs-URL hinzu. Andernfalls erhalten Sie die folgende Fehlermeldung: "ENTRA IDSTS50161: Fehler beim Überprüfen der Autorisierungs-URL des externen Anspruchsanbieters!"

Der Prozess der Anwendungsregistrierung erstellt eine Anwendung mit mehreren Eigenschaften. Sie benötigen diese Eigenschaften für unser Szenario.

Ein weiteres gültiges Modell zur Unterstützung der Integration besteht darin, eine Anwendung für jeden Mandanten zu verwenden. Wenn Sie eine Registrierung mit einem einzelnen Mandanten verwenden, muss der Mandantenadministrator eine Anwendungsregistrierung mit den Eigenschaften in der vorherigen Tabelle für eine Einzelmandantenanwendung erstellen.

Konfigurieren optionaler Ansprüche

Ein Anbieter kann mehr Claims durch optionale Claims für id_token konfigurieren.

Hinzufügen einer externen Authentifizierungsmethode zur Microsoft Entra-ID

Informationen zu externen Identitätsanbietern werden in der Authentifizierungsmethodenrichtlinie jedes Mandanten gespeichert. Die Anbieterinformationen werden als Authentifizierungsmethode des Typs externalAuthenticationMethodConfigurationgespeichert.

Jeder Anbieter hat einen Eintrag im Listenobjekt der Richtlinie. Jeder Eintrag muss Folgendes angeben:

• Wenn die Methode aktiviert ist.
• Die enthaltenen Gruppen, die die Methode verwenden können.
• Die ausgeschlossenen Gruppen, die die Methode nicht verwenden können.

Um die MFA-Anforderung für die Benutzeranmeldung festzulegen, können Benutzer mit der Rolle "Administrator für bedingten Zugriff" eine Richtlinie mit dem Erfordernis von MFA erstellen. Externe Authentifizierungsmethoden werden derzeit nicht mit Authentifizierungsstärken unterstützt.

Erfahren Sie mehr darüber , wie Sie eine externe Authentifizierungsmethode im Microsoft Entra Admin Center hinzufügen.

Microsoft Entra ID-Interaktion mit dem Anbieter

In den nächsten Abschnitten werden die Anbieteranforderungen erläutert und Beispiele für die Interaktion von Microsoft Entra-ID mit einem Anbieter erläutert.

Ermittlung der Metadaten des Anbieters

Ein externer Identitätsanbieter muss einen OIDC Discovery-Endpunkt bereitstellen. Dieser Endpunkt wird verwendet, um weitere Konfigurationsdaten abzurufen.

Die Discovery-URL muss das https-Schema verwenden und muss mit /.well-known/openid-configuration enden. Sie können nach diesem Segment keine zusätzlichen Pfadsegmente, Abfragezeichenfolgen oder Fragmente einschließen. Die vollständige Ermittlungs-URL muss in der Ermittlungs-URL enthalten sein, die Sie beim Erstellen der externen Authentifizierungsmethode konfigurieren.

Der Endpunkt gibt ein dort gehostetes JSON-Dokument mit Anbietermetadaten zurück. Der Endpunkt muss auch einen gültigen Content-Length-Header zurückliefern. Das Metadatendokument mussopenID Connect Discovery 1.0 (mit Errata-Satz 2) einhalten und alle erforderlichen OIDC-Metadatenfelder enthalten.

Die Metadaten des Anbieters müssen die in der folgenden Tabelle aufgeführten Daten enthalten. Diese Werte sind für dieses Erweiterbarkeitsszenario erforderlich. Das JSON-Metadatendokument enthält möglicherweise weitere Informationen.

Informationen zum OIDC-Dokument mit den Werten für Anbietermetadaten finden Sie unter Anbietermetadaten.

https://customcaserver.azurewebsites.net/v2.0/.well-known/openid-configuration
{
  "authorization_endpoint": "https://customcaserver.azurewebsites.net/api/Authorize",
  "claims_supported": [
    "email"
  ],
  "grant_types_supported": [
    "implicit"
  ],
  "id_token_signing_alg_values_supported": [
    "RS256"
  ],
  "issuer": "https://customcaserver.azurewebsites.net/v2.0",
  "jwks_uri": "https://customcaserver.azurewebsites.net/.well-known/jwks",
  "response_modes_supported": [
    "form_post"
  ],
  "response_types_supported": [
    "id_token"
  ],
  "scopes_supported": [
    "openid"
  ],
  "SigningKeys": [],
  "subject_types_supported": [
    "public"
  ]
}

https://customcaserver.azurewebsites.net/.well-known/jwks
{
  "keys": [
    {
      "kty": "RSA",
      "use": "sig",
      "kid": "A1bC2dE3fH4iJ5kL6mN7oP8qR9sT0u",
      "x5t": "A1bC2dE3fH4iJ5kL6mN7oP8qR9sT0u",
      "n": "jq277LRoE6WKM0awT3b...vt8J6MZvmgboVB9S5CMQ",
      "e": "AQAB",
      "x5c": [
        "cZa3jz...Wo0rzA="
      ]
    }
  ]
}

Beispiele für Discovery-URLs und Aussteller

Die folgenden Beispiele veranschaulichen gültige und ungültige Ermittlungs-URL und Ausstellerkombinationen für diese Integration.

Gültige Discovery-URL und Issuer-Paare

• Ermittlungs-URL: https://example.com/.well-known/openid-configuration
  Aussteller: https://example.com
• Ermittlungs-URL: https://example.com:8443/.well-known/openid-configuration
  Aussteller: https://example.com:8443
• Ermittlungs-URL: https://example.com/tenant1/.well-known/openid-configuration
  Aussteller: https://example.com/tenant1

Beispiele für ungültige Entdeckungs-URL und Herausgeber

• Ermittlungs-URL: https://example.com/.well-known/openid-configuration
  Issuer: https://example.com:443/ (Standardmäßiger HTTPS-Port explizit im Herausgeber angegeben.)
• Ermittlungs-URL: https://example.com:443/.well-known/openid-configuration
  Aussteller: https://example.com/ (Port-Missverhältnis.)
• Ermittlungs-URL: https://example.com/.well-known/openid-configuration?client_id=0oasxuxkghOniBjlQ697
  Aussteller: https://example.com (Sie können keine Abfragezeichenfolge in eine Discovery-URL einschließen.)

Zwischenspeichern der Anbietermetadaten

Um die Leistung zu verbessern, speichert Die Microsoft Entra-ID Metadaten zwischen, die der Anbieter zurückgibt, einschließlich der Schlüssel. Das Zwischenspeichern von Anbietermetadaten verhindert einen Ermittlungsaufruf jedes Mal, wenn Microsoft Entra ID mit einem externen Identitätsanbieter kommuniziert.

Dieser Cache wird alle 24 Stunden aktualisiert. Es wird empfohlen, dass Anbieter die folgenden Schritte ausführen, um ihre Schlüssel zu überrollen:

1. Veröffentlichen Sie das vorhandene Zertifikat und das neue Zertifikat in jwks_uri.
2. Melden Sie sich weiterhin mit dem vorhandenen Zertifikat an, bis der Microsoft Entra-ID-Cache aktualisiert, abgelaufen oder erneuert wird (alle 2 Tage).
3. Wechseln Sie zur Anmeldung mit dem neuen Zertifikat.

Wir veröffentlichen keine Zeitpläne für Schlüsselrollover. Der abhängige Dienst muss darauf vorbereitet sein, sowohl sofortige als auch regelmäßige Rollover zu verarbeiten. Wir empfehlen die Verwendung einer dedizierten Bibliothek, die zu diesem Zweck erstellt wurde, wie azure-activedirectory-identitymodel-extensions-for-dotnet. Weitere Informationen finden Sie unter Rollover von Signaturschlüsseln in Microsoft Entra ID.

Ermittlung von Microsoft Entra ID-Metadaten

Anbieter müssen auch die öffentlichen Schlüssel von Microsoft Entra ID abrufen, um die von Microsoft Entra ID ausgestellten Token zu überprüfen.

Microsoft Entra ID-Metadatenermittlungsendpunkte:

• Azure weltweit: https://login.microsoftonline.com/common/v2.0/.well-known/openid-configuration
• Azure für US-Regierungsbehörden: https://login.microsoftonline.us/common/v2.0/.well-known/openid-configuration
• Microsoft Azure, betrieben von 21Vianet: https://login.partner.microsoftonline.cn/common/v2.0/.well-known/openid-configuration

Sie können den öffentlichen Schlüsselbezeichner aus dem Token (dem "Kid" aus JSON Web Signature (JWS)) verwenden, um zu bestimmen, welche der von der jwks_uri Eigenschaft abgerufenen Schlüssel verwendet werden soll, um die Microsoft Entra ID-Tokensignatur zu überprüfen.

Überprüfen von Token, die von Microsoft Entra ID ausgestellt wurden

Informationen zum Überprüfen der von microsoft Entra ID ausgestellten Token finden Sie unter Validieren eines ID-Tokens. Es gibt keine speziellen Schritte für die Verbraucher unserer Ermittlungsmetadaten.

Alle Details zur Tokenüberprüfung finden Sie in der Tokenüberprüfungsbibliothek von Microsoft. Sie können diese Details auch ermitteln, indem Sie den Quellcode durchsuchen. Ein Beispiel finden Sie unter Azure-Beispiele.

Nachdem die Validierung erfolgreich war, können Sie mit der Claims-Payload arbeiten, um Details über den Benutzer und seinen Mandanten abzurufen.

Microsoft Entra ID-Aufruf an den externen Identitätsanbieter

Microsoft Entra ID verwendet den impliziten OIDC-Fluss für die Kommunikation mit dem externen Identitätsanbieter. Wenn Sie diesen Fluss verwenden, erfolgt die Kommunikation mit dem Anbieter nur mithilfe des Autorisierungsendpunkts des Anbieters.

Um den Anbieter über den Benutzer zu informieren, für den Die Microsoft Entra-ID die Anforderung vornimmt, übergibt die Microsoft Entra-ID ein Token über den id_token_hint Parameter.

Dieser Aufruf erfolgt über eine POST Anforderung, da eine große Liste von Parametern an den Anbieter übergeben wird. Eine große Liste verhindert die Verwendung von Browsern, die die Länge einer GET Anforderung begrenzen.

Die Parameter für die Authentifizierungsanforderung sind in der folgenden Tabelle aufgeführt.

Beispiel für einen Umleitungs-URI

Die Umleitungs-URIs sollten beim Anbieter off-band registriert werden. Die umleitungs-URIs, die Sie senden können, sind:

• Azure weltweit: https://login.microsoftonline.com/common/federation/externalauthprovider
• Azure für US-Regierungsbehörden: https://login.microsoftonline.us/common/federation/externalauthprovider
• Microsoft Azure, betrieben von 21Vianet: https://login.partner.microsoftonline.cn/common/federation/externalauthprovider

Beispiel für eine externe Authentifizierungsmethode, die MFA erfüllt

Hier ist ein Beispiel, bei dem eine externe Authentifizierungsmethode MFA-Anforderungen erfüllt. Dieses Beispiel hilft einem Anbieter zu erfahren, welche Ansprüche Microsoft Entra ID erwartet.

Microsoft Entra ID verwendet die Kombination der acr- und amr-Werte zur Validierung, dass:

• Die für den zweiten Faktor verwendete Authentifizierungsmethode erfüllt die MFA-Anforderung.
• Die Authentifizierungsmethode ist ein anderer Typ als die Methode, die zum Abschließen des ersten Faktors für die Anmeldung bei Microsoft Entra ID verwendet wird.

{
  "id_token": {
    "acr": {
      "essential": true,
      "values":["possessionorinherence"]
    },
    "amr": {
      "essential": true,
      "values": ["face", "fido", "fpt", "hwk", "iris", "otp", "pop", "retina", "sc", "sms", "swk", "tel", "vbm"]
    }
  }
}

Standardanspruchsdaten für id_token_hint

In diesem Abschnitt werden die erforderlichen Inhalte des Tokens beschrieben, das wie id_token_hint in der Anforderung an den Anbieter übergeben wird. Das Token enthält möglicherweise mehr Ansprüche als in der folgenden Tabelle dargestellt.

Um zu verhindern, dass das Token für etwas anderes als einen Hinweis verwendet wird, wird es im abgelaufenen Zustand ausgegeben. Das Token ist signiert und kann mithilfe der veröffentlichten Microsoft Entra ID-Ermittlungsmetadaten überprüft werden.

Optionale Ansprüche von Microsoft Entra ID

Wenn ein Anbieter optionale Ansprüche von Microsoft Entra ID benötigt, können Sie die folgenden optionalen Ansprüche für id_token: given_name, family_name, preferred_username, upn konfigurieren. Weitere Informationen finden Sie unter Optionale Ansprüche.

Empfohlene Verwendung von Ansprüchen

Es wird empfohlen, Konten auf der Seite des Anbieters mit dem Konto in Azure zu verknüpfen, indem Sie die oid- und tid-Claims verwenden. Diese beiden Ansprüche sind für das Konto im Mandanten garantiert eindeutig.

Beispiel für „id_token_hint“

Hier ist ein Beispiel von id_token_hint für ein Verzeichnismitglied.

{
  "typ": "JWT",
  "alg": "RS256",
  "kid": "C2dE3fH4iJ5kL6mN7oP8qR9sT0uV1w"
}.{
  "ver": "2.0",
  "iss": "https://login.microsoftonline.com/aaaabbbb-0000-cccc-1111-dddd2222eeee/v2.0",
  "sub": "mBfcvuhSHkDWVgV72x2ruIYdSsPSvcj2R0qfc6mGEAA",
  "aud": "00001111-aaaa-2222-bbbb-3333cccc4444",
  "exp": 1536093790,
  "iat": 1536093791,
  "nbf": 1536093791,
  "name": "Test User 2",
  "preferred_username": "testuser2@contoso.com"
  "oid": "aaaaaaaa-0000-1111-2222-bbbbbbbbbbbb",
  "tid": "aaaabbbb-0000-cccc-1111-dddd2222eeee"
  }.

Hier ist ein Beispiel id_token_hint für einen Gastbenutzer des Mandanten:

{
  "typ": "JWT",
  "alg": "RS256",
  "kid": "C2dE3fH4iJ5kL6mN7oP8qR9sT0uV1w"
}.{
  "ver": "2.0",
  "iss": "https://login.microsoftonline.com/9122040d-6c67-4c5b-b112-36a304b66dad/v2.0",
  "sub": "mBfcvuhSHkDWVgV72x2ruIYdSsPSvcj2R0qfc6mGEAA",
  "aud": "00001111-aaaa-2222-bbbb-3333cccc4444",
  "exp": 1536093790,
  "iat": 1536093791,
  "nbf": 1536093791,
  "name": "External Test User (Hotmail)",
  "preferred_username": "externaltestuser@hotmail.com",
  "oid": "aaaaaaaa-0000-1111-2222-bbbbbbbbbbbb",
  "tid": "aaaabbbb-0000-cccc-1111-dddd2222eeee"
  }.

Vorgeschlagene Aktionen für externe Identitätsanbieter

Es wird empfohlen, dass externe Identitätsanbieter die folgenden Elemente abschließen. Die Liste ist nicht vollständig, und Anbieter sollten andere angemessene Überprüfungsschritte ausführen.

• Aus der Anforderung:

  • Stellen Sie sicher, dass die redirect_uri Veröffentlichung gemäß der Beschreibung im Microsoft Entra ID-Aufruf an den externen Identitätsanbieter erfolgt.
  • Stellen Sie sicher, dass die konfigurierte Discovery-URL HTTPS verwendet und mit /.well-known/openid-configuration endet. Stellen Sie außerdem sicher, dass sie keine Abfrageparameter oder Fragmentbezeichner enthält. Stellen Sie sicher, dass der Ausstellerwert dem Ermittlungsdokument exakt entspricht.
  • Stellen Sie sicher, dass dem client_id ein Wert zugewiesen ist, z. B. die Microsoft Entra ID wie ABCD.
  • Der Anbieter sollte zuerst überprüfen , ob die id_token_hint Microsoft Entra-ID darin angezeigt wird.

• Aus den Ansprüchen in der id_token_hint:

  • (Optional) Rufen Sie Microsoft Graph auf, um weitere Details zu diesem Benutzer abzurufen. Die Ansprüche in oid und tid in id_token_hint sind in dieser Hinsicht nützlich. Ausführliche Informationen zu den in id_token_hintdiesem Artikel bereitgestellten Ansprüchen finden Sie unter Standardansprücheid_token_hint.

• Führen Sie alle anderen Authentifizierungsaktivitäten für das Produkt des Anbieters aus.

• Je nach dem Ergebnis der Benutzeraktionen und anderer Faktoren würde der Anbieter dann eine Antwort erstellen und an Microsoft Entra ID senden, wie im nächsten Abschnitt erläutert.

Verarbeitung der Anbieterantwort durch Microsoft Entra ID

Der Anbieter muss POST verwenden, um eine Antwort an redirect_uri zu senden. Die folgenden Parameter sollten für eine erfolgreiche Antwort bereitgestellt werden:

Bei Erfolg würde der Anbieter dann einen id_token Wert für den Benutzer ausgeben. Microsoft Entra-ID verwendet die veröffentlichten OIDC-Metadaten, um zu überprüfen, ob das Token die erwarteten Ansprüche enthält, und führt eine andere Tokenüberprüfung durch, die OIDC erfordert.

Unterstützte acr-Ansprüche

Unterstützte amr-Ansprüche

Microsoft Entra-ID erfordert, dass MFA zufrieden ist, um ein Token mit MFA-Ansprüchen auszustellen. Daher können nur Methoden mit einem anderen Typ die zweite Faktoranforderung erfüllen. Wie bereits erwähnt, sind die verschiedenen Methodentypen, die verwendet werden können, um den zweiten Faktor zu erfüllen, Wissen, Besitz und Inhärenz.

Microsoft Entra ID überprüft die Typzuordnung basierend auf der folgenden Tabelle.

Microsoft Entra ID betrachtet die MFA als erfüllt, wenn keine Probleme mit dem Token festgestellt werden, und gibt dem Benutzer dann ein Token aus. Andernfalls schlägt die Anforderung des Benutzers fehl.

Der Fehler wird durch das Ausgeben von Fehlerantwortparametern angezeigt.

Die Microsoft Entra-ID betrachtet die Anforderung als erfolgreich, wenn id_token parameter in der Antwort vorhanden ist und das Token gültig ist. Andernfalls gilt die Anforderung als erfolglos. Die Microsoft Entra-ID schlägt den ursprünglichen Authentifizierungsversuch aufgrund der Anforderung der Richtlinie für bedingten Zugriff fehl.

Microsoft Entra ID verwirft den Status des Authentifizierungsversuchs auf seiner Seite etwa 5 Minuten nach der Umleitung an den Anbieter.

Behandlung von Microsoft Entra-ID-Fehlerantworten

Microsoft Azure-Dienste verwenden einen correlationId Wert, um Anrufe über verschiedene interne und externe Systeme hinweg zu korrelieren. Diese dient als allgemeiner Bezeichner des gesamten Vorgangs oder Flusses, der potenziell mehrere HTTP-Aufrufe umfasst. Wenn während eines der Vorgänge ein Fehler auftritt, enthält die Antwort ein Feld mit dem Namen "Korrelations-ID".

Wenn Sie sich an den Microsoft-Support oder einen ähnlichen Dienst wenden, stellen Sie den Korrelations-ID-Wert bereit. Dadurch können Sie schneller auf Telemetrie und Protokolle zugreifen.

Zum Beispiel:

ENTRA IDSTS70002: Error validating credentials. ENTRA IDSTS50012: External ID token from issuer 'https://sts.XXXXXXXXX.com/auth/realms/XXXXXXXXXmfa' failed signature verification. KeyID of token is 'A1bC2dE3fH4iJ5kL6mN7oP8qR9sT0u'

Trace ID: 0000aaaa-11bb-cccc-dd22-eeeeee333333

Correlation ID: aaaa0000-bb11-2222-33cc-444444dddddd

Timestamp: 2023-07-24 16:51:34Z

Benutzerdefinierte Steuerelemente und methoden für die externe Authentifizierung

In microsoft Entra ID können externe Authentifizierungsmethoden und benutzerdefinierte Steuerelemente für bedingten Zugriff parallel ausgeführt werden, während Kunden sich auf externe Authentifizierungsmethoden vorbereiten und migrieren.

Kunden, die derzeit eine Integration mit einem externen Anbieter mithilfe von benutzerdefinierten Steuerelementen verwenden, können sie weiterhin verwenden, ebenso wie alle Richtlinien für bedingten Zugriff, die sie für die Verwaltung des Zugriffs konfiguriert haben. Es wird empfohlen, dass Administratoren während des Migrationszeitraums einen parallelen Satz von Richtlinien für bedingten Zugriff erstellen:

• Die Richtlinien sollten das Gewährungssteuerelement Multi-Faktor-Authentifizierung erfordern anstelle der Gewährung mit benutzerdefinierten Steuerelementen verwenden.

  Hinweis

  Die Gewährung von Zugriffskontrollen basierend auf den Authentifizierungsstärken, einschließlich der integrierten MFA-Stärke, werden von der externen Authentifizierungsmethode nicht unterstützt. Richtlinien sollten nur mit Erfordern der Multi-Faktor-Authentifizierung konfiguriert werden.

• Die neue Richtlinie kann zuerst mit einer Teilmenge von Benutzern getestet werden. Die Testgruppe wird von der Richtlinie ausgeschlossen, die benutzerdefinierte Steuerelemente erfordert, und in die Richtlinie einbezogen, die MFA erfordert. Wenn der Administrator sich sicher ist, dass die Richtlinie, welche MFA verlangt, von der externen Authentifizierungsmethode erfüllt ist, kann der Administrator alle erforderlichen Benutzer in die Richtlinie mit der MFA-Erteilung einschließen. Die richtlinie, die für benutzerdefinierte Steuerelemente konfiguriert ist, kann in die Einstellung "Aus" verschoben werden.

Integrationsunterstützung

Wenn Sie Probleme bei der Erstellung der Integration von externen Authentifizierungsmethoden mit Microsoft Entra ID haben, kann möglicherweise der Microsoft Customer Experience Engineering (CxE) Independent Solution Vendor (ISV) Unterstützung bieten. Um mit dem CxE ISV-Team in Kontakt zu treten, übermitteln Sie eine Anfrage zur Unterstützung.

Referenzen

• OAuth2.0- und OIDC-Spezifikation

Glossar

Verwandte Inhalte

• Weitere Informationen zum Konfigurieren einer externen Authentifizierungsmethode im Microsoft Entra Admin Center finden Sie unter Verwalten einer externen Authentifizierungsmethode in Microsoft (Vorschau).