Używanie Microsoft Entra MFA z dostawcą zewnętrznym (wersja zapoznawcza)

W tym artykule opisano, jak dostawca uwierzytelniania zewnętrznego łączy się z uwierzytelnianiem wieloskładnikowym firmy Microsoft (MFA).

Gdy użytkownik się zaloguje, zostaną ocenione zasady dzierżawy. Wymagania dotyczące uwierzytelniania są określane na podstawie zasobu, do którego użytkownik próbuje uzyskać dostęp.

Wiele zasad może mieć zastosowanie do logowania, w zależności od ich parametrów. Te parametry obejmują użytkowników i grupy, aplikacje, platformę, poziom ryzyka logowania i nie tylko.

Na podstawie wymagań dotyczących uwierzytelniania użytkownik może wymagać zalogowania się przy użyciu innego czynnika, aby spełnić wymaganie uwierzytelniania wieloskładnikowego. Typ drugiego czynnika musi uzupełniać typ pierwszego czynnika.

Administrator dzierżawy dodaje metody uwierzytelniania zewnętrznego do Microsoft Entra ID. Jeśli klient wymaga zewnętrznej metody uwierzytelniania dla MFA, logowanie jest uznawane za spełniające wymogi MFA po zweryfikowaniu obu elementów przez Microsoft Entra ID:

• Pierwszy czynnik został ukończony przy użyciu identyfikatora Entra firmy Microsoft.
• Drugi czynnik został ukończony przy użyciu metody uwierzytelniania zewnętrznego.

Ta weryfikacja spełnia wymaganie uwierzytelniania wieloskładnikowego dla co najmniej dwóch typów metod:

• Coś, co znasz (wiedza)
• Coś, co masz (posiadanie)
• Coś, co cię charakteryzuje (cecha wrodzona)

Metody uwierzytelniania zewnętrznego są implementowane na platformie OpenID Connect (OIDC). Ta implementacja wymaga co najmniej trzech publicznych punktów końcowych w celu zaimplementowania zewnętrznej metody uwierzytelniania:

• Punkt końcowy odkrywania OIDC, opisany w Odnajdywanie metadanych dostawcy
• Prawidłowy punkt końcowy uwierzytelniania OIDC
• Adres URL, pod którym publikowane są publiczne certyfikaty dostawcy

Oto jak logowanie działa z zewnętrzną metodą uwierzytelniania:

1. Użytkownik próbuje zalogować się przy użyciu pierwszego czynnika, takiego jak hasło, do aplikacji chronionej przez identyfikator Firmy Microsoft Entra.

2. Identyfikator entra firmy Microsoft określa, że należy spełnić inny czynnik (na przykład jeśli zasady dostępu warunkowego wymagają uwierzytelniania wieloskładnikowego).

3. Użytkownik wybiera metodę uwierzytelniania zewnętrznego jako drugi czynnik.

4. Identyfikator Entra firmy Microsoft przekierowuje sesję przeglądarki użytkownika do adresu URL metody uwierzytelniania zewnętrznego.

   Ten adres URL jest wykrywany na podstawie adresu URL odnajdywania, który administrator aprowizował podczas tworzenia zewnętrznej metody uwierzytelniania.

   Aplikacja udostępnia wygasły lub prawie wygasły token zawierający informacje umożliwiające zidentyfikowanie użytkownika i najemcy.

5. Zewnętrzny dostawca uwierzytelniania sprawdza, czy token pochodzi z identyfikatora Firmy Microsoft Entra i sprawdza zawartość tokenu.

6. Zewnętrzny dostawca uwierzytelniania może wykonać wywołanie programu Microsoft Graph w celu pobrania dodatkowych informacji o użytkowniku.

7. Zewnętrzny dostawca uwierzytelniania wykonuje wszelkie czynności, które uważa za niezbędne, takie jak uwierzytelnianie użytkownika przy użyciu poświadczeń.

8. Zewnętrzny dostawca uwierzytelniania przekierowuje użytkownika z powrotem do identyfikatora Entra firmy Microsoft z prawidłowym tokenem, w tym wszystkich wymaganych oświadczeń.

9. Identyfikator entra firmy Microsoft sprawdza, czy podpis tokenu pochodzi od skonfigurowanego zewnętrznego dostawcy uwierzytelniania, a następnie sprawdza zawartość tokenu.

