Enable passwordless security key sign-in in Hybrid Azure Active Directory environments

passwordless

This week Microsofts Alex Simons announced the Public preview of Azure AD support for FIDO2 security keys in hybrid environments! This means we can now enable our Hybrid Azure Active Directory environments for FIDO2 security key authentication. When this is enabled, users are able to sign-in to their Hybrid AAD joined Windows 10 devices using a security key and get seamless sign-in to their on-premises and cloud resources.

In this blog post I describe the configuration for enabling our Hybrid Azure Active Directory environment for security key sign-in.

Environment requirements

For this preview there are some requirements to the (on-premises) environment:

  • Domain Controllers running Server 2016/ 2019 (at least CU January 2020)
  • Windows Insider Builds 18945 or later for PCs (hybrid AAD joined)
  • Version 1.4.32.0 or later of Azure AD Connect

Besides these requirements your users need to be enabled for Multi-factor Authentication and combined security information registration needs to be enabled. And of course you need compatible FIDO2 security keys.

I assume you have already expanded your local Active Directory (AD) to Azure Active Directory (AAD). Security key sign-in is not available in an AD which is not connected to AAD.

My lab environment consists of a Domain Controller running Server 2019 (with the 2020-02 CU). On that DC runs Azure AD Connect version 1.4.38.0.
My Windows 10 client runs Windows Insider (slow ring) version 10.0.19041.84.
I tested FIDO2 keys from Feitian and Yubico, which I tested.

Configuration steps

The setup for Hybrid Azure AD environments is almost the same as for Azure AD environments as previously described. Only the step to enable security key sign-in for the on-premises resources is an extra step:

  • Enable security keys for Windows sign-in
  • Enable combined security information registration
  • Enable FIDO2 security keys as Authentication methode
  • Enable passwordless security key sign-in to on-premises resources with Azure Active Directory

Enable security keys for Windows sign-in

We need to enable the the security keys as a sign-in option for our Windows 10 devices in Microsoft Intune. In Intune this can be done by enabling this as part of a tenant wide Windows Hello for Business (WHfB) setting or by deploying an Identity Protection configuration policy.

In this example I used the Identity Protection configuration policy. The advantage of using a configuration policy is you can assign it to a group of users instead of all users.

Open a browser to sign-in to the Microsoft Endpoint Manager admin center.

  • Sign-in to the Endpoint Manager Portal
  • Browse to Devices – Windows – Configuration profiles
  • Click Create profile
  • Give the policy a Name
  • Enter a Description (optional)
  • Choose Windows 10 and later as Platform
  • Choose Identity protection as Profile type
  • On the Settings tab set Use security keys for sign-in to Enable
  • Click OK
  • Click Create
  • Assign the policy to the security group of choice

Image title

Your subtitle here

Enable combined security information registration

The next step is to enable combined security information registration, which is at the moment of writing, in preview.
The feature needs to be enabled from the Azure (AD) Portal.

  • Sign-in to the Azure AD portal
  • Browse to Azure Active Directory – User settings
  • Click Manage user feature preview settings

Image title

Your subtitle here

  • Select All to switch on the feature for all users
  • Click Save

Enable FIDO2 security keys as Authentication methode

The next step is to enable FIDO2 security keys as Authentication method in Azure Active Directory.

  • Still in the Azure AD Portal browse to Azure Active Directory
  • Browse to Security – Authentication methods
  • Click FIDO2 Security Keys
  • Set Enable to Yes
  • Leave Target set to All or switch to Select users and select a security group
  • Click Save

Enable passwordless security key sign-in to on-premises resources with Azure Active Directory

The next steps need to be executed on the server where Azure AD Connect is running in your on-premises environment. As described in the Microsoft documentation, we need to create an Azure AD Kerberos Server object in the on-premises Active Directory.

Azure Active Directory (AD) can issue Kerberos Ticket Granting Tickets (TGTs) for one or more of your Active Directory domains. This functionality allows users to sign into Windows with modern credentials like FIDO2 security keys and access traditional Active Directory based resources. Kerberos Service Tickets and authorization continue to be controlled by your on-premises Active Directory domain controllers.

