共用方式為


Microsoft Entra 多重要素驗證外部方法提供者參考 (預覽)

本主題描述外部驗證提供者如何連線到 Microsoft Entra 多重要素驗證 (MFA)。 外部驗證提供者可以將 Microsoft Entra ID 租用戶整合為外部驗證方法 (EAM)。 EAM 可以滿足存取資源或應用程式之 MFA 需求的第二個因素。 EAM 至少需要 Microsoft Entra ID P1 授權。

當使用者登入時,系統會評估該租用戶原則。 驗證需求是根據使用者嘗試存取的資源來決定。

視其參數而定,多個原則可能會套用至登入。 這些參數包括使用者和群組、應用程式、平台、登入風險層級等等。

根據驗證需求,使用者可能需要使用另一個因素登入,以符合 MFA 需求。 第二個因素需要補充第一個因素的類型。

租用戶系統管理員會將 EAM 新增至 Microsoft Entra ID。如果租用戶需要 MFA 的 EAM,登入會在 Microsoft Entra ID 驗證兩者之後,視為符合 MFA 需求:

  • 使用 Microsoft Entra ID 完成的第一個因素
  • 使用 EAM 完成的第二個因素

該驗證符合下列兩種以上方法類型的 MFA 需求:

  • 您已知的資訊 (知識)
  • 您擁有的事物 (擁有)
  • 您的某些特徵 (固有)

EAM 會在 Open ID Connect (OIDC) 上實作。 此實作至少需要三個公開面向的端點:

讓我們進一步了解登入如何與 EAM 搭配運作:

  1. 使用者嘗試使用密碼等第一個因素登入受 Microsoft Entra ID 保護的應用程式。
  2. Microsoft Entra ID 判斷需要滿足另一個因素。 例如,條件式存取原則需要 MFA。
  3. 使用者選擇 EAM 作為第二個因素。
  4. Microsoft Entra ID 會將使用者的瀏覽器工作階段重新導向至 EAM URL:
    1. 此 URL 會從系統管理員在建立 EAM 時所布建的探索 URL 中探索。
    2. 應用程式會提供過期或即將過期的權杖,其中包含識別使用者和租用戶的資訊。
  5. 外部驗證提供者會驗證權杖是否來自 Microsoft Entra ID,並檢查權杖的內容。
  6. 外部驗證提供者可能會選擇性地呼叫 Microsoft Graph,以擷取使用者的其他資訊。
  7. 外部驗證提供者會執行它認為必要的任何動作,例如使用某些認證來驗證使用者。
  8. 外部驗證提供者會將使用者重新導向回具有有效權杖的 Microsoft Entra ID,包括所有必要的宣告。
  9. Microsoft Entra ID 會驗證權杖的簽章是否來自已設定的外部驗證提供者,然後檢查權杖的內容。
  10. Microsoft Entra ID 會根據需求驗證權杖。
  11. 如果使用者在驗證成功時符合 MFA 需求。 使用者可能也必須符合其他原則需求。

外部方法驗證運作方式的圖表。

使用 Microsoft Entra ID 設定新的外部驗證提供者

EAM 需要代表整合的應用程式才能發出 id_token_hint。 應用程式可以透過兩種方式建立:

  • 在每個使用外部提供者的租用戶中建立。
  • 建立為一個多租用戶應用程式。 特殊權限角色管理員必須授與同意,才能為其租用戶啟用整合。

多租用戶應用程式可減少每個租用戶中設定錯誤的機率。 它也可讓提供者在一個位置對中繼資料進行變更,例如回覆 URL,而不是要求每個租用戶進行變更。

若要設定多租用戶應用程式,提供者管理員必須先:

  1. 建立 Microsoft Entra ID 租用戶 (如果還沒有租用戶)。

  2. 在其租用戶中註冊應用程式。

  3. 將應用程式支援的帳戶類型設定為:任何組織目錄中的帳戶 (任何Microsoft Entra ID 租用戶 - 多租用戶)。

  4. 將委派的 Microsoft Graph 權限 openidprofile 新增至應用程式。

  5. 請勿在此應用程式中發佈任何範圍。

  6. 將外部識別提供者的有效 authorization_endpoint URL 新增至該應用程式作為回覆 URL。

    注意

    提供者探索文件中提供的 authorization_endpoint 應新增為應用程式註冊中的重新導向 URL。 否則,您會收到下列錯誤:ENTRA IDSTS50161:無法驗證外部宣告提供者的授權 URL!

