Password-less 4 of 5: Going password-less with FIDO2 Security Keys Part 2

In my previous blog post I’ve described the reasons why you want (or must) you Security Keys within your environment, which form factors are available (including my personal top #3) and distribution mechanisms of Security Keys to your end users. This second blog post is a follow-up on the previous blog post and will described in detail how you technically can implement Security Keys within your (hybrid) Azure AD environment.

Required technical steps for implementing FIDO2 Security Keys

Now we got Security Keys let’s make sure you can also enroll them within the Azure AD. To be able to enroll them make sure to login to https://portal.azure.com/. Once logged in hit the ‘Azure Active Directory’ blade, go to ‘Security’ and hit ‘Authentication Methods’.

On the ‘Authentication method policy’ tab hit ‘FIDO2 Security Key’.

From here you can configure the use of the Security keys for your organization. So first set the ‘Enable’ state to ‘Yes’ and target this policy to a ‘Selected User’ group or target it to ‘All Users’. If you’re going to test I would suggest to test first before enabling this feature to all of your users, like I’ve also done in the scenario below. In my example I’ve used the group ‘Security Key Users’ which I’ve created myself.

Next to the Target settings you will find the General section in which you can ‘Allow self-service set up’ for end users and ‘Enforce attestation’. The first setting will enable users to enroll security keys themselves, I would strongly encourage you to enable this setting. This as you don’t want to provision each single key for your users with a PIN, you want users to do this on their own based on the self-servicing model. This makes shipping or providing your security keys to end users also much easier as you don’t need to organize those keys based on user and provide them with a random scrambled PIN which they forget within a day.

The second setting is called ‘Enforce Attestation’. If you enable this setting, it will require that keys which you are using have a trusted certificate, therefore you will disable security keys which have a self-signed certificate from being used. Enforcing attestation therefore means that during the enrollment process the certificate is checked to confirm if its legitimate and therefore brings in more secure security keys. In my example I’ve set this feature to ‘Enabled’ and will show you later on that a key will be blocked by this setting.

Now below the general section you will find the ‘Key restriction policy’ settings. In here you can enforce key restrictions so you can make sure that only specific keys will be allowed for enrollment. This increases the security posture of your environment as you can make sure that everyone is using a key model which you as an administrator trust.

To enable this, make sure to enable the ‘Enforce key restriction’ setting and set the ‘Restrict specific keys’ setting to allow.

As you can see in my example I’ve enabled the enrollment for five specific security keys. Each security key has it’s own AAGUID which is defined by the vendor itself. In most cases you can retrieve this AAGUID value from the website of your supplier, for Yubico you can find them on this page.

On the page of Yubico you will find the table below which will supply you with all the details you need, as you can see in my case I’ve used three YubiKey (YubiKey 5 NFC, YubiKey 5C and the Security Key By Yubico).

Unfortunately not all vendors do supply these values for you. For these keys there are two solutions, first do an enrollment and have a look at what AAGUID is used, or you can find out what the AAGUID is via a python script. If you want to retain these settings from the enrollment please disable the ‘Enforce key restrictions’ first, don’t forget to save the settings related to FIDO2 Security key and skip the part about the Python script below.

If you want to do things right at the first place, because your users (or even admins) can bring in all sorts of keys in the meantime, let’s use the Python script.

Now for that you first need to meet a few prerequisites, which are:

  • Download and install Python or install the Python UWP app;
  • Install PIP within Python with the command ‘python -M pip install pip’;

NOTE: This step is not required when using the UWP app.

  • Install fido2 within Python with the command ‘pip install fido2’;

NOTE: To install the fido2 dependencies required for communication with NFC Authenticators, instead use: pip install fido2[pcsc]

Once all the Python requirements are installed you can execute the command ‘python get_info.py‘ from an elevated command prompt (please note that the security key needs to be plugged into the device where you run the script from)..

This will result in the following output for each key, each output contains the AAGUID number which you can set and configure within the ‘Restrict Specific Keys’ section described earlier.

  • For the Yubikey 5 Nano key this results in:
  • For the Yubico Security key this results in:
  • For the Yubikey 5 NFC key this results in:
  • For the Nitrokey FIDO2 key this results in:
  • For the Feitian K27 key this results in:
  • For the Feitian K33 key this results in:
  • For an unsupported FIDO2 security keys this results in:

As you noticed earlier I’ve allowed the use of 5 security keys within my tenant, these are:

  • Yubikey 5 Nano (cb69481e-8ff7-4039-93ec-0a2729a154a8);
  • Yubico Security Key (f8a011f3-8c0a-4d15-8006-17111f9edc7d);
  • Yubikey 5 NFC (2fc0579f-8113-47ea-b116-bb5a8db9202a);
  • Feitian K27 (77010bd7-212a-4fc9-b236-d2ca5e9d4084);
  • Feitian K33 (12ded745-4bed-47d4-abaa-e713f51d6393);

One key which I didn’t allowed was the Nitrokey FIDO2 Security key, this as this security key doesn’t support the attestation enforcement configured within Azure AD (using a non-trusted / self-signed certificate).

Once you have finalized your list of security keys with AAGUID numbers, and therefore finalized the configuration of the FIDO2 Security key section, please ‘Save’ your configuration within the Azure AD.

Now we have configured these settings within the Azure AD, you can already enroll and use your security key for web-based sessions. For most of your employees it would be neat of course to also be able to sign-in to Windows 10 with this security key (think of users which can’t use WHfB because they are working on a shared PC).

For that please go to the Microsoft Endpoint Manager console via https://endpoint.microsoft.com and hit the ‘Devices’ tab and select ‘Enroll devices’.

Now within the ‘Windows Enrollment’ section hit ‘Windows Hello for Business’.

Scroll to the bottom of the Windows Hello for Business settings and there ‘Enable’ the ‘Use security keys for sign-in’ option.

Once done a new option will appear automatically within the Windows 10 logon screen as sign-in method (once the policy has been received). This setting will of course only appear if the machine is Azure AD Joined or Hybrid Azure AD Joined which I described in my earlier blog post.

Now the implementation in the Azure AD is ready it’s time to enroll one of the FIDO2 Security Keys which we’ve allowed to be used.

Required steps for End user enrollment

To enroll your key go to https://myworkaccount.microsoft.com. From the My Account overview select ‘Security Info

Within the ‘Security info’ page hit ‘+ Add Method’.

Select ‘Security key’ and hit ‘Add’.

To start the enrollment of your security key hit ‘Next’.

Before the enrollment starts an MFA challenge is sent, please make sure to ‘accept the MFA challenge’.

Now choose the type of security key you are planning to add beneath your account. Select ‘USB device’ if you can plugin the device into your laptop. If you’re using a NFC security (for example via Bluetooth with the Feitian K33 key) please select ‘NFC device’.

Make sure you key is plugged in right now and click ‘Next’,

Please hit ‘Continue’ on the pop-up which logs your visit to the site.

Now it’s time to ‘configure a PIN on the device’, if a PIN has already been set on the security key, please type in the PIN you earlier configured on this particular security key. Once done hit ‘OK’.

Now ‘touch your security key’ on the available sensor on your Security Key.

Hit ‘allow’ so Microsoft can see the make and model of the security key and confirm if the AAGUID number is allowed to be used.

Enter a ‘Friendly name’ for the security key beneath this account.

Now as you can see the key is listed beneath your account. Looking at the AAGUID numbers you can see that I’ve used a Yubico Security Key in this example.

Of course you can add more than one security key per account. As you can see I’ve added 5 of them beneath my test account. And as you know you can use one security for multiple accounts, so if you have an admin account which is able to use FIDO2 Security Keys you can use the same key for as well your user as admin account which saves you from a password nightmare :-). Good to know is that you won’t need to set a new PIN for the second enrollment of an account on the security key, the PIN which you did just configure must be used.

