Microsoft releases new “Tenant Restriction” capability

A few days ago, Microsoft announced the General Availability of the “Tenant Restriction” capability. Although I have not been able to play with it so far, I wanted to take a few moments to reflect on the usefulness of the feature following a debate I had with a customer questioning me why they would be interested in something like this.

The Tenant Restriction capability, as the name already implies, allows an administrator to restrict access to a specific tenant. You might wonder how this is different from e.g. disallowing someone to authenticate by e.g. disabling their account? In the latter scenario, the user might not be able to use their account to login to e.g. Office 365, but that won’t prevent them from accessing other tenants (with other identities). From a data leakage point-of-view, the latter can be potentially dangerous. Maybe this is best explained with an example.

Let’s say a user called George works for Belgian Waffle House ltd. They have a tenant in Office 365 called “bwf.onmicrosoft.com”. George also works for a non-profit organization called the Belgian Chocolate Lovers and, they too, have a tenant in Office 365 called “bcl.onmicrosoft.com”. When no tenant restrictions have been configured, George can login to the bwf.onmicrosoft.com tenant (as he should!), but nothing would prevent him from logging in into bcl.onmicrosoft.com while at work. One might question why this is a problem, but let’s assume for a second that George first logged into the bwf.onmicrosoft.com tenant and downloaded some corporate documents. Perhaps these documents describe a new merger plan between the Belgian Waffle House and some Swiss Chocolate maker… As a Belgian chocolate lover, he might be interested in that! Either way, after downloading the document, he then logs into the bcl.onmicrosoft.com tenant and can upload the files there. The reason why he is able to login to both tenants is because the endpoint (e.g. login.microsoftonline.com) is a single endpoint for all tenants, world-wide. Blocking the endpoint (e.g. through a proxy server) would also prevent George to login into the bwf.onmicrosoft.com tenant.

Of course, there’s other ways to restrict access –but those pertain to accessing the tenant itself. For instance, an administrator can define a set of corporate IP addresses from which a user is allowed to authenticate into the corporate tenant. While this effectively prevents someone from accessing the tenant outside the corporate network, it doesn’t solve the problem described above.

The way this new Tenant Restriction capability works, is quite simple and the process isn’t really new. When a user authenticates to Azure AD (and thus a service which relies on Azure AD), the authentication platform will also look for a (HTTP) header called “Restrict-Access-To-Tenants“. The value of this header should contain all the tenants the user is allowed to access. If the tenant that the user is trying to authenticate to is listed, access is granted. If not, a warning message is displayed:

Image source: Microsoft.

A few things to reflect upon:

  • For this to work, there must be (some sort of) a proxy server between the user and the internet. Basically, anything that can add a header will do. If you want to ensure the limitation to access a tenant is maintained, e.g. also outside the corporate network, the user must always access the internet through a proxy server that injects the header. For this to work, other counter measures (such as ensuring the user cannot modify proxy settings etc.) must be present. Additionally, the proxy server must be accessible from outside the corporate network as well. One thing that would fit this requirement is a “proxy-as-a-service” such as e.g. ZScaler. But there’s others too.
  • The tenant restriction capability is not something you configure in Azure. Instead, it relies solely on your network infrastructure (proxy, ssl device, …) to inject the header. As such, the latter is quite important and you must consider the implications of doing so.
  • The feature only works with Modern Authentication. This is fine for the majority of Microsoft’s own application, but if you use other applications or even built-in ActiveSync apps, you must block access for those “legacy” apps if you want to maintain the restriction.
  • You can use the feature for free with Office 365, but have to buy a premium license if you want to restrict access to other applications relying on Azure AD for authentication.
  • The process described above only needs to be applied to the authentication process, hence thus only for the Azure AD endpoints. Users must not necessarily go through a proxy for access to e.g. SharePoint online or Exchange online.
  • Given the reliance on Modern Authentication, and because you cannot control how other tenants are setup, if those tenants still allow legacy authentication (e.g. basic auth), the restriction is bypassed (d’oh!). I hope/expect this to change in the future. However, if you also control the endpoint (and thus can control what applications can be used), it is still very effective.

As you can see, while the feature is pretty cool, it’s not 100% watertight. Perhaps that is a problem, perhaps not. It really depends on what your use case is for implementing it. However, if DLP is on your mind, every little thing can help and it can be an efficient way to stop the majority of the users of (accidentally) leaking sensitive data. Of course, it’s only a small cog in a much bigger machine as there’s many other features in Office 365 (and beyond) that can help you to prevent data leakage.

For more details, please read the announcement from Microsoft here.

 

Blog Office 365

Selective authentication for (sub-)domains in Office 365

Office 365 provides various authentication options, such as cloud-IDs, Password Hash Synchronization or federated identities. Leaving out the specifics on how each of these options work, all of them are configured per domain. Whenever trying to access services in Office 365, the user is required to authenticate using its User Principal Name. For sake of simplicity, the general advise it to configure the UPN to match the email address which makes it less confusing for them.

Blog Identity & Security Office 365

Windows Server 2012 R2 ADFS ‘alternative login ID’, removes the need to have an internet-routable UPN

Recently, Microsoft released an update to Windows Server 2012 R2 which – next to a bunch of bug fixes – also includes new features to some of the Operating System’s components. Amongst these new features there’s one that I found particularly interesting, more specifically the update to the AD FS 3.0 component which enables customers to use a different attribute to identify federated uses in Windows Azure AD. The feature itself is better known as “Alternate Login ID”.

As the TechNet documentation on this topic describes, it would now be possible to use a different attributed from the User Principal Name to identify federated users in Office 365. This helps customers who aren’t able to change their UPNs from the current value (like e.g. domain.local or domain.corp) to an internet-routable domain (like domain.com). Even though that in many situations changing the UPN isn’t a big of a deal, some customers leverage the existing UPN in third party applications and therefore might not be able to make this change easily.

If you want to deploy this feature, you’ll have to figure some things out by yourself. The documentation that is currently available doesn’t explain all the steps. At least, that is if you want to implement it right away. I expect the documentation to become available shortly. Also mind that I haven’t seen any official statement that the use of “Alternate Login ID” is already supported by Office 365 today, but the documentation certainly hints to it and if I recall correctly, it was also announced at the Microsoft Exchange Conference, last week.

The configuration itself requires you to jump through a few hoops, including modifying DirSync to refer to the new attribute you’ve selected as being the Alternate Login ID instead of the UPN. Personally, I would still recommend changing the UPN – if possible. But there’s an alternative now and having alternative is always good thing, isn’t it?

I’ll definitely have a go at this later this week and will post my findings here.

-Michael

[Update 04/14/2014] Here’s the KB article describing the update I reference in this article: http://support.microsoft.com/kb/2927690

 

ADFS Blog Exchange Exchange 2013 Hybrid Exchange News Office 365