應用程式註冊程序會建立具有數個屬性的應用程式。 我們的案例需要這些屬性。

屬性 說明
物件識別碼 提供者可以使用物件識別碼搭配 Microsoft Graph 來查詢應用程式資訊。
提供者可以使用物件識別碼,以程式設計方式擷取和編輯應用程式資訊。
Application ID 提供者可以使用應用程式識別碼作為其應用程式的 ClientId。
首頁 URL 提供者首頁 URL 不會用於任何項目,但在應用程式註冊過程中需要。
回覆 URL 提供者的有效重新導向 URL。 其中一個應該符合為提供者租用戶設定的提供者主機 URL。 其中一個已註冊的回覆 URL 必須符合 Microsoft Entra ID 針對主機 URL 透過 OIDC 探索擷取的 authorization_endpoint 前置詞。

每個租用戶的應用程式也是支援整合的有效模型。 如果您使用單一租用戶註冊,則租用戶系統管理員必須針對單一租用戶應用程式,使用上表中的屬性建立應用程式註冊。

注意

使用 EAM 的租用戶中需要應用程式的管理員同意。 如果未授與同意,當系統管理員嘗試使用 EAM:AADSTS900491:找不到<應用程式識別碼>的服務主體時,會出現下列錯誤。

設定選擇性宣告

提供者可以使用 id_token 的選擇性宣告來設定更多宣告。

注意

不論應用程式的建立方式為何,提供者都需要為每個雲端環境設定選擇性宣告。 如果多租用戶應用程式用於全域 Azure 和適用於美國政府的 Azure,則每個雲端環境都需要不同的應用程式和應用程式識別碼。

將 EAM 新增至 Microsoft Entra ID

外部識別提供者資訊會儲存在每個租用戶的驗證方法原則中。 提供者資訊會儲存為 externalAuthenticationMethodConfiguration 類型的驗證方法。

每個提供者在原則的清單物件中都有一個項目。 每個項目都必須陳述:

  • 如果方法已啟用
  • 可以使用方法的內含群組
  • 無法使用方法的排除群組

條件式存取系統管理員可以使用 [需要 MFA 授與] 來建立原則,以設定使用者登入的 MFA 需求。 目前不支援使用驗證強度的外部驗證方法。

如需如何在 Microsoft Entra 系統管理中心內新增外部驗證方法的詳細資訊,請參閱在 Microsoft Entra ID (預覽) 中管理外部驗證方法

與提供者的 Microsoft Entra ID 互動

下一節說明提供者需求,並包含與提供者進行 Microsoft Entra ID 互動的範例。

探索提供者中繼資料

外部識別提供者必須提供 OIDC 探索端點。 此端點可用來取得更多組態資料。 完整的 URL,包括 已知的/oidc-configuration,必須包含在建立 EAM 時所設定的探索 URL 中。

端點會傳回裝載於該處的提供者中繼資料 JSON 文件。 端點也必須傳回有效的內容長度標頭。

下表列出提供者中繼資料中應該存在的資料。 此擴充性案例需要這些值。 JSON 中繼資料文件可能包含詳細資訊。

如需具有提供者中繼資料值的 OIDC 文件,請參閱提供者中繼資料

中繼資料值 註解
Issuer 此 URL 應符合用於探索的主機 URL,以及提供者服務所簽發權杖中的 iss 宣告。
authorization_endpoint Microsoft Entra ID 針對授權進行通訊的端點。 此端點必須呈現為允許應用程式的其中一個回覆 URL。
jwks_uri 其中 Microsoft Entra ID 可找到確認驗證提供者所發出簽章所需的公開金鑰。
[!注意]
JSON Web 金鑰 (JWK) x5c 參數必須存在,才能提供所提供的金鑰 X.509 表示法。
scopes_supported openid 其他值也可能包含在內,但並非必要。
response_types_supported id_token 其他值也可能包含在內,但並非必要。
subject_types_supported
id_token_signing_alg_values_supported Microsoft 支援 RS256
claim_types_supported 一般 這個屬性是選擇性的,但如果存在,則應該包含一般值;也可能包含其他值。
http://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",
  "jwks_uri": "http://customcaserver.azurewebsites.net/.well-known/jwks",
  "response_modes_supported": [
    "form_post"
  ],
  "response_types_supported": [
    "id_token"
  ],
  "scopes_supported": [
    "openid"
  ],
  "SigningKeys": [],
  "subject_types_supported": [
    "public"
  ]
}

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

