限制對租用戶的存取

注重安全性的大型組織想要移到 Microsoft 365 之類的雲端服務，但需要確保其使用者只能存取核准的資源。 傳統上，當公司想要管理存取時，會限制網域名稱或 IP 位址。 這種方法在軟體即服務 (或 SaaS) 應用程式裝載於公用雲端的世界中失敗，這些應用程式會在共用功能變數名稱上執行，例如 outlook.office.com 和 login.microsoftonline.com。 封鎖這些位址會讓使用者無法存取整個網路上的 Outlook，而不僅是限制他們只能存取已核准的身分識別和資源。

Microsoft Entra 對這項挑戰所提出的解決方案是一個稱為租用戶限制的功能。 藉由租用戶限制，組織可依據應用程式用於單一登入的 Microsoft Entra 租用戶來控制對 SaaS 雲端應用程式的存取。 例如，您可能想要允許組織的 Microsoft 365 應用程式存取，同時避免存取這些相同應用程式的其他組織執行個體。

藉由租用戶限制，組織可以指定允許其網路上使用者存取的租用戶清單。 Microsoft Entra ID 僅能將存取權授與給這些允許的租用戶，並封鎖所有其他租用戶，以及您使用者邀請的租用戶。

本文主要說明 Microsoft 365 租用戶限制，但此功能會保護所有將使用者傳送至 Microsoft Entra ID 的應用程式以進行單一登入。 如果您使用 SaaS 應用程式搭配與 Microsoft 365 所用租用戶不同的 Microsoft Entra 租用戶，請務必核准所有必要的租用戶。 (例如，在 B2B 共同作業案例中)。 如需有關 SaaS 雲端應用程式的詳細資訊，請參閱 Active Directory Marketplace。

租用戶功能現在也支援封鎖所有 Microsoft 取用者應用程式的使用者 (MSA 應用程式)，例如 OneDrive、Hotmail 和 Xbox.com。 這項功能會使用個別標頭至 login.live.com 端點，並詳述於本文結尾。

運作方式

整體解決方案包含下列元件：

1. Microsoft Entra ID： 如果 Restrict-Access-To-Tenants: <permitted tenant list> 標頭存在，Microsoft Entra 便只會針對已允許的租用戶發出安全性權杖。

2. 內部部署 Proxy 伺服器基礎結構：此基礎結構是能夠進行傳輸層安全性 (TLS) 檢查的 Proxy 裝置。 您必須設定 Proxy，令其將包含著租用戶允許清單的標頭，插入要送往 Microsoft Entra ID 的流量之中。

3. 用戶端軟體：為了支援租用戶限制，用戶端軟體必須直接從 Microsoft Entra ID 要求權杖，以便 Proxy 基礎結構能夠攔截流量。 瀏覽器型 Microsoft 365 應用程式目前支援租用戶限制，如同使用新式驗證 (例如 OAuth 2.0) 的 Office 用戶端。

4. 新式驗證：雲端服務必須使用新式驗證，才能使用「租用戶限制」並封鎖對所有非允許之租用戶的存取。 根據預設，您必須將 Microsoft 365 雲端服務設定為使用新式驗證通訊協定。 如需有關 Microsoft 365 支援新式驗證項目的最新資訊，請參閱更新的 Office 365 新式驗證 (英文)。

下圖說明概略的流量流程。 租用戶限制只需檢查送往 Microsoft Entra ID 的 TLS 流量，無需檢查送往 Microsoft 365 雲端服務的。 此區別很重要，因為傳送到 Microsoft Entra ID 以進行驗證的流量通常比傳送到 SaaS 應用程式 (例如 Exchange Online 和 SharePoint Online) 的流量少很多。

設定租用戶限制

開始使用租用戶限制的步驟有兩個。 第一步，確定您的用戶端可以連線到正確的位址。 第二步，設定您的 Proxy 基礎結構。

URL 和 IP 位址

若要使用租用戶限制，您的用戶端必須能夠連線至下列 Microsoft Entra URL 以進行驗證：

