In the article from Microsoft is a summary of headers to add to proxy devices to control Office 365 access using tenant restrictions. This article describes how to implement those headers on ProxySG and Advanced Secure Gateway (ASG).
Follow steps below to modify request headers to restrict the tenant used for Office 365 access:
Access the ProxySG or Advanced Secure Gateway (ASG) Management Console.
Launch the Visual Policy Manager (VPM) by going to Configuration->Policy-Visual Policy Manager and press the Launch button in the Management Console.
Within VPM click the Policy menu item and press Add Web Access Layer... Optionally, give the new Web Access Layer a distinctive name (O365 Tenant Restriction Layer in this example) and press OK.
In the first rule edit the Destination 'Any' object by right clicking on it. In the popup window press the New button and add a Combined Destination Object. In that Combined Object give it a distinctive name (optional) and Add New Request URL entries for the following hosts: login.microsoftonline.com, login.microsoft.com, and login.windows.net. Add those Request URL objects to the upper right box of the Combined Destination Object and press OK. The completed Destination Object will look like the following:
In the first rule edit the Action 'Deny' object by right clicking on it. In the popup window press the New button and add a Combined Action Object. In that Combined Action Object give it a distinctive name (optional) and add two Control Request Header objects for headers Restrict-Access-To-Tenants and Restrict-Access-Context. Using the 'Contoso' example from Microsoft's article, here are screenshots of what the two Control Request Header objects for each header would look like individually and added to the combined object:
The completed layer and rule will look like the the following:
Press the Install policy button in VPM to apply the policy.
Microsoft has also provided further clarity regarding the the following:
For the header Restrict-Access-Context you cannot configure the tenant ID for multiple domains by design, this header is for reporting purposes and for stating which is the tenant that has enabled the policy.
The tenant ID inserted here will be the tenant where you will be able to check the reports: “A second header, called Restrict-Access-Context, is used to enable reporting capabilities and help Microsoft support troubleshoot issues. Restrict-Access-Context needs to include the tenant which is configuring the policy. For example, the following header would indicate that Contoso configured the policy, and reporting would be enabled in the Contoso tenant: Restrict-Access-Context: contoso.onmicrosoft.com”
Optionally, if CPL is preferred over using the VPM the following CPL can be installed in a local policy file or CPL layer within the VPM that will accomplish the same goal:
; ------- Beginning of O365 Tenant Restriction CPL -----------
condition=TenantRestrictionDestinations action.Restrict-Access-Context-Set-Header(yes) action.Restrict-Access-To-Tenants-Set-Header(yes)define condition TenantRestrictionDestinations
end condition TenantRestrictionDestinations; Change directory ID below:
define action Restrict-Access-Context-Set-Header
end action Restrict-Access-Context-Set-Header; Change tenant list below:
define action Restrict-Access-To-Tenants-Set-Header
end action Restrict-Access-To-Tenants-Set-Header; ------- End of O365 Tenant Restriction CPL -----------
Client HTTPS requests to hosts login.microsoftonline.com, login.microsoft.com, and login.windows.net will have the headers added to them if SSL interception is enabled on the proxy. See article https://support.symantec.com/en_US/article.TECH241137.html for details on how to enable SSL interception
Please note the Tenant ID is not strickly speaking needed for this policy to work, it is added here for complentness.
Subscribing will provide email updates when this Article is updated. Login is required to Subscribe