Managing user accounts and their access does not need to be hell on earth and a lot of constant work. It can be almost fully automated, in order to have more time to focus on more important things. In this article I would like to provide an overview about the functionalities of Azure AD Access Reviews and spend some thoughts about the few built-in functionalities and the decision points to enrich Azure AD Access Reviews by custom solutions.
What is it about?
Access Reviews, a feature of Azure Active Directory, is a useful security tool to include in any organization’s identity governance process, as users having more than the required access to resources unnecessarily increases the risk of data breaches. In this blog, we dive into the solutions we have built for our customers and the best practices we have discovered. We take a closer look at the built-in features for Azure AD access reviews, whether they are enough for real-life requirements, and whether we can make things even better by using a custom solution instead.
Access Reviews allow you to initiate access review periods in Azure AD. During the reviews, assigned reviewers will check if directory users’ current access to resources is still justified or if we should revoke their permissions. You can use it to check access to Azure AD groups (including Teams teams), enterprise applications, and privileged roles, and target the review to concern the organization’s internal users, guests, or both.
You can create, configure and view the results of access review periods via the Azure Portal (I’ll tell you the exact locations in just a second). In addition, it is possible for us to also create access reviews via the Microsoft Graph API. Even though Azure AD Access Reviews offer us plenty of functionalities already built-in, being able to create programmable reviews offers us even more options to tailor the reviews to precisely match our organization’s needs.
To use the Access Reviews functionality in Azure Active Directory, you will need Azure AD Premium P2. for the users who will be performing the reviews. More details about licensing, including how it applies to guest user, on the Microsoft documentation.
Define the scope of the review
Typically organizations want to use Access Reviews to check access to groups and/or teams. You can find the feature in Azure Portal by navigating to Azure AD and then Identity Governance. The view allows you to create new access reviews and view the results of reviews that happened in the past.
Out-of-the-box, there are two options to choose from for group-related access review scope:
- All Microsoft 365 groups with guest users (not available when reviewing application access)Note: when this option is selected, you can only choose to review guest users only (not all users).
- Select teams + groups (or applications)
In addition, you need to select whether you want to include only guest users or all users in the review.
You can create access reviews also for enterprise applications from the same place as for groups (as you can see from the image above). The option is also available if you navigate to Enterprise applications under Azure AD in Azure Portal.
For privileged roles, access reviews can be found by searching Azure AD Privileged Identity Management in Azure Portal, and then selecting Azure AD roles. When we are evaluating PIM access, we can choose to target either all users and groups or all service principals.
Additionally, if you are reviewing users and groups, you can choose between the following targets:
- All active and eligible assignments
- Eligible assignments only
- Active assignments only
You also need to select which of the privileged roles you want to include in the review scope. Again, you can include all of them or only the ones you are the most concerned about.
The (few) build-in functionalities
As already mentioned, evaluating access to groups and teams is the most common scenario, so let’s focus on that one. Imagine the following scenario: an organization wants to review all teams in the tenant. Which option should we choose?
All teams are connected to Microsoft 365 groups. However, not all Microsoft 365 groups necessarily have teams. In actuality, Planner plans and modern SharePoint Online team sites are also connected to Microsoft 365 groups but don’t necessarily have the Teams feature enabled.
The former option includes all Microsoft 365 groups with guest users within the scope of the review. It covers all teams with guests, but the option also targets Microsoft 365 groups that don’t have teams. Additionally, the option only applies to teams with guest users and leaves out teams only used by the organization’s internal employees. Because of these factors, this option does not fulfill our requirements.
What about the latter option? It allows us to include specific teams and Azure AD groups within the scope of the review. Initially, it sounds like this could work: we can add all teams to the scope manually. However, in practice, this becomes extremely tedious for the following reasons:
- First of all, the list which you are using to select the teams from includes all Azure AD groups and does not in any way indicate which groups have a team attached.
- Second, the list only shows the first 50 Azure AD groups, and to be able to select teams that are further down the list, you need to search for them by name.
- And finally, the selection is in no way dynamic: when new teams are created in the tenant, they’d need to be included in the scope manually later.
As we can see, dynamically including only and all teams within the scope of the review is not possible with the built-in features. Therefore, to be able to reach our goal, a custom solution is required.
When we have a custom solution, we can use any criteria for selecting which groups to include within the scope of the review. For example, with a custom solution, we can automatically select only and all Microsoft 365 groups with the Teams feature enabled — including any teams created in the future — thus fulfilling our requirement. In addition, if desired, we can further filter down the teams to, for example:
- only those which have not been archived
- which have guests
- use a certain classification label
- etc. (The options are essentially limitless!
Dynamic Groups - better exclude them
Dynamic groups use predefined rules to deduce which users should be included as their members. Unfortunately, when we use the built-in access review options, dynamic groups are included in the scope of the review the same way as groups with assigned membership. This is unfortunate because including dynamic groups within the access review scope is useless.
Even if a reviewer selected Deny access as the review result, the user is not removed from the group. Instead, the review status will just get stuck on applying without ever changing to completed. The only way to remove users from dynamic groups is to either change the group membership compilation rules or the user profile properties, so the users no longer get included in the group. This is not something a regular user can do.
With a custom solution, we can automatically leave out groups that use dynamic membership. The only situation in which reviewing dynamic group access could be useful is if we informed an administrator capable of making these changes of the review results (e.g. via a report), so they could evaluate if the organization should readjust the dynamic group rules. This is not an Azure AD feature and must be implemented as a custom solution.
Reviews and Scheduling
In addition to the review scope, we also need to define, who will be doing the review and how often. The built-in features are sufficient to cover the majority of the use cases and offer us the following options for reviewers:
- Group owners (naturally not available when reviewing app or PIM access)
- Selected users or groups
- Users review their own access
- Managers of users (based on Azure AD user profile properties)
For the group owners and managers of users options, we can also set fallback reviewers in case the primary reviewers don’t exist (groups without owners or users without manager set in their profile).
For the recurrence of the review, we can select:
- One time (for group access reviews, this option is only available when the scope is Select teams + groups)
- Weekly
- Monthly
- Quarterly
- Semi-annually (every six months)
- Annually
In addition to frequency, we also define how much time (number of days) the reviewers have to complete the review, when should the review happen for the first time, and when the recurrence should end (never, on a specific date, or after a certain number of occurrences).
Typically, these built-in settings are sufficient, but sometimes an organization might want to schedule the review, e.g., every other month, or have different users review certain subsets of groups. If the built-in options don’t fulfill a specific need, we can set the reviewers and the recurrence exactly as desired via a custom solution.
What happens during and after the review?
When access reviews are initiated, we ideally want to send notifications (possibly including a custom message) about them to the reviewers — how else are they going to know they need to review the access to their resources? Still, some settings control this behavior, so if you, for some reason, don’t want to send out emails when the review period begins, you can turn them off. You can also choose to send reminders if the reviewers haven’t done anything halfway through the review period.
When we define the settings for access reviews, we can select whether the results are automatically applied to the resource or not. In practice, this means that if a reviewer decides to Deny access for a user, the user’s permissions will automatically get removed at the end of the review period. We can also select what happens if reviewers do not take action: there can be no change, the access can be approved or removed automatically, or the system can take the recommended action.
Recommended- vs. Individual actions
The recommended action is based on whether the user has logged in during the past 30 days or not. If they have, the system recommends their access to be retained, and if not, it suggests the access be removed. Personally, I don’t think this is much of a recommendation. Users can be members of many different groups. They might log in to use one of them, but the recommendation is still displayed as approve for all the groups the user is a member of, even if they haven’t viewed the other group contents in ages. Also, users can be absent for more than 30 days, e.g., during the summer holidays.
This “decision helper” setting is enabled by default, and while it may seem great at first glance, it can actually do more harm than good. The reviewers might end up always taking the recommended action “to be on the safe side” without actually stopping to think for themselves, what is truly the correct action to be taken. My recommended action is to disable the setting. The user interface will still show the last login date during the review; the system will just not recommend what action to take.
What can help make reviewers think for themselves is requiring them to enter a short justification message whenever they approve a user’s access (like in the picture above). The quality of the reviews can increase by utilizing this method because the reviewer actually needs to stop to ponder whether the user is justified to have access.
It can also be interesting for administrators to later go through the review results to see the reasons the reviewers base their decisions on. And no need to worry about justifying access being tedious: it can be provided for multiple selected members at once.
Challenging: Automatic disable of accounts with "denied access"
If the review only covers guest user access, you have an additional option to choose whether…
- the user’s membership is removed from the resource, or
- block the user from signing in for 30 days, and then remove them from the tenant.
The latter option sounds super handy at first. It’d be great to disable and eventually remove guest user accounts from the tenant if they no longer need access, right? However, the feature is actually quite problematic.
.
Just as I said earlier, users can be members of many different groups. What happens if their access is approved for some groups but denied for others? If the user’s access is denied for even one group, their account gets disabled and eventually removed from the tenant (if they don’t notice this and contact an administrator within 30 days). It does not sound that useful anymore, huh? Luckily, we can implement much smarter logic for cleaning up unnecessary user accounts through custom solutions. Let’s talk more about this later.
The notification simply contains information on what resource was reviewed, when the review period began, was scheduled to end (admins can manually end access reviews earlier), and a link to the review results in Azure Portal.
Again, this feature sounds more useful than it actually is. Even with the best intentions, it can’t be considered anything close to reporting. In general, attempting to get an overview of how an access review period went as a whole, the built-in features simply don’t offer any useful view for that. You can only open individual access review results (per group) via the Azure Portal; that’s it.
If you wish to get an actual report which offers you summaries and filtering options, a custom solution is your only option. So let’s talk about that next!
A separate access review is created for each resource (group or app) within the scope of the review. Note that whenever the system sends emails, whether it is about the beginning of an access review period, a reminder, or a notification about the end of a review, an individual email is sent about each access review. This means that if a person is selected as a reviewer for many different resources or receiving a notification at the end of the review, they can potentially receive many emails.
Reporting
OK, let’s imagine you’ve already got access reviews up and running. So how do you know if they have actually been useful?
With the out-of-the-box Azure AD capabilities, the only way you can see how an access review has gone is if you open each one of the individual resource-specific access reviews separately and check what membership decisions have actually been made and by whom. Unfortunately, there is not any summary of the access review period that would easily give an overview of how things have gone in general.
Remove Guest user accounts which are no longer needed
So, if you only include guest accounts within the scope of the review, you have an additional option of automatically disabling the guest accounts which access is denied during the review. This is problematic because if a guest is a member of multiple groups, being denied access to even one disables the account. And if the guest does not notice their account has been disabled within 30 days, the account gets deleted from the tenant completely.
You can probably already expect this: custom solutions to the rescue! With them, you can define yourself, how exactly and based on which rules you want guest accounts to get disabled, and when to delete the accounts from the tenant (if ever). Via the Microsoft Graph API, we can check which groups the guest is a member of and when they’ve last logged in. We could, for example, have the following rules:
- If a guest is not a member of any groups and has not logged in for two months, disable their account.
- If a guest is a member of groups but has not logged in for six months, disable their account (we could also remove their access to all the groups at the same time if desired)
- If a guest account has remained disabled for three months straight, remove it from the tenant
In addition to the rules, we can also implement other useful features:
- We could send notifications of the “disable” events, so in case the guest or their contact within the organization still wants to retain their account in the tenant, they could ask the admin to re-enable it in time.
- We could also send summary reports to the administrators, so they could see which accounts were disabled or removed.
These are just a few example ideas! The great thing about custom solutions is that we don’t need to settle for the features and logic offered out-of-the-box. Instead, we can do things exactly the way we want them to be.
Conclusion
Managing user accounts and their access does not need to be tedious and a lot of constant work. It can be almost fully automated, so people can rather focus on more important matters.
Did this article get you excited about Azure AD Access Reviews and interested in automating user account lifecycles? What kind of needs does your organization have regarding the matter? Let me know your thoughts in a comment!
