共用方式為

MFA 伺服器移轉

  • 發行項

本主題說明如何將 Microsoft Entra 使用者的 MFA 設定，從內部部署 Azure MFA 伺服器移轉至 Microsoft Entra 多重要素驗證。

解決方案概觀

MFA 伺服器移轉公用程式可協助將儲存在內部部署 Azure MFA 伺服器中的多重要素驗證資料，直接同步至 Microsoft Entra 多重要素驗證。 將驗證資料移轉至 Microsoft Entra ID 之後，使用者就可以順暢地執行雲端式 MFA，不需要再次註冊或確認驗證方法。 系統管理員可以使用 MFA 伺服器移轉公用程式，以單一使用者或使用者群組為目標進行測試和控制推出，而不需要進行任何全租用戶變更。

影片：如何使用 MFA 伺服器移轉公用程式

請觀看我們的影片，以了解 MFA 伺服器移轉公用程式概觀及其運作方式。

限制和需求

  • MFA 伺服器移轉公用程式需要您在主要 MFA 伺服器上安裝 MFA 伺服器解決方案的新組建。 該組建會對 MFA 伺服器資料檔案進行更新，並包含新的 MFA 伺服器移轉公用程式。 您不需要更新 WebSDK 或使用者入口網站。 安裝更新「不會」自動開始移轉。

    注意

    MFA 伺服器移轉公用程式可以在次要 MFA 伺服器上執行。 如需詳細資訊，請參閱執行次要 MFA 伺服器 (選用)。

  • MFA 伺服器移轉公用程式會將資料庫檔案中的資料複製到 Microsoft Entra ID 中的使用者物件。 在移轉期間，使用者可以成為 Microsoft Entra 多重要素驗證的目標，以測試使用分段推出。 分段移轉可讓您進行測試，而不需要對網域同盟設定進行任何變更。 移轉完成之後，您必須對網域同盟設定進行變更，以完成移轉。

  • 執行 Windows Server 2016 或更高版本的 AD FS 必須在 Microsoft Entra ID 和 Office 365 以外的所有 AD FS 信賴憑證者上提供 MFA 驗證。

  • 檢閱您的 AD FS 存取控制原則，並確定任一原則在驗證過程中都不需要在內部部署環境中執行 MFA。

  • 分段推出最多能以 500,000 位使用者為目標 (10 個群組，每個群組最多 50,000 位使用者)。

移轉指南

階段 步驟
準備 找出 Azure Multi-Factor Authentication 伺服器相依性
備份 Azure Multi-Factor Authentication 伺服器資料檔案
安裝 MFA 伺服器更新
設定 MFA 伺服器移轉公用程式
移轉 移轉使用者資料
驗證和測試
分段推出
教育使用者
完成使用者移轉
Finalize 移轉 MFA 伺服器相依性
更新網域同盟設定
停用 MFA 伺服器使用者入口網站
解除委任 MFA 伺服器

MFA 伺服器移轉通常包含下列程序中的步驟：

MFA 伺服器移轉階段圖。

幾個重點如下︰

當您新增測試使用者時，應該重複階段 1。

  • 移轉工具會使用 Microsoft Entra 群組來判斷應在 MFA 伺服器和 Microsoft Entra多重要素驗證之間同步驗證資料的使用者。 同步使用者資料之後，該使用者即何隨時使用 Microsoft Entra 多重要素驗證。
  • 分段推出可讓您將使用者重新路由至 Microsoft Entra 多重要素驗證，也可使用 Microsoft Entra 群組。 雖然您確實可以在這兩個工具中使用相同的群組，但不建議您這麼做；因為在工具同步使用者的資料之前，使用者就可能已被重新導向至 Microsoft Entra 多重要素驗證。 建議您設定一系列專供 MFA 伺服器移轉公用程式同步驗證資料的 Microsoft Entra 群組，並另設定一系列供分段推出使用的群組，以將目標使用者導向至 Microsoft Entra 多重要素驗證而非內部部署環境。

當您移轉使用者基底時，應該重複階段 2。 在階段 2 結束時，您的整個使用者基底應該會使用 Microsoft Entra 多重要素驗證處理所有依 Microsoft Entra ID 同盟的工作負載。

在前面的階段中，您可以移除各個分段推出資料夾中的使用者，將其從 Microsoft Entra 多重要素驗證的範圍中移出，再路由回源自 Microsoft Entra ID 之所有 MFA 要求的內部部署 Azure MFA 伺服器。