• login.microsoftonline.com
• login.microsoft.com
• login.windows.net

此外，若要存取 Office 365，您的用戶端必須也要能夠連線到 Office 365 URL 與 IP 位址範圍中所定義的完整網域名稱 (FQDN)、URL 和 IP 位址。

Proxy 組態和需求

以下是透過 Proxy 基礎結構啟用租用戶限制的必要設定。 本指導方針是通用的，因此如需了解特定的實作步驟，您應該參考您 Proxy 廠商的文件。

必要條件

• Proxy 必須要能夠執行 TLS 攔截、HTTP 標頭插入，以及使用 FQDN/URL 來篩選目的地。

• 用戶端必須信任 Proxy 針對 TLS 通訊所出示的憑證鏈結。 例如，如果使用來自內部公開金鑰基礎結構 (PKI) 的憑證，就必須信任內部發行的根憑證授權單位憑證。

• 需要 Microsoft Entra ID P1 或 P2 授權才能使用租用戶限制。

組態

針對 login.microsoftonline.com、login.microsoft.com 和 login.windows.net 的每個傳出要求，插入兩個 HTTP 標頭：Restrict-Access-To-Tenants 和 Restrict-Access-Context。

注意

請勿在 Proxy 設定的 *.login.microsoftonline.com 下包含子網域。 此動作會包含 device.login.microsoftonline.com 並影響用於裝置註冊和裝置型條件式存取案例的用戶端憑證驗證。 將您的 Proxy 伺服器設定為從 TLS 中斷和檢查和標頭插入中排除 device.login.microsoftonline.com 和 enterpriseregistration.windows.net 。

這些標頭應該包含下列元素︰

• 就 Restrict-Access-To-Tenants 而言，請使用 <permitted tenant list> 的值，這是您想要允許使用者存取的租用戶清單 (以逗號分隔)。 與租用戶一起註冊的任何網域都可用來在此清單中識別該租用戶，以及目錄識別碼本身。 如需描述租用戶全部三種方式的範例，允許 Contoso、Fabrikam 和 Microsoft 的名稱/值組看起來如下：Restrict-Access-To-Tenants: contoso.com,fabrikam.onmicrosoft.com,aaaabbbb-0000-cccc-1111-dddd2222eeee

• 就 Restrict-Access-Context 而言，請使用單一目錄識別碼的值，用來宣告設定租用戶限制的是哪一個租用戶。 例如，若要宣告 Contoso 是設定租用戶限制原則的租用戶，名稱/值組會顯示如下：Restrict-Access-Context: bbbbcccc-1111-dddd-2222-eeee3333ffff。 您必須在此使用您自己的目錄識別碼，以取得這些驗證的記錄。 如果您使用自己以外的任何目錄識別碼，登入記錄會在其他使用者的租用戶中顯示，並移除所有個人的資訊。 如需詳細資訊，請參閱管理員體驗。

若要尋找您的目錄識別碼：

1. 至少以全域讀者的身分登入 Microsoft Entra 系統管理中心。
2. 瀏覽至 [身分識別]>[概觀]>[概觀]。
3. 複製 [租用戶識別碼] 值。

若要驗證目錄識別碼或網域名稱是否參考相同租用戶，請在後方 URL 將<租用戶>取代為識別碼或網域：https://login.microsoftonline.com/<tenant>/v2.0/.well-known/openid-configuration。 如果具有網域和識別碼的結果相同，則其參考相同的租用戶。

若要避免使用者將其含有非核准租用戶的 HTTP 標頭插入，則當連入要求中出現 Restrict-Access-To-Tenants 標頭時，Proxy 就必須將其取代。

必須強制用戶端對 login.microsoftonline.com、login.microsoft.com 及 login.windows.net 的所有要求使用 Proxy。 雖然租用戶限制的設定需在公司 Proxy 基礎結構上完成，但系統管理員可以直接在 Azure 入口網站中存取租用戶限制報表。

使用者體驗

此節描述使用者和系統管理員的體驗。

終端使用者體驗