10. Identyfikator entra firmy Microsoft weryfikuje token pod kątem wymagań.

11. Jeśli walidacja zakończy się pomyślnie, oznacza to, że użytkownik spełnił wymaganie uwierzytelniania wieloskładnikowego. Użytkownik może również spełniać inne wymagania dotyczące zasad.

Konfigurowanie nowego zewnętrznego dostawcy uwierzytelniania przy użyciu identyfikatora Entra firmy Microsoft

Aby wydać id_token_hint, metody uwierzytelniania zewnętrznego wymagają aplikacji reprezentującej integrację. Aplikację można utworzyć na dwa sposoby:

• W każdym najemcy korzystającym z zewnętrznego dostawcy.
• Jako jedna aplikacja wielodostępna. Aby włączyć integrację dla swojej dzierżawy, administratorzy ról uprzywilejowanych muszą wyrazić zgodę.

Użycie aplikacji wielodostępnej może zmniejszyć prawdopodobieństwo błędnej konfiguracji w każdej dzierżawie. Dostawcy mogą również zmieniać metadane, takie jak adresy URL odpowiedzi w jednym miejscu, zamiast wymagać od każdego najemcy dokonania zmian.

Aby skonfigurować aplikację wielodostępną, administrator dostawcy musi najpierw:

1. Utwórz klienta Microsoft Entra ID (jeśli jeszcze go nie mają).

2. Zarejestruj aplikację w ich kliencie.

3. W aplikacji, w obszarze Obsługiwane typy kont, wybierz pozycję Konta w dowolnym katalogu organizacyjnym (Dowolna dzierżawa Microsoft Entra ID – wielodostępny).

4. Dodaj wartości openid i profile dla delegowanych uprawnień w Microsoft Graph.

5. Nie publikuj żadnych zakresów w tej aplikacji.

6. Dodaj prawidłowe authorization_endpoint adresy URL zewnętrznego dostawcy tożsamości do tej aplikacji jako adresy URL odpowiedzi.

   Uwaga

   W rejestracji aplikacji dodaj authorization_endpoint wartość podaną w dokumencie odnajdywania dostawcy jako adres URL przekierowania. W przeciwnym razie zostanie wyświetlony następujący błąd: "ENTRA IDSTS50161: Nie można zweryfikować adresu URL autoryzacji zewnętrznego dostawcy oświadczeń!"

Proces rejestracji aplikacji tworzy aplikację z kilkoma właściwościami. Te właściwości są potrzebne w naszym scenariuszu.

Innym prawidłowym modelem wspierania integracji jest użycie aplikacji dla każdego najemcy. Jeśli używasz rejestracji jednoddzierżawowej, administrator dzierżawy musi utworzyć rejestrację aplikacji z właściwościami w poprzedniej tabeli dla aplikacji jednoddzierżawowej.

Konfigurowanie opcjonalnych oświadczeń

Dostawca może skonfigurować więcej żądań używając opcjonalnych żądań dla id_token.

Dodawanie zewnętrznej metody uwierzytelniania do identyfikatora Entra firmy Microsoft

Informacje o zewnętrznym dostawcy tożsamości są przechowywane w polityce metod uwierzytelniania każdego dzierżawcy. Informacje o dostawcy są przechowywane jako metoda uwierzytelniania typu externalAuthenticationMethodConfiguration.

Każdy dostawca ma jeden wpis na liście polityki. Każdy wpis musi określać:

• Jeśli metoda jest włączona.
• Grupy, które mogą stosować tę metodę, są uwzględnione.
• Wykluczone grupy, które nie mogą użyć metody .

Aby ustawić wymaganie uwierzytelniania wieloskładnikowego dla logowania użytkownika, użytkownicy z rolą Administratora dostępu warunkowego mogą utworzyć zasadę z przyznawaniem dostępu z wymogiem uwierzytelniania wieloskładnikowego. Metody uwierzytelniania zewnętrznego nie są obecnie obsługiwane z poziomami uwierzytelniania.

Dowiedz się więcej o dodawaniu zewnętrznej metody uwierzytelniania w centrum administracyjnym firmy Microsoft Entra.

Interakcja identyfikatora Entra firmy Microsoft z dostawcą

W następnych sekcjach opisano wymagania dostawcy i opisano przykłady interakcji identyfikatora Entra firmy Microsoft z dostawcą.