階段 3 需要透過 SAML/OAUTH，將所有向內部部署 MFA 伺服器驗證的用戶端 (VPN、密碼管理員等等) 移至 Microsoft Entra 同盟。 如果不支援新式驗證標準，您必須設定已安裝 Microsoft Entra 多重要素驗證延伸模組的 NPS 伺服器。 移轉相依性之後，使用者就不該再使用 MFA 伺服器上的使用者入口網站，而該使用 Microsoft Entra ID 管理其驗證方法 (aka.ms/mfasetup)。 一旦使用者開始使用 Microsoft Entra ID 管理驗證資料，這些方法就不會同步回 MFA 伺服器。 如果您在使用者變更其 Microsoft Entra ID 中的驗證方法後，復原至內部部署 MFA 伺服器，這些變更將會遺失。 完成使用者移轉之後，請變更 federatedIdpMfaBehavior 網域同盟設定。 該變更會告訴 Microsoft Entra ID 不要再於內部部署環境中執行 MFA，以使用 Microsoft Entra 多重要素驗證執行「所有」MFA 要求，無論群組成員資格為何。

下列各節將更詳細說明移轉步驟。

找出 Azure Multi-Factor Authentication 伺服器相依性

我們努力確保移至雲端式 Microsoft Entra 多重要素驗證解決方案將會維持，甚至改善您的安全性態勢。 您應該使用三種廣泛類別來分組相依性：

為了協助您移轉，我們比對了廣泛使用的 MFA 伺服器功能與每種類別的 Microsoft Entra 多重要素驗證對等功能。

MFA 方法

開啟 MFA 伺服器，按一下 [公司設定]：

公司設定的螢幕擷取畫面。

MFA Server Microsoft Entra 多重要素驗證
General Tab
[使用者預設值] 區段
電話 (標準) 不需採取動作
簡訊 (OTP)* 不需採取動作
行動裝置應用程式 (標準) 不需採取動作
電話 (PIN)* 啟用語音 OTP
簡訊 (OTP + PIN)** 不需採取動作
行動裝置應用程式 (PIN)* 啟用數字比對
電話/簡訊/行動裝置應用程式/OATH 權杖語言 語言設定會根據使用者瀏覽器中的地區設定自動套用至使用者
[預設 PIN 規則] 區段 不適用；請參閱上述螢幕擷取畫面中的更新方法
[使用者名稱解析] 索引標籤 不適用，Microsoft Entra 多重要素驗證不需要解析使用者名稱
[簡訊] 索引標籤 不適用，Microsoft Entra 多重要素驗證會使用預設的文字訊息
[OATH 權杖] 索引標籤 不適用，Microsoft Entra 多重要素驗證會使用預設的 OATH 權杖訊息
報表 Microsoft Entra 驗證方法活動報告

*使用 PIN 提供存在證明功能時，會提供以上對等功能。 未以密碼編譯方式繫結至裝置的 PIN 將不足以防範裝置遭到入侵的情況。 若要防範這些情況 (包括 SIM 交換攻擊)，請根據 Microsoft 驗證方法最佳做法，將使用者移至更安全的方法。

**Microsoft Entra 多重要素驗證的預設 MFA 簡訊體驗會向使用者傳送代碼，使用者必須在驗證過程中，將此代碼輸入登入視窗。 代碼往返的需求提供了存在證明功能。

使用者入口網站

開啟 MFA 伺服器，按一下 [使用者入口網站]：

使用者入口網站的螢幕擷取畫面。

MFA Server Microsoft Entra 多重要素驗證
[設定] 索引標籤
使用者入口網站 URL aka.ms/mfasetup
允許使用者註冊 請參閱合併安全性資訊註冊
- 提示輸入備用電話 請參閱 MFA 服務設定
- 提示輸入協力廠商 OATH 權杖 請參閱 MFA 服務設定
允許使用者起始單次許可 請參閱 Microsoft Entra ID TAP 功能
允許使用者選取方法 請參閱 MFA 服務設定
- 電話 請參閱電話文件
- 簡訊 請參閱 MFA 服務設定
- 行動裝置應用程式 請參閱 MFA 服務設定
- OATH 權杖 請參閱 OATH 權杖文件
允許使用者選取語言 語言設定會根據使用者瀏覽器中的地區設定自動套用至使用者
允許使用者啟用行動應用程式 請參閱 MFA 服務設定
- 裝置限制 Microsoft Entra ID 將使用者限制為每位使用者累計五部裝置 (行動裝置應用程式執行個體 + 硬體 OATH 權杖 + 軟體 OATH 權杖)
使用遞補用的安全性問題 如果選擇的驗證方法失敗，Microsoft Entra ID 可讓使用者在驗證時選擇遞補方法
- 要回答的問題 Microsoft Entra ID 中的安全性問題只能用於 SSPR。 如需詳細資訊，請參閱 Microsoft Entra 自訂安全性問題
允許使用者關聯協力廠商 OATH 權杖 請參閱 OATH 權杖文件
使用遞補用的 OATH 權杖 請參閱 OATH 權杖文件
工作階段逾時
[安全性問題] 索引標籤 MFA 伺服器中的安全性問題是用來取得使用者入口網站的存取權。 Microsoft Entra 多重要素驗證僅支援供自助式密碼重設使用的安全性問題。 請參閱安全性問題文件。
[已通過的工作階段] 索引標籤 所有驗證方法註冊流程都是由 Microsoft Entra ID 管理，而且不需要設定
信任的 IP Microsoft Entra ID 信任的 IP

