Passwordless Options in Azure AD
Azure AD supports three different passwordless options today:
Microsoft’s deployment plan includes a good overview of the authentication methods and their benefits or differences in user scenarios.
In general, FIDO2 security key has (in my opinion) strong advantages in use cases where shared machines, high privileged identities, non-TPM hardware or non-Windows clients are included.
Governance policy that requires (physically) separated authenticator from the endpoint device can also be a good reason to choose security keys.
Note: Windows 10 supports “Multi-factor Unlock” which allows to extend WHfB by another trusted signals (such as Trusted Signal via Bluetooth).
A detailed comparison can be found in the Microsoft Docs article “Choose a passwordless method”. It’s important to analyze and consider your compliance requirements, technical conditions of the environment and different personas (user groups). This should be one your initial tasks to plan and decide the suitable way on your passwordless journey.
Authentication of Hybrid Identities with WHfB
In the past, some organizations has decided to implement Hybrid Azure AD-joined devices to enable modern authentication (Azure AD) but also to enabling single sign-on (SSO) to on-premises resources (Active Directory) .
However, it is possible to provide a “SSO experience” with an Azure AD-joined device as well. Windows Hello for Business (WHfB) can be used to get a “Primary Refresh Token” (PRT) from Azure AD and a “Ticket Granting Ticket” (TGT) from Active Directory Domain Services (AD DS).
Two deployment options are available to implement WHfB in a hybrid environment. The decision to use Key or Certificate Trust deployment depends on pre-requisites and the strategy or supported scenarios.
Regardless of the trust model, Kerberos Authentication certificate for Domain Controllers are required and thus the need of a “Public Key Infrastructure” (PKI). Azure AD Connect is involved for synchronizing the public key to Active Directory. The value of the attribute (“msDS-KeyCredentialLink”) will be created during the registration process of the key trust model.
Azure AD-joined devices allows SSO experiences to Azure AD and Active Directory in hybrid deployment models of WHfB. Both trust models of WHfB are relaying on valid and trusted KDC certificates.
More details and source of the image: “How Windows Hello for Business works - Authentication” (Microsoft Docs)
Comparing FIDO2 and WHfB in Hybrid Environments
There are some important differences in implementation expense, operational effort and supported use cases from my current point of view:
- Complexity (deployment and support): FIDO2 as passwordless option simplifies the deployment without having to use certificates or a dependency on PKI. Common issues of Hybrid WHfB deployments are not relevant such as:
- Invalid or inaccessible Certificate Revocation List (CRL)
- Missing or invalid certificates for “KDC Authentication” on Active Directory Domain Controllers
- Misconfiguration of Enterprise CA / PKI
- Flexibility in shared desktop scenarios: WHfB keys are stored locally on the TPM chip of the device, a user would need to enroll their account on each device. Security keys are intended for use on shared or various devices. Credentials are stored on the keys and not on the local device/TPM.
- Dependency on AAD Synchronization: Provisioning process of WHfB needs to be written back as “key credential link” to the AD. Synchronization may take up to 30 minutes. SSO to on-premises won’t work until the sync has been completed.
- Some scenarios are not supported for FIDO2 security keys
This includes explicit authentication on Remote Desktops (RDP) or “Run as”. Verify the full list of “unsupported scenarios to sign-in with FIDO2 keys”.
- Remote Desktop and WHfB is supported in certain scenarios. Certificate trust deployment of WHfB is able to emulate a smart card for application compatibility. Therefore it can be take advantage of the the integrated smart card capabilities in the Remote Desktop Protocol (RDP). Key trust model can only be used in combination of the “Windows Defender Remote Credential Guard”.
Overview of FIDO2 support in hybrid Azure AD environments
Before we go into the details to implement FIDO2 security keys for hybrid authentication, I like to start with an high-level view.
Microsoft Docs describes the SSO proceeding of FIDO2 keys to on-premises resources as follows:
- User signs in to their Windows 10 device with a FIDO2 security key and authenticates to Azure AD.
- Azure AD checks the directory for a Kerberos server key matching the user’s on-premises AD domain.
a) Azure AD generates a Kerberos TGT for the user’s on-premises AD domain. The TGT only includes the user’s SID. No authorization data is included in the TGT.
- The TGT is returned to the client along with their Azure AD Primary Refresh Token (PRT).
- The client machine contacts an on-premises AD domain controller and trades the partial TGT for a fully formed TGT.
- The client machine now has an Azure AD PRT and a full Active Directory TGT and can access both cloud and on-premises resources.
The question(s) I ask myself is how the “Kerberos Server Keys” interacts with Active Directory? Where we can see the request to get a “fully formed TGT” Active Directory (in aspects of security monitoring). Another fundamental questions arises: “What options are available to allow an easy onboarding?” and “How can I establish a secure connectivity to on-premises by using a passwordless authentication method?”.
In the following section, I will set the focus of my (test) deployment scenario with synchronized hybrid identities (Password Hash Sync, no ADFS/federation) and Azure AD-joined devices with Windows 10 (managed by Intune).
Pre-requisites and initial configuration
Windows 10 Clients
First of all, follow the checklist to verify that your client meets the requirements for our use case:
- Compatible FIDO2 security key: Microsoft established partnerships with various FIDO2 key vendors and also offers a list of known providers.
Verify that your endpoint devices are running a latest version of Windows 10 (at minimum version 2004). The clients must be able to establish a connectivity to Azure AD for registration and authentication.
Note: Internet connectivity is required to enable and register the security keys. Connectivity must be ensured, especially for the initial user sign-in (with FIDO2 security keys). Cached logon information should allows local sign-ins by using cached credentials. Nevertheless, a consistent experience requires connectivity to Azure AD and AD Domain Controllers
- Make sure you are using a supported browser in combination of the device type (USB/NFC/BLE). Browser support of FIDO2 is documented on Microsoft Docs.
- Configure P2S VPN to establish a connectivity to your local “Active Directory Domain Controllers” and on-premises resources. In my example I’ve implemented a native Azure VPN solution for P2S connection. This allows me also to use Azure AD authentication and include MFA and Conditional Access Policies. This is a perfect combination which offers an integration of the included identity and security services. Dishan Francis has written a great blog article on implementing Azure AD Authentication for P2S connectivity.
Azure AD and Intune Configuration
- Enable FIDO2 security key method in your Azure AD Tenant for all or a certain group of user.
- Optional: Configure FIDO2 security key restriction to allow only specific types of hardware. FIDO2 standard specifies that an “Authenticator Attestation GUID” (AAGUID) must be provided. Mostly, you’ll find a list of the AAGUID on vendor’s product pages (Example: YubiKey). Check out the blog post about “Configure FIDO2 security key restrictions” (by Peter van der Woude) if you are interested to learn more.
- Enable “Temporary Access Pass” (TAP) to onboard users securely without (traditional) “password”. Consider to configure the policies on your security requirements (e.g. on-time use, lifetime) and restrict the target group (e.g. onboarding group). In particular, I highly recommend to monitor management activities and creation of TAPs..
- Turn on FIDO2 security keys as Credential Provider for Windows sign-in by Intune Device Configuration.
- Enable “Web Sign-in” for initial authentication by using (one-time) TAP in the Windows logon UI. It’s not supported to sign-in with TAP as (initial) user password in the standard logon UI.
Hybrid Identity components and Active Directory
- Requirements and steps to configure “Azure AD Kerberos Server” has been well documented by Microsoft. Follow the steps to create the “Kerberos server object” and run the “Set-AzureADKerberosServer” cmdlet.
- Keep in mind, latest version of Azure AD Connect is needed to use the “AzureADKerberos” PowerShell module for further configuration and management. Although, the sync engine isn’t required or part of the process to establish or provide FIDO2’s SSO functionality to on-premises resources.
Review of created “Azure AD Kerberos Server” Objects
We can found the following objects, which represents the “Azure AD Kerberos Server” in the AD domain, after running the cmdlet:
Microsoft Defender for Identity (MDI) has been tagged the “Computer Object” as “Sensitive” because of the “Read-only DC” security membership:
This object will be also published to “Azure AD” as part of the “Set-AzureADKerberosServer” cmdlet and will be created in context of the user credentials (provided value in the “Cloud Credentials” parameter). You’ll find the following event in the “Azure AD Audit Logs” (Category: “KerberosDomain”):
Note: The krbtgt_AzureAD account seems not be visible in the Azure AD as user or any other type of object.
- Id: GUID (unknown and undocumented value?)
SID of “CN=krbtgt_AzureAD,CN=Users,
SID of “CN=AzureADKerberos,OU=Domain Controllers,
Management of “Azure AD Kerberos” Objects
The PowerShell Module “AzureADKerberos” will be used to view details of the objects in Azure AD and Active Directory. This module is also needed for rotation of the encryption keys (on both sides of your hybrid identity environment).
List objects by using Get-AzureADKerberos
The “Azure AD Kerberos Server” PowerShell module includes also a cmdlet to get an overview of all objects and relevant attributes:
Id : 30775 UserAccount : CN=krbtgt_AzureAD,CN=Users,DC=ad,DC=cloud-architekt,DC=net ComputerAccount : CN=AzureADKerberos,OU=Domain Controllers,DC=ad,DC=cloud-architekt,DC=net DisplayName : krbtgt_30775 DomainDnsName : ad.cloud-architekt.net KeyVersion : 1585708 KeyUpdatedOn : 4/23/2021 10:26:55 AM KeyUpdatedFrom : dc1.ad.cloud-architekt.net CloudDisplayName : krbtgt_30775 CloudDomainDnsName : ad.cloud-architekt.net CloudId : 30775 CloudKeyVersion : 1585708 CloudKeyUpdatedOn : 4/23/2021 10:26:55 AM
Description of the properties are listed in the Microsoft Docs article.
Logs of AzureADKerberos PowerShell Module
Detailed operational logs of executing the cmdlets are stored in the Azure AD Connect Trace logs: “C:\ProgramData\AADConnect\trace-*.log”
Rotation of Azure AD Kerberos encryption key
You should consider to rotate the password of the “krbtgt_AzureAD” on a regular basis. Key rotation is strongly recommended for all “krbtgt” accounts and the AzureADSSOAcc (in case you have deployed the “Seamless SSO” feature)
Important note from Microsoft Docs about procedure and tools to rotate the key:
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.
Therefore you should using the “Set-AzureADKerberosServer” alongside of the parameter “RotateServerKey” cmdlet. After successful completion, check the key versions as a result of running the “Get-AzureADKerberosServer” cmdlet:
Id : 30775 UserAccount : CN=krbtgt_AzureAD,CN=Users,DC=ad,DC=cloud-architekt,DC=net ComputerAccount : CN=AzureADKerberos,OU=Domain Controllers,DC=ad,DC=cloud-architekt,DC=net DisplayName : krbtgt_30775 DomainDnsName : ad.cloud-architekt.net KeyVersion : 1586495 KeyUpdatedOn : 4/23/2021 4:16:33 PM KeyUpdatedFrom : dc1.ad.cloud-architekt.net CloudDisplayName : krbtgt_30775 CloudDomainDnsName : ad.cloud-architekt.net CloudId : 30775 CloudKeyVersion : 1586495 CloudKeyUpdatedOn : 4/23/2021 4:16:33 PM
The key versions of Active Directory (KeyVersion) and Azure AD (CloudKeyVersion) should be identical. Check the logs of “Azure AD connect” for any troubleshooting or detailed review of the rollover process.
Azure AD Audit logs will shown two activities for this key rollover process:
Security Policy to restrict “Azure AD Kerberos Server”
The FAQ of “Hybrid FIDO2 security keys” in Microsoft Docs describes a “security policy” that disallows grant permission to high privilege accounts.
Let’s have a closer look on the following two properties of the “Azure AD Kerberos” Computer object (CN=AzureADKerberos,OU=Domain Controllers,<domain-DN):
msDS-NeverRevealGroup This property is used for RODCs to manage the sensitive users/groups that should not be replicated to a RODC (“Denied replication”). By default, Microsoft blocks high privileged accounts to use “FIDO2 security keys” to get access for on-premises resources:
msDS-RevealOnDemandGroup Another familiar property which is used to define replication to RODCs. All domain users are included to allow caching their passwords on RODC. In this case, the property seems to control which users are allowed for using FIDO2 keys to get SSO to on-premises.