從同盟移轉至 Microsoft Entra 憑證式驗證 (CBA)
此文章說明如何使用 Microsoft Entra 憑證式驗證 (CBA)，從執行中的同盟伺服器 (例如 Active Directory 同盟服務 (AD FS) 內部部署) 移轉至雲端驗證。
分段推出
租用戶系統管理員可以在 Microsoft Entra ID 中啟用 CBA 驗證方法，並將整個網域轉換成受控驗證，以將完整同盟網域完全移至 Microsoft Entra 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 時才能運作，否則密碼驗證將會失敗。
在您的租用戶上啟用憑證式驗證的分段推出
提示
根據您開始使用的入口網站，本文中的步驟可能略有不同。
若要設定分段推出，請遵循下列步驟：
- 至少以使用者系統管理員的身分登入 Microsoft Entra 系統管理中心。
- 搜尋並選取 [Microsoft Entra Connect]。
- 在 [Microsoft Entra Connect] 頁面的 [分段引進雲端驗證] 下，按一下 [啟用受控使用者登入的分段推出]。
- 在 [啟用分段推出] 功能頁面上，按一下 [憑證式驗證] 選項的 [開啟]
- 按一下 [管理群組] 並新增您想要作為雲端驗證之一部分的群組。 若要避免逾時，請確認安全性群組一開始不包含超過 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 的形式傳送該提示。 所使用的憑證必須符合此使用者，方法是透過原則中設定的其中一個使用者名稱繫結。