MFA 伺服器中可用的任何 MFA 方法都必須使用 MFA 服務設定以 Microsoft Entra 多重要素驗證啟用。 除非已啟用，否則使用者無法嘗試其新移轉的 MFA 方法。

驗證服務

Azure MFA 伺服器可作為驗證 Proxy，為使用 RADIUS 或 LDAP 的協力廠商解決方案提供 MFA 功能。 若要探索 RADIUS 或 LDAP 相依性，請按一下 MFA 伺服器中的 [RADIUS 驗證] 和 [LDAP 驗證] 選項。 針對每個相依性，請判斷這些協力廠商是否支援新式驗證。 如果是，請考慮直接與 Microsoft Entra ID 建立同盟。

對於無法升級的 RADIUS 部署，您必須部署 NPS 伺服器並安裝 Microsoft Entra 多重要素驗證 NPS 延伸模組。

對於無法升級或移至 RADIUS 的 LDAP 部署，請判斷是否可以使用 Microsoft Entra Domain Services。 在大多數情況下，已部署 LDAP 來支援終端使用者的內嵌密碼變更。 移轉之後，終端使用者可以使用 Microsoft Entra ID 中的自助式密碼重設來管理密碼。

如果您在除了 Office 365 信賴憑證者信任以外的任何信賴憑證者信任上，啟用了 AD FS 2.0 中的 MFA 伺服器驗證提供者，您必須升級至 AD FS 3.0，或直接讓這些信賴憑證者與 Microsoft Entra ID 建立同盟 (如果這些信賴憑證者支援新式驗證方法)。 判斷每個相依性的最佳行動計畫。

備份 Azure Multi-Factor Authentication 伺服器資料檔案

在您的主要 MFA 伺服器上，針對位於 %programfiles%\Multi-Factor Authentication Server\Data\PhoneFactor.pfdata (預設位置) 的 MFA 伺服器資料檔案製作備份。 如果您需要復原，請確定您有目前安裝版本的安裝程式複本。 如果您不再擁有複本，請連絡客戶支援服務。

視使用者活動而定，資料檔案可能會很快過期。 系統不會擷取備份之後對 MFA 伺服器所做的任何變更，或透過入口網站所做的任何終端使用者變更。 如果復原，將不會還原此點之後所做的任何變更。

安裝 MFA 伺服器更新

在主要 MFA 伺服器上執行新的安裝程式。 升級伺服器之前，請確保該伺服器目前未與其他 MFA 伺服器進行負載平衡或共用流量。 您不需解除安裝目前的 MFA 伺服器，就能執行安裝程式。 安裝程式會使用目前的安裝路徑 (例如 C:\Program Files\Multi-Factor Authentication Server) 執行就地升級。 如果系統提示您安裝 Microsoft Visual C++ 2015 可轉散發套件的更新套件，請接受提示。 隨即會同時安裝套件的 x86 和 x64 版本。 不需要針對使用者入口網站、Web SDK 或 AD FS 配接器安裝更新。

注意

在主要伺服器上執行安裝程式之後，次要伺服器可能會開始記錄未處理的 SB 項目。 這是由於次要伺服器無法辨識在主要伺服器上所做的結構描述變更所致。 預期會發生這些錯誤。 在擁有 10,000 位使用者 (含) 以上的環境中，記錄項目的數量可能會大幅增加。 若要減輕此問題，您可以增加 MFA 伺服器記錄的檔案大小，或升級次要伺服器。

設定 MFA 伺服器移轉公用程式

安裝 MFA 伺服器更新之後，請開啟提升權限的 PowerShell 命令提示字元：將游標暫留在 PowerShell 圖示上，按一下滑鼠右鍵，然後按一下 [以系統管理員身分執行]。 執行在 MFA 伺服器安裝目錄 (預設為 C:\Program Files\Multi-factor Authentication Server) 中找到的 .\Configure-MultiFactorAuthMigrationUtility.ps1 指令碼。

此指令碼會要求您提供 Microsoft Entra 租用戶中應用程式系統管理員的認證。 指令碼接著會在 Microsoft Entra ID 內建立新的 MFA 伺服器移轉公用程式應用程式，以用來將使用者驗證方法寫入至每個 Microsoft Entra 使用者物件。

