外部標識子的驗證和條件式存取

提示

本文適用於 B2B 共同作業和 B2B 直接連線。 如果您的租用戶已針對客戶身分識別和存取管理進行設定,請參閱 Microsoft Entra 外部 ID 中的安全性和控管。

當外部使用者存取您組織中的資源時,驗證流程取決於共同作業方法(B2B 共同作業或 B2B 直接連線)、使用者的識別提供者(外部 Microsoft Entra 租使用者、社交識別提供者等)、條件式存取原則,以及 使用者主租使用者和租使用者主控資源中設定的跨租使用者存取設定

本文說明存取組織中資源的外部用戶驗證流程。 組織可以為其外部使用者強制執行多個條件式存取原則,其可在租使用者、應用程式或個別用戶層級強制執行,其方式與為全職員工和組織成員啟用相同。

外部 Microsoft Entra 使用者的驗證流程

下圖說明當 Microsoft Entra 組織與其他 Microsoft Entra 組織的使用者共用資源時,驗證流程。 此圖顯示跨租使用者存取設定如何搭配條件式存取原則運作,例如多重要素驗證,以判斷使用者是否可以存取資源。 此流程適用於 B2B 共同作業和 B2B 直接連線,但如步驟 6 中所述。

顯示跨租使用者驗證程序的圖表。

步驟 描述:
1 Fabrikam 的使用者(使用者 的主租使用者)會起始登入 Contoso 中的資源( 資源租使用者)。
2 登入期間,Microsoft Entra 安全性令牌服務 (STS) 會評估 Contoso 的條件式存取原則。 它也會藉由評估跨租使用者存取設定來檢查 Fabrikam 使用者是否允許存取 (Fabrikam 的輸出設定和 Contoso 的輸入設定)。
3 Microsoft Entra ID 會檢查 Contoso 的輸入信任設定,以查看 Contoso 是否信任來自 Fabrikam 的 MFA 和裝置宣告(裝置合規性、Microsoft Entra 混合式聯結狀態)。 如果沒有,請跳至步驟 6。
4 如果 Contoso 信任 Fabrikam 的 MFA 和裝置宣告,Microsoft Entra ID 會檢查使用者的驗證會話,指出使用者已完成 MFA。 如果 Contoso 信任 Fabrikam 的裝置資訊,Microsoft Entra ID 會在驗證會話中尋找宣告,指出裝置狀態(符合規範或已加入 Microsoft Entra 混合式)。
5 如果需要 MFA 但未完成,或未提供裝置宣告,Microsoft Entra ID 會視需要在使用者的主租用戶中發出 MFA 和裝置挑戰。 在 Fabrikam 中滿足 MFA 和裝置需求時,使用者可以存取 Contoso 中的資源。 如果無法滿足檢查,則會封鎖存取。
6 當未設定信任設定,且需要 MFA 時,系統會提示 B2B 共同作業用戶輸入 MFA。 他們需要滿足資源租使用者中的 MFA。 B2B 直接連線用戶會封鎖存取。 如果需要裝置合規性,但無法評估,B2B 共同作業和 B2B 直接連線用戶都會封鎖存取。

如需詳細資訊,請參閱 外部用戶 的條件式存取一節。

非 Azure AD 外部使用者的驗證流程

當 Microsoft Entra 組織以 Microsoft Entra 識別元以外的識別提供者與外部使用者共用資源時,驗證流程取決於使用者是使用身分識別提供者進行驗證,還是使用電子郵件單次密碼驗證。 在任一情況下,資源租用戶會識別要使用的驗證方法,然後將使用者重新導向至其識別提供者,或發出一次性密碼。

範例 1:非 Azure AD 外部使用者的驗證流程和令牌

下圖說明當外部使用者從非 Azure AD 身分識別提供者使用帳戶登入時,例如 Google、Facebook 或同盟 SAML/WS-Fed 身分識別提供者時,驗證流程。

此圖顯示來自外部目錄的 B2B 來賓用戶的驗證流程。

