This week part 2 of a series of blog posts on implementing Azure EMS Conditional Access (CA – part 1 here) was published on Microsoft’s Enterprise Mobility and Security Blog.

Predictably, perhaps, this got me thinking about what I might need to have in place before being able to implement this for one of my customers.  From the part 1 post I can see that I need the following “conditions”:

1. User group
2. Location (IP range)
3. Device state
4. Risk

Being an IAM guy myself, my attention was drawn immediately to the first 2 items, purely on the basis that I can’t influence #3 (function of the device and presumably the Intune or equivalent setup), and #4 is data maintained within this Azure feature at the discretion of the Enterprise (to confirm).  Of course #2 is purely about matching IP addresses to trusted network locations, so let’s just look at #1.

User group (integrity thereof)

In an Azure context, this means an Azure AD (AAD) group(s) can be used to apply rules to specific users.  However, who manages these groups, and how?  If you are using AAD Premium then groups can be defined dynamically, thereby giving the impression that we can avoid the need to maintain membership ourselves.  Of course not all groups are going to be manageable this way (e.g. group membership needs to be controlled by a group owner), but assuming you have a group which can be (e.g. “all Adelaide Office managers”), and assuming EMS Conditional Access supports dynamic groups (TBC) then we could automatically grant access to some sort of restricted application in this manner.  However, how confident can we be in the data integrity of the attributes (in this case manager and location)?  Can we be sure that every manager in Adelaide is accurately identified by these properties in AAD?

If it happens we are considering a hybrid identity context, then this could instead be a group synchronised with an on-premises group mastered in Active Directory (AD), or even better some form of IAM platform such as MIM 2016.  In this way (using MIM as an example) it is possible to improve things significantly, e.g.

• Ensure both manager and location attributes are sourced and (MIM-)synchronised from a single reliable/authoritative source such as an HR system, where data is always maintained (hopefuly) in a timely fashion
• Master the group definition in the MIM portal, either as a static group (e.g. with membership approval workflows) or a dynamic (query based) group based on our 2 attributes – you can even have MIM auto-generate these groups for you if you wish (see part 3 of Tomasz’ presentation to the MIMTeam User Group here)
• Be sure to configure AAD Connect to sync the AD users and groups (complete with full attribute set) to AAD

As with previous posts about platform features which leverage user metadata, such as AD Dynamic access, the importance of ensuring and enforcing the integrity of that metadata through the use of a sound Enterprise IAM implementation cannot be overstated.  Sure Azure EMS Conditional Access depends only on groups existing in order to be enforced – but don’t expect this to be effective if the group integrity itself is questionable.

Microsoft Ignite 2017, Australia

For those in my part of the world, don’t forget to register for this year’s event from 14-17 February.  If you are one of the first 20 to register with the code K6EZIUB2, you will pay only $1500.  However, act now, as discounted registrations are only available until 10 February 2017.