注意

JWK x5c 參數必須存在,才能提供所提供的金鑰 X.509 表示法。

提供者中繼資料快取

為了改善效能,Microsoft Entra ID 會快取提供者傳回的中繼資料,包括金鑰。 每次 Microsoft Entra ID 與外部識別提供者交談時,提供者中繼資料快取會防止探索呼叫。

此快取會每隔 24 小時 (一天) 重新整理一次。 以下是我們建議提供者變換其金鑰的方式:

  1. 在「jwks_uri」中發佈現有的憑證新憑證
  2. 繼續使用現有的憑證簽署,直到 Microsoft Entra ID 快取重新整理、過期或更新 (每 2 天)。
  3. 切換至使用新憑證簽署。

我們不會發佈金鑰變換的排程。 相依服務必須準備好處理立即和定期的變換。 我們建議使用專為此用途而建置的專用程式庫,例如 azure-activedirectory-identitymodel-extensions-for-dotnet。 如需詳細資訊,請參閱在 Microsoft Entra ID 中簽署金鑰變換

探索 Microsoft Entra ID 中繼資料

提供者也需要擷取Microsoft Entra ID 的公開金鑰,以驗證 Microsoft Entra ID 所簽發的權杖。

Microsoft Entra ID 中繼資料探索端點:

  • 全域 Azure:https://login.microsoftonline.com/common/v2.0/.well-known/openid-configuration
  • 適用於美國政府的 Azure:https://login.microsoftonline.us/common/v2.0/.well-known/openid-configuration
  • 由 21Vianet 營運的 Microsoft Azure:https://login.partner.microsoftonline.cn/common/v2.0/.well-known/openid-configuration

使用權杖的公開金鑰識別碼 (來自 JSON Web 簽章 (JWS) 的“kid”),可以判斷從 jwks_uri 屬性擷取的金鑰應該用來驗證 Microsoft Entra ID 權杖簽章。

驗證 Microsoft Entra ID 所簽發的權杖

如需如何驗證 Microsoft Entra ID 所簽發權杖的資訊,請參閱驗證和識別碼權杖。 我們的探索中繼資料取用者沒有特殊步驟。

Microsoft的 權杖驗證程式庫具有所記錄權杖驗證細節的所有詳細資料,或可從瀏覽原始程式碼中確定。 如需範例,請參閱 Azure 範例

驗證成功之後,您可以使用宣告承載來取得使用者及其租用戶的詳細資料。

注意

請務必驗證 id_token_hint,以確保 id_token_hint 來自 Microsoft 租用戶,且代表您的整合。 應該完整驗證 id_token_hint,特別是簽章、簽發者、對象以及其他宣告值。

外部識別提供者的 Microsoft Entra ID 呼叫

Microsoft Entra ID 會使用 OIDC 隱含流程與外部識別提供者通訊。 使用此流程時,會使用提供者的授權端點,以獨佔方式與提供者通訊。 為了讓提供者知道 Microsoft Entra ID 針對哪個使用者發出要求,Microsoft Entra ID 會透過 id_token_hint 參數傳入權杖。

此呼叫是透過 POST 要求進行,因為傳遞至提供者的參數清單很大。 大型清單可防止使用限制 GET 要求長度的瀏覽器。

下表列出驗證要求參數。

注意

除非它們列在下表中,否則提供者應該忽略要求中的其他參數。

驗證查詢參數 Description
範圍 (scope) openid
response_type Id_token 用於隱含流程的值。
response_mode form_post 我們使用表單 POST 來避免大型 URL 的問題。 我們預期所有參數都會在要求本文中傳送。
client_id 外部識別提供者提供給 Microsoft Entra ID 的用戶端識別碼,例如 ABCD。 如需詳細資訊,請參閱外部驗證方法描述
redirect_url 外部識別提供者傳送回應 (id_token_hint) 的目標重新導向統一資源識別項 (URI)。
請參閱這個表格後面的範例
nonce Microsoft Entra ID 所產生的隨機字串。 它可以是工作階段識別碼。 如果提供,則必須在回應中傳回至 Microsoft Entra ID。
state 如果傳入,則提供者應該在其回應中傳回狀態。 Microsoft Entra ID 會使用狀態來保留呼叫的相關內容。
id_token_hint 由 Microsoft Entra ID 針對終端使用者所簽發的權杖,並針對提供者的優點傳入。
claims 包含所要求宣告的 JSON Blob。 如需此參數格式的詳細資訊,請參閱 OIDC 文件中的宣告要求參數,以及此資料表之後的範例
client-request-id GUID 值 提供者可以記錄此值,以協助針對問題進行疑難排解。

