Azure AD Conditional Access

Enterprise Mobility + Security (EMS) has a ton of features. That’s no secret: I do Intune, MFA, and AAD Connect password write-back configurations all the time, and our SharePoint team does a ton of work with rights management. And I think we actually do a pretty decent job of informing folks just what, exactly, is included with EMS at both the E3 and E5 levels. As a handy-dandy reminder, here’s a chart:

Azure AD Conditional Access

But as with all bundles (or in this case, bundles of bundles), some parts invariably go under-implemented. And that’s a shame. That’s like owning a big house with a big yard and only ever using 3 rooms. By golly you paid for the whole thing: use it!

I talk to customers regularly who have full E3 Office 365 licensing, but who aren’t leveraging SharePoint or Skype for Business. That’s a lot of value sitting by the wayside, but it turns out there’s one feature of EMS that, in 15 months of deployments, I have never actually seen a customer implement: Azure AD conditional access.

I talk about it all the time. I show brief demos, and the crowds go wild. But it never gets used, and I think I figured out why. EMS is, as stated, a bundle of bundles. Microsoft bought a whole bunch of security companies to piece together a security solution to enable mobile productivity. Microsoft is not, by their own admission, a security company. Individually, and frankly together as a whole, the products WORK really well together, but they are very frustrating to manage.

Today, December 2016, in order to manage an EMS deployment—say at the E5 level—I have 6 different administrative portals that each require some love.

First, to add the licensing for EMS, I go to the Office 365 portal. Then, to gain full administrative control over the users, I start at the classic Azure portal. To deploy an app or manage devices, I have to use Internet Explorer 10 or 11 and browse to the Intune portal. And finally, to leverage Privileged ID Management & Azure Identity Protection, I have to go to the modern Azure portal.

Except that’s not actually all because to enable advanced functionality in multi-factor authentication, I have to first FIND and then go to the Phonefactor portal.

And if I’m running Advanced Threat Analytics, the current version does not yet integrate with the Azure Security Center, so I have to browse to the ATA Center…which has to be done with a connection to my on-prem network.

That’s a lot, and even the most skilled admin could be forgiven for not wanting to dig any deeper. But Azure AD Conditional Access is worth a peek, because while I have certainly helped many companies SSO-integrate their Azure AD with 3rd party SaaS applications, I have yet to help anybody manage access to those applications. So far, the only management has come with credentials and direct assignment of apps.

But we can control access through network location, so users have to first attach to your trusted networks to gain access. We can control access through MFA. We can leverage group membership, OS platform, and even device enrollment state (as managed by Intune). And these conditions can be leveraged per app, allowing enterprise-level controls over who gains access to what, when, and from where. That’s a lot more than just governing what email client can attach to Exchange Online (a native capability of Intune that we HAVE seen in the wild).

If you haven’t explored Azure AD Conditional Access, and you are licensed for Azure AD Premium P1 (included in both flavors of EMS), I urge you to take a look. It’s a great way to impose controls over 2700+ Internet SaaS applications.

 


 

Would you like to find out more about Azure AD Conditional Access? Learn how you can implement Azure AD today.

 

Comments