分享方式：

從 MFA 伺服器移轉至 Microsoft Entra 多重要素驗證

  • 文章

多重要素驗證十分重要，可保護您的基礎結構和資產免於不良執行者的威脅。 Azure Multi-Factor Authentication Server (MFA 伺服器) 不適用於新的部署，將會予以取代。 使用 MFA 伺服器的客戶應該改為使用雲端式 Microsoft Entra 多重要素驗證。

在本文中，假設您有混合式環境，其中：

  • 您使用 MFA 伺服器進行多重要素驗證。
  • 您會將 Microsoft Entra ID 上的同盟與 Active Directory 同盟服務 (AD FS) 或其他身分識別提供者同盟產品搭配使用。
    • 雖然本文的範圍包含 AD FS，但類似的步驟適用於其他身分識別提供者。
  • 您的 MFA 伺服器已與 AD FS 整合。
  • 您可能有使用 AD FS 進行驗證的應用程式。

根據您的目標，您的移轉可能會有多個結束狀態。


 目標：僅解除委任 MFA 伺服器 目標：解除委任 MFA 伺服器並移至 Microsoft Entra 驗證 目標：解除委任 MFA 伺服器和 AD FS
MFA 提供者 將 MFA 提供者從 MFA 伺服器變更至 Microsoft Entra 多重要素驗證。 將 MFA 提供者從 MFA 伺服器變更至 Microsoft Entra 多重要素驗證。 將 MFA 提供者從 MFA 伺服器變更至 Microsoft Entra 多重要素驗證。
使用者驗證 繼續使用同盟進行 Microsoft Entra 驗證。 使用密碼雜湊同步 (慣用) 或傳遞驗證與無縫單一登入 (SSO) 來移至 Microsoft Entra ID。 使用密碼雜湊同步 (慣用) 或傳遞驗證與 SSO 來移至 Microsoft Entra ID。
應用程式驗證 繼續針對您的應用程式使用 AD FS 驗證。 繼續針對您的應用程式使用 AD FS 驗證。 將應用程式移至 Microsoft Entra ID，再移轉至 Microsoft Entra 多重要素驗證。

如果可以，請將您的多重要素驗證和使用者驗證移至 Azure。 如需逐步指引，請參閱移至 Microsoft Entra 多重要素驗證和 Microsoft Entra 使用者驗證。

如果您無法移動使用者驗證，則請參閱使用同盟移至 Microsoft Entra 多重要素驗證的逐步指引。

必要條件

  • AD FS 環境 (如果您未在移轉 MFA 伺服器之前將所有應用程式都移轉至 Microsoft Entra，則為必要項目)
    • 升級為適用於 Windows Server 2019 伺服器陣列行為層級 (FBL) 4 的 AD FS。 此升級可讓您根據群組成員資格選取驗證提供者，以提供更順暢的使用者轉換。 雖然您可以在適用於 Windows Server 2016 FBL 3 的 AD FS 上進行移轉，但對於使用者而言並不會太順暢。 在移轉期間，除非移轉完成，否則系統會提示使用者選取驗證提供者 (MFA 伺服器或 Microsoft Entra 多重要素驗證)。
  • 權限
    • Active Directory 中的 Enterprise 管理員角色，以設定 Microsoft Entra 多重要素驗證的 AD FS 伺服陣列
    • 管理此功能需要全域管理員。

所有移轉路徑的考量

從 MFA 伺服器移轉至 Microsoft Entra 多重要素驗證不是僅與移動已註冊 MFA 的電話號碼有關。 Microsoft 的 MFA 伺服器可以與許多系統整合，而且您必須評估系統使用 MFA 伺服器的方式，來了解與 Microsoft Entra 多重要素驗證整合的最佳方式。

移轉 MFA 使用者資訊

以批次方式移動使用者的常見方式包括依區域、部門或角色 (例如管理員) 來移動使用者。 您應該不斷移動使用者帳戶，從測試與試驗群組開始，並確定您已備妥復原計畫。