Now once you follow the same steps as above with a Security key which either isn’t registered within the allowed AAGUIDs in Azure AD or with a security key which doesn’t support attestation you will receive the notification below telling you that your organization has blocked the use of this particular security key.

In this example I’ve used the Nitrokey FIDO2 Security key to test this (which doesn’t support attestation and besides that isn’t listed within the AAGUID numbers).

Now you’ve done all these configuration steps you should see the option from the Windows 10 logon screen appear and be able to use your provisioned security key to logon to your account.

On the other hand when you use a browser from your home pc, after typing in your username you can hit ‘Sign in with a security key’ to logon to a web based session with your security key.

NOTE: If you are using a key with a biometric sensor (like a fingerprint) you need to enroll this separately. This can be done via the ‘Settings‘ within Windows 10. Once you’re within the ‘Settings‘ pane, please hit ‘Accounts‘ and select ‘Sign-in options‘. From here you can ‘Manage‘ your Security Key and are able to ‘Add‘ a fingerpint on the Security Key. Once done you don’t need to enter your PIN anymore, simply ‘touching’ the security key with the enrolled fingerpint is enough to logon :-).

How to enable a security key in a hybrid environment / deployment?

Now let’s assume you are still working in a hybrid environment with Azure AD Joined devices who still need to be able to access on-premises resources like file shares. Or when you are using Hybrid Azure AD Joined devices which you want to enable with the use of Security keys to do the same.