範例使用者位於 Contoso 網路上，但正在嘗試存取 Fabrikam 的共用 SaaS 應用程式執行個體 (例如 Outlook Online)。 如果 Fabrikam 是 Contoso 執行個體的非省略租用戶，則使用者會看到存取拒絕訊息。 拒絕訊息指出您正嘗試存取屬於 IT 部門未核准之組織的資源。

管理員體驗

雖然租用戶限制的設定是在公司 Proxy 基礎結構上完成設定，但系統管理員可以直接在 Microsoft Entra 系統管理中心中存取租用戶限制報表。 檢視報表：

1. 至少以全域讀者的身分登入 Microsoft Entra 系統管理中心。
2. 瀏覽至 [身分識別]>[概觀]>[租使用者限制]。

如果將租用戶指定為 Restricted-Access-Context 租用戶，其管理員便可以使用此報表來查看因租用戶限制原則而遭封鎖的登入，包括所使用的身分識別及目標目錄識別碼。 如果設定限制的租用戶為登入的使用者租用戶或資源租用戶，則會包含登入。

當不屬於 Restricted-Access-Context、而屬於其他租用戶的使用者登入時，此報表可能只會包含有限的資訊，例如目標目錄識別碼。 在此案例中，會遮罩使用者可識別的資訊，例如名稱和使用者主體名稱，以保護其他租用戶中的使用者資料 (例如，"{PII Removed}@domain.com" or 00000000-0000-0000-0000-000000000000 適當地取代使用者名稱和物件識別碼)。

與 Microsoft Entra 系統管理中心中的其他報告相同，您可以使用篩選來指定報告的範圍。 您可以根據特定時間間隔、使用者、應用程式、用戶端或狀態進行篩選。 如果您選取 [資料行] 按鈕，則可以選擇使用下列欄位的任何組合來顯示資料：

• 使用者 - 此欄位可以移除個人資料，其中其值設定為 00000000-0000-0000-0000-000000000000。
• 應用程式
• 狀態
• 日期
• 日期 (UTC) - UTC 為國際標準時間
• IP 位址
• 用戶端
• 使用者名稱 - 此欄位可以移除個人資料，其中其值設定為 {PII Removed}@domain.com
• 地點
• 目標租用戶識別碼

Microsoft 365 支援

Microsoft 365 應用程式必須符合兩個準則，才能完全支援租用戶限制：

1. 所使用的用戶端支援新式驗證。
2. 啟用新式驗證作為雲端服務的預設驗證通訊協定。

如需 Office 用戶端目前支援新式驗證的最新資訊，請參閱更新的 Office 365 新式驗證。 該頁面也包含在特定 Exchange Online 和「商務用 Skype Online」租用戶上啟用新式驗證的指示連結。 根據預設，SharePoint Online 已啟用新式驗證。 Teams 僅支援新式驗證，且不支援舊版驗證，因此此類許可問題並不適用於 Teams。

Microsoft 365 瀏覽器型應用程式 (例如，Office 入口網站、Yammer、SharePoint 網站及 Outlook 網頁版) 目前支援租用戶限制。 豐富型用戶端 (Outlook、商務用 Skype、Word、Excel、PowerPoint 等等) 只有在使用新式驗證時才可以強制執行租用戶限制。

支援新式驗證的 Outlook 和商務用 Skype 用戶端仍能針對未啟用新式驗證的租用戶使用傳統通訊協定，有效略過租用戶限制。 如果租用戶在驗證期間連絡 login.microsoftonline.com、login.microsoft.com 或 login.windows.net，則租用戶限制可能會封鎖使用舊版通訊協定的應用程式。

針對 Windows 上的 Outlook，客戶可以選擇實作可防止使用者將非已核准郵件帳戶新增至其設定檔的限制。 例如，請參閱防止新增非預設 Exchange 帳戶群組原則設定。

Azure RMS 和 Office 郵件加密不相容

