增強安全性混合式傳訊基礎結構 - 行動存取

Microsoft Entra ID
Microsoft 365
Office 365

本文說明如何為存取 Microsoft Exchange 的 Outlook 行動用戶端實作多重要素驗證。 有兩種架構對應至具有使用者信箱的 Microsoft Exchange 有兩種不同的可能性:

架構 (Exchange Online)

Diagram that shows an architecture for enhanced security in an Outlook mobile access scenario. The user's mailbox is in Exchange Online.

在此案例中,使用者必須使用支援新式驗證的行動用戶端。 我們建議使用 Outlook 行動裝置版 (iOS 版 Outlook / Android 版 Outlook),Microsoft 支援 Outlook。 下列工作流程使用 Outlook 行動裝置版。

下載本文中所有圖表的 Visio 檔案

工作流程 (Exchange Online)

  1. 使用者輸入電子郵件地址來啟動 Outlook 設定檔群組態。 Outlook 行動裝置版會連線到 AutoDetect 服務。
  2. AutoDetect 服務會向 Exchange Online 提出匿名自動探索 V2 要求,以取得信箱。 Exchange Online 會回復 302 重新導向回應,其中包含信箱的 ActiveSync URL 位址,指向 Exchange Online。 您可以在這裡 看到 這種類型的要求範例。
  3. 既然 AutoDetect 服務有信箱內容端點的相關資訊,它可以呼叫 ActiveSync 而不需驗證。
  4. 如這裡的 連線流程所述 ,Exchange 會回應 401 挑戰回應。 它包含授權 URL,可識別用戶端需要用來取得存取權杖的 Microsoft Entra 端點。
  5. AutoDetect 服務會將 Microsoft Entra 授權端點傳回用戶端。
  6. 用戶端會連線到 Microsoft Entra ID 以完成驗證,並輸入登入資訊(電子郵件)。
  7. 如果網域已同盟,則會將要求重新導向至 Web 應用程式 Proxy。
  8. Web 應用程式 Proxy Proxy 對 AD FS 的驗證要求。 使用者會看到登入頁面。
  9. 使用者輸入認證以完成驗證。
  10. 使用者會重新導向回 Microsoft Entra 識別碼。
  11. Microsoft Entra ID 會套用 Azure 條件式存取原則。
  12. 如果裝置已在 Microsoft 端點管理員中註冊、強制執行應用程式保護原則,以及/或強制執行多重要素驗證,原則可以根據使用者的裝置狀態強制執行限制。 您可以在這裡 所述的實作步驟中找到此原則類型 的詳細範例。
  13. 使用者會實作任何原則需求,並完成多重要素驗證要求。
  14. Microsoft Entra ID 會將存取權和重新整理權杖傳回給用戶端。
  15. 用戶端會使用存取權杖來連線到 Exchange Online 並擷取信箱內容。

設定 (Exchange Online)

若要封鎖嘗試透過舊版驗證存取 Exchange Online ActiveSync(圖表中的紅色虛線線),您需要建立 驗證原則 ,以停用 Outlook 行動服務所使用的通訊協定的舊版驗證。 具體而言,您必須停用 AutoDiscover、ActiveSync 和 Outlook 服務。 以下是對應的驗證原則設定:

AllowBasicAuthAutodiscover : False

AllowBasicAuthActiveSync : False

AllowBasicAuthOutlookService : False

建立驗證原則之後,您可以將它指派給使用者試驗群組。 然後,在測試之後,您可以展開所有使用者的原則。 若要在組織層級套用原則,請使用 Set-OrganizationConfig -DefaultAuthenticationPolicy <name_of_policy> 命令。 您必須使用此設定的 Exchange Online PowerShell。

針對同盟網域,您可以設定 AD FS 來觸發多重要素驗證,而不是使用條件式存取原則。 不過,建議您控制連線,並在條件式存取原則層級套用限制。

架構 (Exchange 內部部署)

Diagram that shows an architecture for enhanced security in an Outlook mobile access scenario. The user's mailbox is in Exchange on-premises.

下載本文中所有圖表的 Visio 檔案

在此案例中,使用者必須使用支援新式驗證的行動用戶端,如使用混合式新式驗證 中所述 。 我們建議使用 Outlook 行動裝置版 (iOS 版 Outlook / Android 版 Outlook),Microsoft 支援 Outlook。 下列工作流程使用 Outlook 行動裝置版。

工作流程 (Exchange 內部部署)

  1. 使用者輸入電子郵件地址來啟動 Outlook 設定檔群組態。 Outlook 行動裝置版會連線到 AutoDetect 服務。
  2. AutoDetect 服務會向 Exchange Online 提出匿名自動探索 V2 要求,以取得信箱。
  3. 信箱位於內部部署之後,Exchange Online 會以 302 重新導向回應回復,其中包含 AutoDetect 可用來擷取信箱的 ActiveSync URL 位址的內部部署自動探索 URL。
  4. AutoDetect 會使用在上一個步驟中收到的內部部署 URL,向 Exchange 內部部署提出匿名自動探索 v2 要求,以取得信箱。 Exchange 內部部署會傳回信箱的 ActiveSync URL 位址,指向 Exchange 內部部署。 您可以在這裡 看到 這種類型的要求範例。
  5. 既然 AutoDetect 服務有信箱內容端點的相關資訊,它就可以呼叫內部部署 ActiveSync 端點,而不需要驗證。 如這裡的 連線流程所述 ,Exchange 會回應 401 挑戰回應。 它包含授權 URL,可識別用戶端需要用來取得存取權杖的 Microsoft Entra 端點。
  6. AutoDetect 服務會將 Microsoft Entra 授權端點傳回用戶端。
  7. 用戶端會連線到 Microsoft Entra ID 以完成驗證,並輸入登入資訊(電子郵件)。
  8. 如果網域已同盟,則會將要求重新導向至 Web 應用程式 Proxy。
  9. Web 應用程式 Proxy Proxy 對 AD FS 的驗證要求。 使用者會看到登入頁面。
  10. 使用者輸入認證以完成驗證。
  11. 使用者會重新導向回 Microsoft Entra 識別碼。
  12. Microsoft Entra ID 會套用 Azure 條件式存取原則。
  13. 如果裝置已在 Microsoft 端點管理員中註冊、強制執行應用程式保護原則,以及/或強制執行多重要素驗證,原則可以根據使用者的裝置狀態強制執行限制。 您可以在這裡 所述的實作步驟中找到 此原則類型的詳細範例。
  14. 使用者會實作任何原則需求,並完成多重要素驗證要求。
  15. Microsoft Entra ID 會將存取權和重新整理權杖傳回給用戶端。
  16. 用戶端會使用存取權杖來連線到 Exchange Online 並擷取內部部署信箱內容。 應該從 快取提供內容,如這裡 所述。 為了達成此目的,用戶端會發出布建要求,其中包含使用者的存取權杖和內部部署 ActiveSync 端點。
  17. Exchange Online 中的布建 API 會採用提供的權杖作為輸入。 API 會取得第二個存取和重新整理權杖組,以透過代理者呼叫 Active Directory 來存取內部部署信箱。 第二個存取權杖的範圍是用戶端作為 Exchange Online,以及內部部署 ActiveSync 命名空間端點的物件。
  18. 如果未布建信箱,布建 API 會建立信箱。
  19. 布建 API 會建立與內部部署 ActiveSync 端點的安全連線。 API 會使用第二個存取權杖作為驗證機制來同步處理使用者的傳訊資料。 重新整理權杖會定期用來產生新的存取權杖,以便資料可以在背景同步處理,而不需要使用者介入。
  20. 資料會傳回給用戶端。

組態 (Exchange 內部部署)

若要封鎖嘗試透過舊版驗證存取 Exchange 內部部署 ActiveSync(圖表中的紅色虛線線),您必須建立 驗證原則 ,以停用 Outlook 行動服務所使用的通訊協定舊版驗證。 具體而言,您必須停用 AutoDiscover 和 ActiveSync。 以下是對應的驗證原則設定:

BlockLegacyAuthAutodiscover: True

BlockLegacyAuthActiveSync: True

以下是用來建立此驗證原則的命令範例:

New-AuthenticationPolicy -Name BlockLegacyActiveSyncAuth -BlockLegacyAuthActiveSync -BlockLegacyAuthAutodiscover

建立驗證原則之後,您必須先使用 Set-User user01 -AuthenticationPolicy <name_of_policy> 命令將它指派給使用者試驗群組。 測試之後,您可以展開原則以包含所有使用者。 若要在組織層級套用原則,請使用 Set-OrganizationConfig -DefaultAuthenticationPolicy <name_of_policy> 命令。 您必須使用此組態的 Exchange 內部部署 PowerShell。

您也需要採取步驟來達到一致性,並只允許從 Outlook 用戶端存取。 若要允許 Outlook 行動裝置版作為組織中唯一核准的用戶端,您需要封鎖非支援新式驗證之 Outlook 行動用戶端的連線嘗試。 您必須完成下列步驟,以封鎖 Exchange 內部部署層級上的這些嘗試:

  • 封鎖其他行動裝置用戶端:

    Set-ActiveSyncOrganizationSettings -DefaultAccessLevel Block
    
  • 允許 Exchange Online 連線到內部部署:

    If ((Get-ActiveSyncOrganizationSettings).DefaultAccessLevel -ne "Allow") {New-ActiveSyncDeviceAccessRule -Characteristic DeviceType -QueryString "OutlookService" -AccessLevel Allow}
    
  • 封鎖 iOS 和 Android 版 Outlook 的基本驗證:

    New-ActiveSyncDeviceAccessRule -Characteristic DeviceModel -QueryString "Outlook for iOS and Android" -AccessLevel Block
    

如需這些步驟的詳細資訊,請參閱 搭配 iOS 和 Android 版 Outlook 使用混合式新式驗證。

針對同盟網域,您可以設定 AD FS 來觸發多重要素驗證,而不是使用條件式存取原則。 不過,建議您控制連線,並在條件式存取原則層級套用限制。

元件

  • 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 行動裝置的替代方案。 如果您選擇此替代方案,協力廠商廠商會負責用戶端的支援。

案例詳細資料

企業傳訊基礎結構 (EMI) 是組織的重要服務。 從較舊且較不安全的驗證方法移至新式驗證,是遠端工作普遍面臨的一項重大挑戰。 實作傳訊服務存取的多重要素驗證需求是滿足該挑戰的最有效方式之一。

本文說明兩種架構,可協助您使用 Microsoft Entra 多重要素驗證,在 Outlook 行動裝置存取案例中增強安全性。

本文將說明這些案例:

  • 當使用者的信箱位於 Exchange Online 時,Outlook 行動裝置存取
  • 當使用者的信箱位於 Exchange 內部部署時,Outlook 行動裝置存取

這兩種架構都涵蓋 iOS 版 Outlook 和 Android 版 Outlook。

如需在其他混合式傳訊案例中套用多重要素驗證的相關資訊,請參閱下列文章:

本文不會討論其他通訊協定,例如 IMAP 或 POP。 一般而言,這些案例不會使用這些通訊協定。

一般注意事項

  • 這些架構會使用 同盟 的 Microsoft Entra 身分識別模型。 針對密碼雜湊同步處理和傳遞驗證模型,邏輯和流程相同。 唯一的差異與 Microsoft Entra ID 不會將驗證要求重新導向至內部部署的 Active Directory同盟服務 (AD FS) 的事實有關。
  • 在圖表中,黑色虛線顯示本機 Active Directory、Microsoft Entra 連線、Microsoft Entra ID、AD FS 和 Web 應用程式 Proxy 元件之間的基本互動。 您可以在混合式身分識別所需的埠和通訊協定 瞭解這些互動。
  • 透過 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 的通訊協定和埠需求,請參閱混合式新式驗證概觀中的 ,以搭配內部部署商務用 Skype和 Exchange Server 使用。

如需 Office 365 IP 範圍和埠,請參閱 Office 365 URL 和 IP 位址範圍

如需混合式新式驗證和行動裝置的相關資訊,請參閱 Office 365 IP 位址和 URL Web 服務 未包含之其他端點中的 自動偵測端點。

災害復原

如需此架構中元件復原的相關資訊,請參閱下列資源。

安全性

如需行動裝置安全性的一般指引,請參閱 使用 Microsoft Intune 保護資料和裝置。

如需安全性和混合式新式驗證的相關資訊,請參閱 深入探討:混合式驗證的運作方式

對於具有傳統強周邊保護的封閉式組織,有與 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 慣用架構

部署此案例

若要實作此基礎結構,您必須完成下列文章中所含指引中所述的步驟。 以下是高階步驟:

  1. 保護 Outlook 行動裝置存取,如新式驗證 的這些實作步驟中所述
  2. 封鎖 Microsoft Entra ID 層級的所有其他舊版驗證嘗試。
  3. 使用驗證原則封鎖傳訊服務層級的舊版驗證嘗試。

參與者

本文由 Microsoft 維護。 原始投稿人如下。

主要作者:

若要查看非公用LinkedIn設定檔,請登入 LinkedIn。

下一步