For this you need to do some alternative steps to get this up and running. This as FIDO2 Security Keys can’t be used out of the box to authenticate to the on-premises Active Directory. For this a Kerberos ticket needs to be generated on the on-premises domain and provided end user his device. As a requirement for that within Active Directory a server object will created which can be used by Azure Active Directory to generate Kerberos TGTs for the on-premises Active Directory domain.

To enable this hybrid security key functionality the following pre-requisites must be met:

  • Make sure to patch your server 2016 and 2019 domain controllers;
  • Windows 10 build 18945 or later is required (Windows 10 version 2004)
  • Version 1.4.32.0 or later of Azure AD Connect is required;

Once the above pre-requisites are met let’s logon to the Azure AD Connect server and ‘open a PowerShell session’ and browse to the folder C:\Program Files\Microsoft Azure Active Directory Connect\AzureADKerberos\’.

Now execute the following PowerShell commands:

Import-Module “.\AzureAdKerberos.psd1”

# Specify the on-premises Active Directory domain. A new Azure AD
# Kerberos Server object will be created in this Active Directory domain.
$domain = Read-Host -Prompt “Enter FQDN of Active Directory Domain”

# Enter an Azure Active Directory global administrator username and password.
$AdminUsername = Read-Host -Prompt “Azure/Office 365 Admin User Account”

$AdminPassword = Read-Host -Prompt “Password” -AsSecureString
$cloudCred = New-Object -TypeName System.Management.Automation.PSCredential -argumentlist $AdminUsername, $AdminPassword

# Enter a domain administrator username and password.
$domainCred = Get-Credential

# Create the new Azure AD Kerberos Server object in Active Directory
# and then publish it to Azure Active Directory.
Set-AzureADKerberosServer -Domain $domain -CloudCredential $cloudCred -DomainCredential $domainCred

Now to verify if the Kerberos Server object is created execute the following PS Command:

# Viewing and verifying the Azure AD Kerberos Server
Get-AzureADKerberosServer -Domain $domain -CloudCredential $cloudCred -DomainCredential $domainCred

And as you can see the server object has been created beneath the Domain Controllers OU.

Once this is all done you should be able to logon with a security key in Windows 10 and be able to access an on-premises file share from an Azure AD Joined or Hybrid Azure AD Joined device which is signed in with a Security key.

Some tips & tricks which can become very handy in relation to security keys:

  • If a password has expired the sign in with FIDO2 security key is blocked, if you have fully secured your environment with MFA, a solution for this could be to set the password to never expire on the accounts with a security key.
  • Don’t use the concept ‘Bring Your Own Key’ either from a security as well as a support perspective this is very unwise. From a security perspective you want to know which security keys are used and what security measures are applied on these keys. On the other hand IT support needs to know what to do when a user asks to help with their enrollment of a security key. Mostly this is done remotely and the engineer therefore needs to know what to touch etc, when using different security keys this can bring in an extra load for your IT support personel.
  • The above PowerShell commands for the hybrid functionality are used for one domain in a forest, if you have a multi-domain scenario within your forest and within each domain synchronized users to Azure AD you should execute the above PowerShell steps for each domain within your forest.
  • Please only rotate the Kerberos keys via the below mentioned PowerShell commands, using other tools for this will disrupt the functionality as the Kerberos keys need to be rotated on both ends, Azure AD as well as AD. Keep in mind to do this each month but not more than once in 24 hours as also shown in the error message below.

In the last blog of this series I will explain how to make sure you can use all the previous mentioned password-less methods on other (web-based) apps. This will make sure that besides Windows 10 and Office 365 services, you can use the password-less methods mentioned in all of the previous blogs for other apps as well!

2 thoughts on “Password-less 4 of 5: Going password-less with FIDO2 Security Keys Part 2

  1. Wolfgang M. says:

    >>This as you don’t want to provision each single key for your users with a PIN, you want users to do >>this on their own based on the self-servicing model.

    Say I want to do it this way…did you look into automated provisioning of these keys? I imagine a provisiong process via powershell, registering fido2-keys in the azureAD to have the necessary certificate-pubkeys written back by AAD Connect

    Like

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s