Entitlement management is a new feature of the Azure AD Identity Governance product. Since it was announced at Ignite in 2018, I was able to get on to the Private Preview and start working with it. I set a challenge to the people at Microsoft that we work with, sending them very little information to get me in to it. They stepped up and got that information for me and I began to play. I was as excited as a kid at Christmas to say the least.
Entitlement Management has now gone Generally Available and I am beginning to use it in earnest. At the moment, the focus is very much on collaboration with 3rd parties. How many times have you had to create Active Directory accounts (which then sync to AAD) for people in 3rd Parties to access your SharePoint or SaaS apps? How much do you have to manage these accounts, and do the 3rd Parties tell you when someone has left? How many times has the business stopped working with a 3rd Party but forgotten to tell you as the system administrator? If this sounds familiar, this is where Entitlement Management comes in. Building on the Azure B2B features, it provides a way to grant, revoke and importantly revalidate access. If any of this sounds familiar, and the fact you’re reading this suggests it does, then read on.
There are several key components to Entitlement Management. Catalogs, packages, and policies. We will try and go through these so you get an idea of what to think about when implementing this in your environment.
AAD Identity Governance, including Entitlement Management can be accessed through the AAD Portal, https://aad.portal.azure.com. Setting up the feature is fairly simple as usual with the Azure Portal and you will be guided through everything. If you want to try, feel free, it’s well worth it.
Catalogs
The first thing you will need is a catalog, or collection of catalogs. These catalogs contain resources and access packages. You might choose to have one catalog for everything, or break it down depending on your administration model.
Resources
Within the catalog, you add resources. These resources can be Azure AD Applications complete with role support, SharePoint sites or Azure AD groups. At the time of writing, managing AD groups is not possible using this solution which is a real shame.
Access Packages
Access Packages are where you will give a lot of thought. These packages are a collection of resources that have a policy attached for granting (or denying) access. There are no hard and fast rules for what packages you will create, but they are likely to be based on a combination of Role Based Access Control and Attribute Based Access Control. For example, you might have the following packages defined:
- All Staff, includes Workplace by Facebook, Workday, ServiceNow
- Tech, includes Slack, Azure DevOps (RBAC)
- Customer Care, includes ZenDesk, maybe a more basic version of Office (RBAC)
- Payments Developer, Includes access to Payments AWS/Azure Subscriptions, Payments Azure DevOps boards and repository (ABAC)
A user can be assigned more than one Access Package, allowing for cumulative permissions and each package can specify a dedicated policy for access.
Resource Roles
Within the access package, you can define the resource role. For groups, this can be either a member or owner. Applications that have custom roles you can specify them here such as Admin or User.
Policies
Policies are where a lot of the magic comes in. Policies define who can request access to a package and what the approval process is. The approval process can range from automatically approve through to require approval from specific people. Policies also specify the length of time access is granted for (useful for projects & contractors). Lastly, policies can differ depending on if a user is internal or external (guest account).
Assignments
From within your access package, you can see who has been assigned access and it will state which policy was used to grant access.
Requests
This tab shows the status of each request, whether it has been fulfilled or is waiting for approval.
Roles and Administrators
One of the features of Identity Governance is the ability to delegate the responsibilities to the those who know. You may be lucky and your IAM team knows who should have access to what. However, it might be more a case of your team leaders or external managers know who needs access.
Sponsors
Sponsors play a key role in managing the access to a package. When a request is made and approval is required, it is sent to a sponsor to review. When collaborating with a 3rd Party, it is possible to assign a sponsor from that party to review and approve access. Your accountant for example will know when there is someone else working on your case. If you’re sharing data with them, they can manage the access requests on your behalf.
Sponsors can also be internal to your environment. Maybe you want to approve all access requests, this is a perfectly viable option.
Access Reviews
Access reviews are a big part of the GOVERNANCE feature of Identity Governance. You may have been on the ball granting the access when people needed it, but how often do you review and make sure those people still need the access? Have you changed suppliers and no longer deal with the old one? Are they still registered in your tenant? Access Reviews are key to ensuring that the right person has the right access at the right time. Access Reviews can again be delegated to those who know who needs to be accessing a package.
User Interface
All this is great, but for a user, how do they access this? Well that is all done through the new https://myaccess.microsoft.com portal.
From this portal, they can request access to a new or additional package. They can view the history of their requests (why access was declined), if they are an approver for access they can see a list of requests to approve and finally when access reviews are configured, this is where they go do to them.