您可以使用 MFA 伺服器移轉公用程式，將儲存於內部部署 Azure MFA 伺服器中的 MFA 資料同步處理至 Microsoft Entra 多重要素驗證，並使用分段推出以將使用者重新路由至 Azure MFA。 分段推出可協助測試，而不需要對網域同盟設定進行任何變更。

為了協助使用者區分新增的帳戶與連結至 MFA 伺服器的舊帳戶，請確定以區分這兩個帳戶的方式來命名 MFA 伺服器上行動應用程式的帳戶名稱。 例如，出現於 MFA 伺服器 [行動裝置應用程式] 下的帳戶名稱已重新命名為內部部署 MFA 伺服器。 Microsoft Authenticator 上的帳戶名稱將會隨著下次推播給使用者的通知而變更。

移轉電話號碼時也可能會導致移轉過時的號碼，並讓使用者更有可能保持在電話型 MFA，而不是設定更安全的方法 (例如處於無密碼模式的 Microsoft Authenticator)。 因此，無論您選擇哪個移轉路徑，都建議您讓所有使用者註冊合併安全性資訊。

移轉硬體安全性金鑰

Microsoft Entra ID 會提供對 OATH 硬體權杖的支援。 您可以使用 MFA 伺服器移轉公用程式同步處理 MFA 伺服器與 Microsoft Entra 多重要素驗證之間的 MFA 設定，並使用分段推出來測試使用者移轉，而不需要變更網域同盟設定。

若您只想移轉 OATH 硬體權杖，則必須使用 CSV 檔案將權杖上傳至 Microsoft Entra ID (通常稱為「種子檔案」)。 種子檔案包含祕密金鑰、權杖序號，以及將權杖上傳至 Microsoft Entra ID 所需的其他必要資訊。

如果您不再擁有具有祕密金鑰的種子檔案，就無法從 MFA 伺服器匯出祕密金鑰。 如果您無法再存取祕密金鑰，請連絡硬體廠商以取得支援。

MFA 伺服器 Web 服務 SDK 可以用來匯出指派給所給定使用者的任何 OATH 權杖的序號。 您可以搭配種子檔案來使用此資訊，將權杖匯入 Microsoft Entra ID，並根據序號將 OATH 權杖指派給指定的使用者。 在匯入時，也需要連絡使用者，以提供來自裝置的 OTP 資訊來完成註冊。 請參閱 MFA 伺服器上 Multi-Factor Authentication Server 中的說明檔主題 GetUserInfo>userSettings>OathTokenSerialNumber。

其他移轉

從 MFA 伺服器移轉至 Microsoft Entra 多重要素驗證的決策會開啟其他移轉的大門。 其他移轉的完成取決於許多因素，尤其包括：

  • 您對使用者使用 Microsoft Entra 多重要素驗證的意願
  • 您對將應用程式移至 Microsoft Entra ID 的意願

因為 MFA 伺服器與應用程式及使用者驗證息息相關，所以請考慮將這兩個功能移至 Azure 作為 MFA 移轉的一部分，並且最後解除 AD FS。

建議：

  • 使用 Microsoft Entra ID 進行驗證，因為它可提供更穩固的安全性與治理
  • 盡可能將應用程式移轉至 Microsoft Entra ID

若要選取最適合您組織的使用者驗證方法，請參閱針對 Microsoft Entra 混合式身分識別解決方案選擇正確的驗證方法。 建議您使用密碼雜湊同步 (PHS)。

無密碼驗證

註冊使用者使用 Microsoft Authenticator 作為第二個因素時，建議您在註冊時啟用無密碼手機登入。 如需詳細資訊 (包括其他無密碼方法，例如 FIDO2 安全性金鑰與 Windows Hello 企業版)，請造訪 使用 Microsoft Entra ID 規劃無密碼驗證部署。

Microsoft Identity Manager 自助式密碼重設

Microsoft Identity Manager (MIM) SSPR 可以使用 MFA 伺服器，在密碼重設流程中叫用 SMS 一次性密碼。 MIM 無法設定為使用 Microsoft Entra 多重要素驗證。 建議您評估將 SSPR 服務移至 Microsoft Entra SSPR。 您可以利用使用者註冊 Microsoft Entra 多重要素驗證的機會，使用合併的註冊體驗來註冊 Microsoft Entra SSPR。

