This is Sue Bohn, Partner Director of Program Management for Microsoft identity solutions. We’re back with another mailbag focusing on your common questions on access reviews, an Azure Active Directory (Azure AD) identity governance feature. One of my favorite sayings is there’s nothing more permanent than a temporary solution! Let’s say we exclude some users from a Conditional Access policy temporarily for the next week, with good intentions to remove them as soon as the project is done. We often forget that last part, so access reviews help not only with reviewing these exclusions at regular intervals, but also transferring the work from IT admins to the end users themselves to attest they still need that exclusion or access to a resource. This process works equally well for external identities. Reviewing access on a regular basis needs to be a key aspect of your identity governance strategy.
Hi everyone, it’s Florian reporting in today. Like many of our customers, you might be securing access to resources in your organization via Conditional Access policies. You might be using these policies to ensure that multi-factor authentication (MFA) is turned on, and users sign-in from trusted devices, or from trusted locations. During deployment, you might decide to gradually roll these policies out or have a need to ensure that specific users or accounts are untouched by these policies. In this case, you might specify an “exclude” list. Classic examples of such are the list of VIPs that you want to manage differently, or a set of Service Accounts and users that you may want to exclude from your “Block Legacy Authentication” configuration until you remediated them or find a different configuration to run them on.
Exception lists have the benefit (and the burden) of being setup at one point in time, with the goal of staying for some specific amount of time (where the “amount of time” is less than “forever”). There’s an implicit understanding that, eventually, the exception may go and the list of users that enables this exception should shrink gradually. How can you get a better grip on these exception lists, to get clarity on the most important questions most exception processes struggle with? How many users are running on this exception now? How can we regularly check who still needs this exception? How do we clean up this exception list? The answers to these questions are access reviews.
Access reviews build a framework for checking on and attesting access to resources, such as groups and group membership, privileged roles in Azure AD Privileged Identity Management (PIM), access packages, or Azure AD-integrated applications. In this scenario, the resource we’re reviewing is membership to a group. Reviews can be one-off or scheduled in a campaign-fashion, recurring on a monthly, quarterly, or yearly schedule. Reviewers can be defined and delegated, so that the review can be carried out by the best qualified set of people to do it – this may mean that IT does not review access to the resource, but the resource owner. Optionally, you may choose to have the user self-attest their access needs regularly and remove non-responsive users automatically.
Reviewers will be notified when a new review is set up or a scheduled, regular review has started. They’ll receive an email that points them to a reviewer portal – where they decide on a per-user basis whether access for a resource must be preserved or not:
So how does this come together? Your Azure AD admin team creates the Conditional Access policy and assigns it to the target audience. When “Exclude” is used for scoping, the respective excluded users are added as members of a group to the policy. That group, in turn, is then controlled via access reviews and checked in regular campaigns. Reviewers, at best, are the owners of either the resources the Conditional Access policy is targeted to or – in case of blocking legacy authentication – the Security team.
This becomes a useful tool when you need to review access to a resource – such as group membership that enables or disables Conditional Access, or more straightforward things like a Microsoft Teams team – but don’t necessarily own the resource yourself and you need to delegate.
Can I review who has access to an application?
Access reviews work well with several resources and are not limited to exception lists: the most natural are groups of all kinds (Security, Office 365) as well as assignments to applications. Applications may include line-of-business applications that you created and integrated into Azure AD or any Software-as-a-Service (SaaS) application that you configured with Azure AD. In addition, access reviews work with PIM roles, as well as access packages from Azure AD entitlement management. One prominent use cases for access reviews is the periodic attestation of Microsoft Teams teams or Office 365 Groups: you start an access review and let the group owner attest all members – or external identities only.
Can this help me govern access for external partners to Microsoft Teams?
Yes! Microsoft Teams lives and breathes the promise of flexible collaboration across company boundaries. At the same time, enterprises still want control over who accesses corporate resources. Access reviews are a clean way of governing external users’ continued access to resources, such as Teams – while shifting the responsibility from IT Admins to the teams owners – who can judge better whether or not an external partner needs access.
What ways of automation do I have?
Management of access reviews is supported via Microsoft Graph (in beta). We also have a sample PowerShell script and setup instructions to kick-start your PowerShell script accessing and managing access reviews.
I have multiple reviewers – how do I resolve conflicts?
For access reviews that have multiple reviewers aligned, all reviewers’ choices have equal weight. Access reviews count the last reviewer’s choice for every user to be reviewed – until the review ends. That last reviewer’s decision on whether access should be preserved or not is counted, overwriting potential earlier reviewer’s choices – “last reviewer wins”. All reviewers see other reviewer’s choices. For users that have not been reviewed (i.e. no reviewer commented on a particular user), access reviews can be configured to automatically apply a pre-defined result (Approve or Remove access) based on the user’s last logon or use of the resources.
Can I also review groups that I synchronize from on-premises through Azure AD Connect?
On-premises groups can be targeted for access reviews and reviewers can review end users and their continued access to the resource in question. At the end of the review, reviewers will be given an overview of the review result. Unlike cloud-managed groups, access reviews cannot perform “auto apply results” on on-premises groups, such as removing users from a group. Administrators will have to use the results from access reviews and perform manual actions on the on-premises group to apply the review results.
Can I provide this as self-service to users?
Yes! When creating an access review, there are several choices for reviewers that administrators can take. In addition to “Owners” of the resources and “Selected users” that you delegate as reviewers, there is also a “Self” option, where members of the group in review attest whether they need access or not. The users will be notified via email and will be taken to the reviewer portal via a link in the email. For non-responsive users, the system can also auto-approve or auto-remove access.
What about external identities?
External identities such as partners and contractors are an excellent use-case for organizations to use access reviews! Access Reviews is all tailored to support external identity use cases, from an exception group that you manage for Conditional Access to exempt external partners from MFA, to a Teams team that you want to put under review to have a closer look at external partners and vendors. When creating a review on a group or application, review administrators have a choice between building the review scope over “Everyone” who is member of the group or assigned to the application, or “Guest users only”.
We hope you find this information helpful. Please let us know via Twitter (@AzureAD) or comment below if you have any other questions or clarifications.