若是想要執行移轉的政府雲端客戶，請將指令碼中的 ".com" 項目取代為 ".us"。 此指令碼接著會寫入 HKLM:\SOFTWARE\WOW6432Node\Positive Networks\PhoneFactor\ StsUrl 和 GraphUrl 登錄項目，並指示移轉公用程式使用適當的 GRAPH 端點。

您也需要存取下列 URL：

  • https://graph.microsoft.com/* (若是政府雲端客戶，則為 https://graph.microsoft.us/*)
  • https://login.microsoftonline.com/* (若是政府雲端客戶，則為 https://login.microsoftonline.us/*)

此指令碼會指示您對新建立的應用程式授與管理員同意。 瀏覽至提供的 URL，或在 Microsoft Entra 系統管理中心內，按一下 [應用程式註冊]，尋找並選取 [MFA 伺服器移轉公用程式] 應用程式，按一下 [API 權限]，然後授與適當的權限。

權限的螢幕擷取畫面。

完成後，請瀏覽至 Multi-Factor Authentication Server 資料夾，然後開啟 MultiFactorAuthMigrationUtilityUI 應用程式。 您應該會看見下列畫面：

MFA 伺服器移轉公用程式的螢幕擷取畫面。

您已成功安裝移轉公用程式。

注意

為確保移轉期間的行為無任何變更，當您的 MFA 伺服器與不參考任何租用戶的 MFA 提供者相關聯時，您必須更新要移轉之租用戶的預設 MFA 設定 (例如自訂的問候語)，使符合 MFA 提供者的設定。 建議在移轉任何使用者之前先執行此作業。

執行次要 MFA 伺服器 (選用)

如果您的 MFA 伺服器實作有大量使用者或主要 MFA 伺服器非常忙碌，您可以考慮部署專用的次要 MFA 伺服器來執行 MFA 伺服器移轉公用程式和移轉同步服務。 升級主要 MFA 伺服器之後，請升級現有的次要伺服器或部署新的次要伺服器。 您選擇的次要伺服器不應該處理其他 MFA 流量。

Configure-MultiFactorAuthMigrationUtility.ps1 指令碼應該在次要伺服器上執行，以在 MFA 伺服器移轉公用程式應用程式註冊中註冊憑證。 憑證會用來向 Microsoft Graph 驗證。 在次要 MFA 伺服器上執行移轉公用程式和同步服務，應同時改善手動和自動使用者移轉的效能。

移轉使用者資料

移轉使用者資料不會移除或改變 Multi-Factor Authentication Server 資料庫中的任何資料。 同樣地，此程序不會變更使用者執行 MFA 的位置。 此程序會將內部部署伺服器的資料單向複製到 Microsoft Entra ID 中的對應使用者物件。

MFA 伺服器移轉公用程式會針對所有移轉活動以單一 Microsoft Entra 群組為目標。 您可以直接將使用者新增至此群組，或新增其他群組。 您也可以在移轉期間分階段新增使用者。

若要開始移轉程序，請輸入您要移轉之 Microsoft Entra 群組的名稱或 GUID。 完成後，請按 Tab 鍵或在視窗外按一下，開始搜尋適當的群組。 群組中的所有用戶都會填入。 大型群組可能需要幾分鐘的時間才能完成。

若要檢視使用者的屬性資料，請醒目提示使用者，然後選取 [檢視]：

如何檢視使用者設定的螢幕擷取畫面。

此視窗會顯示 Microsoft Entra ID 和內部部署 MFA 伺服器中所選使用者的屬性。 在使用者移轉之後，您可以使用此視窗來檢視資料是如何寫入的。

[設定] 選項可讓您變更移轉程序的設定：

設定的螢幕擷取畫面。

  • 移轉，有三個選項可用來移轉使用者的預設驗證方法：

    • 一律移轉
    • 只有尚未在 Microsoft Entra ID 中設定時才移轉
    • 如果尚未在 Microsoft Entra ID 中設定，則設定為可用的最安全方法

    當您移轉預設方法時，這些選項可提供彈性。 此外，移轉期間還會檢查驗證方法原則。 如果原則不允許移轉預設方法，則改設定為可用的最安全方法。

  • 使用者比對，可讓您指定不同的內部部署 Active Directory 屬性用以比對 Microsoft Entra UPN，而不是預設比對 userPrincipalName：

    • 移轉公用程式會先嘗試直接比對 UPN，再使用內部部署的 Active Directory 屬性比對。
    • 如果找不到相符項，即會呼叫 Windows API 尋找 Microsoft Entra UPN，並取得 SID 用以搜尋 MFA 伺服器使用者清單。
    • 如果 Windows API 找不到使用者，或 MFA 伺服器中找不到 SID，則會使用設定的 Active Directory 屬性在內部部署 Active Directory 中尋找使用者，然後使用 SID 搜尋 MFA 伺服器使用者清單。

  • 自動同步處理，啟動背景服務，以持續監視內部部署 MFA 伺服器中使用者的任何驗證方法變更，並在定義的指定時間間隔內將其寫入至 Microsoft Entra ID。

  • 同步處理伺服器，允許 MFA 伺服器移轉同步服務在次要 MFA 伺服器上執行，而不是只在主要伺服器上執行。 若要設定移轉同步服務在次要伺服器上執行，則 Configure-MultiFactorAuthMigrationUtility.ps1 指令碼必須在該伺服器上執行，以在 MFA 伺服器移轉公用程式應用程式註冊中註冊憑證。 憑證會用來向 Microsoft Graph 驗證。

