限制對租使用者的存取

發行項
03/14/2024

強調安全性的大型組織想要移至 Microsoft 365 等雲端服務，但必須知道其使用者只能存取核准的資源。傳統上，當公司想要管理存取權時，會限制功能變數名稱或IP位址。這種方法在軟體即服務（或 SaaS）應用程式裝載於公用雲端的世界中失敗，這些應用程式會在和 login.microsoftonline.com等outlook.office.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 ，本文結尾會詳述。

運作方式

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

Microsoft Entra 識別碼：如果 Restrict-Access-To-Tenants: <permitted tenant list> 標頭存在，Microsoft Entra 只會為允許的租用戶發出安全性令牌。
內部部署 Proxy 伺服器基礎結構：此基礎結構是能夠進行傳輸層安全性 (TLS) 檢查的 Proxy 裝置。您必須設定 Proxy，將包含允許租使用者清單的標頭插入至以 Microsoft Entra ID 為目標的流量。
客戶端軟體：若要支援租使用者限制，用戶端軟體必須直接從 Microsoft Entra ID 要求令牌，讓 Proxy 基礎結構可以攔截流量。瀏覽器型 Microsoft 365 應用程式目前支援租用戶限制，如同使用新式驗證 (例如 OAuth 2.0) 的 Office 用戶端。
新式驗證：雲端服務必須使用新式驗證來使用租使用者限制，並封鎖對所有未省略租使用者的存取。根據預設，您必須將 Microsoft 365 雲端服務設定為使用新式驗證通訊協定。如需 Microsoft 365 新式驗證支援的最新資訊，請參閱更新的 Office 365 新式驗證。

下圖說明高階流量流程。租使用者限制僅需要 TLS 檢查 Microsoft Entra ID 的流量，而不是 Microsoft 365 雲端服務的流量。這項區別很重要，因為向 Microsoft Entra ID 進行驗證的流量量通常比 Exchange Online 和 SharePoint Online 等 SaaS 應用程式的流量量要低得多。

Diagram of tenant restrictions traffic flow.

設定租使用者限制

有兩個步驟可開始使用租使用者限制。首先，請確定您的用戶端可以連線到正確的位址。其次，設定 Proxy 基礎結構。

URL 和IP位址

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

此外，若要存取 Office 365，您的用戶端也必須能夠連線到 Office 365 URL 和 IP 位址範圍中定義的完整功能變數名稱（FQDN）、URL 和 IP 位址。

Proxy 組態和需求

需要下列設定，才能透過 Proxy 基礎結構啟用租使用者限制。本指南是泛型的，因此您應該參考 Proxy 廠商的檔以取得特定實作步驟。

必要條件

Proxy 必須使用 FQDN/URL 來執行 TLS 攔截、HTTP 標頭插入和篩選目的地。
客戶端必須信任 Proxy 針對 TLS 通訊所提供的憑證鏈結。例如，如果使用來自內部公開金鑰基礎結構 (PKI) 的憑證，就必須信任內部發行的根憑證授權單位憑證。
需要 Microsoft Entra ID P1 或 P2 授權才能使用租使用者限制。

組態

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

注意

請勿在 Proxy 設定中包含子 *.login.microsoftonline.com 域。這麼做會包含 device.login.microsoftonline.com 並干擾客戶端憑證驗證，這會在裝置註冊和裝置型條件式存取案例中使用。將您的 Proxy 伺服器設定為從 TLS 中斷和檢查和標頭插入中排除和enterpriseregistration.windows.net排除device.login.microsoftonline.com。

標頭應該包含下列元素：

針對 Restrict-Access-To-Tenants，請使用允許的 <租使用者清單>值，這是您想要允許使用者存取的租使用者逗號分隔清單。任何向租用戶註冊的網域都可以用來識別此清單中的租使用者，以及目錄標識符本身。如需描述租用戶全部三種方式的範例，允許 Contoso、Fabrikam 和 Microsoft 的名稱/值組看起來如下：Restrict-Access-To-Tenants: contoso.com,fabrikam.onmicrosoft.com,72f988bf-86f1-41af-91ab-2d7cd011db47
針對 Restrict-Access-Context，請使用單一目錄標識碼的值，宣告哪個租使用者正在設定租使用者限制。例如，若要宣告 Contoso 是設定租用戶限制原則的租用戶，名稱/值組會顯示如下：Restrict-Access-Context: 456ff232-35l2-5h23-b3b3-3236w0826f3d。您必須在這裡使用自己的目錄識別碼來取得這些驗證的記錄。如果您使用您自己的任何目錄標識碼，登入記錄檔 *會出現在其他人的租使用者中，並移除所有個人資訊。如需詳細資訊，請參閱管理員體驗。

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

