Azure AD Access Reviews — Built-in Features and Custom Solutions

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.

Access Reviews 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.

Table of Contents

1. What are Azure AD Access Reviews
2. Defining the scope of the review
   1. The built-in options leave a lot to be desired
   2. Dynamic groups: Exclude from scope or alert admins
3. Reviewers and scheduling: The built-in options are usually sufficient
4. What happens during and after the review?
   1. Taking the recommended action vs. thinking for yourself
   2. Automatically disabling user accounts with denied access is very problematic
   3. Notifications are not the same as reporting
5. Reporting
6. Disabling and removing no longer needed guest user accounts from the tenant
7. How to choose?

What are Azure AD Access Reviews

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 reviews programmatically offers us even more options to tailor the reviews to precisely match our organization’s needs.

Defining 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 to target:

• 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 built-in options leave a lot to be desired

As I said, evaluating access to groups and teams is the most common scenario, so let’s focus on that. 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, e.g., …

• only those which have not been archived
• which have guests
• use a certain classification label
• etc.

The options are essentially limitless!

Dynamic groups: Exclude from scope or alert admins

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.

Reviewers and scheduling: The built-in options are usually sufficient

In addition to the review scope, we also need to define, who will be doing the review and how often. The built-in features 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 are defining 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.

Taking the recommended action vs. thinking for yourself

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.

Automatically disabling user accounts with denied access is very problematic

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.

Notifications are not the same as reporting

Finally, you can choose to send a notification to selected users or groups when an access review ends.

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!

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.

Luckily, with custom solutions, we can create stylish, informative, and filterable reports by ourselves! We can, for example, easily see answers to the following questions, which quickly tell us how beneficial the access reviews have been in practice.

• Has there been manual reviews? Meaning, have the reviewers actually reviewed the memberships, or have the access reviews simply been automatically handled at the end of the review period based on the default action defined during the review setup because none of the reviewers have taken any action?
• Has there been any denies? Meaning, has some unneeded access actually been removed thanks to the access reviews?

We can also display information on the report of each reviewed resource, so viewers can quickly drill deeper into the resources that pique their interest. The information can include, for example, the following:

• The access review period
• Reviewed resource
• Group type — useful for informing admins of the required changes to dynamic group rules
• Review type
• Assigned reviewers
• Review results: member, result and the reviewer — perhaps even the justification
• etc.

Without a report like this, how could you truly know how useful access reviews are in an organization and instruct the reviewers to be more active to get better quality reviews? Of course, you can always hope the reviewers are doing their job as expected, but knowing it for sure and taking corrective action is next to impossible without proper reporting.

Disabling and removing no longer needed guest user accounts from the tenant

As I mentioned earlier, 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.

How to choose?

Before you start implementing a custom solution, you always want to check if the built-in features of Azure AD Access Reviews are sufficient for your purposes. There is no need to create a custom solution if you find those features enough in your case. However, the built-in features leave a lot to be desired, so it does not come as a surprise that many organizations rather want to use a custom solution for access reviews, so they can set them up exactly the way their organization needs them to work, and receive reports of the results so that they can evaluate their effectiveness.

Here’s a little recap of the things we’ve discussed in this article. Hopefully, it will help you make decisions. Also, don’t hesitate to go back up and reread parts of this article to refresh your memory on the topics.

Afterword

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 the comments section below!

If you enjoyed reading this blog post and would like to consume more content from me in the future, feel free to follow me on Twitter and sign up for my Insider newsletter. Other than that, thank you for reading, it is always appreciated, and until next time!

Laura