Azure Rights Management 服務 (Azure RMS) 和Office 郵件加密功能與租使用者限制不相容。 這些功能必須將您的使用者登入至其他租用戶，以取得加密文件的解密金鑰。 由於租用戶限制封鎖對其他租用戶的存取，因此無法存取自未經授權租用戶傳送至使用者的加密電子郵件和文件。

測試

如果您想要先試用租用戶限制，然後才為整個組織實作此功能，則您有兩個選項：運用使用 Fiddler 這類工具的主機型方法，或是分段推出 Proxy 設定。

適用於主機型方法的 Fiddler

Fiddler 是一個免費的 Web 偵錯 Proxy，可用來擷取和修改 HTTP/HTTPS 流量，包括插入 HTTP 標頭。 若要設定 Fiddler 以測試租用戶限制，請執行下列步驟：

1. 下載並安裝 Fiddler。

2. 依照 Fiddler 的說明文件 (英文) 操作，設定 Fiddler 以將 HTTPS 流量解密。

3. 設定 Fiddler 以使用自訂規則來插入 Restrict-Access-To-Tenants 和 Restrict-Access-Context 標頭：

   1. 在「Fiddler Web 偵錯工具」中，選取 [Rules] (規則) 功能表，然後選取 [Customize Rules…] (自訂規則…)，以開啟 CustomRules 檔案。

   2. 在 OnBeforeRequest 函式中新增下列幾行。 將<租用戶識別碼清單>取代為向您租用戶註冊的網域 (例如 contoso.onmicrosoft.com)。 使用您租用戶的 Microsoft Entra GUID 識別碼來取代 <directory ID>。 您必須包含正確的 GUID 識別碼，記錄才會顯示在您的租使用者中。

    // Allows access to the listed tenants.
      if (
          oSession.HostnameIs("login.microsoftonline.com") ||
          oSession.HostnameIs("login.microsoft.com") ||
          oSession.HostnameIs("login.windows.net")
      )
      {
          oSession.oRequest["Restrict-Access-To-Tenants"] = "<List of tenant identifiers>";
          oSession.oRequest["Restrict-Access-Context"] = "<Your directory ID>";
      }
   
    // Blocks access to consumer apps
      if (
          oSession.HostnameIs("login.live.com")
      )
      {
          oSession.oRequest["sec-Restrict-Tenant-Access-Policy"] = "restrict-msa";
      }
   

   如果您需要允許多個租用戶，請使用逗號來分隔租用戶名稱。 例如：

   oSession.oRequest["Restrict-Access-To-Tenants"] = "contoso.onmicrosoft.com,fabrikam.onmicrosoft.com";

4. 儲存並關閉 CustomRules 檔案。

設定 Fiddler 之後，您可以移至 [File] \(檔案) 功能表並選取 [Capture Traffic] \(擷取流量)，來擷取流量。

分段推出 Proxy 設定

視您 Proxy 基礎結構的功能而定，您可能可以向使用者分段推出設定。 如需考慮，請參閱下列概略選項：

1. 使用 PAC 檔案將測試使用者指向測試 Proxy 基礎結構，同時又讓一般使用者繼續使用生產環境 Proxy 基礎結構。
2. 有些 Proxy 伺服器可以使用群組來支援不同的組態。

如需具體的詳細資料，請參閱您的 Proxy 伺服器文件。

封鎖取用者應用程式

取用者帳戶和組織帳戶都可支援的 Microsfot 應用程式 (例如 OneDrive)，有時可裝載在相同 URL 上。 這表示必須針對工作目的存取該 URL 的使用者也可以存取該 URL 以供個人使用。 根據您的作業指導方針，可能無法使用此選項。

某些組織會藉由封鎖 login.live.com 來封鎖個人帳戶進行驗證，以嘗試修正此問題。 此修正程式有數個缺點：

1. 封鎖 login.live.com 會封鎖在 B2B 來賓案例中個人帳戶的使用，這可能會侵害訪客和共同作業。
2. Autopilot 必須使用 login.live.com 以便部署。 當封鎖 login.live.com 時，Intune 和 Autopilot 案例可能會失敗。
3. 依賴裝置識別碼 login.live.com 服務的組織遙測和 Windows 更新會停止運作。

