This blog is the first in a small series on Azure AD Premium P2’s Identity Governance toolkit.
Azure AD entitlement management is a bit of an overlooked gem. It’s a feature that automates the processes for giving users access to resources. The typical scenario is a user has just joined a new department or is a new employee. Over time, the resources their team need access to have sprawled across the M365 estate and it would be laborious to give permission to them all manually – if you even remember them all. Additionally, you want to ensure the user’s access is time-controlled so that as their role changes, their access does too.
Entitlement management allows those resources to be accessed in what it calls an access package. In an access package, you throw in the resources a user will need. What sort of resources? You can include groups (security or M365 types), Azure AD registered apps, and SPO sites. You can therefore also assign users licenses (assign it to a group), join a Team (linked to an M365 Group), or any other type of resource allocation linked to the groups they join.
The access packages then have policies that control the users who can request them and the approvers who, optionally, approve those requests. You aren’t limited to only one policy, which gives you the ability to configure different rules for different users. Users who you give the ability to request access can then visit the My Access portal link (myaccess.microsoft.com) to kick off the process.
The cool thing is, when you start working with entitlement management, you are not going to overburden IT. You may think this is just going to shift the responsibility for resource allocation from the team into central IT, but entitlement management can be fully delegated to allow others to create and manage access packages. For example, you can empower a team manager to control access packages. This is managed with a concept called catalogues which are a management boundary for access packages. You delegate permissions to catalogue creators, catalogue owners, or access package managers (most permissions to least; refer to here for a full a comparison).
Additionally, you can leverage Azure AD B2B and allow guests to get access packages, time-controlled with expiration dates for security. Time-control is not limited to guests and is part of the aforementioned policies you give access packages.
Licensing gets a bit convoluted when you consider guests. As mentioned, this is an Azure AD Premium P2 feature, but you obviously cannot assign this to a guest. Instead, to be license compliant, each licensed user in your tenant entitles you to use the feature for five guest users. Administrative tasks also don’t need a P2 license. For example, setting up the packages. But as soon as you are someone who can use or does use an access package, you need a license. This is typical in the M365 licensing structure, where if a user benefits from the service, they need a license.
Run-through
1. From the Azure AD admin centre (aad.portal.azure.com), browse to Identity Governance > Entitlement management > Access packages > New access package.
2. Give your access package a name, description, and catalogue. From this page, you can also create a new catalogue (management container) and specify if it’s enabled internally and/or externally. After entering all this information, click Next: Resource roles.
3. You now add groups, apps, and SPO sites to the package, and the role (permissions) they have for each of these. This is important to note, as it means if you need to give different people different roles, this must be done with different access packages. When done, choose Next: Requests.
4. Requests control who is allowed to request access to the package. This means if a user is not added here, they will not even be informed of the package’s existence. At this point, the users, except guests, must have an Azure AD P2 license. There are three top-level options:
- users in your directory, which in this example I select, and then scope to all tenant users (but could choose named users/groups)
- users not in your directory, which could leverage Azure AD B2B and allow other organisations to be eligible by listing their domains
- administrator direct assignments, which doesn’t let anyone request and enforces that an administrator must assign the user the package
5. Within the request controls, there are approval options. Firstly, you can either enable or disable approval. If disabled, users who were specified in the above just need to choose to enrol into the access package; there are no additional ‘hoops’. If enabled, you can require the user to provide a justification and then one or two additional stages.
The stages are users or groups that must approve the request. If the user is approved by stage one, they are passed to stage two as a final approval step. In the options for the first approver, you can choose their manager (derived from Azure AD attributes) or a named group/user. If you choose their manager, you can also enter ‘fallback’ groups/users, as that may interfere with business processes if, for example, the manager is unavailable. You also control, for both first and second stages, a timeout value. If the approvers do not approve it in this timescale, it’s automatically denied. Don’t rush these steps – consider the business processes involved and communicate with stakeholders to get it right, balancing security and the user experience.
Finally, you want to choose yes to enable new requests and assignments to make the policy available. When all sorted, choose Next: Lifecycle.
6. The lifecycle options control how long access packages last for the user, either by date or a number of days. You can also control whether or not the user can request an extension and if the approval flow previously configured must be run through again for the extension. Additionally, you can enforce access reviews, which can be done either in self-review or specific reviewer mode. An access review is a review of continued access to the access package and can be useful as an additional identity governance control by the delegated administrator or the user to themselves declare they no longer need it.
7. After this stage, you are given the chance to review the configuration before creating the access package. You can revisit the access package later on to make changes if required by going to Azure AD > Identity Governance > Entitlement management > Access packages > your access package.
8. To get access, the user must visit My Access (myaccess.microsoft.com), browse the access packages scoped to them, and choose + Request access. They enter a business justification (if you required it) and can enter their own time restriction.
9. The approval process beings as the user in the first stage receives an email prompting them to approve or deny the request. Remember, if they do not respond within the earlier specified timescale, the requestor will automatically be denied.
10. When the approver clicks approve or deny request, they are taken to My Access’s approvals page. From here, they can approve or deny, view the details of the request, and also browse their approval history. The approver may have to provide justification if you specified it as a requirement in the initial set up.
11. An email goes to the requester to confirm they have access. An email also goes to the approver to confirm the action.
12. Now when the user visits My Access, they can see the access package in the active tab of the access packages list. They can also link directly to the resources from this page and do other actions such as revoke their own access, share (send a link to another person to request), or request an extension. Notice in the screenshot below there is a red notification icon to indicate the end date (self-imposed in this case) is soon.
Note: Entitlement management is a feature in Azure AD but it is not exactly a product, in the sense that something like Conditional Access is. Hence why it’s not in Title Case in this blog… just so my fellow grammarists are at ease 😉
