Last week Microsoft released the public preview of the ability to convert Azure AD Users from members to B2B members. This means that full Azure AD User Objects (rather than Guests) can be federated to another tenant and that the Azure AD User object remains as a ‘member’ User Type. Authentication for B2B members is performed by the external users home tenant. This is particularly useful for accounts in an organisation that represent partners and vendors. Converting existing Azure AD accounts allows them to retain their object ID, UPN, group memberships, and app assignments. Even better, in order to convert Azure AD members to B2B members you don’t need to manually delete and re-invite the user or reassign resources. Note: This is a one-way process
In this post I provide a little more detail on my evaluation of this preview function to convert Azure AD Users from members to B2B members. At a high level the process simply involves;
- updating the Azure AD Account in the Resource Tenant with their foreign UPN/Email Address
- performing the B2B Invite process
Previously I have written about using Microsoft Identity Manager to automate the process of performing B2B Guest Invites. Potentially MIM could be used to convert external partners accounts to B2B Members (not covered in this post).
You will need an Azure AD Registered application with permissions to manage Azure AD Users and Invite Guest Users. Ensure that the permissions to manage Azure AD Users and Invite Guests are assigned as Application permissions and not Delegated. Also grant admin consent for these permissions.
Update Azure AD Users and initiate the B2B Invite
Note: Updating Azure AD Users otherMails attribute (for Cloud Only account transposition to B2B Members) is only possible for accounts that are NOT Administrators OR assigned one or more of the following Roles Directory Readers, Guest Inviter, Message Center Reader, and Reports Reader.
For Cloud Only (Azure AD) users the ‘otherMails‘ Azure AD User object attribute needs to be updated to reflect the users foreign AAD UPN.
For AADC synchronised users the ‘mail‘ attribute needs to be updated to reflect the users foreign AAD UPN.
The screenshot below shows an Azure AD User. This user we will convert to become a B2B Member User.
Update Azure AD User
To update the Azure AD User account I’m using PowerShell. The PowerShell script example below uses the MSAL.PS Module to simplify Microsoft GraphAPI authentication that I’ve previously detailed here in this post. We will retrieve the user to update, update the otherMails attribute for their foreign address (this is for a Cloud Only user) and send them a B2B Invitation (optional).
- line 3 for your tenant name
- line 4 for your registered Application ID
- line 5 for your registered Application Secret
- line 13 for the displayName of the AAD User you want to update
- line 14 for the users foreign UPN/Email address
Perform B2B Invitation
We will perform the B2B Invitation also using PowerShell and the information returned for the user in the update user process above.
To invite the user, we use the invitation API to pass both the internal user object and the user’s foreign UPN/Email address along with the invitation options.
The following example sends an email notification for them to redeem. This is optional and can be disabled by setting “sendInvitationMessage” = $false in the script below. At that point the customizedMessageBody is also redundant.
With an invitation performed when the user accepts the invitation (where invitation notifications are sent) or the user is invited (no invitation notification), the Azure AD B2B service changes the existing member user object to a B2B member user. The following shows the notification using the configuration shown in the script above.
After redeeming the invite (if invitations are sent) the AAD User Object automatically updates to reflect the Display Name from the federated identities home tenant, and the Source changes from Azure Active Directory to External Azure Active Directory.
Note: The User type still stays as Member, not Guest as per traditional AAD B2B.
That’s it, you’re done. The partner can now use their partner identity for access to their customers Azure AD integrated Applications and Services.
Organisations using Azure AD can now provide their business partners/vendors etc with the ability to use their primary organisations identity to access their customers applications and services. Lifecycle management is now respected from their primary home identity, and users don’t have to remember two sets of login credentials. Also keep in mind the identity is an AAD Member identity, not a Guest. Applications that previously didn’t treat AAD Guest accounts as first class identities will work with this federated identity model.