共用方式為


從同盟移轉至 Microsoft Entra 憑證式驗證 (CBA)

此文章說明如何使用 Microsoft Entra 憑證式驗證 (CBA),從執行中的同盟伺服器 (例如 Active Directory 同盟服務 (AD FS) 內部部署) 移轉至雲端驗證。

分段推出

租用戶系統管理員可以不用試驗測試,直接將聯邦網域完全轉移至 Microsoft Entra CBA。 在 Microsoft Entra ID 中啟用 CBA 驗證方法,並將整個網域轉換為受控驗證。 不過,如果客戶想要在完整網域移轉至受控狀態之前,測試少數使用者是否可使用 Microsoft Entra CBA 進行驗證,他們就可以使用分段推出功能。

憑證型驗證 (CBA) 的分段推出可協助客戶選擇性地將一小組使用者轉為使用 Microsoft Entra ID (不再重新導向至同盟 IdP),並搭配選取的使用者群組,然後將 Microsoft Entra ID 中的網域設定從同盟轉換成受控,藉此從在同盟 IdP 上執行 CBA 轉換到 Microsoft Entra ID。 分段推出並非專為網域長時間或大量使用者保持同盟而設計。

觀看此快速影片,示範從 ADFS 憑證型驗證移轉至 Microsoft Entra CBA

注意

為使用者啟用分段推出時,用戶會被視為受控使用者,且所有驗證都會發生在Microsoft Entra ID。 針對同盟租戶,如果在分段推出中啟用 CBA,則只有在啟用 PHS 時,密碼驗證才有效。 否則,密碼驗證會失敗。

在您的租用戶上啟用憑證式驗證的分段推出

提示

根據您開始使用的入口網站,本文中的步驟可能略有不同。

若要設定分段推出,請遵循下列步驟:

  1. 至少以使用者系統管理員的身分登入 Microsoft Entra 系統管理中心
  2. 搜尋並選取 [Microsoft Entra Connect]
  3. 在 [Microsoft Entra Connect] 頁面上的 [雲端驗證分段推出] 底下,選取 為受控使用者登入啟用分段推出
  4. [啟用分段推出 功能] 頁面上,針對 [憑證式驗證] 選項選取 [on] 選項
  5. 選取 管理群組,然後新增您想加入以成為雲端驗證一部分的群組。 若要避免逾時,請確認安全性群組一開始不包含超過 200 位成員。

如需詳細資訊,請參閱分段推出

使用 Microsoft Entra Connect 更新 certificateUserIds 屬性

AD FS 系統管理員可以使用 [同步處理規則編輯器] 來建立規則,以將屬性的值從 AD FS 同步處理至 Microsoft Entra 使用者物件。 如需詳細資訊,請參閱 certificateUserIds 的同步處理規則 (部分機器翻譯)。

Microsoft Entra Connect 需要名為「混合式身分識別管理員」的特殊角色,其能授與必要的權限。 您需要此角色,以取得寫入新雲端屬性的權限。

注意

如果使用者使用同步處理的屬性,例如使用者名稱系結的用戶物件中的 onPremisesUserPrincipalName 屬性,則任何具有Microsoft Entra Connect 伺服器系統管理存取權的使用者都可以變更同步處理的屬性對應,並變更同步處理屬性的值。 使用者不需要是雲端管理員。AD FS 系統管理員應確定Microsoft Entra Connect 伺服器的系統管理存取權應受到限制,而特殊許可權帳戶應為僅限雲端帳戶。

關於從 AD FS 移轉至 Microsoft Entra ID 的常見問題

同盟 AD FS 伺服器是否可以有具特殊權限的帳戶?

雖然可以,但 Microsoft 建議讓具特殊權限的帳戶是僅限雲端的帳戶。 使用僅限雲端的帳戶來進行具特殊權限的存取,可以限制 Microsoft Entra ID 暴露在遭入侵之內部部署環境的程度。 如需詳細資訊,請參閱保護 Microsoft 365 免遭內部部署攻擊

如果組織採取同時執行 AD FS 與 Azure CBA 的混合式方式,其是否仍然容易受到 AD FS 入侵的影響?

Microsoft 建議讓具特殊權限的帳戶是僅限雲端的帳戶。 這種做法會減少 Microsoft Entra ID 在已遭入侵的內部部署環境中的暴露風險。 將具特殊權限的帳戶保持為僅限雲端,是達成此目標的基礎作法。

針對已同步處理的帳戶:

  • 如果其位於受控網域 (非同盟),則不會有任何來自同盟 IdP 的風險。
  • 如果其位於同盟網域,但帳戶的子集正透過分段推出移至 Microsoft Entra CBA,則其會面臨與同盟 Idp 相關的風險,直到同盟網域完全切換至雲端驗證為止。

組織是否應該排除 AD FS 之類的同盟伺服器,防止從 AD FS 跳躍至 Azure 的功能?

透過同盟,攻擊者可以模擬任何人 (例如 CIO),即使他們無法取得如高全線管理員帳戶的僅限雲端角色也一樣。

在 Microsoft Entra ID 中與某個網域建立同盟時,必須對同盟 IdP 採取高度的信任。 AD FS 只是其中一個範例,但此概念同樣也適用於「任何」同盟 IdP。 許多組織都會特別部署同盟 IdP (例如 AD FS) 來達成憑證式驗證。 在此情況下,Microsoft Entra CBA 會完全移除 AD FS 相依性。 透過 Microsoft Entra CBA,客戶可以將應用程式資產移至 Microsoft Entra ID,以將其 IAM 基礎結構現代化,並在降低成本的同時提升安全性。

從安全性觀點來看,認證 (包括 X.509 憑證、CAC、PIV 等等) 本身或是所使用的 PKI 並不會有任何變更。 PKI 擁有者會保留憑證發行和撤銷生命週期和原則的完整控制權。 撤銷檢查和驗證會在 Microsoft Entra ID 發生,而不是同盟 IdP。 這些檢查可以直接針對 Microsoft Entra ID 為所有使用者提供無密碼且防網路釣魚的驗證。

驗證如何搭配 Windows 與同盟 AD FS 和 Microsoft Entra 雲端驗證運作?

Microsoft Entra CBA 要求使用者或應用程式提供登入使用者的 Microsoft Entra UPN。

在瀏覽器範例中,使用者最常輸入其 Microsoft Entra UPN。 Microsoft Entra UPN 是用於領域和使用者探索。 所使用的憑證必須符合此使用者,方法是透過原則中設定的其中一個使用者名稱繫結。

在 Windows 登入中,該比對會取決於裝置是混合式還是已加入 Microsoft Entra。 但在這兩種情況下,如果提供用戶名稱提示,Windows 會將提示傳送為Microsoft Entra UPN。 所使用的憑證必須符合此使用者,方法是透過原則中設定的其中一個使用者名稱繫結。

下一步