重新導向 URI 的範例

重新導向統一資源識別項 (URI) 應該向提供者頻外註冊。 可傳送的重新導向 URI 如下:

  • 全域 Azure:https://login.microsoftonline.com/common/federation/externalauthprovider
  • 適用於美國政府的 Azure:https://login.microsoftonline.us/common/federation/externalauthprovider
  • 由 21Vianet 營運的 Microsoft Azure:https://login.partner.microsoftonline.cn/common/federation/externalauthprovider

滿足 MFA 的 EAM 範例

以下是 EAM 滿足 MFA 的驗證範例。 此範例可協助提供者知道 Microsoft Entra ID 預期的宣告。

Microsoft Entra ID 會使用 acramr 值的組合進行驗證:

  • 用於第二個因素的驗證方法符合 MFA 需求
  • 驗證方法與用來完成登入 Microsoft Entra ID 之第一個因素的方法不同
{
  "id_token": {
    "acr": {
      "essential": true,
      "values":["possessionorinherence"]
    },
    "amr": {
      "essential": true,
      "values": ["face", "fido", "fpt", "hwk", "iris", "otp", "pop", "retina", "sc", "sms", "swk", "tel", "vbm"]
    }
  }
}

預設 Id_token_hint 宣告

本節描述在對提供者發出的要求中,傳遞為 id_token_hint 權杖的必要內容。 權杖可能包含比下表更多的宣告。

索賠 Description
iss 識別建構並傳回權杖的 Security Token Service (STS),以及在其中驗證使用者的 Microsoft Entra ID 租用戶。 您的應用程式應該使用宣告的 GUID 部分來限制可登入應用程式的租用戶集合 (如果有的話)。 簽發者應符合使用者所登入租用戶之 OIDC 探索 JSON 中繼資料的簽發者 URL。
aud 對象應設定為外部識別提供者的用戶端識別碼,以取得 Microsoft Entra ID。
exp 過期時間設定為在發行時間之後的短時間內過期,足以避免時間扭曲問題。 由於此權杖並非用於驗證,因此其有效性期限沒有理由超過要求。
iat 如常設定發行時間。
tid 租用戶識別碼用於將租用戶公告給提供者。 它代表使用者所來自的 Microsoft Entra ID 租用戶。
oid Microsoft 身分識別平台中物件的不可變識別碼。 在此情況下,它是使用者帳戶。 它也可用來安全地執行授權檢查,以及做為資料庫資料表中的索引鍵。 此識別碼可跨應用程式唯一識別使用者。 登入相同使用者的兩個不同應用程式會在 oid 宣告中收到相同的值。 因此,oid 可用於查詢 Microsoft 線上服務,例如 Microsoft Graph。
preferred_username 提供人類看得懂的值,用以識別權杖的主體。 此值不保證是租用戶中的唯一值,並且應該僅用於顯示目的。
sub 簽發者終端使用者的主體識別碼。 權杖判斷提示其相關資訊的主體,例如應用程式的使用者。 這個值不可變,而且無法重新指派或重複使用。 它可用來安全地執行授權檢查 (例如當權杖用於存取資源時),並可做為資料庫資料表中的索引鍵。 由於主體一律是存在於 Microsoft Entra ID 所簽發的權杖中,因此建議您在一般用途的授權系統中使用此值。 不過,主體是成對識別碼,對於特定應用程式識別碼來說,主體是唯一的。 因此,如果單一使用者使用兩個不同的用戶端識別碼登入兩個不同的應用程式,則這些應用程式會收到兩個不同的主體宣告值。 視您的架構和隱私權需求而定,此結果不一定是您想要的。 另請參閱 oid 宣告 (這確實會在租用戶內的應用程式中保持不變)。

若要防止它用於提示以外的任何項目,權杖會發出為過期。 權杖已簽署,且可以使用已發佈的 Microsoft Entra ID 探索中繼資料進行驗證。

來自 Microsoft Entra ID 的選擇性宣告

