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

“Conference season” is about to start!

Every year in September, right after the summer holidays, there is an unofficial start of a new “work season”. For some this unofficial start moment comes a bit earlier, for others a bit later. Some even say their work season lasts the entire year… But that’s besides the point. The fall traditionally also heralds a myriad of tech conferences, each fighting for a moment in the spotlights. With Microsoft’s massive Ignite conference moving in from May, this year’s “conference season” promises to be exceptionally busy.

I’ve always liked going to conferences. Although content is important, having the opportunity to talk to peers and interact with the speakers (experts) is something I’ve learned to value more and more with each conference I attended in the past.

This year, I’m lined up to speak at a bunch of conferences again. If you have read some of my previous announcements, you’ll notice that I’m speaking at a pretty much the same conferences as before. Continue reading to find out why!

Blog Events News

Latest security bulletin addresses vulnerability in AD FS

The April 2015 Security Bulletin, Microsoft released an update for Active Directory Federation Service 3.0 which comes with Windows Server 2012 R2.

According to the documentation, the vulnerability would allow an attacker to gain access to an application – such as Office 365. Apparently the flaw is in the logoff process. As I understand it from the limited information available, although the user appears to have logged off, the logoff actually failed allowing an attacker to re-use the existing token to access the application as the user.

Although the bulletin mentions that Microsoft has no knowledge of any cases where this vulnerability was exploited, I personally wouldn’t wait for it to happen to me… 🙂

More information can be found here: https://technet.microsoft.com/library/security/MS15-040

ADFS Blog News Office 365

Building an enterprise security strategy for Exchange

These days, the news is all about big brother watching us. You can’t open a newspaper of watch news on TV without being slammed with the news that one or the other intelligence agency is actively gathering information from other nations or important enterprises.

Especially the later case makes one wonder what you can do about it? I don’t believe there is a 100% safe system. However, there’s nothing wrong with trying to make an attacker’s life as hard as possible. There are many ways to do this and having a multi-layered defense is what you should be looking at. However, it’s not only about protecting your network or access to your network, it’s also about protecting your applications.

Recently, I wrote an article about some simple things you can do to secure your Exchange messaging environment. If you want to know more about it, have a look at my latest article for Search Exchange: http://searchexchange.techtarget.com/tip/Build-an-enterprise-security-strategy-for-Exchange

Enjoy!

Exchange Exchange 2013

Microsoft rereleases MS13-061 Security Update for Exchange 2013

After last weeks debacle where the Security Update MS13-061 went (really) bad and had to be pulled, Microsoft rereleased the update today. This new version – let’s call it v2 for a change (notice the sarcasm here) – contains a minor change; albeit one that makes a huge difference…

The initial version caused some registry settings to be overwritten incorrectly whereas this version corrects that and keeps the registry settings (as it should). The details of these registry settings can be found here: KB 2879739

The update can be found below:

For more information, please consult the original announcement by the Exchange Product Team.

Exchange 2013

Microsoft releases a bunch of Rollup- and Security updates for Exchange

Moments ago, Microsoft released a bunch of Rollup Updates and (critical) security updates for Exchange:

  • Update Rollup 11 for Exchange Server 2007 SP3
  • Update Rollup 7 for Exchange Server 2010 SP2
  • Update Rollup 2 for Exchange Server 2010 SP3
  • Exchange Server 2013 RTM CU1 MSRC Security bulletin MS13-061
  • Exchange Server 2013 RTM CU2 MSRC Security bulletin MS13-061

By now, you should be familiar with the “traditional” way of how the Rollup Updates work for Exchange 2007 and 2010. New, however, are the security updates for Exchange 2013. As announced before, these security updates only have a limited scope within which they are supported.

As such, you’ll have to make sure that you are running either of the following Exchange 2013 versions:

  • Exchange 2013 RTM CU1
  • Exchange 2013 RTM CU2 v2

In case you’ve missed it: Yes, you need version 2 of CU2 for Exchange 2013 installed.

For more information on the updates, have a look at the original announcement here

Security Update MS13-061

It seems that Oracle is once to blame for the critical security update, which has already been announced a few days ago. As described on the Security Bulletin page, the vulnerability would allow to remotely execute code on your Exchange Servers.

In fact, there are multiple vulnerabilities of which 2 again have to do with WebReady Document viewing (just like earlier this year). The third vulnerability is because the feature called “Outside In” is used in DLP.

I haven’t had the opportunity to read more about it, but if you want the original announcement has been updated with more information:

Happy updating…!

Exchange 2013

Demo of spoofing attack shows that Android & IOS devices can be wiped due to Untrusted SSL certificates

Articles at Ars Technica and Tweakers.net (Dutch) reported that Peter Hannay, an Australian Security Expert, demoed at the Blackhat conference how Adroid and IOS devices could be wiped by spoofing the connections to the Exchange server using Untrusted SSL Certificates:

Android devices that connect to an Exchange server with a self-signed certificate will connect to any server at its designated address, even when its SSL credential has been spoofed or contains invalid data. iOS devices fared only slightly better in Hannay’s tests: They issued a warning, but allowed users to connect anyway. Microsoft Windows Phone handsets, by contrast, issued an error and refused to allow the end user to connect.

For the attacker to succeed, he must be able to spoof the connection. This could easily be achieved by setting up an unsecured Wi-Fi network. Past Blackhat conferences have proven that people tend to connect to unsecured Wi-Fi networks; even if they do not know it’s roots!

Hannay has developed an attack that uses a WiFi network to implement a rogue server with a self-signed certificate, rather than one issued by a trusted certificate authority. Vulnerable devices on the same network that try to connect to their regular Exchange server won’t reach that intended destination. Instead, it will initiate communications with Hannay’s imposter machine.

Although the problem doesn’t seem to lie with the Exchange Server, I agree with Paul Cunningham his point-of-view: I’m also curious to see how Microsoft will react to these findings.

ActiveSync in the future?

Crappy ActiveSync implementations have always been a thorn in the flesh of Microsoft. To “force” better implementations they launched the ActiveSync Logo Program. However, it seems however that the program somehow missed it’s target…

Although Exchange Server 2013 still supports ActiveSync, Dave Stork reported that Windows 8 still ships with version 14. This might point out that Microsoft is perhaps reducing it’s effort to further develop ActiveSync. I wouldn’t be surprise is Microsoft is trying to shift away from ActiveSync in the future: that way they don’t have to deal with problems that are introduced by the bad implementation of ActiveSync in mobile devices.

However, I haven’t come across a worthy replacement for it in the Release Preview of Exchange Server 2013 yet… Time will tell, but I’m watching closely to see what ‘s still to come.

Until later!

Blog Exchange