Running an Azure AD Access Review for Every Guest in Every Group
When I wrote about Azure AD Access Reviews for Office 365 Groups (now Microsoft 365 Groups) in November 2017, I concluded that “any tenant that wants to use access reviews to control external access to Office 365 Groups or Microsoft Teams faces the challenge of having to create individual access reviews for each group that has guest members.” It’s taken Microsoft a while, but now they’ve launched the public preview for access reviews covering guest users in all Teams and Groups in a tenant.
It’s not as if a major technical challenge exists to know what groups have guest members. Perhaps the impulse comes from the ongoing success of Teams and the fact that every team is underpinned by a Microsoft 365 group. Many companies exploit Azure B2B collaboration in Teams to share information and work with people in other organizations (I am a guest member in seven other tenants). The upshot is that you end up with lots of guest accounts. With over 500,000 users, Accenture is the world’s largest Teams deployment, and the number of teams with guests it must manage is probably mindboggling.
Creating an All-Guests Access Review
If you’ve created access reviews before, you’ll find it simple to set up the preview. Go to the Identity Governance section of the Azure AD admin center, select Access reviews, and create a new review. Figure 1 shows that we’ve selected the scope is all groups (including groups with guests used for Yammer communities) and that the review covers only guests instead of all members.
The next step is to nominate the people who will do the review and the review period. Usually, the best people to decide whether a guest should retain their access is the group/team owner. You can choose other people to review membership with the caveat that these people should know why the guest was added to a group membership.
The settings in Figure 2 show that we’ve opted for an annual review and that the review cycle will continue indefinitely (no end date is set). The duration is 182 days, meaning that reviewers have this time to perform the review and decide to keep or deny membership to guests.
The review settings (Figure 3) dictate what happens when reviewers assess guest members. We can see that if they don’t do anything, membership is left unchanged. If they do decide, Azure AD can auto-apply their choice (enable auto-apply results) or leave the membership to be manually adjusted (disable auto-apply results). In most cases, it’s best to auto-apply results, especially if no change happens when a review isn’t done.
The ability to be notified about guest sign-in history is an interesting “decision helper.” If the guest hasn’t signed in within the last 30 days, their account is flagged on the basis that an unused membership could be removed (you can use the same sign-in data for reporting guest access for up to 180 days).
Email Reminders
The settings chosen for the review opted for email notifications. Once the review begins, Azure AD sends email to the owners of each group with guests to prompt them to review their guest members (Figure 4 – the logo used in the message is an example of custom branding for Azure AD).
Some up-front communication is needed to let group owners know that reviews are about to start and what they need to do. If this doesn’t happen, group owners might be underimpressed to receive a blizzard of messages in a short period (I received 26).
Progressing Access Reviews
Clicking the Start review link in the message brings the group owner to the My Access page where they can access the membership data for the groups to review via the Access reviews link. After selecting a group, the decision can be made to approve, deny, or “can’t make up my mind” for each guest (Figure 5). Or if they want to depend on Azure AD, they can take the Accept recommendations option and have Azure AD do the work.
The problem about letting Azure AD decide is that some sparse criteria are used. As far as I can see, Azure AD denies access to any guest who hasn’t signed in within the last 30 days. This might be what you want, but a 30-day period is too short to use as a basic rule. People do take vacations and guests don’t sign into other tenants unless they need to, such as to access a document or take part in a Teams conversation. Fortunately, it’s easy to reverse an automatic decision and do the right thing by selecting and editing the guest entry (Figure 6).
In fairness, Microsoft recognizes that the 30-day cutoff is a blunt instrument to decide to deny or approve recommendations. Expect to see the ability to customize the period in the future. However, even if Microsoft allows tenants to go back 180 days, sign-in data is sometimes no indicator of guest activity. For instance, guests in Outlook groups use email for communication and might never sign into the host tenant.
One thing I noticed is that if new guests are added to a group after a review commences, they don’t show up for the review. The logic here is that someone (group owner or admin) has decided that the guest should be in the group, so there’s no need to review that call. Also, it prevents the “shifting sands” problem where reviewers don’t know when a review cycle is complete.
Completing the Review
Eventually, the review period completes, and Azure AD then applies the decisions made by group owners. Unlike other access reviews, Microsoft hasn’t added the ability for an administrator to stop a review early to apply the access decisions.
Azure AD administrators can review details of how access reviews are progressing through the admin center (Figure 7). However, I can’t imagine this being done in large tenants where this policy might cover thousands of groups. This seems like an opportunity for ISVs to build better dashboards and tools to help large tenants cope with guest access reviews.
Microsoft hasn’t included cmdlets to interact with access reviews in the AzureAD PowerShell module, but you can use the Graph to fetch details of reviews by issuing calls with the Invoke-RestMethod cmdlet or the Graph module for PowerShell. The documentation for the API is available online.
Licensing
Azure AD Premium P2 licenses are required for those involved (creating or administering) in access reviews. Microsoft describes the requirement and gives some examples of how to calculate how many licenses an organization might need on this page.
Good Feature for Large Organizations
Having the ability to create an access review that takes in all groups with guests in a tenant is a nice feature that is likely to be popular with large organizations, especially those who have Azure AD Premium P2 licenses already. Smaller tenants can approach the problem in different ways using tools like PowerShell to track guest membership of groups or to find out if guests are active.
One gap which remains is for tenant administrators to know what users do as guests in other tenants. Perhaps Microsoft will deliver an access review with that scope next?