如果提供者需要來自 Microsoft Entra ID 的選擇性宣告,您可以為 id_token 設定下列選擇性宣告:given_name、、family_namepreferred_usernameupn。 如需詳細資訊,請參閱選擇性宣告

Microsoft 建議使用 oid 和 tid 宣告,將提供者端的帳戶與 Azure AD 中的帳戶建立關聯。 這兩個宣告保證對租用戶中的帳戶而言是唯一的。

id_token_hint 的範例

以下是目錄成員的 id_token_hint 範例:

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

以下是租用戶中來賓使用者的 id_token 提示範例:

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


外部識別提供者的建議動作

我們建議外部識別提供者完成這些步驟。 此清單並不詳盡,且提供者應該在其認為適合時完成其他驗證步驟。

  1. 從要求:
  2. 來自 id_token_hint 中的宣告:
    • 他們可以選擇性地呼叫 Microsoft Graph,以擷取此使用者的其他詳細資料。 id_token_hint 中的 oidtid 宣告在這方面很有用。 如需 id_token_hint 中所提供宣告的詳細資訊,請參閱預設 id_token_hint 宣告
  3. 然後執行提供者產品所建置以執行的任何其他驗證活動。
  4. 根據使用者動作的結果和其他因素,提供者接著會建構回應並傳回至 Microsoft Entra ID,如下一節所述。

提供者回應的 Microsoft Entra ID 處理

提供者需要將回應「張貼」回 redirect_uri。 應該在成功的回應上提供下列參數:

參數 數值 Description
id_token 外部識別提供者所發出的權杖。
state 在要求中傳遞的相同狀態 (如果有的話)。 否則,這個值不應該存在。

成功時,提供者會針對使用者發出 id_token。 Microsoft Entra ID 會使用已發佈的 OIDC 中繼資料來驗證權杖是否包含預期的宣告,並執行 OIDC 所需權杖的任何其他驗證。

索賠 Description
iss 簽發者 – 必須符合提供者探索中繼資料的簽發者。
aud 對象 – Microsoft Entra ID 用戶端識別碼。 請參閱 Microsoft Entra ID 對外部識別提供者的呼叫中的 client_id。
exp 過期時間 – 如常設定。
iat 發行時間 – 如常設定。
sub 主體 – 必須符合所傳送 id_token_hint 的 sub,才能起始此要求。
nonce 在要求中傳遞的相同 nonce。
acr 驗證要求的 acr 宣告。 此值應該符合傳送至起始此要求之要求中的其中一個值。 應該只傳回一個 acr 宣告。 如需宣告清單,請參閱支援的 acr 宣告
amr 用於驗證中驗證方法的 amr 宣告。 此值應該以陣列的形式傳回,且應該只傳回一個方法宣告。 如需宣告清單,請參閱支援的 amr 宣告
支援的 acr 宣告
索賠 備註
possessionorinherence 驗證必須以擁有或固有為基礎的因素進行。
knowledgeorpossession 驗證必須以知識或擁有為基礎的因素進行。
knowledgeorinherence 驗證必須以知識或固有為基礎的因素進行。
knowledgeorpossessionorinherence 驗證必須以知識或擁有或固有為基礎的因素進行。
知識 驗證必須以知識為基礎的因素進行。
擁有 驗證必須以擁有為基礎的因素進行。
固有 驗證必須以固有為基礎的因素進行。
支援的 amr 宣告
索賠 備註
face 使用臉部辨識進行生物特徵辨識
fido FIDO2 已使用
fpt 使用指紋進行生物特徵辨識
hwk 擁有硬體安全金鑰的證明
iris 使用虹膜掃描進行生物特徵辨識
otp 單次密碼
pop 擁有權證明
retina 使用視網膜掃描進行生物特徵辨識
sc 智慧卡
sms 透過文字確認為已註冊號碼
swk 確認是否有軟體安全金鑰
tel 透過電話確認
vbm 使用聲紋進行生物特徵辨識

Microsoft Entra ID 需要滿足 MFA 才能發出具有 MFA 宣告的權杖。 因此,只有具有不同類型的方法才能滿足第二個因素需求。 如先前所述,可用來滿足第二個因素的不同方法類型是知識、擁有和固有。

Microsoft Entra ID 會根據下表驗證類型對應。

