Microsoft Previews Azure Active Directory Entitlement Management

Posted on by Tony Redmond in Azure Active Directory, Microsoft 365, and Office 365

Identity Governance for the Enterprise

If you’re willing to stump up for premium licenses, Azure Active Directory (AAD) offers several methods to control access to privileged or confidential information under the Identity Governance moniker. I like Access Reviews, which forces regular reviews of mechanisms like group membership to stop people retaining privileged access via security or Office 365 groups.

Given the use of Azure B2B collaboration (guest user accounts) to allow external access to resources like Groups, Teams, and Planner, it’s almost inevitable that some guest users keep membership long after their need passes. Regular reviews of group membership forces owners to decide if continued membership is justified. It’s a good way of limiting access to resources to those who need access for as long as they need access.

Entitlement Management

Microsoft has now launched the preview of Azure AD Entitlement Management, policy-driven access management for Office 365 Groups, apps, and SharePoint Online sites. This is not something that will interest small tenants where the administrator knows everything that’s going on, but it should be considered by large enterprise tenants where automation becomes hugely important for access management.

Anyone can enable the preview by going to the Identity Governance section of the Azure AD portal. Be aware that once the feature is generally available, Microsoft might enforce licensing controls and you’ll need to buy Azure AD Premium P2 licenses to continue. This won’t be a problem if you have the Enterprise Mobility and Security or Microsoft 365 E5 plans as the Azure AD licenses are included in these suites. Even if you choose not to buy licenses, the assignments made to user accounts by policy won’t be invalidated. You’ll just have to manage them manually in the future.

Managing Access to Office 365 Groups

I wanted to explore a simple example to illustrate the concepts used by entitlement management. After reading the documentation, I decided to create a policy to manage access to a set of Office 365 groups that contain sensitive information. My first surprise was that I couldn’t manage any Office 365 groups used by Teams because the picker used doesn’t allow these groups to be selected. Clearly the AAD developers didn’t read the news that Teams hides the groups it uses from Exchange address lists. This should be an easy fix.

In any case, I figured out that I needed to create an access package, the basic object for entitlement management. An access package is composed of various components. Let’s see what each does.

Access Policies

Access policies define how long users have access to the resources and who can add users. Multiple policies can exist within a single access package to cover different sets of users and circumstances. For example, one policy might be used by administrators to grant access while another is used to allow tenant users to submit access requests for approval. In Figure 1 you see that the policy allows administrators to grant access to the resources defined in the package for 730 days.

Policy Settings AAD Entitlement
Figure 1: Policy settings in an AAD entitlement package (image credit: Tony Redmond)

You can also create an approval workflow for internal or external users by defining sets of users who can request access. Curiously, only security groups or individual accounts can be used to define the set – it would be nice to be able to use Office 365 groups here too.

Details of the access package are published using a special URL created for the package and those within the scope of the defined set can request access (Figure 2). Requests are routed to nominated approvers to can grant or deny access.

AAD Access Package
Figure 2: Requesting access to an access package (image credit: Tony Redmond)

Resource roles

Resource roles define the resources users can access and the access they will have (for example, to be a member or owner of a group or site). The manageable resources are Office 365 groups, apps, and SharePoint sites. Figure 3 shows that access will be granted to three Office 365 groups and one SharePoint site.

AAD Entitlement Resource Roles
Figure 3: Listing the resource roles in an AAD entitlement package (image credit: Tony Redmond)

Assignments

Assignments define the users allowed access to the resources via a policy. In Figure 4 we see how users are assigned to the access package. You can only add individual users (tenant or guest accounts).

Assigning Users to AAD entitlement policy
Figure 4: Assigning users to an AAD entitlement package (image credit: Tony Redmond)

Requests

Requests track the progress of assignments requested by administrators or users. An assignment has a “delivery state” to report the progress of granting access through the workflow process. A “delivered” status means that a workload like SharePoint has successfully granted access to a user while “delivering” means that provisioning is in progress. Figure 5 shows that two assignments are partially delivered (the same information is seen under the Assignment and Requests tabs). This came about when I added a distribution list as a resource. AAD entitlement policies don’t support distribution lists, but I could select a list and add it. I resolved the issue by removing the distribution list from the list of resources. Eventually, AAD sorted things out and all the assignments were delivered.

Assignments
Figure 5: Viewing the delivery status of assignments (image credit: Tony Redmond)

Setting Permissions

Background processes take care of interpreting the access set by policy and granting the necessary access to the resources. This worked well and most permissions were in place within a few minutes. When the access period defined in policies expire, background processes reverse course and remove permissions.

Problems with Permissions for SharePoint and Groups

I was surprised to be able to include SharePoint sites belonging to Teams as resources. The list presented by Azure AD seems to exclude sites belonging to Office 365 groups that are not team-enabled while listing those belonging to Teams. The list of SharePoint sites should be restricted to those not managed by Office 365 groups.

Because Groups manages the permissions for resources belonging to Office 365 groups, it’s not a good idea for AAD to assign explicit permissions to these sites. Microsoft has some work to do to figure out the filters used to present users and resources and make sure that access works properly for resources controlled by Office 365 groups. If they don’t, a big permissions mess might result like the one shown in Figure 6.

Permissions for SPO site
Figure 6: : A mess of permissions set for a group-managed SharePoint site (image credit: Tony Redmond)

Automation is Good

As noted above, entitlement policies won’t be much use for small to medium tenants. This is very much an enterprise feature. You’ve got to expect bugs and gaps in preview versions and that’s exactly what’s present here. I expect Microsoft to fix these issues before general availability (my mind wonders why Avanade, the customer featured in the announcement, didn’t run into the problems I found within 30 minutes). If they do, entitlement policies will be a worthwhile addition to Microsoft’s Identity Governance portfolio.

BECOME A PETRI MEMBER:

Don't have a login but want to join the conversation? Sign up for a Petri Account

Register