Enabling Azure Active Directory Tenant Restrictions with F5

Microsoft’s Azure Active Directory(Azure AD) is the largest cloud-based enterprise directory in the world.  According to the data presented at the Microsoft Ignite conference, it has more than 750 million user accounts and handles more than 1.3 billion authentications per day.   Azure AD is the heart that powers access to Microsoft’s Office 365 application suite, so every customer that uses Office 365 or Azure cloud is using Azure AD. 

Of course, with adoption of SaaS apps such as Office 365, enterprises face challenge with data security and access restrictions.  For example, many customers from various compliance-intensive verticals need to have stricter controls over which Azure AD identities can access Office 365 from with the boundaries of the corporate network(or even outside of it from corporate-owned assets). For many years, customers struggled with that challenge, as Microsoft did not have a native solution to address it.  For example, take a look at how one of the Office 365 customers frames the question about their needs to restrict access to Office 365 from their network:

Fortunately, Microsoft has listened to their customer needs, and has recently released the Tenant Restriction option for Azure AD.  Microsoft says that they have developed this feature with extensive input from their customers, especially those in financial, healthcare, and pharmaceutical industries.  From the description that Microsoft provides, their implementation is similar to Google's, but they actually require two headers:  

Restrict-Access-To-Tenants:  and 
Restrict-Access-Context: 

This approach appears to be more sophisticated, because it not only ensures a variety of tenants to be customized to meet the organizational access needs, but it also specifies the Azure AD anchor - the tenant that is setting these restrictions.  Since the directory id is not commonly accessible to anyone but the tenant admin, this feature provides greater security against abuse and/or misuse by unauthorized parties.  Below, you can find a sample Microsoft diagram and flow of how the Tenant Restriction options works, where I took liberty of placing an F5 device in place of a generic proxy that handles header insertion.  Of course, your deployment of proxies or F5 devices on your network might differ, but this is just a start to explain how F5 helps facilitate the implementation of this feature.

F5 already provides a broad range of unique solutions for enhancing security to Office 365.  In addition, the need for overall SSL visibility and dynamic service chaining of the outbound traffic are driving rapid adoption of new F5 solutions such as SSL Orchestrator and Secure Web Gateway.   All this aligns really well with enabling customers to implement new Azure AD Tenant Restrictions using their F5 investment by making a small change to existing configuration.

For example, in order to implement Azure AD Tenant Restrictions in my Secure Web Gateway demo environment, I added a simple macro to take care of identifying traffic destined to Microsoft’s authentication service and insert the required headers.  

And here’s how I am inserting the required headers:

Of course, if you’re running SSL Orchestrator, you can implement similar functionality in the construct of that configuration.  I’m really excited about Microsoft’s release of the Tenant Restrictions feature, as it will drive increased adoption and better security for enterprises using Office 365, and I hope that many of our existing and future customers will leverage the appropriate F5 product to help them easily achieve better security posture with using Office 365.