Table of Contents
Eliminating the Need for Azure AD Unmanaged Accounts
The language used in Microsoft’s September 2 announcement that tenants should “Say goodbye to unmanaged Azure AD accounts for B2B collaboration” created some confusion. The problem is that Microsoft never quite explained what unmanaged (or “viral”) Azure AD accounts are in their post. Some folks might be confused about what their initiative is all about.
The blog refers to people who used self-service sign-up to create Azure AD guest accounts “by validating ownership of their work email address when their domain is not verified in Azure AD.” This causes a problem because “users would create accounts in a tenant not managed by the IT department of their organization.”
Managed and Unmanaged Tenants
Azure AD is composed of many tenant directories. A managed tenant is one that has a global administrator (the manager) created to support a service like Microsoft 365 or Dynamics 365. All Microsoft 365 organizations have a managed Azure AD tenant.
When Microsoft introduced Azure B2B Collaboration in 2016, they created the ability of external users to sign up to be guest members in managed tenants using the email address of the external users to validate their existence. A guest account exists in the directory of the tenant where the guest accesses some resources, like documents in SharePoint Online or a team. Azure AD also attempts to link the guest account to the user’s real account in the directory of their source tenant. Some of these guests came from email domains that didn’t use Azure AD, and Microsoft uses unmanaged tenants based on the users’ email domains to store their accounts.
Let’s take a practical example. I add the email address of an external user to the membership of a Microsoft 365 group or team. This action causes Azure AD to create a guest account and generate an invitation to the external user to redeem the invitation and confirm their email address. The user receives the invitation by email and accepts it. Azure AD is now happy that the user is real and marks the guest account as having accepted the invitation. The external user can then use their guest account to participate in the group or guest and all is well.
This scheme works until the organization that owns the email domain decides to use Azure AD because they want to use a service like Microsoft 365. At that point, the organization must take over the unmanaged tenant and its unmanaged accounts. This process is well-known and documented, but it interferes with the smooth onboarding of organizations into services.
No More Azure AD Unmanaged Accounts
What’s happening now is that Microsoft is removing the need to create unmanaged accounts and tenants by removing the ability of external users to validate using email addresses. Instead, if an external user doesn’t come from:
- Another Azure AD tenant.
- A directory that federates with Azure AD, like Google.
- Consumer Microsoft Services (MSA).
Microsoft will either use a one-time password (OTP) to validate their email address or require the user to create a consumer account using their email address. Microsoft stresses that unmanaged Azure AD accounts used by guest accounts already present in customer organizations will continue to work. The new redemption process (Figure 1) only applies to new guest accounts.
Cleaning up Azure AD Unmanaged Accounts
Microsoft’s post indicates that some tenants have thousands of unmanaged Azure AD accounts in their directories. As noted above, these accounts will continue to work, but if you want to clean them up (essentially to force people with unmanaged accounts to revalidate to Azure AD), Microsoft has a set of tools to help.
After reading the documentation, I tested the procedure on my tenant. Some PowerShell configuration is necessary. You must install:
- The latest version of the Microsoft Graph PowerShell SDK.
- The MSIdentityTools module This module is maintained by the Microsoft Directory Services team and contains a set of tools “for performing enhanced Identity administration activities.” The tools are also available from GitHub, so you can examine the code there (for instance, here’s the code for Get-MsIdUnmanagedExternalUser).
In addition, before you run the Get-MsIdUnmanagedExternalUser cmdlet to find unmanaged (viral) accounts, you must import the msidentity.microsoft.graph module. Here’s what I did to run the code in my tenant:. As you can see, three accounts were identified.
Import-Module msidentitytools,microsoft.graph Connect-MgGraph -Scope User.Read.All Select-MgProfile Beta Get-MsIdUnmanagedExternalUser Id DisplayName Mail UserPrincipalName -- ----------- ---- ----------------- 39cac377-02cc-4919-ad44-d9f1a7cc5eae Glen Weaver gweaver@gwdevelop.com gweaver_gedevelop.com#EX... 3e97b38b-6031-4501-bdba-4d05fff67ec6 Michael Conroy michaeld@conroycons.com michaeld_conroycons.com#EXT... 94687a75-7a3e-4001-b15e-7fc91cc7ac4e Norbert Platz n.platz@devs.de n.platz@devs.de#EX...
As you might expect, the three accounts belonged to email domains that didn’t use Azure AD. I had created the accounts in September 2016, soon after the introduction of Azure B2B Collaboration support for what was then Office 365 Groups (now Microsoft 365 Groups). The ExternalUserState property of each account was set to Accepted, meaning that the users had redeemed their invitation to be a guest user in my tenant.
To force the unmanaged accounts to go through Microsoft’s new redemption process, you run Get-MsIdUnmanagedExternalUser again and pipe the results to Reset-MsIdExternalUser. This action causes Azure AD to reissue the invitation to the email address for each account and reset the ExternalUserState property to PendingAcceptance.
Get-MsIdUnmanagedExternalUser | Reset-MsIdExternalUser Id InviteRedeemUrl -- --------------- d325b1e4-c6d8-4d24-b384-05bd145abf6f https://login.microsoftonline.com/redeem?rd=https%3a%2f%2finvitations.microsoft... bb1112fc-c0b1-4b0e-a43b-dfd0914c8345 https://login.microsoftonline.com/redeem?rd=https%3a%2f%2finvitations.microsoft...
It’s up to each external user to decide if they wish to redeem their invitation, and if they do, they must use the new redemption process. If a guest chooses not to redeem their invitation, you can consider removing their account after a reasonable period.
Not Too Much to Complain About
The advent of cross-tenant access policies means that guest accounts and Azure B2B Collaboration is less important than they were once. We all learn with experience, and it seems that Microsoft has learned that unmanaged tenants and unmanaged (or viral) accounts are not as good an idea as they seemed to be in 2016.
I can’t see a downside in what Microsoft is doing. They allow tenants to leave unmanaged guest accounts alone if they want to, and tools are available if an organization decides to move these accounts to a managed status. Apart from some minor disruption for those being asked to go through the invitation redemption process again, there’s not much to complain about.
So much change, all the time. It’s a challenge to stay abreast of all the updates Microsoft makes across Office 365. Subscribe to the Office 365 for IT Pros eBook to receive monthly insights into what happens, why it happens, and what new features and capabilities mean for your tenant.
One Reply to “Microsoft Sets Out to Block Unmanaged Azure AD Guest Accounts”