Odnajdywanie metadanych dostawcy

Zewnętrzny dostawca tożsamości musi zapewnić punkt końcowy OIDC Discovery. Ten punkt końcowy służy do uzyskiwania większej ilości danych konfiguracji.

Adres URL odnajdywania musi używać schematu https i musi kończyć się ciągiem /.well-known/openid-configuration. Nie można uwzględnić żadnych dodatkowych segmentów ścieżki, ciągów zapytania ani fragmentów po tym segmencie. Adres URL pełnego odnajdywania musi być uwzględniony w adresie URL odnajdywania, który konfigurujesz podczas tworzenia zewnętrznej metody uwierzytelniania.

Punkt końcowy zwraca dokument JSON metadanych dostawcy, który jest tam hostowany. Punkt końcowy musi również zwrócić prawidłowy nagłówek o długości zawartości. Dokument metadanych musi być zgodny z funkcją OpenID Connect Discovery 1.0 (uwzględniającą zestaw errata 2) i uwzględnić wszystkie wymagane pola metadanych OIDC.

Metadane dostawcy muszą zawierać dane wymienione w poniższej tabeli. Te wartości są wymagane w tym scenariuszu rozszerzalności. Dokument metadanych JSON może zawierać więcej informacji.

Aby zapoznać się z dokumentem OIDC zawierającym wartości metadanych dostawcy, zobacz Metadane dostawcy.

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="
      ]
    }
  ]
}

Przykłady odkrywczych adresów URL i wydawców

W poniższych przykładach zobrazowano prawidłowe oraz nieprawidłowe kombinacje adresów URL odnajdywania i wystawców dla tej integracji.

Ważny adres URL wykrywania i pary wydawców

• Adres URL odnajdywania: https://example.com/.well-known/openid-configuration
  Emitenta: https://example.com
• Adres URL odnajdywania: https://example.com:8443/.well-known/openid-configuration
  Emitenta: https://example.com:8443
• Adres URL odnajdywania: https://example.com/tenant1/.well-known/openid-configuration
  Emitenta: https://example.com/tenant1

Nieprawidłowe adresy URL odnajdywania i przykłady wystawców

• Adres URL odnajdywania: https://example.com/.well-known/openid-configuration
  Wystawca: https://example.com:443/ (Domyślny port HTTPS został jawnie dodany przez wystawcę).
• Adres URL odnajdywania: https://example.com:443/.well-known/openid-configuration
  Wystawca: https://example.com/ (Niepasujący port.)
• Adres URL odnajdywania: https://example.com/.well-known/openid-configuration?client_id=0oasxuxkghOniBjlQ697
  Wystawca: https://example.com (Nie można uwzględnić ciągu zapytania w adresie URL odnajdywania).

Buforowanie metadanych dostawcy

Aby zwiększyć wydajność, identyfikator entra firmy Microsoft buforuje metadane zwracane przez dostawcę, w tym klucze. Buforowanie metadanych dostawcy zapobiega wywoływaniu funkcji wykrywania za każdym razem, gdy Microsoft Entra ID komunikuje się z zewnętrznym dostawcą tożsamości.

Ta pamięć podręczna jest odświeżana co 24 godziny. Zalecamy, aby dostawcy wykonali następujące kroki, aby obrócić swoje klucze:

1. Opublikuj istniejący certyfikat i nowy certyfikat w programie jwks_uri.
2. Loguj się przy użyciu istniejącego certyfikatu, dopóki pamięć podręczna Microsoft Entra ID nie zostanie odświeżona, nie wygasła lub nie została zaktualizowana (co 2 dni).
3. Przejdź do logowania przy użyciu nowego certyfikatu.

Nie publikujemy harmonogramów rotacji kluczy. Usługa zależna musi być przygotowana do obsługi zarówno natychmiastowych, jak i okresowych przełączania. Zalecamy użycie dedykowanej biblioteki utworzonej w tym celu, takiej jak azure-activedirectory-identitymodel-extensions-for-dotnet. Aby uzyskać więcej informacji, zobacz Odnowienie klucza podpisu w usłudze Microsoft Entra ID.

Odkrywanie metadanych Microsoft Entra ID