步驟 描述:
1 B2B 來賓使用者要求存取資源。 資源會將使用者重新導向至其資源租使用者,這是受信任的IdP。
2 資源租使用者會將用戶識別為外部使用者,並將使用者重新導向至 B2B 來賓使用者的 IdP。 使用者在IdP中執行主要驗證。
3 授權原則會在 B2B 來賓使用者的 IdP 中進行評估。 如果使用者滿足這些原則,B2B 來賓使用者的 IdP 會向用戶發出令牌。 用戶會重新導向回具有令牌的資源租使用者。 資源租用戶會驗證令牌,然後根據其條件式存取原則評估使用者。 例如,資源租使用者可能需要使用者執行 Microsoft Entra 多重要素驗證。
4 系統會評估輸入跨租使用者存取設定和條件式存取原則。 如果滿足所有原則,資源租用戶會發出自己的令牌,並將使用者重新導向至其資源。

範例 2:一次性密碼用戶的驗證流程和令牌

下圖說明啟用電子郵件單次密碼驗證,且外部使用者未透過其他方式進行驗證,例如 Microsoft Entra ID、Microsoft 帳戶(MSA)或社交識別提供者時,流程。

此圖顯示 B2B 來賓使用者具有單次密碼的驗證流程。

步驟 描述:
1 使用者要求存取另一個租使用者中的資源。 資源會將使用者重新導向至其資源租使用者,這是受信任的IdP。
2 資源租使用者會將用戶識別為外部電子郵件一次性密碼 (OTP) 使用者,並將具有 OTP 的電子郵件傳送給使用者。
3 使用者擷取 OTP 並提交程式代碼。 資源租用戶會根據其條件式存取原則來評估使用者。
4 一旦滿足所有條件式存取原則,資源租使用者就會發出令牌,並將使用者重新導向至其資源。

外部用戶的條件式存取

組織可以針對外部 B2B 共同作業和 B2B 直接連線用戶強制執行條件式存取原則,其方式與為組織的全職員工和成員啟用相同。 透過引進跨租使用者存取設定,您也可以信任來自外部 Microsoft Entra 組織的 MFA 和裝置宣告。 本節說明將條件式存取套用至組織外部使用者的重要考慮。

注意

具有條件式存取的自定義控件不支援跨租使用者信任。

將條件式存取原則指派給外部用戶類型

設定條件式存取原則時,您可以更細微地控制您想要套用原則的外部用戶類型。 外部用戶會根據其驗證方式(內部或外部)以及其與貴組織的關係(來賓或成員)進行分類。

  • B2B 共同作業來賓使用者 - 大部分被認為是來賓的使用者都屬於此類別。 此 B2B 共同作業使用者具有外部 Microsoft Entra 組織或外部身分識別提供者的帳戶(例如社交身分識別),而且他們在貴組織中具有來賓層級許可權。 在 Microsoft Entra 目錄中建立的用戶物件具有 Guest 的 UserType。 此類別包含受邀的 B2B 共同作業使用者,以及使用自助式註冊的使用者。
  • B2B 共同作業成員使用者 - 此 B2B 共同作業使用者具有外部 Microsoft Entra 組織或外部身分識別提供者(例如社交身分識別)和成員層級存取貴組織中資源的帳戶。 此案例常見於由多個租用戶組成的組織,其中使用者會被視為較大型組織的一部分,而且需要成員層級存取組織其他租使用者中的資源。 在資源 Microsoft Entra 目錄中建立的用戶物件具有 Member 的 UserType。
  • B2B 直接連線使用者 - 能夠透過 B2B 直接連線存取您資源的外部使用者,這是與另一個 Microsoft Entra 組織的相互雙向連線,可讓單一登錄存取特定 Microsoft 應用程式(目前為 Microsoft Teams 連線 共用頻道)。 B2B 直接連線使用者在您的 Microsoft Entra 組織中沒有存在,而是從應用程式內進行管理(例如,由 Teams 共用頻道擁有者管理)。
  • 本機來賓使用者 - 本機來賓使用者具有目錄中管理的認證。 在 Microsoft Entra B2B 共同作業可供使用之前,通常會藉由設定用戶物件 UserType 將 UserType 設定為來賓,來設定其內部認證,以與散發者、供貨商、廠商和其他人員共同作業。
  • 服務提供者使用者 - 做為貴組織雲端服務提供者的組織(Microsoft Graph 合作夥伴特定組態 中的 isServiceProvider 屬性為 true)。
  • 其他外部使用者 - 適用於任何不屬於這些類別但未被視為貴組織內部成員的使用者,這表示他們不會透過 Microsoft Entra 識別符在內部進行驗證,而且在資源 Microsoft Entra 目錄中建立的用戶對象沒有 Member 的 UserType。