以至少全域讀者身分登入 Microsoft Entra 系統管理中心。
流覽至 [身分識別概>觀>概觀]。
複製 [ 租用戶標識符 ] 值。

若要驗證目錄識別碼或功能變數名稱參考相同的租使用者，請使用該標識碼或網域取代 <此 URL 中的租> 使用者： https://login.microsoftonline.com/<tenant>/v2.0/.well-known/openid-configuration。如果具有網域和識別碼的結果相同，則其參考相同的租用戶。

若要防止使用者以未核准的租使用者插入自己的 HTTP 標頭，如果傳入要求中已有 Restrict-Access-To-Tenants 標頭，Proxy 就必須取代 Restrict-Access-To-Tenants 標頭。

用戶端必須強制針對、 login.microsoft.com和 login.windows.net的所有要求login.microsoftonline.com使用 Proxy。例如，如果使用 PAC 檔案將用戶端導向使用 Proxy，則使用者不應該能夠編輯或停用 PAC 檔案。

用戶體驗

本節說明終端使用者和系統管理員的體驗。

終端使用者體驗

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

Screenshot of tenant restrictions error message, from April 2021.

管理體驗

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

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

指定為 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 應用程式必須符合兩個準則，才能完全支援租用戶限制：

使用的用戶端支援新式驗證。
新式驗證會啟用為雲端服務的預設驗證通訊協定。

如需 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 Service （RMS）和 Office 郵件加密功能與租使用者限制不相容。這些功能依賴將使用者登入其他租使用者，以取得加密檔的解密密鑰。由於租使用者限制會封鎖對其他租使用者的存取，因此無法存取從不受信任的租用戶傳送給使用者的加密郵件和檔。

測試

如果您想要在針對整個組織實作租使用者限制之前先試用租使用者限制，您有兩個選項：使用 Fiddler 之類的工具，或使用 Proxy 設定的分段推出主機型方法。

以主機為基礎的方法的 Fiddler

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

下載並安裝 Fiddler。
根據 Fiddler 的說明檔，將 Fiddler 設定為解密 HTTPS 流量。
設定 Fiddler 以使用自定義規則插入 Restrict-Access-To-Tenants 和 Restrict-Access-Context 標頭：
1. 在 Fiddler Web 調試程式工具中，選取 [ 規則 ] 功能表，然後選取 [ 自定義規則... ] 以開啟 CustomRules 檔案。
2. 在函式 OnBeforeRequest 中新增下列幾行。以向租用戶註冊的網域取代 <租用戶標識碼> 清單（例如， contoso.onmicrosoft.com）。以租使用者的 Microsoft Entra GUID 識別碼取代 <目錄> 標識碼。 您必須包含正確的 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";
儲存並關閉 CustomRules 檔案。

設定 Fiddler 之後，您可以移至 [檔案 ] 功能表，然後選取 [擷取流量] 來擷取流量。

Proxy 設定的分段推出

視 Proxy 基礎結構的功能而定，您可以暫存對用戶的設定推出。如需考慮，請參閱下列高階選項：

使用 PAC 檔案將測試使用者指向測試 Proxy 基礎結構，而一般使用者則繼續使用生產 Proxy 基礎結構。
某些 Proxy 伺服器可能支援使用群組的不同組態。

如需特定詳細數據，請參閱您的 Proxy 伺服器檔。

封鎖取用者應用程式

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

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

封鎖 login.live.com 會封鎖 B2B 來賓案例中的個人帳戶使用，這可能會干擾訪客和共同作業。
Autopilot 需要使用 login.live.com 才能部署。當封鎖時 login.live.com ，Intune 和 Autopilot 案例可能會失敗。
依賴裝置標識碼 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 會封鎖取用者應用程式的使用，但允許透過數種其他類型的流量和驗證：

裝置的使用者較少流量。此選項包含 Autopilot、Windows Update 和組織遙測的流量。
取用者帳戶的 B2B 驗證。受邀與租使用者共同作業的 Microsoft 帳戶用戶會進行驗證以 login.live.com，以存取資源租使用者。
1. 此存取是使用 Restrict-Access-To-Tenants 標頭來控制，以允許或拒絕該資源租使用者的存取權。
許多 Azure 應用程式和 Office.com 所使用的「傳遞」驗證，其中應用程式會使用 Microsoft Entra 識別碼在取用者內容中登入取用者使用者。
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 - 檢查下一節， 只允許在應用程式 子標題中設定的組織帳戶。

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