Deployment frequently asked questions (FAQs) for hybrid FIDO2 security keys in Azure AD

This article covers deployment frequently asked questions (FAQs) for hybrid Azure AD joined devices and passwordless sign-in to on-prem resources. With this passwordless feature, you can enable Azure AD authentication on Windows 10 devices for hybrid Azure AD joined devices using FIDO2 security keys. Users can sign into Windows on their devices with modern credentials like FIDO2 keys and access traditional Active Directory Domain Services (AD DS) based resources with a seamless single sign-on (SSO) experience to their on-prem resources.

The following scenarios for users in a hybrid environment are supported:

  • Sign in to hybrid Azure AD joined devices using FIDO2 security keys and get SSO access to on-prem resources.
  • Sign in to Azure AD joined devices using FIDO2 security keys and get SSO access to on-prem resources.

To get started with FIDO2 security keys and hybrid access to on-premises resources, see the following articles:

Security keys

My organization requires multi-factor authentication to access resources. What can I do to support this requirement?

FIDO2 Security keys come in a variety of form factors. Contact the device manufacturer of interest to discuss how their devices can be enabled with a PIN or biometric as a second factor. For a list of supported providers, see FIDO2 security keys providers.

Where can I find compliant FIDO2 security keys?

For a list of supported providers, see FIDO2 security keys providers.

What if I lose my security key?

You can remove keys in the Azure portal by navigating to the Security info page and removing the FIDO2 security key.

How is the data protected on the FIDO2 security key?

FIDO2 security keys have secure enclaves that protect the private keys stored on them. A FIDO2 security key also has anti-hammering properties built into it, like in Windows Hello, where you can't extract the private key.

How does the registering of FIDO2 security keys work?

For more information how to register and use FIDO2 security keys, see Enable passwordless security key sign-in.

Is there a way for admins to provision the keys for the users directly?

No, not at this time.

Why I am getting "NotAllowedError" in the browser, when registering FIDO2 keys?

You will receive "NotAllowedError" from fido2 key registration page. This typically happens when user is in private (Incognito) window or using remote desktop where FIDO2 Private key access is not possible.

Prerequisites

Does this feature work if there's no internet connectivity?

Internet connectivity is a pre-requisite to enable this feature. The first time a user signs in using FIDO2 security keys, they must have internet connectivity. For subsequent sign-in events, cached sign-in should work and let the user authenticate without internet connectivity.

For a consistent experience, make sure that devices have internet access and line of sight to DCs.

What are the specific end points that are required to be open to Azure AD?

The following endpoints are needed for registration and authentication:

  • *.microsoftonline.com
  • *.microsoftonline-p.com
  • *.msauth.net
  • *.msauthimages.net
  • *.msecnd.net
  • *.msftauth.net
  • *.msftauthimages.net
  • *.phonefactor.net
  • enterpriseregistration.windows.net
  • management.azure.com
  • policykeyservice.dc.ad.msft.net
  • secure.aadcdn.microsoftonline-p.com

For a full list of endpoints needed to use Microsoft online products, see Office 365 URLs and IP address ranges.

How do I identify the domain join type (Azure AD joined or hybrid Azure AD joined) for my Windows 10 device?

To check if the Windows 10 client device has the right domain join type, use the following command:

Dsregcmd/status

The following sample output shows that the device is Azure AD joined as AzureADJoined is set to YES:

+---------------------+
| Device State        |
+---------------------+

AzureADJoined: YES
EnterpriseJoined: NO
DomainedJoined: NO

The following sample output shows that the device is hybrid Azure AD joined as DomainedJoined is also set to YES. The DomainName is also shown:

+---------------------+
| Device State        |
+---------------------+

AzureADJoined: YES
EnterpriseJoined: NO
DomainedJoined: YES
DomainName: CONTOSO

On a Windows Server 2016 or 2019 domain controller, check that the following patches are applied. If needed, run Windows Update to install them:

From a client device, run the following command to verify connectivity to an appropriate domain controller with the patches installed:

nltest /dsgetdc:<domain> /keylist /kdc

What's the recommendation on the number of DCs that should be patched?

We recommend patching a majority of your Windows Server 2016 or 2019 domain controllers with the patch to ensure they can handle the authentication request load of your organization.

On a Windows Server 2016 or 2019 domain controller, check that the following patches are applied. If needed, run Windows Update to install them:

Can I deploy the FIDO2 credential provider on an on-premises only device?