注意

[所有來賓和外部使用者] 選項現在已取代為 [來賓和外部使用者] 及其所有子類型。 對於先前已選取 [所有來賓和外部使用者] 的 Condtional Access 原則的客戶,現在會看到 [來賓和外部使用者] 以及選取的所有子類型。 UX 中的這項變更對條件式存取後端評估原則的方式沒有任何功能影響。 新的選取專案可讓客戶在建立其條件式存取原則時,選擇來賓和外部使用者的規格類型,以在使用者範圍中包含/排除。

深入了解 條件式存取使用者指派

比較外部標識符條件式存取原則

下表提供 Microsoft Entra 外部 ID 中安全策略和合規性選項的詳細比較。 安全策略和合規性是由條件式存取原則下的主機/邀請組織所管理。

原則 B2B 共同作業使用者 B2B 直接連線使用者
授與控件 — 封鎖存取 支援 支援
授與控件 - 需要多重要素驗證 支援 支援,需要設定輸入 信任設定 以接受來自外部組織的 MFA 宣告
授與控件 - 需要符合規範的裝置 支援時,需要設定輸入 信任設定 ,以接受來自外部組織的相容裝置宣告。 支援時,需要設定輸入 信任設定 ,以接受來自外部組織的相容裝置宣告。
授與控件 - 需要 Microsoft Entra 混合式已加入裝置 支援,需要設定輸入 信任設定 以接受來自外部組織的 Microsoft Entra 混合式已加入裝置宣告 支援,需要設定輸入 信任設定 以接受來自外部組織的 Microsoft Entra 混合式已加入裝置宣告
授與控制項 - 需要核准的用戶端應用程式 不支援 不支援
授與控件 - 需要應用程式保護原則 不支援 不支援
授與控件 - 需要變更密碼 不支援 不支援
授與控件 - 使用規定 支援 不支援
工作階段控制項 ─ 使用應用程式強制執行的限制 支援 不支援
工作階段控制檔 ─ 使用條件式存取應用程控 支援 不支援
會話控件 - 登入頻率 支援 不支援
會話控件 - 持續性瀏覽器會話 支援 不支援

Microsoft Entra 外部使用者的 MFA

在 Microsoft Entra 跨租使用者案例中,資源組織可以建立條件式存取原則,要求所有來賓和外部使用者的 MFA 或裝置合規性。 一般而言,需要 B2B 共同作業使用者存取資源,才能使用資源租用戶設定其 Microsoft Entra 多重要素驗證。 不過,Microsoft Entra 識別碼現在提供信任來自其他 Microsoft Entra 租使用者的 MFA 宣告的能力。 使用另一個租用戶啟用 MFA 信任可簡化 B2B 共同作業使用者的登入程式,並啟用 B2B 直接連線使用者的存取。

如果您將輸入信任設定設定設定為接受來自 B2B 共同作業或 B2B 直接連線使用者主租使用者的 MFA 宣告,Microsoft Entra ID 會檢查使用者的驗證會話。 如果會話包含宣告,指出使用者主租使用者中已符合 MFA 原則,則會將用戶順暢地登入您的共享資源。

