共用方式為


對 Outlook for iOS 和 Android 使用混合新式驗證

iOS 和 Android 版 Outlook 應用程式是設計成在行動裝置上體驗Microsoft 365 或 Office 365 的最佳方式,方法是使用Microsoft服務來協助尋找、規劃及排定您的日常生活和工作的優先順序。 Outlook 透過 Microsoft Entra 條件式存取和 Intune 應用程式保護原則等功能來保護公司數據時,提供您所需的安全性、隱私權和支援。 下列各節提供混合式新式驗證架構的概觀、其部署所需的必要條件,以及如何安全地部署iOS版 Outlook 和 Android for Exchange 內部部署信箱。

混合式 Exchange Server 客戶的Microsoft雲端架構

iOS 和 Android 版 Outlook 是雲端支援的應用程式。 此特性表示您的體驗是由在Microsoft雲端中執行之安全且可調整的服務所提供的本機安裝應用程式所組成。

針對 Exchange Server 信箱,iOS 版 Outlook 和 Android 版架構會直接內建在Microsoft雲端,為客戶提供更多優點,例如安全性、隱私權、內建合規性,以及Microsoft在 Microsoft 信任中心Azure 信任中心認可的透明作業。

iOS 和 Android 版 Outlook 中的混合式新式驗證。

在 Microsoft 365 或以 Office 365 為基礎的架構中,iOS 版和 Android 版 Outlook 會使用原生Microsoft同步處理技術,在 Microsoft 365 或 Office 365 與應用程式之間,端對端受到 TLS 保護連線保護的數據同步處理。

Exchange ActiveSync (EAS) Exchange Online 與內部部署環境之間的連線可同步處理使用者的內部部署數據,並在您的 Exchange Online 租使用者中包含四周的電子郵件、所有行事歷數據、所有聯繫人數據和辦公室外狀態。 在 Microsoft Entra ID 中刪除帳戶的 30 天后,系統會自動從 Exchange Online 移除此數據。

內部部署環境與 Exchange Online 之間的數據同步處理與使用者行為無關。 此不相依性可確保我們可以快速地將新訊息傳送至裝置。

在Microsoft雲端中處理資訊可提供進階的功能,例如焦點收件匣的電子郵件分類、自定義的旅遊和行事曆體驗,以及改善的搜尋速度。 依賴雲端進行密集的處理,並將用戶裝置所需的資源降至最低,可增強應用程式的效能和穩定性。 最後,它可讓 Outlook 建置可跨所有電子郵件帳戶運作的功能,不論基礎伺服器 (的技術功能為何,例如不同版本的 Exchange Server、Microsoft 365 或 Office 365) 。

具體而言,這個新架構具有下列改善:

  1. Enterprise Mobility + Security 支援:客戶可以利用 Microsoft Enterprise Mobility + Security (EMS) ,包括 Microsoft Intune 和 Microsoft Entra ID P1 或 P2,以啟用條件式存取和 Intune 應用程式保護原則,以控制及保護行動裝置上的公司訊息數據。

  2. 完全由Microsoft雲端提供技術支持:內部部署信箱數據會同步處理至 Exchange Online,這可提供安全性、隱私權、合規性和透明作業的優點,Microsoft在 Microsoft 信任中心認可這些作業。

  3. OAuth 可保護用戶的密碼:Outlook 會使用混合式新式驗證 (OAuth) 來保護用戶的認證。 混合式新式驗證為 Outlook 提供安全的機制來存取 Exchange 數據,而不需要觸及或儲存使用者的認證。 登入時,使用者會直接針對身分識別平臺進行驗證, (Microsoft Entra ID 或 ADFS) 等內部部署識別提供者,並接收傳回的存取令牌,這會授與 Outlook 存取使用者信箱或檔案的許可權。 服務在任何時間點都無法存取用戶的密碼。

  4. 提供唯一的裝置標識碼:每個 Outlook 連線都會在 Microsoft Intune 中唯一登錄,因此可以作為唯一連線來管理。

  5. 在 iOS 和 Android 上解除鎖定新功能:此更新可讓 Outlook 應用程式利用目前 Exchange 內部部署不支援的原生Microsoft 365 或 Office 365 功能,例如使用完整 Exchange Online 搜尋和焦點收件匣。 只有在使用 iOS 版和 Android 版 Outlook 時,才能使用這些功能。

注意事項

無法透過內部部署 Exchange 系統管理中心 (EAC) 進行裝置管理。 管理行動裝置需要 Intune。