Dostawcy muszą również pobrać klucze publiczne identyfikatora Entra firmy Microsoft, aby zweryfikować tokeny wystawione przez identyfikator Entra firmy Microsoft.

Punkty końcowe odnajdywania metadanych Microsoft Entra ID:

• Globalna platforma Azure: https://login.microsoftonline.com/common/v2.0/.well-known/openid-configuration
• Platforma Azure dla instytucji rządowych USA: https://login.microsoftonline.us/common/v2.0/.well-known/openid-configuration
• Platforma Microsoft Azure obsługiwana przez firmę 21Vianet: https://login.partner.microsoftonline.cn/common/v2.0/.well-known/openid-configuration

Możesz użyć identyfikatora klucza publicznego z tokenu ("kid" z JSON Web Signature (JWS)) aby określić, który z kluczy pobranych z właściwości jwks_uri należy użyć do zweryfikowania podpisu tokenu Microsoft Entra ID.

Weryfikowanie tokenów wystawionych przez Microsoft Entra ID

Aby uzyskać informacje na temat sprawdzania poprawności tokenów wystawionych przez identyfikator firmy Microsoft Entra, zobacz Weryfikowanie tokenu identyfikatora. Nie ma żadnych specjalnych kroków dla użytkowników metadanych odnajdywania.

Wszystkie szczegóły dotyczące weryfikacji tokenu można znaleźć w bibliotece weryfikacji tokenów firmy Microsoft. Te szczegóły można również ustalić, przeglądając kod źródłowy. Aby zapoznać się z przykładem, zobacz Przykłady platformy Azure.

Po pomyślnym zakończeniu walidacji możesz pracować z ładunkiem roszczeń, aby uzyskać szczegółowe informacje o użytkowniku i jego dzierżawcy.

Wywołanie usługi Microsoft Entra ID do zewnętrznego dostawcy tożsamości

Identyfikator Entra firmy Microsoft używa niejawnego przepływu OIDC do komunikowania się z zewnętrznym dostawcą tożsamości. W przypadku korzystania z tego przepływu komunikacja z dostawcą odbywa się przy użyciu tylko punktu końcowego autoryzacji dostawcy.

Aby poinformować dostawcę o użytkowniku, dla którego identyfikator Entra firmy Microsoft wysyła żądanie, identyfikator Entra firmy Microsoft przekazuje token za pośrednictwem parametru id_token_hint .

To wywołanie jest wykonywane za pośrednictwem POST żądania, ponieważ duża lista parametrów jest przekazywana do dostawcy. Duża lista uniemożliwia korzystanie z przeglądarek, które ograniczają długość GET żądania.

Parametry żądania uwierzytelniania są wymienione w poniższej tabeli.

Przykład identyfikatora URI przekierowania

Identyfikatory URI przekierowania powinny być zarejestrowane u dostawcy poza pasmem. URI przekierowania, których można używać, to:

• Globalna platforma Azure: https://login.microsoftonline.com/common/federation/externalauthprovider
• Platforma Azure dla instytucji rządowych USA: https://login.microsoftonline.us/common/federation/externalauthprovider
• Platforma Microsoft Azure obsługiwana przez firmę 21Vianet: https://login.partner.microsoftonline.cn/common/federation/externalauthprovider

Przykład metody uwierzytelniania zewnętrznego, która spełnia wymagania uwierzytelniania wieloskładnikowego

Oto przykład, w którym zewnętrzna metoda uwierzytelniania spełnia wymagania uwierzytelniania wieloskładnikowego. Ten przykład ułatwia dostawcy poznanie oświadczeń, których oczekuje identyfikator Entra firmy Microsoft.

Identyfikator Microsoft Entra ID używa kombinacji wartości acr i amr w celu sprawdzenia, czy:

• Metoda uwierzytelniania używana dla drugiego czynnika spełnia wymaganie uwierzytelniania wieloskładnikowego.
• Metoda uwierzytelniania jest innym typem niż metoda użyta do ukończenia pierwszego czynnika logowania do identyfikatora Entra firmy Microsoft.

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

Domyślne oświadczenia id_token_hint

W tej sekcji opisano wymaganą zawartość tokenu, który jest przekazywany jako id_token_hint w żądaniu do dostawcy. Token może zawierać więcej oświadczeń niż pokazano w poniższej tabeli.