如果未啟用 MFA 信任,則 B2B 共同作業使用者和 B2B 直接連線使用者的使用者體驗不同:

  • B2B 共同作業使用者:如果資源組織未對使用者的主租用戶啟用 MFA 信任,則會向使用者顯示來自資源組織的 MFA 挑戰。 (流程與 非 Azure AD 外部使用者的 MFA 流程。

  • B2B 直接連線使用者:如果資源組織未對使用者的主租用戶啟用 MFA 信任,則會封鎖使用者存取資源。 如果您想要允許 B2B 與外部組織直接連線,而您的條件式存取原則需要 MFA,您必須設定輸入信任設定以接受來自組織的 MFA 宣告。

深入瞭解如何 設定 MFA 的輸入信任設定。

非 Azure AD 外部使用者的 MFA

對於非 Azure AD 外部使用者,資源租使用者一律負責 MFA。 下列範例顯示典型的 MFA 流程。 此案例適用於任何身分識別,包括 Microsoft 帳戶 (MSA) 或社交標識符。 當您未使用其主 Microsoft Entra 組織設定信任設定時,此流程也適用於 Microsoft Entra 外部使用者。

  1. 名為 Fabrikam 的公司中的系統管理員或資訊工作者邀請另一家名為 Contoso 的公司的使用者使用 Fabrikam 的應用程式。

  2. Fabrikam 的應用程式已設定為在存取時要求 Microsoft Entra 多重要素驗證。

  3. 當 Contoso 的 B2B 共同作業用戶嘗試存取 Fabrikam 的應用程式時,系統會要求他們完成 Microsoft Entra 多重要素驗證挑戰。

  4. 然後,來賓使用者可以使用 Fabrikam 設定其 Microsoft Entra 多重要素驗證,然後選取選項。

Fabrikam 必須有足夠的進階 Microsoft Entra ID 授權,才能支援 Microsoft Entra 多重要素驗證。 Contoso 的用戶接著會從 Fabrikam 取用此授權。 如需 B2B 授權的相關信息,請參閱 Microsoft Entra 外部 ID 計費模型。

注意

MFA 會在資源租用完成,以確保可預測性。 當來賓使用者登入時,他們會看到背景中顯示的資源租使用者登入頁面,以及前景中自己的主租使用者登入頁面和公司標誌。

適用於 B2B 共同作業使用者的 Microsoft Entra 多重要素驗證重設 (證明)

下列 PowerShell Cmdlet 可用來 向 B2B 共同作業用戶證明 或要求 MFA 註冊。

注意

自 2024 年 3 月 30 日起,Azure AD 和 MSOnline PowerShell 模組已被淘汰。 若要深入了解,請閱讀淘汰更新。 在此日期之後,對這些模組的支援僅限於對 Microsoft Graph PowerShell SDK 的移轉協助和安全性修正。 淘汰的模組將繼續運作至 2025 年 3 月 30 日。

我們建議移轉至 Microsoft Graph PowerShell 以與 Microsoft Entra ID (以前稱為 Azure AD) 互動。 如需了解常見的移轉問題,請參閱移轉常見問題注意:MSOnline 1.0.x 版可能會在 2024 年 6 月 30 日之後發生中斷。

  1. 連線 至 Microsoft Entra 識別碼:

    $cred = Get-Credential
    Connect-MsolService -Credential $cred
    
  2. 使用證明方法取得所有使用者:

    Get-MsolUser | where { $_.StrongAuthenticationMethods} | select UserPrincipalName, @{n="Methods";e={($_.StrongAuthenticationMethods).MethodType}}
    

    例如:

    Get-MsolUser | where { $_.StrongAuthenticationMethods} | select UserPrincipalName, @{n="Methods";e={($_.StrongAuthenticationMethods).MethodType}}
    
  3. 重設特定使用者的 Microsoft Entra 多重要素驗證方法,要求使用者再次設定證明方法,例如:

    Reset-MsolStrongAuthenticationMethodByUpn -UserPrincipalName gsamoogle_gmail.com#EXT#@ WoodGroveAzureAD.onmicrosoft.com
    

外部使用者的驗證強度原則

驗證強度是條件式訪問控制,可讓您定義外部用戶必須完成存取資源的特定多重要素驗證方法組合。 此控件特別適用於限制組織內敏感性應用程式的外部存取,因為您可以針對外部使用者強制執行特定的驗證方法,例如網路釣魚防護方法。

您也可以將驗證強度套用至您共同作業或連線的不同 來賓或外部使用者 類型。 這表示您可以強制執行 B2B 共同作業、B2B 直接連線和其他外部存取案例特有的驗證強度需求。

Microsoft Entra ID 提供三 項內建驗證強度

  • 多重要素驗證強度
  • 無密碼 MFA 強度
  • 網路釣魚防護 MFA 強度

您可以使用下列其中一個內建強度,或根據您想要要求的驗證方法建立自定義驗證強度原則。

注意

目前,您只能將驗證強度原則套用至使用 Microsoft Entra ID 進行驗證的外部使用者。 針對電子郵件一次性密碼、SAML/WS-Fed 和 Google 同盟使用者,請使用 MFA 授與控件來要求 MFA。

當您將驗證強度原則套用至外部 Microsoft Entra 使用者時,此原則會與跨租使用者存取設定中的 MFA 信任設定搭配運作,以判斷外部使用者必須執行 MFA 的位置和方式。 Microsoft Entra 使用者會先在主租使用者 Microsoft Entra 租使用者中使用自己的帳戶進行驗證。 然後,當使用者嘗試存取您的資源時,Microsoft Entra ID 會套用驗證強度條件式存取原則,並檢查您是否已啟用 MFA 信任。

在外部使用者案例中,滿足驗證強度可接受的驗證方法會因使用者正在主租使用者或資源租使用者中完成 MFA 而有所不同。 下表指出每個租使用者中可接受的方法。 如果資源租用戶選擇信任來自外部 Microsoft Entra 組織的宣告,則資源租使用者只接受 「首頁租使用者」數據行中所列的宣告以進行 MFA 履行。 如果資源租使用者停用 MFA 信任,外部用戶必須使用 「資源租使用者」數據行中列出的其中一種方法,在資源租使用者中完成 MFA。

資料表 1。 外部使用者的驗證強度 MFA 方法
驗證方法 主租使用者 資源租使用者
SMS 作為第二個因素
語音通話
Microsoft Authenticator 推播通知
Microsoft Authenticator 電話登入
OATH 軟體權杖
OATH 硬體權杖
FIDO2 安全性金鑰
Windows Hello 企業版
憑證型驗證

若要設定將驗證強度需求套用至外部使用者或來賓的條件式存取原則,請參閱 條件式存取:需要外部使用者的驗證強度。

外部 Microsoft Entra 使用者的用戶體驗

驗證強度原則會與跨租使用者存取設定中的 MFA 信任設定搭配運作,以判斷外部使用者必須執行 MFA 的位置和方式。

首先,Microsoft Entra 使用者會在自己的主租使用者中使用自己的帳戶進行驗證。 然後,當使用者嘗試存取您的資源時,Microsoft Entra ID 會套用驗證強度條件式存取原則,並檢查您是否已啟用 MFA 信任。

  • 如果啟用 MFA 信任,Microsoft Entra ID 會檢查使用者的驗證會話是否有宣告,指出使用者主租使用者中已完成 MFA。 (請參閱 表 1 :在外部使用者主租使用者中完成時,MFA 履行可接受的驗證方法。如果會話包含宣告,指出使用者主租使用者中已符合 MFA 原則,且方法符合驗證強度需求,則允許使用者存取。 否則,Microsoft Entra 標識符會向使用者提出挑戰,要求使用可接受的驗證方法在主租使用者中完成 MFA。 MFA 方法必須在主租用戶中啟用,而且用戶必須能夠註冊它。
  • 如果停用 MFA 信任,Microsoft Entra ID 會向使用者提出挑戰,以使用可接受的驗證方法在資源租使用者中完成 MFA。 (請參閱 表 1 用於外部使用者可接受 MFA 履行的驗證方法。

如果用戶無法完成 MFA,或條件式存取原則(例如符合規範的裝置原則)會阻止他們註冊,則會封鎖存取。

裝置合規性和 Microsoft Entra 混合式已加入裝置原則

組織可以使用條件式存取原則,要求 Microsoft Intune 管理使用者的裝置。 這類原則可能會封鎖外部使用者存取,因為外部用戶無法向資源組織註冊其非受控裝置。 裝置只能由使用者的主租使用者管理。

不過,您可以使用裝置信任設定來解除封鎖外部使用者,同時仍需要受管理的裝置。 在跨租使用者存取設定中,您可以選擇信任來自外部使用者主租使用者的宣告,以瞭解用戶的裝置是否符合其裝置合規性政策,還是 已加入 Microsoft Entra 混合式。 您可以為所有 Microsoft Entra 組織或個別組織設定裝置信任設定。

啟用裝置信任設定時,Microsoft Entra ID 會檢查使用者的驗證會話是否有裝置宣告。 如果會話包含裝置宣告,指出已在使用者的主租使用者中符合原則,外部使用者就會獲得您共用資源的無縫登錄。

重要

  • 除非您願意信任來自外部使用者主租使用者之裝置合規性或 Microsoft Entra 混合式加入狀態的宣告,否則不建議套用需要外部使用者使用受控裝置的條件式存取原則。

裝置篩選

為外部使用者建立條件式存取原則時,您可以根據 Microsoft Entra ID 中已註冊裝置的裝置屬性來評估原則。 藉由使用裝置條件的篩選條件,您可以使用支援的運算符和屬性,以及條件式存取原則中的其他可用指派條件,以特定裝置為目標。

裝置篩選可以與跨租使用者存取設定搭配使用,以在其他組織中管理的裝置上根據原則。 例如,假設您想要根據特定裝置屬性封鎖來自外部 Microsoft Entra 租使用者的裝置。 您可以採取下列步驟來設定裝置屬性型原則:

  • 設定您的跨租使用者存取設定,以信任來自該組織的裝置宣告。
  • 將您想要用於篩選的裝置屬性指派給其中 一個支援的裝置擴充屬性
  • 使用裝置篩選條件建立條件式存取原則,以封鎖對包含該屬性之裝置的存取。

深入瞭解使用 條件式存取篩選裝置。

行動應用程式管理原則

我們不建議為外部使用者要求應用程式保護原則。 條件式存取授與控件,例如 [需要核准的 用戶端應用程式] 和 [要求應用程式保護原則 ] 要求裝置在資源租用戶中註冊。 這些控制項只能套用至 iOS 和 Android 裝置。 由於使用者的裝置只能由其主租使用者管理,因此這些控件無法套用至外部來賓使用者。

以位置為基礎的條件式存取

如果邀請組織可以建立定義其合作夥伴組織的受信任 IP 位址範圍,則可以強制執行以 IP 範圍為基礎的位置型原則。

您也可以根據 地理位置強制執行原則。

風險型條件式存取

如果外部來賓用戶滿足授與控件,則會強制執行登入風險原則。 例如,組織可能需要 Microsoft Entra 多重要素驗證,才能有中度或高登入風險。 不過,如果使用者先前尚未在資源租用戶中註冊 Microsoft Entra 多重要素驗證,則會封鎖使用者。 這樣做是為了防止惡意用戶註冊自己的 Microsoft Entra 多重要素驗證認證,以防他們入侵合法的用戶密碼。

不過,無法在 資源租用戶中解決用戶風險原則。 例如,如果您需要對高風險外部來賓用戶進行密碼變更,則會因為無法重設資源目錄中的密碼而遭到封鎖。

條件式存取用戶端應用程式條件

用戶端應用程式條件 對 B2B 來賓用戶的行為與任何其他類型用戶的行為相同。 例如,您可以防止來賓使用者使用舊版驗證通訊協定。

條件式存取會話控件

會話控件 對於 B2B 來賓用戶的行為與任何其他類型用戶的行為相同。

身分識別保護和用戶風險原則

Identity Protection 會偵測 Microsoft Entra 使用者的遭入侵認證,並將可能遭到入侵的使用者帳戶標示為「有風險」。身為資源租使用者,您可以將用戶風險原則套用至外部使用者,以封鎖有風險的登入。對於外部使用者,用戶風險會在其主目錄進行評估。 這些使用者嘗試存取資源時,會在資源目錄中評估這些用戶的即時登入風險。 不過,由於外部使用者的身分識別存在於其主目錄中,以下是限制:

  • 如果外部使用者觸發 Identity Protection 使用者風險原則來強制重設密碼,則會遭到封鎖,因為它們無法在資源組織中重設其密碼。
  • 資源組織有風險的用戶報告不會反映外部使用者,因為風險評估發生在外部使用者的主目錄中。
  • 資源組織中的 管理員 無法關閉或補救有風險的外部使用者,因為它們無法存取 B2B 使用者的主目錄。

您可以在 Microsoft Entra 識別碼中建立包含所有組織外部使用者的群組,以防止以風險為基礎的原則影響外部使用者。 然後,將此群組新增為內建 Identity Protection 用戶風險和登入風險原則的排除專案,以及使用登入風險作為條件的任何條件式存取原則。

如需詳細資訊,請參閱 Identity Protection 和 B2B 使用者

下一步

如需詳細資訊,請參閱下列文章: