Restrict users to a specific office 365 tenant via Forcepoint Content Gateway proxy
- Article Number: 000017790
- Products: Forcepoint Web Security, TRITON AP-WEB
- Version: 8.5, 8.4, 8.3
- Last Published Date: January 13, 2021
Notes & Warnings
Important SSL decryption must be enabled at the Forcepoint Content Gateway proxy for the requests to the Office 365 application that the end-users access. Similarly, The WCG will not be able to insert the custom headers if either the Office365 SSL Decryption Bypass or Content Gateway Bypass features are enabled. Phase 1 of the configuration
To prevent users from inserting their own HTTP header with non-approved tenants, the proxy needs to replace the Restrict-Access-To-Tenants header if it is already present in the incoming request.
Clients must be forced to use the proxy for all requests to login.microsoftonline.com, login.microsoft.com, and login.windows.net. For example, if PAC files are used to direct clients to use the proxy, end-users shouldn't be able to edit, disable the PAC files or explicit proxy configuration.
For Restrict-Access-To-Tenants, use a value of <permitted tenant list>, which is a comma-separated list of tenants you want to allow users to access. Any domain that is registered with a tenant can be used to identify the tenant in this list. For example, to permit access to both Contoso and Fabrikam tenants, the name/value pair looks like: Restrict-Access-To-Tenants: contoso.onmicrosoft.com,fabrikam.onmicrosoft.com. This is controlled at the O365 portal where the tenants were created.
The above configuration manages the client connection to the Microsoft SaaS tenant. For more information see Microsoft's documentation Tenant Restrictions. To restrict Forcepoint Web Security Cloud hosted users to specific Office 365 Tenants please see steps in article Restrict users to specific Office 365 Tenants |
Problem Description
How to allow access to your organization’s Office 365 applications, while preventing access to other organizations’ instances of these same applications and restrict end-users from logging into accounts of Office 365 tenancies that do not belong to my organisation. I would like to control the access via Forcepoint Content Gateway proxy. |
Resolution
Watch Video: Web Security Proxy Configurations for Microsoft Office 365 documenting the following steps: For each incoming request to login.microsoftonline.com, login.microsoft.com, and login.windows.net, insert two HTTP headers: Restrict-Access-To-Tenants and Restrict-Access-Context.
add_hdr dest_domain login.microsoftonline.com Restrict-Access-To-Tenants=tenant.onmicrosoft.com
add_hdr dest_domain login.microsoft.com Restrict-Access-To-Tenants=tenant.onmicrosoft.com add_hdr dest_domain login.windows.net Restrict-Access-To-Tenants=tenant.onmicrosoft.com
add_hdr dest_domain login.windows.net Restrict-Access-To-Tenants=tenant1.onmicrosoft.com,tenant2.onmicrosoft.com
You can add a source IP range to match only a range of users in the organisation. This is optional and is not necessary for the tenancy to work but restrict the configuration only to IP range set. This option is good for migration of the policy as a testbed.
For Restrict-Access-Context, use the value of a single directory ID, declaring which tenant is setting the tenant restrictions. For example, to declare Tenant1 as the tenant that set the tenant restrictions policy, the name/value pair looks like: Restrict-Access-Context: 456ff232-35l2-5h23-b3b3-3236w0826f3d. Any domain that is registered with a tenant can be used to identify the tenant in this list
add_hdr dest_domain login.microsoftonline.com Restrict-Access-Context=
add_hdr dest_domain login.microsoft.com Restrict-Access-Context= add_hdr dest_domain login.windows.net Restrict-Access-Context= Keywords: Restrict-Access_Context; Restrict-Access-To-Tenants; tenant; header injection; custom header; tenant restriction; azure; office365; saas; O365; bypass; decryption; wcg; onpremise; filter.config |
Article Feedback
Want 24/7 Tech Support?
Learn more