KB Article | Forcepoint Support

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
  1. Configured the proxy with the tenant restriction to secure and preserve your access to your Microsoft O365 tenant.
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.
  1. The tenant rule can be modified to allow more tenants in the Restrict-Access-To-Tenants
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.

  1. Browse to Configure > Security > Access Control > Filtering in the Forcepoint Content Gateway manager.
  2. Click the Edit File button. A new tab will open.
  3. Set Rule Type to add_hdr.
  4. Set Primary Destination Value to login.microsoftonline.com then login.microsoft.com and then login.windows.net, you need to repeat this configuration for each domain (login.microsoft.com).
  5. Under Additional Specifiers:
    • Set Custom Header to Restrict-Access-To-Tenants.
    • Set Header Value to tenant1.onmicrosoft.com,tenant2.onmicrosoft.com only if you would like to restrict connection to two tenants.
  6. Set Rule Type to add_hdr.
  7. Set Primary Destination Value to login.microsoftonline.com then login.microsoft.com and then login.windows.net, you need to repeat this configuration for each domain (login.microsoft.com).
  8. Under Additional Specifiers:
    • Set Customer Header to Restrict-Access-Context= 
    • Set Header Value to 456ff232-35l2-5h23-b3b3-3236w0826f3d - this content string has to be your organization directory ID.
  9. You can add any Secondary Specifiers which are optional, as an example you can restrict the configuration to a specific range of user by IPs, or even a single IP address.
    • Uses Range format, not CIDR.
    • Example: 1.1.1.1 or 0.0.0.0-255.255.255.255 
  10. Click Add and then Apply.
 
  • A general rule should look like below:
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
  • Example of both domains
add_hdr dest_domain login.windows.net Restrict-Access-To-Tenants=tenant1.onmicrosoft.com,tenant2.onmicrosoft.com
  • Example of an additional secondary specifier
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.  
  • Example for Restrict-Access-Context
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



Thank you for the feedback and comments.