共用方式為


MFA 伺服器移轉

本主題涵蓋如何將 Microsoft Entra 使用者的 MFA 設定從內部部署 Azure MFA Server 遷移至 Microsoft Entra 多重要素驗證。

解決方案概觀

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

影片:如何使用 MFA Server 移轉公用程式

查看我們的影片,以取得 MFA Server 移轉公用程式的概觀及其運作方式。

限制和需求

  • MFA 伺服器移轉公用程式需要新的 MFA Server 解決方案組建才能安裝在主要 MFA 伺服器上。 組建會更新 MFA Server 資料檔,並包含新的 MFA Server 移轉公用程式。 您不需要更新 WebSDK 或使用者入口網站。 安裝更新 不會 自動啟動移轉。

    注意

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

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

  • 執行 Windows Server 2016 或更高版本的 AD FS 必須提供任何 AD FS 信賴憑證者的 MFA 驗證,不包括 Microsoft Entra ID 和 Office 365。

  • 檢閱您的 AD FS 訪問控制原則,並確定沒有任何要求在內部部署執行 MFA 作為驗證程式的一部分。

  • 分段推出最多可以鎖定 500,000 個使用者(10 個群組,每個群組最多 50,000 個使用者)。

移轉指南

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

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

MFA 伺服器移轉階段的圖表。

一些重要要點:

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

  • 移轉工具會使用 Microsoft Entra 群組來判斷應該在 MFA Server 與 Microsoft Entra 多重要素驗證之間同步處理驗證數據的使用者。 同步處理用戶數據之後,該使用者便已準備好使用 Microsoft Entra 多重要素驗證。
  • 分段推出可讓您使用 Microsoft Entra 群組,將使用者重新路由傳送至 Microsoft Entra 多重要素驗證。 雖然您當然可以針對這兩個工具使用相同的群組,但建議您將其反對,因為使用者可能會在工具同步處理其數據之前重新導向至 Microsoft Entra 多重要素驗證。 建議設定 Microsoft Entra 群組,以便由 MFA 伺服器移轉公用程式同步處理驗證數據,以及另一組分段推出群組,以將目標用戶導向至 Microsoft Entra 多重要素驗證,而不是內部部署。

當您移轉使用者基底時,應該重複階段 2 。 在階段 2 結束時,您的整個使用者基底應該針對與 Microsoft Entra 識別元同盟的所有工作負載使用 Microsoft Entra 多重要素驗證。

在先前的階段中,您可以從分段推出資料夾移除使用者,使其脫離 Microsoft Entra 多重要素驗證的範圍,並針對源自 Microsoft Entra ID 的所有 MFA 要求,將它們路由回內部部署 Azure MFA 伺服器。

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

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

識別 Azure Multi-Factor Authentication Server 相依性

我們已努力確保移至雲端式 Microsoft Entra 多重要素驗證解決方案,以維持甚至改善您的安全性狀態。 有三個廣泛的類別應該用來將相依性分組:

為了協助您進行移轉,我們已將廣泛使用的 MFA Server 功能與每個類別的 Microsoft Entra 多重要素驗證中的功能對等專案進行比對。

MFA 方法

開啟 MFA Server,按兩下 [公司 設定

公司 設定的螢幕快照。

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 Server,按兩下 [使用者入口網站]:

使用者入口網站的螢幕快照。

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 Server 中的安全性問題可用來取得使用者入口網站的存取權。 Microsoft Entra 多重要素驗證僅支援自助式密碼重設的安全性問題。 請參閱 安全性問題檔
[傳遞的會話] 索引標籤 所有驗證方法註冊流程都是由 Microsoft Entra ID 管理,且不需要設定
受信任的IP Microsoft Entra ID 信任的 IP

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

驗證服務

Azure MFA Server 可以為使用 RADIUS 或 LDAP 的第三方解決方案提供 MFA 功能,方法是做為驗證 Proxy。 若要探索RADIUS或LDAP相依性,請按一下 MFA Server 中的 [RADIUS 驗證] 和 [LDAP 驗證] 選項。 針對每個相依性,判斷這些第三方是否支援新式驗證。 如果是,請考慮直接與 Microsoft Entra 識別符同盟。

針對無法升級的 RADIUS 部署,您必須部署 NPS 伺服器,並安裝 Microsoft Entra 多重要素驗證 NPS 擴充功能

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

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

備份 Azure Multi-Factor Authentication Server 數據檔

備份位於主要 MFA Server 上 %programfiles%\Multi-Factor Authentication Server\Data\電話 Factor.pfdata (預設位置)的 MFA Server 數據檔。 如果您需要復原,請確定您目前已安裝版本的安裝程序複本。 如果您不再有複本,請連絡客戶支持服務。

視用戶活動而定,數據檔可能會很快過時。 對 MFA Server 所做的任何變更,或不會擷取備份之後透過入口網站所做的任何用戶變更。 如果您復原,將不會還原此點之後所做的任何變更。

安裝 MFA Server 更新

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

注意

在主伺服器上執行安裝程序之後,輔助伺服器可能會開始記錄 未處理的 SB 專案。 這是因為在輔助伺服器無法辨識的主伺服器上所做的架構變更。 這些錯誤是預期的。 在有 10,000 位使用者以上的環境中,記錄項目數量可能會大幅增加。 若要減輕此問題,您可以增加 MFA Server 記錄的檔案大小,或升級輔助伺服器。

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

安裝 MFA Server 更新之後,開啟提升許可權的 PowerShell 命令提示字元:將滑鼠停留在 PowerShell 圖示上,按兩下滑鼠右鍵,然後按兩下 [以 管理員 istrator 執行]。 執行 MFA Server 安裝目錄中找到的 .\Configure-MultiFactorAuthMigrationUtility.ps1 腳本(預設為 C:\Program Files\Multi-Factor Authentication Server)。

此腳本會要求您提供 Microsoft Entra 租使用者中 Application 管理員 istrator 的認證。 然後,腳本會在 Microsoft Entra ID 內建立新的 MFA Server 移轉公用程式應用程式,以用來將使用者驗證方法寫入每個 Microsoft Entra 用戶物件。

對於想要執行移轉的政府雲端客戶,請將腳本中的「.com」專案取代為 “.us”。 此腳本接著會撰寫 HKLM:\SOFTWARE\WOW6432Node\Positive Networks\電話 Factor\ StsUrl 和 GraphUrl 登錄專案,並指示移轉公用程式使用適當的 GRAPH 端點。

您也需要存取下列 URL:

  • https://graph.microsoft.com/* (或 https://graph.microsoft.us/* 適用於政府雲端客戶)
  • https://login.microsoftonline.com/* (或 https://login.microsoftonline.us/* 適用於政府雲端客戶)

腳本會指示您將系統管理員同意授與新建立的應用程式。 流覽至提供的 URL,或在 Microsoft Entra 系統管理中心內,按兩下 [應用程式註冊],尋找並選取 MFA Server Migration Utility 應用程式,按兩下 [API 許可權 ],然後授與適當的許可權。

許可權的螢幕快照。

完成後,流覽至 Multi-Factor Authentication Server 資料夾,然後開啟 MultiFactorAuthMigrationUtilityUI 應用程式。 您應該會看到下列畫面:

MFA 伺服器移轉公用程式的螢幕快照。

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

注意

若要確保移轉期間的行為沒有變更,如果您的 MFA Server 與沒有租用戶參考的 MFA 提供者相關聯,您必須更新您要移轉之租用戶的預設 MFA 設定(例如自定義問候語),以符合 MFA 提供者中的設定。 建議您在移轉任何使用者之前執行這項操作。

執行次要 MFA 伺服器 (選擇性)

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

Configure-MultiFactorAuthMigrationUtility.ps1 腳本應該在輔助伺服器上執行,以向 MFA Server 移轉公用程式應用程式註冊註冊憑證。 憑證可用來向 Microsoft Graph 進行驗證。 在次要 MFA 伺服器上執行移轉公用程式和同步處理服務,應改善手動和自動化使用者移轉的效能。

移轉使用者資料

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

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

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

若要檢視使用者的屬性數據,請反白顯示使用者,然後選取 [ 檢視]:

如何檢視使用設定的螢幕快照。

此視窗會顯示 Microsoft Entra ID 和內部部署 MFA Server 中所選使用者的屬性。 您可以使用此視窗來檢視資料在移轉後寫入使用者的方式。

[設定] 選項可讓您變更移轉程式的設定:

設定的螢幕快照。

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

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

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

  • 使用者比對 – 可讓您指定不同的 內部部署的 Active Directory 屬性來比對 Microsoft Entra UPN,而不是與 userPrincipalName 的預設比對:

    • 移轉公用程式會先嘗試直接比對 UPN,再使用 內部部署的 Active Directory 屬性。
    • 如果找不到相符專案,它會呼叫 Windows API 來尋找 Microsoft Entra UPN 並取得 SID,其用來搜尋 MFA Server 使用者清單。
    • 如果 Windows API 找不到使用者或 MFA Server 中找不到 SID,則會使用已設定的 Active Directory 屬性來尋找 內部部署的 Active Directory 中的使用者,然後使用 SID 來搜尋 MFA Server 使用者清單。
  • 自動同步處理 – 啟動背景服務,以持續監視內部部署 MFA Server 中使用者的任何驗證方法變更,並在定義的指定時間間隔將它們寫入 Microsoft Entra ID。

  • 同步處理伺服器 – 允許 MFA 伺服器移轉同步服務在次要 MFA 伺服器上執行,而不只是在主要伺服器上執行。 若要將移轉同步服務設定為在輔助伺服器上執行,腳本必須在伺服器上執行, Configure-MultiFactorAuthMigrationUtility.ps1 才能向 MFA Server Migration Utility 應用程式註冊註冊憑證。 憑證可用來向 Microsoft Graph 進行驗證。

移轉程式可以是自動或手動的。

手動程式步驟如下:

  1. 若要開始使用者或選取多個使用者的移轉程式,請在選取您想要移轉的每個使用者時按住 Ctrl 鍵。

  2. 選取所需的用戶之後,按兩下 [移轉使用者選取的使用者>>] [確定]。

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

  4. 即使使用者未變更,您也可以移轉使用者。 根據預設,公用程式會設定為 [僅移轉已變更的使用者]。 按兩下 [ 移轉所有使用者 ] 以重新移轉先前未變更的移轉使用者。 如果系統管理員需要重設使用者的 Azure MFA 設定,而且想要重新移轉使用者,則移轉未變更的使用者在測試期間很有用。

    [移轉使用者] 對話框的螢幕快照。

針對自動程式,按兩下 [設定中的 [自動同步處理],然後選取您要同步處理所有使用者,還是只想要指定 Microsoft Entra 群組的成員。

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

方法 邏輯
手機 如果沒有擴充功能,請更新 MFA 電話。
如果有擴充功能,請更新 Office 電話。
例外狀況:如果預設方法是簡訊,請卸除延伸模組並更新 MFA 電話。
備份 電話 如果沒有擴充功能,請更新替代電話。
如果有擴充功能,請更新 Office 電話。
例外狀況:如果 電話 和備份 電話 都有擴充功能,請略過備份 電話。
行動應用程式 如果使用者也有硬體 OATH 令牌,最多將移轉五部裝置,或只有四部裝置。
如果有多個具有相同名稱的裝置,則只會移轉最新的裝置。
裝置將從最新到最舊的順序排序。
如果裝置已存在於 Microsoft Entra 識別符中,請比對 OATH 令牌秘密密鑰並更新。
- 如果 OATH 令牌秘密金鑰沒有相符專案,請在裝置令牌上比對
-- 如果找到,請為 MFA Server 裝置建立軟體 OATH 令牌,以允許 OATH Token 方法運作。 通知仍會使用現有的 Microsoft Entra 多重要素驗證裝置運作。
-- 如果找不到,請建立新的裝置。
如果新增裝置將會超過五個裝置的限制,則會略過裝置。
OATH 令牌 如果裝置已存在於 Microsoft Entra 識別符中,請比對 OATH 令牌秘密密鑰並更新。
- 如果找不到,請新增硬體 OATH 令牌裝置。
如果新增裝置將超過五個裝置的限制,則會略過 OATH 令牌。

MFA 方法會根據已移轉的專案進行更新,並設定預設方法。 MFA Server 會追蹤上次移轉時間戳,只有在使用者的 MFA 設定變更或系統管理員修改在 [設定] 對話框中移轉的專案時,才會再次移轉使用者。

在測試期間,建議您先進行手動移轉,並進行測試,以確保指定的用戶數目如預期般運作。 測試成功之後,請針對您想要移轉的 Microsoft Entra 群組開啟自動同步處理。 當您將使用者新增至此群組時,其資訊會自動同步處理至 Microsoft Entra ID。 MFA Server Migration Utility 以一個 Microsoft Entra 群組為目標,不過該群組可以同時包含使用者和巢狀使用者群組。

完成後,確認會通知您已完成的工作:

確認的螢幕快照。

如確認訊息中所述,移轉的數據可能需要幾分鐘的時間才會出現在 Microsoft Entra ID 內的用戶物件上。 用戶可以流覽至 aka.ms/mfasetup 來檢視其已移轉的方法。

提示

如果您不需要檢視 Microsoft Entra MFA 方法,則可以縮短顯示群組所需的時間。 單擊 [檢視>Azure AD MFA 方法],切換 AAD 預設值AAD 電話、AAD 替代AAD OfficeAAD 裝置AAD OATH 令牌的數據行顯示。 隱藏數據行時,會略過某些 Microsoft Graph API 呼叫,這可大幅改善使用者載入時間。

檢視移轉詳細數據

您可以使用稽核記錄或 Log Analytics 來檢視 MFA Server 至 Azure MFA 使用者移轉的詳細數據。

使用稽核記錄

若要存取 Microsoft Entra 系統管理中心的稽核記錄,以檢視 MFA Server 至 Azure MFA 使用者移轉的詳細數據,請遵循下列步驟:

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

  2. 流覽至 [身分識別>監視與健康情況>稽核記錄]。 若要篩選記錄,請按兩下 [ 新增篩選]。

    如何新增篩選的螢幕快照。

  3. 選取 [由 [動作專案] 起始, 然後按兩下 [ 套用]。

    [由動作專案起始] 選項的螢幕快照。

  4. 輸入 Azure MFA 管理 ,然後按兩下 [ 套用]。

    MFA 管理選項的螢幕快照。

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

    用戶移轉詳細數據的螢幕快照。

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

    代碼 方法
    0 語音行動裝置
    2 語音辦公室
    3 語音替代行動裝置
    5 SMS
    6 Microsoft Authenticator 推播通知
    7 硬體或軟體令牌 OTP
  6. 如果已移轉任何使用者裝置,則會有個別的記錄專案。

    已移轉裝置的螢幕快照。

使用 Log Analytics

您也可以使用 Log Analytics 查詢 MFA Server 到 Azure 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 group(s) 設為 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,並使用您想要設定分段推出租使用者中的混合式身分識別 管理員 istrator 帳戶登入 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 資源。 公用檔尚未使用新的多重要素Authentication 功能進行更新,但有如何與 API 互動的詳細資訊。

  3. 確認使用者 MFA 體驗。 以下是一些要檢查的事項:

    1. 使用者是否在 aka.ms/mfasetup 中看到其方法?
    2. 使用者是否會收到電話/簡訊?
    3. 他們是否能夠使用上述方法成功進行驗證?
    4. 使用者是否成功收到驗證器通知? 他們是否能夠核准這些通知? 驗證是否成功?
    5. 使用者是否能夠成功使用硬體 OATH 令牌進行驗證?

教育使用者

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

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

完成使用者移轉

重複移轉步驟:移轉用戶數據和驗證和測試區段,直到移轉所有用戶數據為止。

移轉 MFA 伺服器相依性

使用您在驗證服務收集的數據點,開始執行所需的各種移轉。 完成之後,請考慮讓使用者在合併註冊入口網站中管理其驗證方法,而不是在 MFA 伺服器上的使用者入口網站中管理。

更新網域同盟設定

完成使用者移轉,並將所有 驗證服務 移出 MFA Server 之後,就可以更新網域同盟設定。 更新之後,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": "MIIE3jCCAsagAwIBAgIQQcyDaZz3MI",
   "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": "MIIE3jCCAsagAwIBAgIQQcyDaZz3MI",
   "signingCertificateUpdateStatus": {
        "certificateUpdateResult": "Success",
        "lastRunDateTime": "2021-08-25T07:44:46.2616778Z"
    },
   "federatedIdpMfaBehavior": "rejectMfaByFederatedIdp"
}

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

注意

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

選擇性:停用 MFA Server 使用者入口網站

完成移轉所有用戶數據之後,終端使用者就可以開始使用 Microsoft Entra ID 合併註冊頁面來管理 MFA 方法。 有幾個方法可防止使用者在 MFA Server 中使用使用者入口網站:

  • 將 MFA Server 使用者入口網站 URL 重新導向至 aka.ms/mfasetup
  • 清除 MFA Server [使用者入口網站] 區段中 [設定] 索引卷標底下的 [允許使用者登入] 複選框,以防止使用者完全登入入口網站。

解除委任 MFA 伺服器

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

復原方案

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

  1. 卸載 MFA Server 8.1。

  2. 將 電話 Factor.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": "MIIE3jCCAsagAwIBAgIQQcyDaZz3MI",
       "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": "MIIE3jCCAsagAwIBAgIQQcyDaZz3MI",
       "signingCertificateUpdateStatus": {
            "certificateUpdateResult": "Success",
            "lastRunDateTime": "2021-08-25T07:44:46.2616778Z"
        },
       "federatedIdpMfaBehavior": "enforceMfaByFederatedIdp"
    }
    

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

下一步