Azure AD B2B Health

|
Published

Whether you are just enabling Azure AD B2B (Business-to-Business) to allow collaboration with users external to your organization, or it has been in place for some time, it is important to recognize common problems that may be present in your tenant.

We’ve worked with hundreds of organizations and put together the following list as much to help ourselves as our clients. The top issues we’ve seen are:


User Type Not Populated

Azure AD B2B first launched in August 2014. If your tenant pre-dates that, there is a chance that some of your users don’t have a user type populated. There are only two types of users – members and guests. Members are typically your staff and are also typically licensed by the organization for Microsoft 365. Guests should always be external to your organization, and typically fall under the free guest licensing for many Microsoft 365 features.

The problem with users that have no user type, is that if you have conditional access policies for security that apply different rules to members than guests (which is common) they may not be properly applied to these users. Typically, these users would be members, and it is important that the appropriate security policies are applied to them.

Fixing these users up is quite straight forward. You can use our Power BI dashboard to identify the problem users and fix them manually in the Azure portal, or use our Tenant Health Updater PowerShell to find and fix them.


Mismatch Between Email and UPN

This issue is a tougher one to plan ahead for, because it is actually a problem in your guest's tenants.

UPN stands for User Principal Name, and is effectively your guests username in their home tenant. Often it is the same, but it can be different, either by design or by change. One common scenario is when an organization changes its name, and all staff email addresses change. Their email then no longer matches their UPN. Another is that for security reasons an organization doesn’t want bad actors externally to guess their staff’s UPN from their email addresses.

The problem when you invite these users in as B2B users is that you are inviting them by their email address, not their UPN. When they go to sign in to your system, they need to know to use their UPN, not their email address. They have to remember the same thing when they sign in to their own organization’s systems, but they may not remember that.

The best solution is to have the guest organizations update their policies to allow their staff to sign in using their email address. This eliminates the confusion, but it does raise some additional security concerns.

  • If the reason they are different is so people cannot as easily guess usernames, IT is not going to allow this
  • If the organization uses Azure AD P2’s Identity Protection features for additional security, this does apply when someone signs in with their email address instead of their UPN

Missing Email

In Azure AD, it is not a requirement to have an email address on a member account. However, email is required for direct sign in without accepting the Microsoft invitation.

When Azure AD B2B first launched, it required guests to receive and accept a Microsoft email invitation. In many cases this was confusing for users, and Microsoft now allows direct invitations. This means you can send your own invitation without any special Azure AD links, and guests can access any systems that you have given them access to.

Like the above email / UPN mismatch, this is something that needs to be addressed in the guest's tenants Azure AD.

Unaccepted Invitations

As noted above, Azure AD B2B used to require guests to receive a special Microsoft email with a URL to accept their invitation as a guest. Without accepting this, they would not be able to sign in as a guest to the inviting tenant.

The invitations are no longer needed, but users that were invited when it was required and didn’t accept can’t sign in. Simply re-sending the invitation only partially helped, as the guests would still need to accept this new Microsoft invitation.

Previously our only solution was to delete and re-invite the user. This required care to make sure their profile, group memberships, and roles were all recreated properly, so the guests could do the things they were invited into. Recently Microsoft released a preview feature that allows you to reset the invitation, and this removes the requirement that users accept any new invitation. This can be done without sending any invitation, and guests are not aware of the change being made.

The safest way to address this if you feel your tenant has users in this state is to reset all guest's invitations that have not been accepted. Our Power BI tool will identify these users, and our Tenant Health Updater PowerShell allows you to reset all guests with unaccepted invitations.

Conflicting Microsoft Account

In the past when creating a personal Microsoft account, it was possible to create one using the same email address as your organizational Microsoft 365 account. When signing in to Azure AD, Microsoft will then present a dialog asking if you want to sign in with your work, school, or personal account.

The problem here is that users are often unsure which choice they should be making, and in some cases, Microsoft doesn’t present the dialog, and the user gets a sign in error. Unfortunately, there is no solution to this, other than recommending to the user that they change their email on their Microsoft account. Microsoft actively encourages users to do this, as they no longer allow creation of accounts in this way due to the confusion and problems they cause.

More Resources

To help identify and correct a number of these issues, we’ve published the following companion articles:

Latest Articles