An Azure AD Kerberos Server object is created in your on-premises Active Directory and then securely published to Azure Active Directory. The object isn’t associated with any physical servers. It’s simply a resource that can be used by Azure Active Directory to generate Kerberos TGTs for your Active Directory Domain.

  • Sign-in to the Azure AD Connect Server
  • Open PowerShell as admin and browse to C:\Program Files\Microsoft Azure Active Directory Connect\AzureADKerberos\
  • Execute these command lines:
    Import-Module “.\AzureAdKerberos.psd1”
    $domain = “peterklapwijk.com”
    $cloudCred = Get-Credential
  • Enter an Azure Active Directory global administrator username and password

Don`t forget to replace peterklapwijk.com with your own AD domain.

  • Execute the command:
    $domainCred = Get-Credential
  • Enter a domain administrator username and password
  • Execute the command:
    Set-AzureADKerberosServer -Domain $domain -CloudCredential $cloudCred -DomainCredential $domainCred

If this is executed successful, in Active Directory User and Computers, in the Domain Controllers OU a Computer object created is “AzureADKerberos”.

And in the Users OU an User object is created “krbtgt_AzureAD”.

Your setup is finished. Your users are now able to sign-in to their Windows 10 device using a FIDO2 security key!

End-user experience

The end-user experience for Hybrid Azure AD joined device is about the same as for Azure AD joined devices.
The user first needs to register a FIDO2 security key via https://myprofile.microsoft.com, as I described in this previous post.

When that is finished it`s time to use the key to sign-in to a Hybrid Azure AD joined Windows 10 device.

If you have not put in the security key in a USB port, you can click Sign-in options to se the sign-in options which are available on the device.

On this Hybrid AAD joined device two sign-in options are available:
Password (the key icon on the left)
USB Security key (the USB icon on the right).
Click the USB icon.

When you click on the security key icon, you are asked to insert the key.

When you insert your FIDO2 security key, you are prompted to enter your PIN code.
After entering your PIN, you are asked to touch your key. After you have touched your key, you are signed-in to Windows without entering your password!

If you used a Bio version FIDO2 key, you only have to touch the key to sign-in.

To sign-in to a Windows 10 device it isn`t necessary to choose the security key sign-in option. As soon as you insert the security key, the key is recognized as sign-in option and you are directly asked for the security key PIN.

That`s it for enabling FIDO2 security key sign-in in a Hybrid Azure AD environment. Users are able to sign-in to a Windows 10 device, access on-premises resources, like file shares, and are able to authenticate to Azure AD connected SaaS apps like Office 365.

Thank you for ready and happy testing!

3 Comments

  1. Hi,
    I am facing the following issue after implementing this technology:
    The Kerberos client could not locate a domain controller for domain OurDomainName: 0xC000005E. Kerberos authentication requires communicating with a domain controller.

    The service principal name (SPN) krbtgt/NT Authority@OurDomainName is not registered, which caused Kerberos authentication to fail: 0x7. Use the setspn command-line tool to register the SPN.

    Here is the log from WebAuthN:

    WebAuthN Ctap GetAssertion completed.

    TransactionId: {6f203a33-07a5-4d7a-ba04-ffd8075118eb}
    Error: 0x8007052E. The user name or password is incorrect.

    Even though the ID and Password are correct.

    When connected to vpn, I can lock the PC and then can unlock the PC with Key. After couple of hours the same issue can’t login with the following error “Sorry, try that again. There was an issue with the server.”

    • I also have the same issue, for first time windows configuration should the laptop needs line of sight to the ad or azure ad? I get the same error Sorry, try that again. There was an issue with the server.”
      Where do I check the logs of what happenned?

  2. Great article, thank you!
    One comment: If you’re using MFA for the cloud credentials, the command is slightly different.
    $userPrincipalName = “admin@yourdomain.com”
    Set-AzureADKerberosServer -Domain $domain -UserPrincipalName $userPrincipalName -DomainCredential $domainCred

Leave a Reply

Your email address will not be published.


*