Including: Email one-time passcode authentication
Apologies in advance, this was meant to be a short-sharp blog, but once I started writing I rapidly realised the current and future behaviours of Azure AD B2B required a lengthy explanation.
On the 25th January 2019, a new method of authenticating Azure B2B users went into public preview. This new method is called email one-time passcode authentication; in this blog, I am going to use OTP as a suitable acronym. I don’t like the name chosen for this new feature, but I do have a suggestion for the name, you will see if you keep reading. For some time, I had intended to blog on the different B2B invitation/redemption processes and authentication methods used when users external to your AD are invited to collaborate on resources secured within your tenant (directory). The release of the preview has triggered me into action; I hope you find the blog a useful read.
Coincidentally on the 25th January (1964), the Beatles had their first number one hit “I Want to Hold Your Hand”. In the words of the Beatles, let me hold your hand and guide you through the current behaviour of Azure AD B2B and the significant impact of Email one-time passcode authentication.
When you want a user, external to your organisation, to work with resources in your Azure AD tenant you can add them as a normal user within your tenant. You are now responsible for managing that user’s authentication, resetting passwords and creating policies and procedures to disable the user’s account if they no longer worked for their parent organization. This results in costly and time-consuming tasks that often leave orphaned accounts. From a user’s perspective, they are challenged with yet another sign-in username and password.
Azure B2B provides a mechanism to invite an external user and provision that user in your tenant so that they can be assigned to groups, applications, MFA and licenses, but their sign-in credentials and authentication are managed by their home domain. The user’s home domain may be another Azure AD tenant or some other entity.
You may have noticed I deliberately haven’t used the term guest user. Invitations created through the portal set the UserType to Guest. When a user is programmatically invited, Graph APIs or PowerShell, the UserType can either be set to Guest or Member. A Guest user has a restricted view of data within the directory and cannot enumerate directory objects such as all users and all groups. The guest user restrictions can be removed via the External collaboration settings in the portal.
Now you might well think that the UserType will either be Guest or Member, that seems a reasonable assumption, and this belief could lead you to create dynamic groups based on the UserType property only to find some users are not added. For users that added to the directory before August 2014, the UserType is null. You can fix it by setting the appropriate user type.
External users are invited into the directory through an email invitation process. The invited user has to be able to receive the email. Consequently, an email domain for the user must exist.
The one thing in common for all external users added via the B2B process is that an external entity authenticates them. The authentication method could be via a manage Azure AD tenant, unmanaged tenant, Microsoft Account (MSA), Google federation, or now with OTP an authentication code sent to the external user’s email alias. For simplicity in this blog I am going to refer to these different authentications for the external user as A4E, what would we do without acronyms?
When OTP has been enabled, it replaces some of the previous methods. OTP is enabled via the portal and applies to the whole tenant.
The process to invite an external into your tenant is the same regardless of the A4E. When the user starts to redeem the invitation, the behaviour varies based on the A4E.
In the tables that follow the B2B behaviour is shown when the invitation is redeemed. The behaviours shown are with OTP disabled. At the end of this blog, I cover the changes introduced with OTP. It is important to understand the current behaviours as they will exist for some time.
To make it easier to understand, I have used real domain names; the slightly strange names are from my Identity Masterclasses, it allows each attendee to have multiple domains with which to work (The numeric value, 5 in this case, is replaced with a numeric value for each attendee). Come to one of the classes, and discover more!
In all of the following scenarios, the user is invited as a B2B user into the 5.users.xtshub.com Azure AD. The invited user must be able to receive emails, but there is no requirement for the Azure AD tenant to be enabled for O365.
After the invitation is sent the external user is shown in the inviting tenant as an “Invited user”.
For all of the scenarios that follow the user receives an email indicating that they have been invited to access applications in the MSC-5A organization.
The email will be sent from the Microsoft Invitations <invites@microsoft.com> alias, if you want to send the invitations from your own account. Create the invitations programmatically and then generate your own emails.
The invited user redeems the invitation. The redemption process varies depending on the status of the invited user. In all the redemption processes the invited user is requested to accept the permissions that are required by the inviting tenant. If an invited user cancels the Review Permission form, they are not provisioned as an external user
Scenario 1
Scenario 1 shows the redemption process when a user is invited from an email domain that is also a verified domain in an Azure AD tenant, and the user has an account in that tenant. Tom homed in 5.partners.xtshub.com means that he has an account in the tenant and it is his home directory where he authenticates.
After Tom has completed the redemption process, his new status can be seen in the 5.users.xtshub.com tenant.
Sometimes the invited user's email alias and Azure AD UPNs do not match. In this situation, you need to programmatically generate an invitation using the UPN of the external user and not automatically send the email. You could then email them an appropriate link.
Scenario 2
Scenario 2 shows the redemption process when a user is invited from an email domain that is also a verified domain in an Azure AD tenant, but the invited user does not have an account in that tenant.
There are two possible outcomes which depend on the state of the tenant-wide setting AllowEmailVerifiedUsers. If AllowEmailVerifiedUsers = TRUE, users can be automatically added to the tenant via an email verification process. If AllowEmailVerifiedUsers = FALSE, users cannot be automatically added.
In scenario 2 the results depend on whether email verification is enabled/disabled in the directory. For US tenants email verification is enabled by default, and for most of the rest of the world, it is disabled. For a more detailed explanation and how to check/modify the behaviour see my blog “Azure AD B2B invitations and email verified users.”
Scenario 3
Scenario 3 shows the redemption process when a user is invited from an email domain for which there is no Azure AD tenant with a matching verified domain. This method is only used if the email domain is not considered to be a commercial email domain such as Gmail, Outlook, Yahoo, etc.
The first time a user is invited from this email domain, Microsoft spins up an Azure AD. You can get a clue that this is happening because the user is asked to select the country in which to create the tenant.
Microsoft initial called these tenants viral tenants and the users within viral users. Subsequently, they were renamed to unmanaged tenants.
There are some challenges with unmanaged tenants. Firstly, users are added with a UserType of member. Consequently, a user can sign-in with PowerShell and enumerate all of the other users in the unmanaged tenant. The second challenge is to how to manage the situation where Microsoft has created an unmanaged tenant, with a domain name that they do not own, and the owner wants to use the domain name. The owner may want to create their own managed Azure AD tenant or add the domain to an existing tenant. The owner of the domain can take back control via an internal or external take over. Both methods require the owner to prove ownership by adding a specific record to the DNS zone for the domain.
You may be wondering what happens if you forget your password? The good news is that self-service password reset (SSPR) is enabled for unmanaged tenants. When requesting an SSPR, the user is sent a verification code to their email alias.
Scenario 4
Scenario 4 shows the redemption process when a user is invited from an email domain for which an unmanaged Azure AD tenant has been created. The process is the same as for Scenario 2 with AllowEmailVerifiedUsers = TRUE. Adding users through email verification is always enabled for an unmanaged Azure AD tenant.
Scenario 5
Scenario 5 shows the redemption process when a user with a Microsoft Account (MSA) that matches their email alias is invited.
MSA accounts are fully supported for external users in Azure AD. As you will see in the next scenario matching MSAs are used to support invited users from other email domains classified as commercial.
Scenario 6
Scenario 6 shows the redemption process when a user is invited from a commercial email domain. Except for a Google account which can be federated, users cannot authenticate using the identity provider for their email domain. Microsoft solves this issue by creating an MSA with the same username as the email alias. The following diagram show this behaviour:
Scenario 7
Scenario 7 shows inviting a user with a Gmail account. There are two possible paths to redemption depending on whether federation between the 5.user.xtshub.com tenant and Google is enabled or not. If federation has not been enabled a matching MSA account is created for the user. When federation is enabled, the invited user is authenticated by Google.
Federation with Google is configured via the Azure portal and the Google developer’s portal https://console.developers.google.com. See https://docs.microsoft.com/en-us/azure/active-directory/b2b/google-federation for help with setting up federation.
A Google user can receive emails at both @gmail.com and @googlemail.com.
When a federated Google user accesses an application or service, they must use a link that includes the tenant ID, in our case 5.users.xtshub.com. If you access an application that redirects you to the tenant for authentication that’s fine, but accessing a generic link such as https://portal.azure.com/ causes an error.
Fix the issue by adding a domain hint
https://portal.azure.com/5.users.xtshub.com
https://myapps.microsoft.com/5.users.xtshub.com
Email one-time passcode authentication
From the above scenarios, you can see that creating unmanaged tenants or matching MSA accounts is not particularly elegant. Email one-time passcode authentication provides a new solution, eliminating the need for adding users to tenants via email verification, unmanaged tenants and matching MSAs.
OTP applies for users that don’t have
An Azure AD account
A Microsoft account (MSA)
A federated Google account (@gmail.com or @googlemail.com)
If a user signs in using an account that does not meet the above criteria, an email will be sent to the user’s email alias with a verification code. This code is used instead of a password.
Just to be clear the 30 minute shown above refers to using the code to complete the sign in. Once you have authenticated the session last 24 hours, you will need to sign-in again to prove you still have ownership of the email account.
The first time the invited user accesses an application in 5.users.xtshub.com they will be prompted to Review Permissions. As with all the other scenarios once they have accepted the required permissions the user’s status will change from an invited user in the 5.users.xtshub.com directory and the Source is shown as OTP. Subsequent sign in will be via a new code sent to the user’s email.
As with Google federation, the tenant must be identified in any links.
Wrap-up
I hope you have found this blog informative, OTP will eliminate the need for adding users to tenants via email verification, unmanaged tenants and matching MSAs. However, I imagine legacy artefacts will be around for quite some time, and it’s important to understand them.
At the beginning of this blog, I said that I had a suggested name for OTP and that is “self-federation”. I like this term because by using a code sent to your email address you are effectively acting as the IdP and identifying yourself!
That’s it for now – Please tweet me if you found the blog helpful @john_craddock and don’t forget to book a place on my Identity Masterclass or my new Protocols Troubleshooting masterclass 😊