No, this feature isn't supported for on-premise only device. The FIDO2 credential provider wouldn't show up.

FIDO2 security key sign-in isn't working for my Domain Admin or other high privilege accounts. Why?

The default security policy doesn't grant Azure AD permission to sign high privilege accounts on to on-premises resources.

To unblock the accounts, use Active Directory Users and Computers to modify the msDS-NeverRevealGroup property of the Azure AD Kerberos Computer object (CN=AzureADKerberos,OU=Domain Controllers,<domain-DN>).

Under the hood

How is Azure AD Kerberos linked to my on-premises Active Directory Domain Services environment?

There are two parts - the on-premises AD DS environment, and the Azure AD tenant.

Active Directory Domain Services (AD DS)

The Azure AD Kerberos server is represented in an on-premises AD DS environment as a domain controller (DC) object. This DC object is made up of multiple objects:

  • CN=AzureADKerberos,OU=Domain Controllers,<domain-DN>

    A Computer object that represents a Read-Only Domain Controller (RODC) in AD DS. There's no computer associated with this object. Instead, it's a logical representation of a DC.

  • CN=krbtgt_AzureAD,CN=Users,<domain-DN>

    A User object that represents a RODC Kerberos Ticket Granting Ticket (TGT) encryption key.

  • CN=900274c4-b7d2-43c8-90ee-00a9f650e335,CN=AzureAD,CN=System,<domain-DN>

    A ServiceConnectionPoint object that stores metadata about the Azure AD Kerberos Server objects. The administrative tools use this object to identify and locate the Azure AD Kerberos Server objects.

Azure Active Directory

The Azure AD Kerberos Server is represented in Azure AD as a KerberosDomain object. Each on-premises AD DS environment is represented as a single KerberosDomain object in the Azure AD tenant.

For example, you may have an AD DS forest with two domains such as contoso.com and fabrikam.com. If you allow Azure AD to issue Kerberos Ticket Granting Tickets (TGTs) for the entire forest, there are two KerberosDomain objects in Azure AD - one object for contoso.com and one for fabrikam.com.

If you have multiple AD DS forests, you have one KerberosDomain object for each domain in each forest.

Where can I view these Kerberos server objects that are created in AD DS and published in Azure AD?

To view all objects, use the Azure AD Kerberos Server PowerShell cmdlets included with the latest version of Azure AD Connect.

For more information, including instructions on how to view the objects, see create Kerberos server Objects.

Why can't we have the public key registered to on-premises AD DS so there is no dependency on the internet?

We received feedback around the complexity of deployment model for Windows Hello for Business, so wanted to simplify the deployment model without having to use certificates and PKI (FIDO2 doesn't use certificates).

How are the keys rotated on the Kerberos server object?

Like any other DC, the Azure AD Kerberos Server encryption krbtgt keys should be rotated on a regular basis. It's recommended to follow the same schedule as you use to rotate all other AD DS krbtgt keys.

Note

Although there are other tools to rotate the krbtgt keys, you must use the PowerShell cmdlets to rotate the krbtgt keys of your Azure AD Kerberos Server. This method makes sure that the keys are updated in both the on-premises AD DS environment and in Azure AD.

Why do we need Azure AD Connect? Does it write any info back to AD DS from Azure AD?

Azure AD Connect doesn't write info back from Azure AD to AD DS. The utility includes the PowerShell module to create the Kerberos Server Object in AD DS and publish it in Azure AD.

What does the HTTP request/response look like when requesting PRT+ partial TGT?

The HTTP request is a standard Primary Refresh Token (PRT) request. This PRT request includes a claim indicating a Kerberos Ticket Granting Ticket (TGT) is needed.

Claim Value Description
tgt true Claim indicates the client needs a TGT.

Azure AD combines the encrypted client key and message buffer into the PRT response as additional properties. The payload is encrypted using the Azure AD Device session key.

Field Type Description
tgt_client_key string Base64 encoded client key (secret). This key is the client secret used to protect the TGT. In this passwordless scenario, the client secret is generated by the server as part of each TGT request and then returned to the client in the response.
tgt_key_type int The on-premises AD DS key type used for both the client key and the Kerberos session key included in the KERB_MESSAGE_BUFFER.
tgt_message_buffer string Base64 encoded KERB_MESSAGE_BUFFER.

Next steps

To get started with FIDO2 security keys and hybrid access to on-premises resources, see the following articles: