Have we talked about Entitlement Management and Identity Governance? We haven’t? Oh my word, let’s fix that right now.
I’ve been nerding out about EM (as the cool kids call it) since finding it in Preview a couple years ago. At the time I was just starting to get heavily involved in decentralized identity, and I saw Identity Governance as the perfect vehicle for Microsoft to plug in external identities into internal systems. And while I still think that’s a key motivator for the solution, it does SO MUCH MORE.
Remember back in ye olden dayes when we had to manage eleventy-three different types of groups in AD, and nobody knew when or why or where to use a Domain Global vs a Domain Local group? Well there actually WAS a purpose to those group types, and it wasn’t just to confound admins.
A Domain Global group was intended to hold users. A Domain Local group was intended to grant specific access rights to resources. Put the two together and gain nested access for the user to the resource. Sounds way too complicated to manage at scale, and yes: it was. Users calling in after midnight would get a frazzled helpdesk agent who could find the right resource-access group for the frustrated user, see that the user wasn’t in the group, and add them. Magically the problem would go away, except that introduced new problems that rippled throughout the enterprise.
But if the Domain Global group was named for the role—or rather the JOB TITLE—of the user, then it made a whole lot more sense. Then the Domain Local resource-access groups made sense to not contain users: they were just constituent components of that job. So your HR Specialist could be assigned exactly one group membership in the enterprise: HR SPECIALIST. That group would be a member of the ‘HR Share – READ ONLY’ domain local group, and similar groups defining print access and whatever else was necessary. The HR SPECIALIST group could then be included into the HR MANAGER group, which could step up rights to the HR Share, and on and on until you get to the HR DIRECTOR group. Rights are cumulative, and it works well. No users get assigned directly to resources.
Bear in mind that none of this is fundamentally revolutionary: it’s all the actual best practices recommendation dating back to the creation of Active Directory Domain Services in 1999. I’ve just only ever seen it done in a handful of organizations.
Now we’re reconstructing access in the cloud, granting rights to apps and teams and cloud resources and scrambling to find meaningful ways to govern that access without domain hierarchy, and so many of the tools want us to manage controls at an individual user level, which just doesn’t scale.
Enter Entitlement Management, a component in Azure AD P2. Entitlement Management allows us to create catalogs of apps, services, teams, you name it, and serve those up with granular controls to different roles. We can assign control of a whole catalog to an individual user, so if HR knows their own systems, they can be responsible for entering them into the catalog. Then we can serve up access packages in the exact same way that we did Active Directory Domain Global groups, except we can do even better because it can be done via self-service requests, with built-in multi-stage approvals and periodic access reviews.
Better still (crazy that we can continue to improve on this!), those access packages may contain resources from the catalog, but only a subset of a given app. We can, for instance, put a SharePoint Online site into a catalog, but serve up an access package that only allows grantees read access. Or contribute. Or whatever you want.
And? Coming into public preview right now, we have the ability to define ‘separation of duties’ to access packages, so that if, for instance, your CISO tries to activate the ‘Compliance Officer’ access package, they can be programmatically denied.
Want to include external users in your access packages? Sure: why not! Bring in a sub-contractor and have them use their own identities to request a given access package. You can even time-bound it, so they have to re-request access on the contract renewal date.
If that sounds a bit like time-bound admin access through Privileged Identity Management, it’s because PIM is another element of the same Identity Governance solution!
And all of this builds on the controls and capabilities already present in Azure AD, so your Conditional Access, group memberships, and MFA policies aren’t bypassed.
Identity Governance, and Entitlement Management in particular, enables dramatic scalability for identity management, with a huge reduction in IT bottlenecks for access and resource controls, while enabling users self-service capabilities that extend beyond the enterprise.
Comments