SaaS App Gating Office 365 with Azure AD
Configure Azure AD to only allow access to Office 365 through Twingate.
This guide is a practical example of the instructions described in Azure Active Directory SaaS App Gating. We will walk through setting up Microsoft Azure AD Conditional Access to allow access to Office 365 applications via a Twingate Remote Network, and deny other access methods.
- Office 365 Business Subscription
- License for Azure AD Conditional Access (licensing information here)
- At least one deployed Connector with an associated public IP address (make a note of the public IP address associated with each Connector as we will use it later)
1. Add a Twingate Resource
Sign into the Twingate Admin Console. In the Remote Network containing the Connectors that will be used for access, create a Twingate Resource for Office 365:
Depending on the Microsoft Apps you would like to protect, you may need to add more Twingate Resources mapped to public URLs. For example:
2. Setup Azure AD Conditional Access
Azure AD Conditional Access is used to restrict access to services based on specific policies. This guide shows how to set up a simple policy to restrict access to one user, but you should create a policy definition that addresses your own requirements.
If configured incorrectly, Conditional Access can lock accounts out from the Azure portal, including global admin accounts. Please ensure you check your policy carefully before applying it.
2.1. Add a trusted location
First, we need to add a trusted location in Azure. Navigate to the Azure AD Conditional Access configuration page and click “Named locations”:
This location will represent the public IP address of our Connector. Give it a name and enter the public CIDR address of the Connector:
2.2. Configure Conditional Access
For the new trusted location in our Conditional Access policy, specify that access to Office 365 applications will only be allowed when routing via the Connector’s public IP address.
Click on “Policies”, then “New policy” from the Conditional Access configuration screen. You will then be asked to configure the policy giving it a name:
In the example above, we have defined the policy to apply only to a specific “TEST” user account. You should configure who the policy will apply to based on your own requirements, although we recommend testing the policy on a single account before applying it to a wider group.
Next, we will specify which apps this policy is applied to. In this case, Office 365:
Finally, we need to add an access condition that is configured to include any location:
And also exclude our trusted location:
This condition needs to be configured to Block access under the Grant section:
This configuration may sound counterintuitive, so let’s recap how the location condition works:
If a user connects from any location except our trusted location (the Connector’s public IP address), then access will be denied. This means that if a user connects from the Twingate’s Connector’s public IP address, access will be granted.
2.3. Enable the policy
Now it’s time to enable our new policy. We recommend first enabling the policy as “Report-only” for testing, and then toggle it to “On” when you’re ready:
This completes the configuration. Twingate users can now access the Office 365 Resource by signing into their Twingate Client and connecting to Office 365. Any requests to this domain will automatically route via the Connector and be allowed by the Conditional Access policy. You should also see this activity appear in the Conditional Access logs.
Last updated 8 hours ago