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:

  1. User signs in to their Windows 10 device with a FIDO2 security key and authenticates to Azure AD.
  2. 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.
  3. The TGT is returned to the client along with their Azure AD Primary Refresh Token (PRT).
  4. The client machine contacts an on-premises AD domain controller and trades the partial TGT for a fully formed TGT.
  5. The client machine now has an Azure AD PRT and a full Active Directory TGT and can access both cloud and on-premises resources.

Source: “Enable passwordless security key sign-in to on-premises resources with Azure Active Directory” (Microsoft Docs)

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

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:

“CN=AzureADKerberos,OU=Domain Controllers," This object represent a “Computer” object and “looks like” a “Read-Only Domain Controller” (RODC).

Microsoft Defender for Identity (MDI) has been tagged the “Computer Object” as “Sensitive” because of the “Read-only DC” security membership:

“CN=krbtgt_AzureAD,CN=Users," Similar to regular deployments of RODC, the “Azure AD Kerberos Server” creates a separated “krbtgt” user object (SAMAccountName: krbtgt_). This user account will be used to sign and encrypt all Kerberos tickets. Microsoft’s seems to follow the same approach (as for RODC) to ensure a cryptographic security isolation between Azure AD’s Kerberos Sever Keys and On-Premises Domain Controllers.

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.

“CN=900274c4-b7d2-43c8-90ee-00a9f650e335,CN=AzureAD,CN=System," This object stores metadata as “Service-Connection-Point” to establish a relation of all related “Azure AD Kerberos Server” objects. Attribute “keywords” includes the following values:

  • Id: GUID (unknown and undocumented value?)
  • UserAccountSid: SID of “CN=krbtgt_AzureAD,CN=Users,”
  • ComputerAccountSid: 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.



➡ Part 2: Onboarding, Authentication and Monitoring



Original cover image by Jan Alexander / Pixabay

You May Also Enjoy

Microsoft Entra Workload ID - Lifecycle Management and Operational Monitoring

22 minute read

Workload identities should be covered by lifecycle management and processes to avoid identity risks such as over-privileged permissions but also inactive (stale) accounts. Regular review of the provisioned non-human identities and permissions should be part of identity operations. In th...