Aby zapobiec użyciu tokenu do niczego innego niż jako wskazówka, jest wydawany jako wygasły. Token jest podpisany i można go zweryfikować przy użyciu opublikowanych metadanych odnajdywania identyfikatorów Microsoft Entra ID.

Opcjonalne oświadczenia z identyfikatora Entra firmy Microsoft

Jeśli dostawca potrzebuje opcjonalnych oświadczeń z identyfikatora Entra firmy Microsoft, możesz skonfigurować następujące opcjonalne oświadczenia dla id_token: given_name, family_name, preferred_username, upn. Aby uzyskać więcej informacji, zobacz Opcjonalne oświadczenia.

Zalecane użycie stwierdzeń

Zalecamy skojarzenie kont po stronie dostawcy z kontem na platformie Azure przy użyciu żądań oid i tid. Te dwa oświadczenia mają zagwarantowaną unikatowość dla konta tego dzierżawcy.

Przykład „id_token_hint”

Oto przykład id_token_hint elementu członkowskiego katalogu:

{
  "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"
  }.

Oto przykład id_token_hint użytkownika-gościa w dzierżawcy:

{
  "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"
  }.

Sugerowane akcje dla zewnętrznych dostawców tożsamości

Zalecamy, aby zewnętrzni dostawcy tożsamości wypełnili następujące elementy. Lista nie jest wyczerpująca, a dostawcy powinni wykonać inne kroki weryfikacji zgodnie z ich potrzebami.

• Z zapytania:

  • Upewnij się, że element redirect_uri został opublikowany zgodnie z opisem w temacie Microsoft Entra ID call to the external identity provider (Wywołanie identyfikatora entra firmy Microsoft do zewnętrznego dostawcy tożsamości).
  • Upewnij się, że skonfigurowany adres URL odnajdywania używa protokołu HTTPS i kończy się ciągiem /.well-known/openid-configuration. Upewnij się również, że nie zawiera parametrów zapytania ani identyfikatorów fragmentów. Upewnij się, że wartość wystawcy jest dokładnie zgodna z dokumentem odnajdywania.
  • Upewnij się, że element client_id ma wartość przypisaną do identyfikatora Entra firmy Microsoft, na przykład ABCD.
  • Dostawca powinien najpierw zweryfikowaćid_token_hint, który jest prezentowany przez Microsoft Entra ID.

• Z roszczeń w pliku id_token_hint:

  • (Opcjonalnie) Wywołaj program Microsoft Graph , aby pobrać inne szczegóły dotyczące tego użytkownika. Roszczenia oid i tid w id_token_hint tym zakresie są przydatne. Aby uzyskać szczegółowe informacje na temat oświadczeń podanych w systemie id_token_hint, zobacz Oświadczenia domyślneid_token_hint.

• Przejmij wszelkie inne działania uwierzytelniania dla produktu dostawcy.

• W zależności od wyniku akcji użytkownika i innych czynników dostawca utworzy i wyśle odpowiedź z powrotem do identyfikatora Entra firmy Microsoft, jak wyjaśniono w następnej sekcji.

Przetwarzanie odpowiedzi dostawcy przez Microsoft Entra ID

Dostawca musi użyć POST aby wysłać odpowiedź z powrotem do redirect_uri. Następujące parametry powinny zostać podane w odpowiedzi zakończonej powodzeniem:

W przypadku powodzenia dostawca wystawi wartość id_token dla użytkownika. Microsoft Entra ID używa opublikowanych metadanych OIDC, aby sprawdzić, czy token zawiera oczekiwane oświadczenia, i przeprowadza wszelkie inne weryfikacje tokenu wymagane przez OIDC.

Obsługiwane roszczenia acr

Obsługiwane oświadczenia AMR

Microsoft Entra ID wymaga, aby wymagania dotyczące uwierzytelniania wieloskładnikowego były spełnione, aby wystawić token z żądaniami dotyczącymi MFA. W związku z tym tylko metody o innym typie mogą spełniać drugie wymaganie współczynnika. Jak wspomniano wcześniej, do spełnienia drugiego czynnika można użyć różnych typów metod, takich jak wiedza, posiadanie i cecha.

Microsoft Entra ID weryfikuje mapowanie typów na podstawie poniższej tabeli.

