As a good host benefits: Azure AD welcomes your guests (accounts) using Security Keys

Imagine yourself, use security keys to provide guest accounts access to resources in environments where use of smartphones is prohibited. This use case recently came across during an interesting conversation with a customer. In short, the answer is yes. Security keys can be used in such scenarios which are subject to strict security controls.

In this blog post I’ll explain what it takes to provide different types of guest accounts access using a security key in an Azure AD B2B scenario. This works for (External) Azure AD accounts but does it work for other accounts like Microsoft Accounts (MSA) or Google as well? More on that later…

Azure AD User types

Before we go further into the use case, hereby some background about the user types which we can identify in Azure AD. The user type indicates the relationship of the user to the host tenancy which can have two values:

• Member This value indicates an employee of the host organization and a user in the organization’s payroll. For example, this user expects to have access to internal-only sites. This user is not considered an external collaborator.
• Guest This value indicates a user who isn’t considered internal to the company, such as an external collaborator, partner, or customer. Such a user isn’t expected to receive a CEO’s internal memo or receive company benefits, for example.

Furthermore we can distinct the various sources of an Azure AD guest account, namely:

• Invited User This user has been invited but has not yet redeemed an invitation.
• External Active Directory This user is homed in an external organization and authenticates by using an Azure AD account that belongs to the other organization.
• Microsoft Account This user is homed in a Microsoft account and authenticates by using a Microsoft account.
• Windows Server Active Directory This user is signed in from on-premises Active Directory that belongs to this organization.
• Azure Active Directory This user authenticates by using an Azure AD account that belongs to this organization.

Use-case further explained

The customer has laboratories where contractors must perform certain activities, based on manuals published in Microsoft Teams. These documents are accessible through Microsoft Teams where contractors must use their own organizational- or personal account, whether an Azure AD-, Google- or Microsoft Account.

Due the nature of high-tech technology, the information is highly confidential and access to these laboratories is only permitted under strict supervision. Therefore access to these laboratories as well as access to information systems is only permitted under strict conditions. For example, smartphones are prohibited in these laboratories and strong authentication is a prerequisite for gaining access to information systems.

Strong Authentication

There are many authentication methods available to provide strong authentication as part Multi-Factor Authentication (OATH token, phone call, SMS, Authenticator App or Phone Sign-in) or Windows Hello for Business. As mentioned laboratories are subject to strict policies whereby the use of a smartphone is prohibited. As a result a number of authentication methods are ruled out. As a result contractors guest accounts have to use other authentication methods to meet the security standards.

Security Keys

Given the frameworks that contractors must comply with,  a security key seems to be the ideal solution. It provides strong authentication, it can be used in combination with a organization- or personal account and is convenient without the need of a smartphone.

Working with contractors

As mentioned contractors are required to use there own accounts to get access to laboratory manuals, based on organizational- or personal accounts. This is achieved by the nature of Azure AD which supports Business-to-Business (B2B) scenarios which allows you to work with external organizations or individuals in Azure AD. It allows collaboration to securely share your company’s applications and services with guest users and external partners from any organization, while maintaining control over your own corporate data.

Setup

Now we have a clear understanding of the scenario, let’s bring the components together, focusing on the configuration of the host tenant. The operation and configuration of guest accounts fall outside the scope of this blog post, so we assume that this has already been done.

• Add and register a Security Key as authentication method for an Organizational-, Google– or Microsoft account.
• Create one or more dynamic Azure AD security groups which contains guest users which to target specific Authentication Method- or Conditional Access policies to meet the strong authentication requirement(s).
• Configure Azure AD Authentication Method policy to allow guest users to use Security Keys.

Most likely you want to make a distinction based on Source property of your userType (Azure AD, External Azure Active Directory, Google or Microsoft Account) to target various policies (e.g. Authentication Methods or Conditional Access policies) in order to be able to differentiate various security controls.

Configure Authentication method

In order to allow a guest user account to log in with a security key, an authentication method policy must be configured in your host tenant. How to configure Azure AD Authentication methods policies can be read here.

Microsoft Teams, by excellence the collaboration hub

Now we’ve completed the technical foundation we’ll continue with the use case. As mentioned before, contractors uses Microsoft Teams to access documents to conduct tests and other activities in restricted laboratories.

Azure AD Guest Account

First I’ll log in with an External Azure AD Guest account, by using a security key. In the animation below you see the log in experience with a security key.

Microsoft Account (MSA)

For contractors who do not have an organizational account, they can use a personal account to log in. This is the tricky and thus interesting part. There are two flows to log in with a Microsoft Account.

In the first log in flow, authentication calls out to Azure AD so never hits the MSA service to authenticate the Microsoft Account.

When using the second log in flow, authentication calls out to MSA service which authenticates the Microsoft Account successfully. But…the application here doesn’t seems to be able to pass-through the token accordingly.

Unfortunately the use of a security key for Microsoft Account guest accounts doesn’t work well. Other authentication methods for Microsoft Accounts like Windows Hello or Phone Sign-in works flawless, but are not allowed due to the security controls mentioned earlier.

Google Account

By setting up federation with Google, you can allow invited users to sign in to Microsoft Teams with their own Gmail accounts, without having to create Microsoft accounts (MSA).

Google federation is designed specifically for Gmail users. To federate with G Suite domains, use the direct federation feature.

Conclusion

Now we have reviewed the different types of guest accounts, we can conclude that only (External) Azure AD accounts offers the desired user experience for the use case mentioned. For Microsoft Accounts, the log in flow is too fragile to be considered as a valid option yet. Finally, Google accounts does support the use of a security keys but not in the context of an Azure AD guest account.

During this comparison we’ve experienced some catches to be taken into account.

• In the combination, security keys are not interpreted as a multi-factor method using Conditional Access. A hardware OATH token might be a valid alternative but is less secure & less convenient than a Security Key. Would be great to add a Security Key as an ‘Access Control’ option as part of Conditional Access policy.
• The log in flow for Microsoft accounts using a Security Key (FIDO2) is fragile. You’ve to provide you e-mail address after which you select Security Key as the authentication method.
• Azure AD UserType can be changed (Member/Guest) however the Source can’t. be used for filtering

Sources

• https://docs.microsoft.com/en-us/azure/active-directory/b2b/user-properties
• https://docs.microsoft.com/en-us/azure/active-directory/user-help/security-info-setup-security-key
• https://support.microsoft.com/en-us/help/4463210/windows-10-sign-in-microsoft-account-windows-hello-security-key
• https://docs.microsoft.com/bs-latn-ba/azure/active-directory/b2b/google-federation