Claim 方法 類型 備註
face 固有 使用臉部辨識進行生物特徵辨識
fido 擁有 FIDO2 已使用。 某些實作可能也需要生物特徵辨識,但會對應擁有方法類型,因為它是主要安全性屬性。
fpt 固有 使用指紋進行生物特徵辨識
hwk 擁有 擁有硬體安全金鑰的證明
iris 固有 使用虹膜掃描進行生物特徵辨識
otp 擁有 一次密碼
pop 擁有 擁有權證明
retina 固有 使用視網膜掃描進行生物特徵辨識
sc 擁有 智慧卡
sms 擁有 透過文字確認為已註冊號碼
swk 擁有 軟體安全金鑰是否存在證明
tel 擁有 透過電話確認
vbm 固有 使用聲紋進行生物特徵辨識

如果找不到任何權杖問題,則 Microsoft Entra ID 會視為滿足 MFA,並將權杖發行給終端使用者。 否則,終端使用者的要求會失敗。

失敗會以發出錯誤回應參數來表示。

參數 數值 Description
錯誤 ASCII 錯誤碼,例如 access_denied 或 temporarily_unavailable。

如果回應中存在 id_token 參數,且權杖有效,則 Microsoft Entra ID 會視為要求成功。 否則,要求會被視為失敗。 由於條件式存取原則的需求,導致 Microsoft Entra ID 原始驗證嘗試失敗。

Microsoft Entra ID 會在重新導向至提供者大約 5 分鐘後,放棄驗證嘗試的狀態。

Microsoft Entra ID 錯誤回應處理

Microsoft Azure 服務會使用 correlationId,將各種內部和外部系統的呼叫相互關聯。 它可用作整個作業或流程的通用識別碼,這些識別碼可能牽涉到多個 HTTP 呼叫。 在任何作業期間發生錯誤時,回應會包含名為相互關聯識別碼的欄位。

當您連絡 Microsoft支援服務或類似的服務時,請提供此相互關聯識別碼的值,因為它有助於更快速地存取遙測和記錄。

例如:

ENTRA IDSTS70002︰驗證認證時發生錯誤。 ENTRA IDSTS50012:來自簽發者 'https://sts.XXXXXXXXX.com/auth/realms/XXXXXXXXXmfa' 的外部 ID 權杖未能通過簽章驗證。 權杖的 KeyID 是 'A1bC2dE3fH4iJ5kL6mN7oP8qR9sT0u' 追蹤識別碼:0000aaaa-11bb-cccc-dd22-eeeeee333333 相互關聯識別碼:aaaa0000-bb11-2222-33cc-444444dddddd 時間戳記:2023-07-24 16:51:34Z

自訂控制項和 EAM

在 Microsoft Entra ID 中,EAM 和條件式存取自訂控制項可以在客戶準備並移轉至 EAM 時平行運作。

目前使用自訂控制項與外部提供者整合的客戶可以繼續使用它們,以及他們設定用來管理存取的任何條件式存取原則。 建議系統管理員在移轉期間建立一組平行的條件式存取原則:

  • 原則應該使用 [需要多重要素驗證] 授與控制項,而不是自訂控制項授與。

    注意

    EAM 無法滿足於根據驗證強度來授與控制項,包括內建 MFA 強度。 原則應該只使用 [需要多重要素驗證] 來設定。 我們正積極努力支援具有驗證強度的 EAM。

  • 新的原則可以先使用使用者子集進行測試。 測試群組會從需要自訂控制項的原則中排除,並包含在需要 MFA 的原則中。 一旦系統管理員熟悉 EAM 所滿足需要 MFA 的原則之後,系統管理員便可以使用 MFA 授與,在原則中包含所有必要使用者,而針對自訂控制項設定的原則可以移至 [關閉]

整合支援

如果您在建置 EAM 與 Microsoft Entra ID 整合時發生任何問題,Microsoft 客戶體驗工程 (CxE) 獨立解決方案廠商 (ISV) 或許可以提供協助。 若要與 CxE ISV 小組互動,請提交協助要求

參考資料

詞彙

詞彙 描述
MFA 多重要素驗證。
EAM 外部驗證方法是來自 Microsoft Entra ID 以外提供者的驗證方法,用作驗證使用者的一部分。
OIDC Open ID Connect 是以 OAuth 2.0 為基礎的驗證通訊協定。
00001111-aaaa-2222-bbbb-3333cccc4444 針對外部驗證方法整合的 appid 範例。

下一步

如需如何在 Microsoft Entra 系統管理中心設定 EAM 的詳細資訊,請參閱在 Microsoft 中管理外部驗證方法 (預覽版)