數據安全性、存取和稽核控制

當內部部署數據與 Exchange Online 同步處理時,客戶對於如何在 Exchange Online 中保護數據有疑問。 Microsoft雲端中的加密 會討論如何使用 BitLocker 進行磁碟區層級加密。 iOS 版和 Android 版 Outlook 架構支援使用 Microsoft Purview 客戶密鑰的服務加密,但請注意,用戶必須具有 Office 365 企業版 E5 授權 (或政府或教育版) 的對應版本,才能使用 set-mailuser Cmdlet 來指派加密原則。

根據預設,Microsoft工程師在 Microsoft 365 或 Office 365 中沒有常設系統管理許可權和零常設存取權來存取客戶內容。 系統管理訪問控制 會討論人員檢測、背景檢查、加密箱和客戶加密箱等等。

ISO 稽核的服務保證控件檔提供 365 和 Office 365 Microsoft實作之全域資訊安全性標準和法規的稽核控件狀態。

線上流程

使用混合式新式驗證啟用 iOS 和 Android 版 Outlook 時,連線流程如下所示。

混合式新式驗證中的驗證流程。

  1. 使用者輸入其電子郵件地址之後,iOS 版 Outlook 和 Android 版會連線到 AutoDetect 服務。 AutoDetect 會藉由啟動自動探索查詢以 Exchange Online 來判斷信箱類型。 Exchange Online 會判斷使用者的信箱是內部部署,並使用內部部署自動探索URL傳回302重新導向至 AutoDetect。 AutoDetect 會針對內部部署自動探索服務啟動查詢,以判斷電子郵件位址的 ActiveSync 端點。 嘗試內部部署的 URL 類似下列範例: <https://autodiscover.contoso.com/autodiscover/autodiscover.json?Email=test%40contoso.com&Protocol=activesync&RedirectCount=3>

  2. AutoDetect 會啟動與上述步驟 1 所傳回內部部署 ActiveSync URL 的連線,並具有空的持有人挑戰。 空白持有人挑戰會告訴內部部署 ActiveSync 用戶端支援新式驗證。 內部部署 ActiveSync 會以 401 挑戰回應回應,並包含 WWW-Authenticate: Bearer 標頭。 在 WWW-Authenticate 中:持有人標頭是authorization_uri值,可識別應該用來取得 OAuth 令牌的 Microsoft Entra 端點。

  3. AutoDetect 會將 Microsoft Entra 端點傳回給用戶端。 用戶端會開始登入流程,而使用者會看到 Web 窗體 (或重新導向至 Microsoft Authenticator 應用程式) ,而且可以輸入認證。 視身分識別組態而定,此程式可能涉及同盟端點重新導向至內部部署識別提供者。 最後,用戶端會取得名為 AT1/RT1 的存取和重新整理令牌組。 此存取令牌的範圍限於具有 Exchange Online 端點物件的iOS和Android版 Outlook 用戶端。

  4. iOS 和 Android 版 Outlook 會建立與 Exchange Online 的連線,併發出布建要求,其中包含使用者的存取令牌 (AT1) 和內部部署 ActiveSync 端點。

  5. Exchange Online 內的 MRS 布建 API 會使用 AT1 作為輸入,並取得名為 AT2/RT2 的第二個存取和重新整理令牌組 (,) 透過 Active Directory 的代理呼叫來存取內部部署信箱。 第二個存取令牌的範圍是 Exchange Online 用戶端,以及內部部署 ActiveSync 命名空間端點的物件。

  6. 如果未布建信箱,則布建 API 會建立信箱。

  7. MRS 布建 API 會建立內部部署 ActiveSync 端點的安全連線,並使用 AT2 存取令牌作為驗證機制來同步處理使用者的訊息數據。 RT2 會定期用來產生新的 AT2,讓數據可以在背景中同步處理,而不需要使用者介入。

  8. 數據會傳回給用戶端。

技術和授權需求

混合式新式驗證架構具有下列技術需求:

注意事項

Office 365 美國政府社群和防禦租使用者、Office 365 德國租使用者,以及由 21Vianet 租使用者營運中國 Office 365 不支援利用混合式新式驗證與 Outlook 行動裝置的內部部署帳戶。

  1. Exchange 內部部署設定

    • Exchange Server 2019 累積更新 1 (CU1) 或更新版本、Exchange Server 2016 累計更新 8 (CU8) 或更新版本,或在所有 Exchange 伺服器上 Exchange Server 2013 CU19 或更新版本。 在混合式部署 (內部部署 Exchange 和 Exchange Online) 或使用 Exchange Online 封存 (EOA) 及其內部部署 Exchange 部署的組織中,您需要在最新的 CU 或最新版本之前部署一個 CU。

    • 所有 Exchange 2007 或 Exchange 2010 伺服器都必須從環境中移除。 這些版本的 Exchange 不受主要支援,無法與受 Intune 管理的 iOS 和 Android Outlook 搭配使用。 在此架構中,iOS 版和 Android 版 Outlook 會使用 OAuth 作為驗證機制。 發生其中一個內部部署組態變更,可讓 OAuth 端點以Microsoft雲端作為預設授權端點。 進行這項變更時,用戶端可以開始交涉 OAuth 的使用。 因為這項變更橫跨整個組織,Exchange 2013 或 2016 前面的 Exchange 2010 信箱錯誤地認為他們可以執行 OAuth (無法) ,最後會處於中斷連線狀態, (Exchange 2010 不支援 OAuth 作為驗證機制) 。

  2. Active Directory 同步處理。 透過 Microsoft Entra Connect,將整個內部部署郵件收件者目錄與 Microsoft Entra ID 同步處理。 如果您已在 Microsoft Entra Connect 組態中啟用 Microsoft Entra 應用程式和屬性篩選,請確定已選取下列應用程式:

    • Office 365 專業增強版
    • Exchange Online
    • Azure RMS
    • Intune

    如果您未在 Microsoft Entra Connect 組態中啟用 Microsoft Entra 應用程式和屬性篩選,則預設已選取所有必要的應用程式。

    重要事項

    iOS 和 Android 版 Outlook 會針對利用混合式新式驗證的內部部署信箱,使用租使用者的 Exchange Online 全域通訊清單。 如果所有郵件收件者都未同步至 Microsoft Entra ID,使用者將會遇到郵件流程問題。

  3. Exchange 混合式設定:需要 Exchange 內部部署與 Exchange Online 之間的完整混合式關聯性。

    • 混合式Microsoft 365 或 Office 365 組織是使用Exchange傳統混合式拓撲模式在完整混合式設定中設定,並已如Exchange部署小幫手中所指定進行設定。

      注意事項

      混合式代理程式不支援混合式新式驗證。

    • 需要Microsoft 365 或 Office 365 企業版、商務或教育組織。

    • 內部部署信箱數據會同步處理於Microsoft 365 或 Office 365 組織設定所在的相同數據中心區域,或帳戶 PreferredDataLocation 中定義的數據中心區域。 如需Microsoft 365 和 Office 365 數據所在位置的詳細資訊,請造訪 Microsoft 信任中心。 如需 PreferredDataLocation 的詳細資訊,請參閱 多地理位置功能

    • Exchange ActiveSync 和自動探索的外部 URL 主機名必須發佈為服務主體,才能透過混合式設定精靈 Microsoft Entra ID。

    • 自動探索和 Exchange ActiveSync 命名空間必須可從因特網存取,且無法由預先驗證解決方案前置。

    • 請確定負載平衡器與 Exchange 伺服器之間未使用 SSL 或 TLS 卸除,因為此設定會影響 OAuth 令牌的使用。 支援 SSL 和 TLS 橋接 (終止和重新加密) 。

  4. Intune 設定:) 不支援 Intune 獨立部署和共同管理部署 (基本行動性和安全性 Microsoft 365。

  5. Microsoft 365 和 Office 365 授權

    • iOS 版和 Android 版 Outlook 免費供 iOS App Store 和 Google Play 的取用者使用。 不過,商業使用者需要包含 Office 傳統型應用程式的Microsoft 365 或 Office 365 訂閱:商務用 Microsoft 365 Apps、Microsoft 365 商務標準版、Microsoft 365 Apps 企業版 Office 365 企業版E3、Office 365 企業版 E5 或政府或教育版方案的對應版本。 具有下列訂用帳戶的商業使用者可在具有整合式螢幕 10.1 吋或更少的裝置上使用 Outlook 行動應用程式:Office 365 企業版 E1、Office 365 F1、Office 365 A1、Microsoft 365 商務基本版,如果您只有Exchange Online 沒有 Office) 的授權 (。 如果您只有 Exchange 內部部署 (Exchange Server) 授權,則您沒有使用應用程式的授權。
    • 使用進階 Exchange Online 功能 (例如,使用客戶金鑰多地理位置功能的服務加密) 需要在 Microsoft 365 系統管理 Center 內將適用的 Office 365 或Microsoft 365 訂用帳戶授權指派給內部部署使用者。

    如需如何指派授權的詳細資訊,請參閱 個別或大量新增使用者

  6. EMS 授權:每個內部部署使用者都必須具有下列其中一個授權:

    • Intune 獨立 + Microsoft Entra ID P1 或 P2 或 Microsoft Entra ID P1 或 P2
    • 企業行動力 + 安全性 E3、Enterprise Mobility + Security E5

實作步驟

若要在組織中啟用混合式新式驗證的支援,需要下列每個步驟,如下列各節所述:

  1. 建立條件式存取原則
  2. 建立 Intune 應用程式保護原則
  3. 啟用混合式新式驗證

建立條件式存取原則

當組織決定將使用者存取 Exchange 資料的方式標準化,並使用 iOS 版 Outlook 和 Android 做為終端使用者的唯一電子郵件應用程式時,他們可以設定條件式存取原則來封鎖其他行動存取方法。 iOS 和 Android 版 Outlook 會透過 Microsoft Entra 身分識別物件進行驗證,然後連線到 Exchange Online。 因此,您必須建立 Microsoft Entra 條件式存取原則,以限制行動裝置連線至 Exchange Online。 若要執行這項工作,您需要兩個條件式存取原則,每個原則都以所有潛在用戶為目標。 如需建立這些原則的詳細數據,請參閱 條件式存取:需要核准的用戶端應用程式或應用程式保護原則

  1. 請遵循使用行動 裝置要求核准的用戶端應用程式或應用程式保護原則中的步驟。 此原則允許適用於 iOS 和 Android 的 Outlook,但會封鎖 Exchange ActiveSync 行動用戶端連線到 Exchange Online 的 OAuth 和基本身份驗證。

    注意事項

    此原則可確保行動使用者可以使用適用的應用程式存取所有 Office 端點。

  2. 請遵循封鎖所有裝置上的 Exchange ActiveSync 中的步驟,以防止 Exchange ActiveSync 在非行動裝置上使用基本身份驗證的用戶端連線到 Exchange Online。

    上述原則使用授與控件 [需要應用程式保護原則],這可確保在授與存取權之前,Intune 應用程式保護原則會套用至 iOS 和 Android 版 Outlook 內的相關聯帳戶。 如果未將使用者指派給 Intune 應用程式保護原則、未獲得 Intune 授權,或應用程式未包含在 Intune 應用程式保護原則中,則原則會防止使用者取得存取令牌並取得傳訊數據的存取權。

  3. 最後,遵循使用 Microsoft Entra 條件式存取封鎖舊版驗證,以封鎖 iOS 和 Android 裝置上其他 Exchange 通訊協定的舊版驗證;此原則僅應以Microsoft 365 或 Office 365 Exchange Online 雲端應用程式和 iOS 和 Android 裝置平臺為目標。 這種方法可確保使用 Exchange Web 服務、IMAP4 或 POP3 通訊協定搭配基本身份驗證的行動應用程式無法連線到 Exchange Online。

重要事項

若要使用應用程式型條件式存取原則,必須在 iOS 裝置上安裝 Microsoft Authenticator 應用程式。 對於 Android 裝置,則會要求 Intune Company Portal 應用程式。 如需詳細資訊,請參閱使用 Intune 的應用程式型條件式存取

若要封鎖其他行動裝置用戶端, (例如行動操作系統中包含的原生郵件用戶端,) 無法連線到您的內部部署環境, (透過對 內部部署的 Active Directory) 進行基本身份驗證:

您可以使用內建的 Exchange 行動裝置存取規則,並在 Exchange 管理命令介面中設定下列命令來封鎖所有行動裝置連線:

Set-ActiveSyncOrganizationSettings -DefaultAccessLevel Block

注意事項

命令可能會影響使用其行動裝置連線到 Exchange 內部部署的使用者。

建立 Intune 應用程式保護原則

啟用混合式新式驗證之後,所有內部部署行動使用者都可以使用使用 Microsoft 365 或 Office 365 架構的 iOS 和 Android 版 Outlook。 因此,請務必使用 Intune 應用程式保護原則來保護公司數據。

使用如何建立和指派應用程式保護原則中所述的步驟,建立iOS和Android的Intune應用程式保護原則。 每個原則至少必須符合下列條件:

  1. 它們包含所有Microsoft行動應用程式,例如 Word、Excel 或 PowerPoint,因為此包含可確保使用者可以安全地存取及操作任何Microsoft應用程式內的公司數據。

  2. 它們會模擬 Exchange 為行動裝置提供的安全性功能,包括:

    • 需要 PIN 才能存取 (,其中包括選取類型、PIN 長度、允許簡單 PIN、允許指紋)
    • 加密應用程式數據
    • 封鎖受控應用程式在「已越獄」和 Root 破解的裝置上執行
  3. 它們會指派給所有使用者。 這個廣泛的指派可確保所有使用者都受到保護,無論他們是否使用iOS和Android版 Outlook。

除了上述最低原則需求之外,您還應考慮部署進階保護原則設定,例如 限制與其他應用程式的剪下、複製和貼上 ,進一步防止公司數據外洩。 如需可用設定的詳細資訊,請參閱 Microsoft Intune 中的Android應用程式保護原則設定和iOS應用程式保護原則設定

重要事項

若要對 Intune 中已註冊 Android 裝置上的應用程式套用 Intune 應用程式防護原則,使用者也必須安裝 Intune Company Portal。 如需詳細資訊,請參閱 Microsoft Intune 中的Android應用程式保護原則設定

啟用混合式新式驗證

  1. 如果您尚未啟用混合式新式驗證,請檢閱混合式新式驗證概觀中所述的必要條件,以及搭配內部部署 商務用 Skype 和 Exchange 伺服器使用它的必要條件。 完成必要條件之後,請執行如何設定內部部署 Exchange Server 以使用混合式新式驗證中的步驟。

  2. 建立 Exchange 內部部署裝置存取允許規則,以允許 Exchange Online 使用 ActiveSync 通訊協定連線到您的內部部署環境:

    If ((Get-ActiveSyncOrganizationSettings).DefaultAccessLevel -ne "Allow") {New-ActiveSyncDeviceAccessRule -Characteristic DeviceType -QueryString "OutlookService" -AccessLevel Allow}
    

    注意事項

    無法透過內部部署 Exchange 系統管理中心管理裝置。 需要 Intune 才能管理行動裝置。

  3. 建立 Exchange 內部部署裝置存取規則,以防止使用者透過 Exchange ActiveSync 通訊協定使用 iOS 版 Outlook 和 Android 連線到內部部署環境:透過 Exchange ActiveSync 通訊協定進行基本身份驗證:

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

    注意事項

    建立此規則之後,即會封鎖具有基本身份驗證使用者的iOS版 Outlook 和 Android 版。

  4. 確定您的內部部署 Exchange ActiveSync maxRequestLength 已設定為符合傳輸組態的 MaxSendSize/MaxReceiveSize:

    • 路徑:%ExchangeInstallPath%\FrontEnd\HttpProxy\Sync\web.config
    • 財產: maxRequestLength
    • 值:以 KB 大小設定 (10 MB 為 10240,例如)

不支援的用戶端功能

使用混合式新式驗證搭配 iOS 和 Android 版 Outlook 的內部部署信箱不支援下列功能。

  • 草稿資料夾和草稿訊息同步處理
  • 使用郵件清單底部的 [載入更多訊息] 鏈接檢視超過四周的電子郵件
  • 共用行事歷存取和委派行事歷存取
  • 共用和委派信箱數據存取
  • 離開的 Cortana 時間/行進時間
  • 豐富的會議位置
  • 使用 Microsoft To Do 進行工作管理
  • 增益集
  • 趣味行事曆
  • 播放我的電子郵件
  • 敏感度標籤
  • S/MIME
  • 排程傳送

只有當內部部署基礎結構使用 Exchange Server 2016 和更新版本時,才支援下列功能:

  • 行事曆附件

線上流程常見問題

:我的組織有一個安全策略,要求將因特網輸入連線限製為核准的IP位址或 FQDN。 此架構是否可以進行該設定?

:Microsoft建議開啟和存取自動探索和 ActiveSync 通訊協定的內部部署端點,且不受任何限制。 在某些可能無法執行的情況中。 例如,如果您與另一個第三方統一端點管理 (UEM) 解決方案共存,您可能會想要對 ActiveSync 通訊協定進行限制,以防止使用者在移轉至 Intune 和 iOS 版 Outlook 和 Android 版時略過 UEM 解決方案。 如果您必須在內部部署防火牆或閘道邊緣裝置上設定限制,Microsoft建議根據 FQDN 端點進行篩選。 如果無法使用 FQDN 端點,請篩選 IP 位址。 請確定允許清單中包含下列 IP 子網和 FQDN:

:我的組織目前使用第三方UEM解決方案來控制行動裝置連線能力。 在因特網上公開 Exchange ActiveSync 命名空間,可讓使用者在共存期間略過第三方 UEM 解決方案。 如何避免這種情況?

:有三種可能的解決方案可解決此問題:

  1. 實作 Exchange 行動裝置存取規則,以控制哪些裝置已核准連線。
  2. 某些第三方 UEM 解決方案會與 Exchange 行動裝置存取規則整合、封鎖未經核准的存取,同時在使用者的 ActiveSyncAllowedDeviceIDs 屬性中新增核准的裝置。
  3. 在 Exchange ActiveSync 命名空間上實作IP限制。

:是否可以使用 Azure ExpressRoute 來管理Microsoft雲端與內部部署環境之間的流量?

:連線到Microsoft雲端需要因特網連線能力。 Microsoft建議將自動探索和 Exchange ActiveSync 直接公開至因特網;如需詳細資訊,請參閱Microsoft 365 和 Office 365 網路連線原則。 不過,Exchange 混合式案例支援 Azure ExpressRoute。 如需詳細資訊,請參閱適用於 Microsoft 365 和 Office 365 的 Azure ExpressRoute

使用 ExpressRoute 時,ExpressRoute 連線沒有私人 IP 空間,也無法進行「私人」DNS 解析。 貴公司想要透過 ExpressRoute 使用的任何端點都必須在公用 DNS 中解析。 如果該端點解析為包含在與 ExpressRoute 線路相關聯之公告前置詞中的 IP, (當您在 ExpressRoute 連線) 上啟用Microsoft對等互連時,您的公司必須在 Azure 入口網站 中設定這些前置詞,從 Exchange Online 到內部部署環境的輸出聯機會透過 ExpressRoute 線路路由傳送。 您的公司必須確保與這些連線相關聯的傳回流量通過ExpressRoute線路 (避免非對稱式路由) 。

重要事項

因為適用於 Android、iOS 和 Mac 的 Outlook 也無法支援 Azure ExpressRoute (和行動原生郵件用戶端,) ,如果您打算在行動裝置或 Mac 裝置上存取電子郵件,則不建議使用 Azure ExpressRoute。 這是因為在 ExpressRoute 線路上公告給 Microsoft 的公用 IP 空間,以及在因特網線路上公告的公用 IP 空間, () 。

:假設只有四周的訊息數據會同步至 Exchange Online,這是否表示在iOS版 Outlook 和 Android 版中執行的搜尋查詢無法傳回本機裝置上可用數據以外的資訊?

:在 iOS 和 Android 版 Outlook 中執行搜尋查詢時,如果專案位於裝置上,則會傳回符合搜尋查詢的專案。 此外,搜尋查詢會透過 Exchange Online 傳遞至 Exchange 內部部署。 Exchange 內部部署會對內部部署信箱執行搜尋查詢,並將結果傳回 Exchange Online,以將結果轉送至用戶端。 內部部署查詢結果會在 Exchange Online 中儲存一天,然後再被刪除。

:如何? 知道在 iOS 版和 Android 版 Outlook 中已正確新增電子郵件帳戶嗎?

:透過混合式新式驗證新增的內部部署信箱,會在 iOS 版和 Android 版 Outlook 的帳戶設定中標示為 Exchange (混合式 ) ,如下列範例所示:

針對混合式新式驗證設定的 iOS 和 Android 版 Outlook 帳戶範例。

驗證常見問題

:混合式新式驗證和iOS版 Outlook 和 Android 支援哪些身分識別設定?

:混合式新式驗證支援下列具有 Microsoft Entra ID 的身分識別組態:

  • 同盟身分識別與 Microsoft Entra ID 支援的任何內部部署身分識別提供者
  • 透過 Microsoft Entra Connect 進行密碼哈希同步處理
  • 透過 Microsoft Entra Connect 傳遞驗證

:適用於iOS和Android版 Outlook 的驗證機制為何? 認證是否儲存在 Microsoft 365 或 Office 365?

:請參閱在 Exchange Online 中使用新式驗證的帳戶設定

:iOS 和 Android 版 Outlook 及其他Microsoft Office 行動應用程式是否支援單一登錄?

:請參閱在 Exchange Online 中使用新式驗證的帳戶設定

:在 iOS 和 Android 版 Outlook 中,Active Directory 驗證連結庫 (ADAL) 所產生和使用的令牌存留期為何?

:請參閱在 Exchange Online 中使用新式驗證的帳戶設定

:當使用者的密碼變更時,存取令牌會發生什麼事?

:請參閱在 Exchange Online 中使用新式驗證的帳戶設定

:有辦法讓使用者在將帳戶新增至 iOS 和 Android 版 Outlook 時略過 AutoDetect 嗎?

:是,用戶可以隨時略過 AutoDetect,並透過 Exchange ActiveSync 通訊協定使用基本身份驗證手動設定連線。 為了確保使用者不會透過不支援 Microsoft Entra 條件式存取或 Intune 應用程式保護原則的機制來建立與內部部署環境的連線,內部部署 Exchange 系統管理員必須設定封鎖 ActiveSync 連線的 Exchange 裝置存取規則。 若要執行這項工作,請在 Exchange 管理命令介面中輸入下列命令:

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

:當組織從iOS版和Android版 Outlook 的基本身份驗證移至混合式新式驗證時,會發生什麼事?

:在組織依照上述實作 步驟啟用混合式新式驗證之後,用戶必須在iOS版和Android版 Outlook 中刪除其現有的帳戶配置檔,因為配置檔會使用基本身份驗證。 用戶接著可以建立使用混合式新式驗證的新配置檔。

疑難排解

本節說明使用混合式新式驗證搭配 iOS 和 Android 版 Outlook 的內部部署信箱最常見的問題或錯誤。

自動探索和 ActiveSync

在設定檔建立期間,用戶應該會看到類似下列螢幕快照中的 [新式驗證] 對話框:

在成功設定混合式新式驗證期間,用戶應該會看到的對話框。

相反地,如果使用者看到下列其中一個對話框,則會發生自動探索或 ActiveSync 內部部署端點的問題。

以下是向使用者呈現舊版基本身份驗證 Exchange ActiveSync 體驗的範例:

對話框,指出使用者正在看到舊版基本身份驗證 Exchange ActiveSync 體驗。

以下範例說明當 AutoDetect 無法探索使用者內部部署信箱的設定時,使用者會看到的內容。

當 AutoDetect 無法探索其內部部署信箱的設定時,使用者會看到的對話方塊。

在任一案例中,請確認您的內部部署環境已正確設定。 若要執行這項工作:從 TechNet 資源庫下載並執行適用於 iOS 和 Android 版 Outlook 的驗證混合式新式驗證設定腳本。

當您檢閱文稿的輸出時,應該會看到來自自動探索的下列輸出:

{
    "Protocol": "activesync",
    "Url": "https://mail.contoso.com/Microsoft-Server-ActiveSync"
}

內部部署 ActiveSync 端點應該會傳回下列回應,其中 WWW-Authenticate 標頭包含authorization_uri:

Content-Length →0
Date →Mon, 29 Jan 2018 19:51:46 GMT
Server →Microsoft-IIS/10.0 Microsoft-HTTPAPI/2.0
WWW-Authenticate →Bearer client_id="00000002-0000-0ff1-ce00-000000000000", trusted_issuers="00000001-0000-0000-c000-000000000000@5de110f8-2e0f-4d45-891d-bcf2218e253d,00000004-0000-0ff1-ce00-000000000000@contoso.com", token_types="app_asserted_user_v1 service_asserted_app_v1", authorization_uri="https://login.windows.net/common/oauth2/authorize"
Www-Authenticate →Basic realm="mail.contoso.com"
X-Powered-By →ASP.NET
request-id →5ca2c827-5147-474c-8457-63c4e5099c6e

如果自動探索或 ActiveSync 回應與上述範例不類似,您可以調查下列可能原因:

  1. 如果無法連線到自動探索端點,則可能會有防火牆或負載平衡器設定問題 (例如,已設定IP限制,而且) 沒有所需的IP範圍。 此外,Exchange 前面可能有裝置需要預先驗證才能存取自動探索端點。

  2. 如果自動探索端點未傳回正確的 URL,則 ActiveSync 虛擬目錄的 ExternalURL 值會有設定問題。

  3. 如果無法連線到 ActiveSync 端點,則會有防火牆或負載平衡器設定問題。 同樣地,其中一個範例是已設定IP限制,而且不需要必要的IP範圍。 此外,Exchange 前面可能有裝置需要預先驗證才能存取 ActiveSync 端點。

  4. 如果 ActiveSync 端點未包含authorization_uri值,請使用 Exchange 管理命令介面確認 EvoSTS 驗證伺服器已設定為預設端點:

    Get-AuthServer EvoSts | Format-List IsDefaultAuthorizationEndpoint
    
  5. 如果 ActiveSync 端點未包含 WWW-Authenticate 標頭,則 Exchange 前方的裝置可能會回應查詢。

用戶端同步處理問題

有幾個案例可能會導致 iOS 版和 Android 版 Outlook 中的數據過時。 一般而言,此數據條件是因為第二個存取令牌的問題, (MRS 在 Exchange Online 中用來同步處理數據與內部部署環境) 的令牌。 此問題的兩個最常見原因為:

  • 內部部署的 SSL/TLS 卸除。
  • EvoSTS 憑證元數據問題。

使用 SSL/TLS 卸除時,會針對特定 URI 發出令牌,而該值會包含通訊協定值 (“https://”) 。 當負載平衡器卸除 SSL/TLS 時,Exchange 收到的要求會透過 HTTP 傳入,因 http:// 通訊協定值而導致宣告不符。 下列範例描述來自 Fiddler 追蹤的響應標頭:

Content-Length →0
Date →Mon, 29 Jan 2018 19:51:46 GMT
Server →Microsoft-IIS/10.0 Microsoft-HTTPAPI/2.0
WWW-Authenticate →Bearer client_id="00000002-0000-0ff1-ce00-000000000000", trusted_issuers="00000001-0000-0000-c000-000000000000@00c118a9-2de9-41d3-b39a-81648a7a5e4d", authorization_uri="https://login.windows.net/common/oauth2/authorize", error="invalid_token"
WWW-Authenticate →Basic realm="mail.contoso.com"
X-Powered-By →ASP.NET
request-id →2323088f-8838-4f97-a88d-559bfcf92866
x-ms-diagnostics →2000003;reason="The hostname component of the audience claim value is invalid. Expected 'https://mail.contoso.com'. Actual 'http://mail.contoso.com'.";error_category="invalid_resource"

如上述技術和 授權需求一節中所指定,OAuth 流程不支援 SSL/TLS 卸除。

針對 EvoSTS 憑證元數據,EvoSTS 所使用的憑證元數據偶爾會在 Microsoft 365 或 Office 365 中更新。 具有 「OrganizationCapabilityManagement」 組織功能的 Exchange 內部部署仲裁信箱負責偵測變更,以及在內部部署更新對應的元數據;此程式會每隔八小時執行一次。

Exchange 系統管理員可以使用 Exchange 管理命令介面執行下列 Cmdlet 來尋找此信箱:

$x=Get-mailbox -arbitration | ? {$_.PersistedCapabilities -like "OrganizationCapabilityManagement"};Get-MailboxDatabaseCopyStatus $x.database.name

在裝載 OrganizationCapabilityManagement 仲裁信箱資料庫的伺服器上,檢閱 MSExchange AuthAdmin 來源事件的應用程式事件記錄檔。 事件應該會告訴您 Exchange 是否可以重新整理元數據。 如果元數據已過期,您可以使用此 Cmdlet 手動重新整理它:

Set-AuthServer EvoSts -RefreshAuthMetadata

您也可以建立排程工作,每隔 24 小時執行一次上述命令。

Exchange Online 統計數據

您可以使用下列 Exchange Online Cmdlet 來查看每個已同步處理內部部署信箱的統計資訊。

  1. 首先,取得租使用者中已同步處理內部部署信箱的位置,並指定內部部署信箱的身分識別 (例如 jane@contoso.com ,) 。

    $m = Get-MailboxLocation <identity>
    
  2. 若要查看信箱相關的統計數據,請使用

    Get-MailboxStatistics $m.id
    
  3. 若要查看行動裝置統計數據 (,例如查看 iOS 和 Android 版 Outlook 上次同步至 Exchange Online) 的時間,請使用

    Get-MobileDeviceStatistics -Mailbox $m.id
    

如需詳細資訊,請參閱 Get-MailboxStatisticsGet-MobileDeviceStatistics

其他問題

還有其他問題可能會導致混合式新式驗證無法正常運作。 如需詳細資訊,請參閱 宣佈 Exchange 內部部署的混合式新式驗證中的疑難解答一節。