如果您無法移動 SSPR 服務，或利用 MFA 伺服器來叫用 Privileged Access Management (PAM) 案例的 MFA 要求，建議您更新為 替代第三方 MFA 選項。

RADIUS 用戶多和 Microsoft Entra 多重要素驗證

MFA 伺服器支援 RADIUS，以針對支援此通訊協定的應用程式和網路裝置叫用多重要素驗證。 如果您將 RADIUS 與 MFA 伺服器搭配使用，則建議將用戶端應用程式移至 Microsoft Entra ID 上的新式通訊協定，例如 SAML、Open ID Connect 或 OAuth。 如果無法更新應用程式，則您可以使用 Microsoft Entra 多重要素驗證延伸模組來部署網路原則伺服器 (NPS)。 網路原則伺服器 (NPS) 延伸模組可以作為 RADIUS 型應用程式與 Microsoft Entra 多重要素驗證之間的配接器，以提供第二個驗證因素。 此「配接器」可讓您將 RADIUS 用戶端移至 Microsoft Entra 多重要素驗證，並解除委任您的 MFA 伺服器。

重要考量

針對 RADIUS 用戶端使用 NPS 時有一些限制，建議您評估任何 RADIUS 用戶端，以判斷是否可以將它們升級為新式驗證通訊協定。 請洽詢服務提供者，以取得支援的產品版本和其功能。

  • NPS 延伸模組不會使用 Microsoft Entra 條件式存取原則。 如果您保留 RADIUS 並使用 NPS 延伸模組，則所有進入 NPS 的驗證要求都會需要使用者執行 MFA。
  • 使用者必須先註冊 Microsoft Entra 多重要素驗證，才能使用 NPS 延伸模組。 否則，此延伸模組無法驗證使用者，而這可能會產生服務台電話。
  • NPS 延伸模組叫用 MFA 時，會將 MFA 要求傳送至使用者的預設 MFA 方法。
    • 因為登入是在非 Microsoft 應用程式上進行，所以使用者通常無法不會看到需要多重要素驗證與已將要求傳送至其裝置的視覺通知。
    • 在多重要素驗證需求期間，使用者必須具有其預設驗證方法的存取權，才能完成需求。 他們無法選擇替代方法。 即使已在租用戶驗證方法和多重要素驗證原則中停用預設驗證方法，仍會使用預設驗證方法。
    • 使用者可以在 [安全性資訊] 頁面中變更預設多重要素驗證方法 (aka.ms/mysecurityinfo)。
  • RADIUS 用戶端的可用 MFA 方法是由傳送 RADIUS 存取要求的用戶端系統所控制。
    • 在使用者輸入密碼之後需要使用者輸入的 MFA 方法，只能與支援使用 RADIUS 的存取挑戰回應的系統搭配使用。 輸入方法可能包括 OTP、硬體 OATH 權杖或 Microsoft Authenticator。
    • 某些系統可能會將可用的多重要素驗證方法限制為 Microsoft Authenticator 推播通知和通話。

注意

RADIUS 用戶端與 NPS 系統之間使用的密碼加密演算法以及用戶端可以使用的輸入方法，會影響可用的驗證方法。 如需詳細資訊，請參閱判斷您的使用者可以使用的驗證方法。

常見的 RADIUS 用戶端整合包括遠端桌面閘道和 VPN 伺服器之類的應用程式。 其他可能包括：

  • Citrix 閘道
    • Citrix 閘道支援 RADIUS 和 NPS 延伸模組整合，以及 SAML 整合。
  • Cisco VPN
    • Cisco VPN 支援 SSO 的 RADIUS 和 SAML 驗證。
    • 從 RADIUS 驗證移至 SAML，即可整合 Cisco VPN，而不是部署 NPS 延伸模組。
  • 所有 VPN

部署 NPS 的資源

下一步