Improve your cloud environment security by automating identity management with Azure AD Access reviews

Azure Active Directory’s Access Reviews feature 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 what the built-in features for Azure AD access reviews are, are they enough for real-life requirements, and can we make things even better by using a custom solution instead!

What are Azure AD Access Reviews?

Access Reviews is a feature of Azure Active Directory that allows you to initiate an access review period. During the review, assigned reviewers will check if directory users’ current access to resources is still justified, or if their permissions should be revoked. 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.

Utilizing Access Reviews requires the organization to purchase Azure AD Premium P2 licenses for the users who will be performing the reviews. You can read more details on licensing, including how it applies to guest users, on the Microsoft documentation.

 
Defining the scope of the review

Typically organizations want to use Access Reviews for checking the 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. 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. 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 that have guest users and leaves out teams that are 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 simply 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 simply not possible with the built-in features. 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. 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

When we use the built-in access review options, dynamic groups are included in the scope of the review exactly the same way as groups with assigned membership. Including dynamic groups within the access review scope is pointless because even if a reviewer were to select Deny access as the review result, the user does not get removed from the group. If you perform an access review for a dynamic group, its status will just get stuck on applying without ever changing to completed.

Dynamic groups use predefined rules to deduce which users should be included as their members. The only way to remove users from dynamic groups is to either change the group membership compilation rules or the user profile properties so that 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 an administrator capable of making these changes was informed of the review results (e.g, via a report), so they could evaluate if the dynamic group rules should be readjusted. 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 to occur, 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, there are settings that 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. What this means is 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 any action: there can be no change, the access can be approved or removed automatically, or the recommended action can be taken.

Taking the recommended action vs. Thinking for yourself

The recommended action is simply 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 last login date will still be shown during the review; the system will just not recommend what action to take.

What can help make reviewers think for themselves is to require them to enter a short justification message whenever they are approving 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 or not.

It can also be interesting for administrators to later go through the review results to see what kind of 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. 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 (access reviews can be manually ended 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 any kind of overview of how an access review period went as a whole, the built-in features simply don’t offer any kind of 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. 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 is sending 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 to receive a notification at the end of the review, they can potentially receive a lot of emails.

Reporting

OK, let’s imagine you’ve already got access reviews up and running. 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 done and by whom. There is not any kind of 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 for each of the reviewed resources, so the report 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? You can only hope the reviewers are doing their job as expected, but knowing it for sure and being able to take 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 of them 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 the accounts should be removed completely 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 you don’t need to settle for the features and logic offered out-of-the-box. Things can be done exactly the way you 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 to be 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 they can evaluate their effectiveness.

Afterword

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

So, 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.

What next?

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?

Contact us, so we can discuss, design and implement the perfect access review process for your organization.