移轉程序可為自動或手動。

手動程式步驟如下：

  1. 若要開始某位使用者或所選多位使用者的移轉程序，請按住 Ctrl 鍵，同時選取您想要移轉的每位使用者。

  2. 選取所需的使用者之後，請按一下 [移轉使用者]>[選取的使用者]>[確定]。

  3. 若要移轉群組中的所有使用者，請按一下 [移轉使用者]>[Microsoft Entra 群組中的所有使用者]>[確定]。

  4. 即使使用者未變更，您也可以移轉使用者。 根據預設，公用程式會設定為僅移轉已變更的使用者。 按一下 [移轉所有使用者]，重新移轉之前已移轉的未變更使用者。 當系統管理員需要重設使用者的 Azure MFA 設定，又想要重新移轉這些設定時，在測試期間移轉未變更的使用者會很有用。

    [移轉使用者] 對話方塊的螢幕擷取畫面。

如需自動程序，請按一下 [設定] 中的 [自動同步處理]，然後選取您要同步所有使用者，還是只同步指定 Microsoft Entra 群組的成員。

下表列出各種方法的同步邏輯。

方法 邏輯
手機 如果沒有延伸模組，請更新 MFA 電話。
如果有延伸模組，請更新 Office 電話。
例外狀況：如果預設方法是簡訊，請卸除延伸模組並更新 MFA 電話。
備份手機 如果沒有延伸模組，請更新替代電話。
如果有延伸模組，請更新 Office 電話。
例外狀況：如果電話和備份電話都有延伸模組，請略過備份電話。
行動應用程式 最多會移轉五部裝置；如果使用者也有硬體 OATH 權杖，則只會移轉四部。
如果有多部同名的裝置，則只會移轉最新的裝置。
裝置會從最新排到最舊。
裝置如已在 Microsoft Entra ID 中，請比對 OATH 權杖祕密金鑰並更新。
- 如果 OATH 權杖祕密金鑰沒有相符項目，請比對裝置權杖
-- 如果找到，請為 MFA 伺服器裝置建立軟體 OATH 權杖，以允許 OATH 權杖方法運作。 使用現有的 Microsoft Entra 多重要素驗證裝置，通知仍可作用。
-- 如果找不到，請建立新的裝置。
如果新增的裝置將超過五部裝置的限制，則會略過裝置。
OATH 權杖 裝置如已在 Microsoft Entra ID 中，請比對 OATH 權杖祕密金鑰並更新。
- 如果找不到，請新增硬體 OATH 權杖裝置。
如果新增的裝置將超過五部裝置的限制，則會略過 OATH 權杖。

MFA 方法會根據已移轉的項目來進行更新，並會設定預設方法。 MFA 伺服器會追蹤上次移轉時間戳記，並只在使用者的 MFA 設定變更或系統管理員於 [設定] 對話方塊中修改要移轉的項目時，才會再次移轉使用者。

在測試期間，建議先執行手動移轉，並進行測試以確保指定數目的使用者行為符合預期。 測試成功之後，請針對想要移轉的 Microsoft Entra 群組開啟自動同步。 當您將使用者新增至此群組時，其資訊會自動同步至 Microsoft Entra ID。 MFA 伺服器移轉公用程式會以一個 Microsoft Entra 群組為目標，但該群組可以同時包含使用者和巢狀的使用者群組。

完成後，會出現確認通知您工作已完成：

確認的螢幕擷取畫面。

如確認訊息中所述，移轉的資料可能需要幾分鐘的時間才會出現在 Microsoft Entra ID 內的使用者物件上。 使用者可以瀏覽至 aka.ms/mfasetup 檢視其移轉方法。

提示

如果不需要檢視 Microsoft Entra MFA 方法，則可縮短顯示群組所需要的時間。 按一下 [檢視]>[Azure AD MFA 方法]，切換顯示 [AAD 預設]、[AAD 手機]、[AAD 替代]、[AAD 辦公室]、[AAD 裝置]、[AAD OATH 權杖] 等欄標籤。 隱藏欄標籤時會略過一些 Microsoft Graph API 呼叫，這可大幅縮短使用者載入時間。

