本文說明如何為存取 Microsoft Exchange 的 Outlook 桌面用戶端實作多重要素驗證。 Microsoft Exchange 有四種架構對應至具有使用者信箱的四種不同可能性：
注意
在圖表中，黑色虛線顯示本機 Active Directory、Microsoft Entra 連線、Microsoft Entra ID、AD FS 和 Web 應用程式 Proxy 元件之間的基本互動。 您可以在混合式身分識別所需的埠和通訊協定 中 瞭解這些互動。
架構 （Exchange Online）
在此案例中，使用者必須使用支援新式驗證的 Outlook 用戶端版本。 如需詳細資訊，請參閱 新式驗證如何適用于 Office 2013、Office 2016 和 Office 2019 用戶端應用程式 。 此架構同時涵蓋 Windows 版 Outlook 和 Mac 版 Outlook。
工作流程 （Exchange Online）
- 使用者嘗試透過 Outlook 存取 Exchange Online。
- Exchange Online 提供 Microsoft Entra 端點的 URL，用來擷取存取權杖以取得信箱的存取權。
- Outlook 會使用該 URL 連線到 Microsoft Entra ID。
- 只要同盟網域，Microsoft Entra ID 就會將要求重新導向至內部部署 AD FS。
- 使用者在 AD FS 登入頁面上輸入認證。
- AD FS 會將會話重新導向回 Microsoft Entra ID。
- Microsoft Entra ID 會針對行動應用程式和桌面用戶端套用具有多重要素驗證需求的 Azure 條件式存取原則。 如需設定該原則的相關資訊，請參閱本文的部署一節 。
- 條件式存取原則會呼叫 Microsoft Entra 多重要素驗證。 使用者取得完成多重要素驗證的要求。
- 使用者完成多重要素驗證。
- Microsoft Entra ID 會發出存取和重新整理權杖的問題，並將其傳回給用戶端。
- 藉由使用存取權杖，用戶端會連線到 Exchange Online 並擷取內容。
設定 （Exchange Online）
若要封鎖透過舊版驗證存取 Exchange Online 的嘗試（圖表中的紅色虛線），您必須建立 驗證原則 ，以停用 Outlook 服務所使用的通訊協定的舊版驗證。 這些是您需要停用的特定通訊協定：自動探索、MAPI、離線通訊錄和 EWS。 以下是對應的組態：
AllowBasicAuthAutodiscover ： False
AllowBasicAuthMapi ： False
AllowBasicAuthOfflineAddressBook ： False
AllowBasicAuthWebServices ： False
AllowBasicAuthRpc ： False
Office 365 不再支援 遠端程序呼叫 （RPC） 通訊協定 ，因此最後一個參數不會影響用戶端。
以下是用來建立此驗證原則的命令範例：
New-AuthenticationPolicy -Name BlockLegacyOutlookAuth -AllowBasicAuthRpc:$false -AllowBasicAuthMapi:$false -AllowBasicAuthAutodiscover:$false
-AllowBasicAuthWebServices:$false -AllowBasicAuthOfflineAddressBook:$false
注意
根據預設，建立原則之後，也會停用所有其他通訊協定的舊版驗證（例如 IMAP、POP 和 ActiveSync）。 若要變更此行為，您可以使用類似下列的 PowerShell 命令來啟用通訊協定：
Set-AuthenticationPolicy -Identity BlockOutlook -AllowBasicAuthImap:$true
建立驗證原則之後，您必須先使用 Set-User user01 -AuthenticationPolicy <name_of_policy> 命令將它指派給使用者試驗群組。 測試之後，您可以展開原則以包含給所有使用者。 若要在組織層級套用原則，請使用 Set-OrganizationConfig -DefaultAuthenticationPolicy <name_of_policy> 命令。 您必須使用此設定的 Exchange Online PowerShell。
架構（Exchange Online、AD FS）
此案例與上一個案例相同，不同之處在于它會使用不同的觸發程式進行多重要素驗證。 在上一個案例中，我們使用本機 AD FS 進行驗證。 然後，我們會將成功驗證的相關資訊重新導向至 Microsoft Entra ID，其中條件式存取原則會強制執行多重要素驗證。 在此案例中，我們不會使用條件式存取來強制執行多重要素驗證，而是在 AD FS 層級上建立存取控制原則，並在該處強制執行多重要素驗證。 其餘的架構與上一個架構相同。
注意
只有當您無法使用前一個案例時，才建議此案例。
在此案例中，使用者必須使用支援新式驗證的 Outlook 用戶端版本。 如需詳細資訊，請參閱 新式驗證如何適用于 Office 2013、Office 2016 和 Office 2019 用戶端應用程式 。 此架構同時涵蓋 Windows 版 Outlook 和 Mac 版 Outlook。
工作流程（Exchange Online、AD FS）
使用者嘗試透過 Outlook 存取 Exchange Online。
Exchange Online 提供 Microsoft Entra 端點的 URL，用來擷取存取權杖以取得信箱的存取權。
Outlook 會使用該 URL 連線到 Microsoft Entra ID。
如果網域已同盟，Microsoft Entra ID 會將要求重新導向至內部部署 AD FS。
使用者在 AD FS 登入頁面上輸入認證。
AD FS 會回應 AF DS 存取控制原則，呼叫 Microsoft Entra 多重要素驗證來完成驗證。 以下是該類型的 AD FS 存取控制原則範例：
使用者取得完成多重要素驗證的要求。
使用者完成多重要素驗證。
AD FS 會將會話重新導向回 Microsoft Entra ID。
Microsoft Entra ID 會發出存取和重新整理權杖的問題，並將其傳回給用戶端。
藉由使用存取權杖，用戶端會連線到 Exchange Online 並擷取內容。
設定 （Exchange Online、AD FS）
注意
在步驟 6 中實作的存取控制原則會套用至信賴憑證者信任層級，因此會影響透過 AD FS 的所有 Office 365 服務的所有驗證要求。 您可以使用 AD FS 驗證規則來套用其他篩選 。 不過，我們建議您使用條件式存取原則（如先前架構所述），而不是針對 Microsoft 365 服務使用 AD FS 存取控制原則。 先前的案例比較常見，而且藉由使用它，您可以達到更佳的彈性。
若要封鎖透過舊版驗證存取 Exchange Online 的嘗試（圖表中的紅色虛線），您必須建立 驗證原則 ，以停用 Outlook 服務所使用的通訊協定的舊版驗證。 這些是您需要停用的特定通訊協定：自動探索、MAPI、離線通訊錄和 EWS。 以下是對應的組態：
AllowBasicAuthAutodiscover ： False
AllowBasicAuthMapi ： False
AllowBasicAuthOfflineAddressBook ： False
AllowBasicAuthWebServices ： False
AllowBasicAuthRpc ： False
Office 365 不再支援 RPC 通訊協定 ，因此最後一個參數不會影響用戶端。
以下是用來建立此驗證原則的命令範例：
New-AuthenticationPolicy -Name BlockLegacyOutlookAuth -AllowBasicAuthRpc:$false -AllowBasicAuthMapi:$false -AllowBasicAuthAutodiscover:$false
-AllowBasicAuthWebServices:$false -AllowBasicAuthOfflineAddressBook:$false
架構 （Exchange 內部部署）
此架構同時涵蓋 Windows 版 Outlook 和 Mac 版 Outlook。
工作流程 （Exchange 內部部署）
- Exchange Server 上具有信箱的使用者會啟動 Outlook 用戶端。 Outlook 用戶端會連線到 Exchange Server，並指定其具有新式驗證功能。
- Exchange Server 會傳送回應給用戶端，要求它從 Microsoft Entra ID 取得權杖。
- Outlook 用戶端會連線到 Exchange Server 所提供的 Microsoft Entra URL。
- Azure 會識別使用者的網域已同盟，因此它會將要求傳送至 AD FS（透過 Web 應用程式 Proxy）。
- 使用者在 AD FS 登入頁面上輸入認證。
- AD FS 會將會話重新導向回 Microsoft Entra ID。
- Microsoft Entra ID 會針對行動應用程式和桌面用戶端套用具有多重要素驗證需求的 Azure 條件式存取原則。 如需設定該原則的相關資訊，請參閱本文的部署一節 。
- 條件式存取原則會呼叫 Microsoft Entra 多重要素驗證。 使用者取得完成多重要素驗證的要求。
- 使用者完成多重要素驗證。
- Microsoft Entra ID 會發出存取和重新整理權杖的問題，並將其傳回給用戶端。
- 使用者向 Exchange Server 呈現存取權杖，而 Exchange 會授權存取信箱。
組態 （Exchange 內部部署）
若要封鎖透過舊版驗證存取 Exchange 內部部署的嘗試（圖表中的紅色虛線線），您必須建立 驗證原則 ，以停用 Outlook 服務所使用的通訊協定的舊版驗證。 這些是您需要停用的特定通訊協定：自動探索、MAPI、離線通訊錄、EWS 和 RPC。 以下是對應的組態：
BlockLegacyAuthAutodiscover ： True
BlockLegacyAuthMapi ： True
BlockLegacyAuthOfflineAddressBook ： True
BlockLegacyAuthRpc ： True
BlockLegacyAuthWebServices ： True
RPC 通訊協定不支援新式驗證，因此不支援 Microsoft Entra 多重要素驗證。 Microsoft 建議 使用適用于 Windows 用戶端的 Outlook MAPI 通訊協定。
以下是用來建立此驗證原則的命令範例：
New-AuthenticationPolicy -Name BlockLegacyOutlookAuth -BlockLegacyAuthAutodiscover -BlockLegacyAuthMapi -BlockLegacyAuthOfflineAddressBook -BlockLegacyAuthRpc
建立驗證原則之後，您必須先使用 Set-User user01 -AuthenticationPolicy <name_of_policy> 命令將它指派給使用者試驗群組。 測試之後，您可以展開原則以包含所有使用者。 若要在組織層級套用原則，請使用 Set-OrganizationConfig -DefaultAuthenticationPolicy <name_of_policy> 命令。 您必須使用此組態的 Exchange 內部部署 PowerShell。
架構 （Exchange 內部部署、AD FS）
此案例與上一個案例類似。 不過，在此案例中，AD FS 會觸發多重要素驗證。 此架構同時涵蓋 Windows 版 Outlook 和 Mac 版 Outlook。
注意
只有在您無法使用前一個案例時，才建議使用此案例。
工作流程 （Exchange 內部部署、AD FS）
使用者會啟動 Outlook 用戶端。 用戶端會連線到 Exchange Server，並指定其具有新式驗證功能。
Exchange Server 會傳送回應給用戶端，要求它從 Microsoft Entra ID 取得權杖。 Exchange Server 會為用戶端提供 Microsoft Entra ID 的 URL。
用戶端會使用 URL 來存取 Microsoft Entra ID。
在此案例中，網域是同盟的。 Microsoft Entra ID 會透過 Web 應用程式 Proxy 將用戶端重新導向至 AD FS。
使用者在 AD FS 登入頁面上輸入認證。
AD FS 會觸發多重要素驗證。 以下是該類型的 AD FS 存取控制原則範例：
使用者取得完成多重要素驗證的要求。
使用者完成多重要素驗證。
AD FS 會將會話重新導向回 Microsoft Entra ID。
Microsoft Entra ID 會向使用者發出存取和重新整理權杖的問題。
用戶端會將存取權杖呈現至 Exchange 內部部署伺服器。 Exchange 會授權存取使用者的信箱。
設定 （Exchange 內部部署、AD FS）
注意
在步驟 6 中實作的存取控制原則會套用至信賴憑證者信任層級，因此會影響所有通過 AD FS 之 Office 365 服務的驗證要求。 您可以使用 AD FS 驗證規則來套用其他篩選 。 不過，我們建議您使用條件式存取原則（如先前架構所述），而不是針對 Microsoft 365 服務使用 AD FS 存取控制原則。 先前的案例比較常見，而且藉由使用它，您可以達到更佳的彈性。
若要封鎖透過舊版驗證存取 Exchange 內部部署的嘗試（圖表中的紅色虛線線），您必須建立 驗證原則 ，以停用 Outlook 服務所使用的通訊協定的舊版驗證。 這些是您需要停用的特定通訊協定：自動探索、MAPI、離線通訊錄、EWS 和 RPC。 以下是對應的組態：
BlockLegacyAuthAutodiscover ： True
BlockLegacyAuthMapi ： True
BlockLegacyAuthOfflineAddressBook ： True
BlockLegacyAuthRpc ： True
BlockLegacyAuthWebServices ： True
RPC 通訊協定不支援新式驗證，因此不支援 Microsoft Entra 多重要素驗證。 Microsoft 建議 使用適用于 Windows 用戶端的 Outlook MAPI 通訊協定。
以下是用來建立此驗證原則的命令範例：
New-AuthenticationPolicy -Name BlockLegacyOutlookAuth -BlockLegacyAuthAutodiscover -BlockLegacyAuthMapi -BlockLegacyAuthOfflineAddressBook -BlockLegacyAuthRpc
建立驗證原則之後，您必須先使用 Set-User user01 -AuthenticationPolicy <name_of_policy> 命令將它指派給使用者試驗群組。 測試之後，您可以展開原則以包含所有使用者。 若要在組織層級套用原則，請使用 Set-OrganizationConfig -DefaultAuthenticationPolicy <name_of_policy> 命令。 您必須使用此組態的 Exchange 內部部署 PowerShell。
元件
- Microsoft Entra ID 。 Microsoft Entra ID 是 Microsoft 雲端式身分識別和存取管理服務。 它提供新式驗證，基本上是以 EvoSTS 為基礎（Microsoft Entra ID 所使用的安全性權杖服務）。 它會作為 Exchange Server 內部部署的驗證服務器。
- Microsoft Entra 多重要素驗證 。 多重要素驗證是在登入程式期間提示使用者進行另一種識別形式的程式，例如手機上的程式碼或指紋掃描。
- Microsoft Entra 條件式存取 。 條件式存取是 Microsoft Entra ID 用來強制執行組織原則的功能，例如多重要素驗證。
- AD FS。 AD FS 透過透過改善的安全性，跨安全性和企業界限共用數位身分識別與權利，藉此啟用同盟身分識別和存取管理。 在這些架構中，它用來協助使用同盟身分識別的使用者登入。
- Web 應用程式 Proxy 。 Web 應用程式 Proxy使用 AD FS 預先驗證 Web 應用程式的存取權。 它也可作為 AD FS Proxy。
- Microsoft Intune。 Intune 是我們的雲端式整合端點管理，可跨 Windows、Android、Mac、iOS 和 Linux 作業系統管理端點。
- Exchange Server。 Exchange Server 會在內部部署裝載使用者信箱。 在這些架構中，它會使用 Microsoft Entra ID 發行給使用者的權杖來授權信箱的存取權。
- Active Directory 服務 。 Active Directory 服務會儲存網域成員的相關資訊，包括裝置和使用者。 在這些架構中，使用者帳戶屬於 Active Directory 服務，並且會同步處理至 Microsoft Entra ID。
- 商務 用 Outlook。 Outlook 是支援新式驗證的用戶端應用程式。
案例詳細資料
企業傳訊基礎結構 （EMI） 是組織的重要服務。 從較舊且較不安全的驗證方法移至新式驗證，是遠端工作普遍面臨的一項重大挑戰。 實作傳訊服務存取的多重要素驗證需求是滿足該挑戰的最有效方式之一。
本文說明使用 Microsoft Entra 多重要素驗證增強 Outlook 桌面用戶端存取案例中安全性的四種架構。
這些是四種架構，根據 Microsoft Exchange 的四種不同可能性：
這四個架構都涵蓋 Windows 版 Outlook 和 Mac 版 Outlook。
如需在其他混合式傳訊案例中套用多重要素驗證的相關資訊，請參閱下列文章：
本文不會討論其他通訊協定，例如 IMAP 或 POP。 一般而言，這些案例不會使用這些通訊協定。
一般注意事項
- 這些架構會使用 同盟 的 Microsoft Entra 身分識別模型。 針對密碼雜湊同步處理和傳遞驗證模型，邏輯和流程相同。 唯一的差異與 Microsoft Entra ID 不會將驗證要求重新導向至內部部署的 Active Directory同盟服務 （AD FS） 的事實有關。
- 透過 Exchange 內部部署 ，我們表示具有最新更新和信箱角色的 Exchange 2019。
- 在真實環境中，您不會只有一部伺服器。 您將有一個負載平衡的 Exchange 伺服器陣列，以達到高可用性。 此處所述的案例適用于該組態。
潛在的使用案例
此架構與下列案例相關：
- 增強 EMI 安全性。
- 採用零信任 安全性策略。
- 在轉換至 Exchange Online 或與 Exchange Online 共存期間，針對內部部署傳訊服務套用標準高層級的保護。
- 在封閉式或高度安全的組織中強制執行嚴格的安全性或合規性需求，例如財務部門中的組織。
考量
這些考慮會實作 Azure Well-Architected Framework 的支柱，這是一組指導原則，可用來改善工作負載的品質。 如需詳細資訊，請參閱 Microsoft Azure Well-Architected Framework 。
可靠性
可靠性可確保您的應用程式可以符合您對客戶所做的承諾。 如需詳細資訊，請參閱 可靠性要素 概觀。
可用性
整體可用性取決於所涉及的元件可用性。 如需可用性的相關資訊，請參閱下列資源：
內部部署解決方案元件的可用性取決於實作的設計、硬體可用性，以及內部作業和維護常式。 如需這些元件之一些的可用性資訊，請參閱下列資源：
若要使用混合式新式驗證，您必須確定網路上的所有用戶端都可以存取 Microsoft Entra ID。 您也需要持續維護 Office 365 防火牆埠和 IP 範圍開啟。
如需 Exchange Server 的通訊協定和埠需求，請參閱混合式新式驗證概觀中的
如需 Office 365 IP 範圍和埠，請參閱 Office 365 URL 和 IP 位址範圍 。
如需混合式新式驗證和行動裝置的相關資訊，請參閱 Office 365 IP 位址和 URL Web 服務 未包含之其他端點中的 自動偵測端點。
災害復原
如需此架構中元件復原的相關資訊，請參閱下列資源。
- 針對 Microsoft Entra 識別碼： 推進 Microsoft Entra 可用性
- 針對使用 AD FS 的案例： Azure 中具有Azure 流量管理員的高可用性跨地理 AD FS 部署
- 針對 Exchange 內部部署解決方案： Exchange 高可用性
安全性
安全性可提供針對蓄意攻擊和濫用寶貴資料和系統的保證。 如需詳細資訊，請參閱 安全性要素 概觀。
如需安全性和混合式新式驗證的相關資訊，請參閱 深入探討：混合式驗證的運作方式 。
對於具有傳統強周邊保護的封閉式組織，有與 Exchange 混合式傳統設定相關的安全性考慮。 Exchange 混合式新式設定不支援混合式新式驗證。
如需 Microsoft Entra 識別碼的相關資訊，請參閱 Microsoft Entra 安全性作業指南 。
如需使用 AD FS 安全性之案例的相關資訊，請參閱下列文章：
成本最佳化
成本優化是考慮如何減少不必要的費用，並提升營運效率。 如需詳細資訊，請參閱 成本優化要素 概觀。
實作的成本取決於您的 Microsoft Entra ID 和 Microsoft 365 授權成本。 總成本也包括內部部署元件的軟體和硬體成本、IT 作業、訓練和教育，以及專案實作。
這些解決方案至少需要 Microsoft Entra ID P1。 如需定價詳細資料，請參閱 Microsoft Entra 定價 。
如需 AD FS 和 Web 應用程式 Proxy的相關資訊，請參閱 Windows Server 2022 的定價和授權。
如需詳細資訊，請參閱下列資源：
效能效益
效能效率是工作負載以有效率的方式調整的能力，以符合使用者放置的需求。 如需詳細資訊，請參閱 效能效率要素概觀 。
工作負載效能取決於所涉及的元件效能，以及網路效能。 如需詳細資訊，請參閱 使用基準和效能歷程記錄 的 Office 365 效能微調。
如需影響 AD FS 服務之案例效能的內部部署因素相關資訊，請參閱下列資源：
如需 AD FS 延展性的相關資訊，請參閱 規劃 AD FS 伺服器容量 。
如需 Exchange Server 內部部署延展性的相關資訊，請參閱 Exchange 2019 慣用架構 。
部署此案例
以下是高階步驟：
- 設定 Exchange 混合式設定並啟用混合式新式驗證 ，以保護 Outlook 桌面存取。
- 封鎖 Microsoft Entra 識別碼層級 的所有舊版驗證嘗試 。 使用 驗證原則封鎖傳訊服務層級上的舊版驗證 嘗試。
設定條件式存取原則
若要設定強制執行多重要素驗證的 Microsoft Entra 條件式存取原則，如本文中的一些架構所述：
在 [用戶端應用程式] 視窗中，選取 [ 行動應用程式和桌面用戶端 ]：
在 [授與 ] 視窗中套用多重要素驗證需求：
參與者
本文由 Microsoft 維護。 原始投稿人如下。
主要作者：
- Pavel Kondrashov |雲端解決方案架構師
- Ella Parkum |主要客戶解決方案架構師-工程
若要查看非公用LinkedIn設定檔，請登入 LinkedIn。
下一步
- 宣佈 Exchange 內部部署的混合式新式驗證
- 混合式新式驗證概觀和與內部部署 Exchange 伺服器搭配使用的必要條件
- 搭配使用 AD FS 宣告型驗證搭配Outlook 網頁版
- 如何設定 Exchange Server 內部部署以使用混合新式驗證
- Exchange 2019 慣用架構
- 使用 Azure 流量管理員在 Azure 中部署高可用性跨地區 AD FS
- 搭配 iOS 和 Android 版 Outlook 使用混合式新式驗證
- 在 Exchange Online 中使用新式驗證的帳戶設定