Microsoft Entra ID uznaje, że uwierzytelnianie wieloskładnikowe (MFA) jest spełnione, jeśli nie wykryto żadnych problemów z tokenem, i wydaje token użytkownikowi. W przeciwnym razie żądanie użytkownika kończy się niepowodzeniem.

Błąd jest wskazywany przez wystawianie parametrów odpowiedzi na błędy.

Microsoft Entra ID uznaje żądanie za zakończone powodzeniem, jeżeli id_token parameter znajduje się w odpowiedzi i token jest prawidłowy. W przeciwnym razie żądanie jest uznawane za nieudane. Microsoft Entra ID nie powiodła się pierwotna próba uwierzytelnienia ze względu na wymóg Polityki dostępu warunkowego.

Identyfikator Entra firmy Microsoft porzuca stan próby uwierzytelnienia na jego końcu około 5 minut po przekierowaniu do dostawcy.

Obsługa odpowiedzi na błędy Microsoft Entra ID

Usługi platformy Microsoft Azure używają correlationId wartości do korelowania wywołań w różnych systemach wewnętrznych i zewnętrznych. Służy jako wspólny identyfikator całej operacji lub przepływu, który potencjalnie obejmuje wiele wywołań HTTP. Gdy wystąpi błąd podczas dowolnej operacji, odpowiedź zawiera pole o nazwie Identyfikator korelacji.

Gdy skontaktujesz się z pomocą techniczną firmy Microsoft lub podobną usługą, podaj wartość identyfikatora korelacji . Ułatwia szybsze uzyskiwanie dostępu do danych telemetrycznych i dzienników.

Na przykład:

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

Niestandardowe kontrolki i metody uwierzytelniania zewnętrznego

W usłudze Microsoft Entra ID metody uwierzytelniania zewnętrznego i niestandardowe mechanizmy kontroli dostępu warunkowego mogą działać równolegle, podczas gdy klienci przygotowują się i migrują do metod uwierzytelniania zewnętrznego.

Klienci, którzy obecnie korzystają z integracji z dostawcą zewnętrznym przy użyciu kontrolek niestandardowych, mogą nadal ich używać, oraz wszelkich zasad dostępu warunkowego skonfigurowanych do zarządzania dostępem. Zalecamy, aby administratorzy utworzyli równoległy zestaw zasad dostępu warunkowego w okresie migracji:

• Zasady powinny używać mechanizmu Wymagaj uwierzytelniania wieloskładnikowego zamiast mechanizmu przyznawania dostępu niestandardowego.

  Uwaga

  Zastosuj kontrolę na podstawie siły uwierzytelniania, w tym wbudowanej mocy uwierzytelniania wieloskładnikowego, które nie są spełnione przez zewnętrzną metodę uwierzytelniania. Zasady powinny być konfigurowane tylko przy użyciu opcji Wymagaj uwierzytelniania wieloskładnikowego.

• Nowe zasady można najpierw przetestować przy użyciu podzestawu użytkowników. Grupa testowa jest wykluczona z zasad wymagających kontrolek niestandardowych i uwzględniona w zasadach wymagających uwierzytelniania wieloskładnikowego. Gdy administrator jest pewien, że zasady wymagające uwierzytelniania wieloskładnikowego są spełnione przez zewnętrzną metodę uwierzytelniania, administrator może uwzględnić wszystkich wymaganych użytkowników w zasadach, przyznając im dostęp z wymogiem uwierzytelniania wieloskładnikowego. Zasady skonfigurowane dla kontrolek niestandardowych można przenieść do ustawienia Wyłączone .

Obsługa integracji

Jeśli napotkasz jakiekolwiek problemy podczas tworzenia integracji metody uwierzytelniania zewnętrznego z Microsoft Entra ID, inżynierowie Microsoft Customer Experience (CxE) oraz Niezależny Dostawca Rozwiązań (ISV) mogą być w stanie pomóc. Aby zaangażować się w zespół niezależnego dostawcy oprogramowania CxE, prześlij wniosek o pomoc.

Źródła

• Specyfikacja OAuth2.0 i OIDC

Słownik

Treści powiązane

• Aby uzyskać więcej informacji na temat konfigurowania zewnętrznej metody uwierzytelniania w centrum administracyjnym firmy Microsoft Entra, zobacz Zarządzanie zewnętrzną metodą uwierzytelniania w firmie Microsoft (wersja zapoznawcza).