檢視移轉詳細資料

您可以使用 [稽核記錄] 或 Log Analytics 來檢視 Azure MFA 使用者移轉的 MFA 伺服器詳細資料。

使用 [稽核記錄]

請遵循下列步驟存取 Microsoft Entra 系統管理中心的 [稽核記錄]，以檢視 Azure MFA 使用者移轉的 MFA 伺服器詳細資料：

  1. 至少要以驗證系統管理員的身分登入 Microsoft Entra 系統管理中心。

  2. 瀏覽至 [身分識別]>[監視和健康情況]>[稽核記錄]。 若要篩選記錄，請按一下 [新增篩選]。

    如何新增篩選的螢幕擷取畫面。

  3. 選取 [啟動者 (執行者)]，然後按一下 [套用]。

    [啟動者 (執行者] 選項的螢幕擷取畫面。

  4. 鍵入 Azure MFA Management，然後按一下 [套用]。

    MFA 管理選項的螢幕擷取畫面。

  5. 此篩選只會顯示 MFA 伺服器移轉公用程序記錄。 若要檢視使用者移轉的詳細資料，請按一下資料列，然後選擇 [已修改的屬性] 索引標籤。此索引標籤會顯示已註冊 MFA 方法和電話號碼的變更。

    使用者移轉詳細資料的螢幕擷取畫面。

    下表列出每個代碼的驗證方法。

    代碼 方法
    0 語音行動裝置
    2 語音辦公室
    3 語音備用行動電話
    5 SMS
    6 Microsoft Authenticator 推播通知
    7 硬體或軟體權杖 OTP

  6. 如已移轉任何使用者裝置，則會有個別的記錄項目。

    已移轉裝置的螢幕擷取畫面。

使用 Log Analytics

您也可以使用 Log Analytics 查詢 Azure MFA 使用者移轉的 MFA 伺服器詳細資料。

AuditLogs
| where ActivityDateTime > ago(7d)
| extend InitiatedBy = tostring(InitiatedBy["app"]["displayName"])
| where InitiatedBy == "Azure MFA Management"
| extend UserObjectId = tostring(TargetResources[0]["id"])
| extend Upn = tostring(TargetResources[0]["userPrincipalName"])
| extend ModifiedProperties = TargetResources[0]["modifiedProperties"]
| project ActivityDateTime, InitiatedBy, UserObjectId, Upn, ModifiedProperties
| order by ActivityDateTime asc

此螢幕擷取畫面顯示使用者移轉的變更：

已移轉使用者的 Log Analytics 螢幕擷取畫面。

此螢幕擷取畫面顯示裝置移轉的變更：

已移轉裝置的 Log Analytics 螢幕擷取畫面。

您也可以使用 Log Analytics 摘要使用者移轉活動。

AuditLogs
| where ActivityDateTime > ago(7d)
| extend InitiatedBy = tostring(InitiatedBy["app"]["displayName"])
| where InitiatedBy == "Azure MFA Management"
| extend UserObjectId = tostring(TargetResources[0]["id"])
| summarize UsersMigrated = dcount(UserObjectId) by InitiatedBy, bin(ActivityDateTime, 1d)

Log Analytics 摘要的螢幕擷取畫面。

驗證和測試

成功移轉使用者資料之後，您可以先使用分段推出來驗證終端使用者體驗，再進行全域租用戶變更。 下列程序可讓您以特定 Microsoft Entra 群組為目標，進行 MFA 的分段推出。 分段推出會通知 Microsoft Entra ID 對目標群組中的使用者使用 Microsoft Entra 多重要素驗證來執行 MFA，而不是將使用者傳送至內部部署環境執行 MFA。 您可以進行驗證和測試，建議您使用 Microsoft Entra 系統管理中心，但如果想要的話，也可以使用 Microsoft Graph。

啟用分段推出

  1. 瀏覽至下列 URL：啟用分段推出功能 - Microsoft Azure。

  2. 將 [Azure 多重要素驗證] 變更為 [開啟]，然後按一下 [管理群組]。

    分段推出的螢幕擷取畫面。

  3. 按一下 [新增群組]，然後新增群組，其中包含您想要為 Azure MFA 啟用的使用者。 選取的群組會出現在顯示的清單中。

    注意

    您使用下列 Microsoft Graph 方法設為目標的任何群組也會出現在此清單中。

    管理群組功能表的螢幕擷取畫面。

使用 Microsoft Graph 啟用分段推出

  1. 建立 featureRolloutPolicy

    1. 瀏覽至 aka.ms/ge，然後在您想要設定分段推出的租用戶中使用混合式身分識別系統管理員帳戶登入 Graph 總管。

    2. 確定選取以下列端點為目標的 POST：https://graph.microsoft.com/v1.0/policies/featureRolloutPolicies

    3. 您的要求本文應該包含下列內容 (請將 MFA 推出原則變更為您組織的名稱和描述)：

      {
     "displayName": "MFA rollout policy",
     "description": "MFA rollout policy",
     "feature": "multiFactorAuthentication",
     "isEnabled": true,
     "isAppliedToOrganization": false
}

      要求的螢幕擷取畫面。

    4. 使用相同端點執行 GET，並記下識別碼值 (在下圖中已劃掉)：

      GET 命令的螢幕擷取畫面。

  2. 以包含所想要測試使用者的 Microsoft Entra 群組為目標

    1. 使用下列端點建立 POST 要求 (請將 {ID of policy} 取代為您從步驟 1d 複製的識別碼值)：

      https://graph.microsoft.com/v1.0/policies/featureRolloutPolicies/{ID of policy}/appliesTo/$ref

    2. 要求本文應該包含下列內容 (請將 {ID of group} 取代為您想要設為分段推出目標的群組物件識別碼)：

      {
"@odata.id": "https://graph.microsoft.com/v1.0/directoryObjects/{ID of group}"
}

    3. 針對您想要設為分段推出目標的任何其他群組重複步驟 a 和 b。

    4. 您可以針對下列 URL 執行 GET 來檢視目前存在的原則：

      https://graph.microsoft.com/v1.0/policies/featureRolloutPolicies/{policyID}?$expand=appliesTo

      上述程序會使用 featureRolloutPolicy 資源。 公開文件尚未更新為新的 multifactorAuthentication 功能，但包含如何與 API 互動的詳細資訊。

  3. 確認終端使用者 MFA 體驗。 請檢查下列事項：

    1. 使用者是否在 aka.ms/mfasetup 中看到其方法？
    2. 使用者是否會接到電話/收到簡訊？
    3. 他們是否可以使用上述方法成功進行驗證？
    4. 使用者是否成功收到 Authenticator 通知？ 他們是否可以核准這些通知？ 驗證是否成功？
    5. 使用者是否可以使用硬體 OATH 權杖成功進行驗證？

教育使用者

確保使用者知道移至 Azure MFA 之後預期的情況，包括新的驗證流程。 您也可能想要指示使用者在移轉完成之後使用 Microsoft Entra ID 合併註冊入口網站 (aka.ms/mfasetup) 來管理其驗證方法，而不是使用者入口網站。 對 Microsoft Entra ID 中驗證方法所做的任何變更都不會傳播回您的內部部署環境。 如果您必須復原至 MFA 伺服器，使用者在 Microsoft Entra ID 中所做的任何變更都將無法在 MFA 伺服器使用者入口網站中使用。

如果您使用相依於 Azure MFA 伺服器的協力廠商解決方案進行驗證 (請參閱驗證服務)，您會希望使用者在使用者入口網站中繼續對其 MFA 方法進行變更。 這些變更將會自動同步至 Microsoft Entra ID。 移轉這些協力廠商解決方案之後，您就可以將使用者移至 Microsoft Entra ID 合併註冊頁面。

完成使用者移轉

重複移轉使用者資料以及驗證和測試小節中的移轉步驟，直到移轉所有使用者資料為止。

移轉 MFA 伺服器相依性

使用您在驗證服務中收集的資料點，開始執行各種必要的移轉。 完成此作業之後，請考慮讓使用者在合併註冊入口網站中管理其驗證方法，而不是在 MFA 伺服器上的使用者入口網站中。

更新網域同盟設定

完成使用者移轉並將所有驗證服務從 MFA 伺服器移出之後，就可以更新網域同盟設定。 更新之後，Microsoft Entra 就不會再將 MFA 要求傳送至您的內部部署同盟伺服器。

若要設定 Microsoft Entra ID 忽略對內部部署同盟伺服器的 MFA 要求，請安裝 Microsoft Graph PowerShell SDK，並將 federatedIdpMfaBehavior 設定為 rejectMfaByFederatedIdp，如下列範例所示。

要求

PATCH https://graph.microsoft.com/beta/domains/contoso.com/federationConfiguration/6601d14b-d113-8f64-fda2-9b5ddda18ecc
Content-Type: application/json
{
  "federatedIdpMfaBehavior": "rejectMfaByFederatedIdp"
}

回應

注意：為了方便閱讀，此處顯示的回應物件可能會縮短。

HTTP/1.1 200 OK
Content-Type: application/json
{
  "@odata.type": "#microsoft.graph.internalDomainFederation",
  "id": "6601d14b-d113-8f64-fda2-9b5ddda18ecc",
   "issuerUri": "http://contoso.com/adfs/services/trust",
   "metadataExchangeUri": "https://sts.contoso.com/adfs/services/trust/mex",
   "signingCertificate": "A1bC2dE3fH4iJ5kL6mN7oP8qR9sT0u",
   "passiveSignInUri": "https://sts.contoso.com/adfs/ls",
   "preferredAuthenticationProtocol": "wsFed",
   "activeSignInUri": "https://sts.contoso.com/adfs/services/trust/2005/usernamemixed",
   "signOutUri": "https://sts.contoso.com/adfs/ls",
   "promptLoginBehavior": "nativeSupport",
   "isSignedAuthenticationRequestRequired": true,
   "nextSigningCertificate": "A1bC2dE3fH4iJ5kL6mN7oP8qR9sT0u",
   "signingCertificateUpdateStatus": {
        "certificateUpdateResult": "Success",
        "lastRunDateTime": "2021-08-25T07:44:46.2616778Z"
    },
   "federatedIdpMfaBehavior": "rejectMfaByFederatedIdp"
}

無論使用者是否為分段推出工具的目標，都不會再將使用者重新導向至 MFA 的內部部署同盟伺服器。 請注意，這最多可能需要 24 小時才會生效。

注意

網域同盟設定的更新最多可能需要 24 小時才會生效。

停用 MFA 伺服器使用者入口網站

完成移轉所有使用者資料之後，終端使用者就可以開始使用 Microsoft Entra ID 合併註冊頁面來管理 MFA 方法。 有幾種方式可防止使用者使用 MFA 伺服器中的使用者入口網站：

  • 將 MFA 伺服器使用者入口網站 URL 重新導向至 aka.ms/mfasetup
  • 在 MFA 伺服器的 [使用者入口網站] 區段中，清除 [設定] 索引標籤下的 [允許使用者登入] 核取方塊，以防止任何使用者登入入口網站。

解除委任 MFA 伺服器

當您不再需要 Azure MFA 伺服器時，請遵循您的一般伺服器淘汰做法。 Microsoft Entra ID 中不需要採取任何特殊動作來指出 MFA 伺服器淘汰。

復原計畫

如果升級發生問題，請遵循下列步驟來復原：

  1. 解除安裝 MFA 伺服器 8.1。

  2. 將 PhoneFactor.pfdata 取代為升級之前所做的備份。

    注意

    自備份之後所做的任何變更都將會遺失，但如果升級之前剛進行備份且升級失敗，則遺失情況應該會降到最低。

  3. 執行舊版 (例如 8.0.x.x) 的安裝程式。

  4. 設定 Microsoft Entra ID 接受內部部署同盟伺服器的 MFA 要求。 使用 Graph PowerShell 將 federatedIdpMfaBehavior 設定為 enforceMfaByFederatedIdp，如下列範例所示。

    要求

    PATCH https://graph.microsoft.com/beta/domains/contoso.com/federationConfiguration/6601d14b-d113-8f64-fda2-9b5ddda18ecc
Content-Type: application/json
{
  "federatedIdpMfaBehavior": "enforceMfaByFederatedIdp"
}

    下列回應物件會縮短以增加可讀性。

    回應

    HTTP/1.1 200 OK
Content-Type: application/json
{
  "@odata.type": "#microsoft.graph.internalDomainFederation",
  "id": "6601d14b-d113-8f64-fda2-9b5ddda18ecc",
   "issuerUri": "http://contoso.com/adfs/services/trust",
   "metadataExchangeUri": "https://sts.contoso.com/adfs/services/trust/mex",
   "signingCertificate": "A1bC2dE3fH4iJ5kL6mN7oP8qR9sT0u",
   "passiveSignInUri": "https://sts.contoso.com/adfs/ls",
   "preferredAuthenticationProtocol": "wsFed",
   "activeSignInUri": "https://sts.contoso.com/adfs/services/trust/2005/usernamemixed",
   "signOutUri": "https://sts.contoso.com/adfs/ls",
   "promptLoginBehavior": "nativeSupport",
   "isSignedAuthenticationRequestRequired": true,
   "nextSigningCertificate": "A1bC2dE3fH4iJ5kL6mN7oP8qR9sT0u",
   "signingCertificateUpdateStatus": {
        "certificateUpdateResult": "Success",
        "lastRunDateTime": "2021-08-25T07:44:46.2616778Z"
    },
   "federatedIdpMfaBehavior": "enforceMfaByFederatedIdp"
}

將 Azure MFA 的分段推出 設定為 [關閉]。 這會再次將使用者重新導向至您的 MFA 內部部署同盟伺服器。

下一步