取用者應用程式的設定

當 Restrict-Access-To-Tenants 標頭作為允許清單時，Microsoft 帳戶 (MSA) 區塊會以拒絕訊號的形式運作，藉以告知 Microsoft 帳戶平台不允許使用者登入取用者應用程式。 若要傳送此訊號，sec-Restrict-Tenant-Access-Policy 標頭會使用本文 Proxy 組態和 需求一節中所述的相同公司 Proxy 或防火牆，將 login.live.com 插入至造訪的流量。 標頭的值必須是 restrict-msa。 當標頭存在且取用者應用程式嘗試直接登入使用者時，該登入會遭到封鎖。

取用者應用程式的驗證目前不會顯示在系統管理員記錄中，因為 login.live.com 與 Microsoft Entra ID 個別主控。

標頭的用途，且不會封鎖

restrict-msa 原則會封鎖取用者應用程式的使用，但允許透過多個其他類型的流量和驗證：

1. 裝置的無使用者 (User-less) 流量。 這選項包括 Autopilot、Windows Update 和組織遙測的流量。
2. 取用者帳戶的 B2B 驗證。 具有 Microsoft 帳戶且受邀與租使用者共同作業的使用者會向 login.live.com 進行驗證，以便存取資源租用戶。
   1. 這項存取是使用 Restrict-Access-To-Tenants 標頭來控制，以允許或拒絕對該資源租用戶的存取。
3. 「傳遞」驗證，由許多 Azure 應用程式和 Office.com 所使用，其中應用程式會使用 Microsoft Entra ID 在取用者內容中登入取用者使用者。
   1. 此存取也會使用 Restrict-Access-To-Tenants 標頭來控制，以允許或拒絕存取特定「傳遞」租使用者 (f8cdef31-a31e-4b4a-93e4-5f571e91255a)。 如果此租用戶未出現在您允許網域的 Restrict-Access-To-Tenants 清單中，Microsoft Entra ID 會封鎖取用者帳戶登入這些應用程式。

不支援 TLS 中斷和檢查的平台

租用戶限制取決於 HTTPS 標頭中允許租用戶清單的插入。 此相依性需要傳輸層安全性檢查 (TLSI) 來中斷和檢查流量。 對於客戶端無法中斷和檢查流量以新增標頭的環境，租用戶限制無法運作。

以 Android 7.0 和更新版本為例。 Android 變更其處理受信任憑證授權單位 (CA) 的方式，為安全的應用程式流量提供更安全的預設值。 如需詳細資訊，請參閱 Android Nougat 中受信任憑證授權單位的變更。

遵循 Google 的建議，Microsoft 用戶端應用程式預設會忽略使用者憑證。 此原則可讓這類應用程式無法使用租用戶限制，因為網路 Proxy 所使用的憑證會安裝在使用者憑證存放區中，用戶端應用程式不信任這些憑證。

對於無法中斷和檢查流量以將租用戶限制參數新增至標頭的環境，Microsoft Entra ID 的其他功能可以提供保護。 下列清單提供有關這類 Microsoft Entra 功能的詳細資訊。

• 條件式存取：只允許使用受控/相容裝置
• 條件式存取：管理訪客/外部使用者的存取
• B2B 共同作業：針對 "Restrict-Access-To-Tenants" 參數中列出的相同租用戶，依據跨租用戶存取限制輸出規則
• B2B 共同作業：將 B2B 使用者的邀請限制為 "Restrict-Access-To-Tenants" 參數中列出的相同網域
• 應用程式管理：限制使用者同意應用程式的方式
• Intune：透過 Intune 套用應用程式原則，以將受管理應用程式使用限制為僅限已註冊裝置的 UPN - 檢查下方的區段，只允許在應用程式子標題中設定的組織帳戶。

不過，某些特定案例只能使用租用戶限制來涵蓋。

下一步

• 閱讀更新的 Office 365 新式驗證 (英文)
• 檢閱 Office 365 URL 與 IP 位址範圍