EBS Analysis: Passwordless security key sign-in to on-premises resources – Microsoft Entra ID

Posted on by escapebusinesssolutions in Uncategorized

Eliminating Passwords for Hybrid Access: Microsoft Entra ID Passwordless Security Keys to On-Premises Resources

The enterprise identity landscape has reached an inflection point. Organizations have largely solved passwordless authentication for cloud resources—Microsoft 365, SaaS applications, and modern web services all support FIDO2 security keys and Windows Hello for Business. Yet the on-premises estate remains a stubborn exception. Domain controllers still expect Kerberos tickets. File shares, IIS-backed intranet sites, and line-of-business applications still negotiate NTLM or Kerberos. Users carry a security key for the cloud and a password for the data center.

Microsoft Entra ID now bridges that gap. By issuing Kerberos ticket-granting tickets (TGTs) for Active Directory domains, Entra ID allows a user who signs in with a FIDO2 security key to obtain a valid on-premises TGT without ever presenting a password. The result is true single sign-on across the hybrid boundary: one modern credential, seamless access to both cloud and legacy resources. For enterprises committed to eliminating passwords, this capability removes the final architectural excuse for retaining them.

Architecture and Capabilities

The solution centers on a logical construct called the Microsoft Entra Kerberos server object. Despite the name, no additional physical server is deployed. The object is created in on-premises Active Directory, then securely published to Microsoft Entra ID through Microsoft Entra Connect. It serves as a cryptographic resource that Entra ID uses to generate Kerberos TGTs for the associated AD domain.

Each on-premises AD domain maps to a single KerberosDomain object in Entra ID. A forest with multiple domains yields multiple KerberosDomain objects; multiple forests yield one per domain per forest. This 1:1 mapping ensures that ticket issuance respects existing domain boundaries and trust relationships.

Supported device states include Microsoft Entra joined and Microsoft Entra hybrid joined devices running Windows 10 version 2004 or later. Pure on-premises AD DS-joined devices (no Entra registration) are explicitly excluded. The feature works with Microsoft-compatible FIDO2 security keys and with Windows Hello for Business Cloud trust deployments.

From a resource perspective, the feature enables single sign-on to:

  • Cloud resources: Microsoft 365, SAML-enabled applications, and any service trusting Entra ID tokens.
  • On-premises resources: Windows-integrated authentication to websites (IIS), SharePoint on-premises, file shares, and any resource using Kerberos or NTLM authentication.

Notably unsupported scenarios include Remote Desktop Protocol (VDI, Citrix, standard RDP) using a security key, direct server logon with a security key, and any deployment lacking Entra device registration.

How the Authentication Flow Works

Understanding the ticket exchange is essential for troubleshooting and capacity planning. The flow proceeds as follows:

  1. A user signs in to a Windows 10/11 device using a FIDO2 security key. The device authenticates to Microsoft Entra ID using the private key stored on the security key, completing a passwordless credential ceremony.
  2. Entra ID checks its directory for a Kerberos Server key matching the user’s on-premises AD domain (via the KerberosDomain object).
  3. Entra ID generates a partial Kerberos TGT for that domain. This TGT contains the user’s security identifier (SID) but no authorization data (no PAC).
  4. The partial TGT is returned to the client alongside the user’s Entra Primary Refresh Token (PRT).
  5. The client contacts an on-premises writable domain controller and presents the partial TGT. The DC validates the TGT’s signature (using the shared krbtgt secret), enriches it with authorization data, and returns a fully formed TGT.
  6. The client now holds both an Entra PRT (for cloud resources) and a full AD TGT (for on-premises Kerberos/NTLM resources).

This design preserves the on-premises DC as the ultimate authority for authorization. Entra ID never sees group memberships or resource ACLs; it merely vouches for the user’s identity via the partial TGT. The DC completes the trust chain.

Prerequisites and Environment Readiness

Before deployment, several hard requirements must be satisfied. Treat these as gating criteria—attempting configuration without them will produce opaque failures.

Device and Platform Requirements

  • Client devices: Windows 10 version 2004 or later (Enterprise, Pro, or Education editions).
  • Domain controllers: Windows Server 2016 or later, with all current security updates applied.
  • Kerberos encryption policy: AES256_HMAC_SHA1 must be enabled where the “Network security: Configure encryption types allowed for Kerberos” policy is configured on DCs.

Identity and Synchronization Prerequisites

The following Entra attributes must be populated via Microsoft Entra Connect for every hybrid user:

  • onPremisesSamAccountName (synchronized as accountName in Entra Connect)
  • onPremisesDomainName (synchronized as domainFQDN)
  • onPremisesSecurityIdentifier (synchronized as objectSID)

These are synchronized by default. If attribute filtering has been customized, verify these three remain selected.

Administrative Credentials

Two distinct credential sets are required during configuration:

  • Domain credentials: An AD user who is a member of both Domain Admins (for the target domain) and Enterprise Admins (for the forest). Referred to in documentation as $domainCred.
  • Cloud credentials: An Entra user assigned the Hybrid Identity Administrator role. Referred to as $cloudCred.

FIDO2 Enablement

The organization must first complete the “Enable passkeys (FIDO2) for your organization” process in the Entra admin center. This registers the tenant for FIDO2 attestation and configures the relying party configuration required for security key registration.

Implementation: Creating the Microsoft Entra Kerberos Server Object

The AzureADHybridAuthenticationManagement PowerShell module orchestrates the creation and publication of the Kerberos server object. The module can be installed on any machine with network access to an on-premises DC and the PowerShell Gallery; it does not require installation on the Entra Connect server itself, though the Microsoft.Online.PasswordSynchronization.Rpc.dll dependency must be present (it is present on the Entra Connect server by default).

Module Installation

# Ensure TLS 1.2 for PowerShell Gallery access
[Net.ServicePointManager]::SecurityProtocol = [Net.ServicePointManager]::SecurityProtocol -bor [Net.SecurityProtocolType]::Tls12

# Install the module
Install-Module -Name AzureADHybridAuthenticationManagement -AllowClobber

As of version 2.3.331.0, the module no longer installs the AzureADPreview module as a dependency.

Cloud Environment Selection

By default, the module targets the Microsoft Commercial cloud. For sovereign clouds (Government, Germany, China), the target endpoint must be explicitly set:

# List available cloud endpoints and their numeric identifiers
Get-AzureADKerberosServerEndpoint

# Set the desired cloud (replace 2 with the appropriate value)
Set-AzureADKerberosServerEndpoint -TargetEndpoint 2

Per-Domain Configuration

Run the following in each domain and forest containing Entra-synced users. The example assumes a domain-joined machine with a Domain Admin account; adjust credential parameters as needed.

# If running as a domain admin on a domain-joined machine, -DomainCredential can be omitted.
# If the organization enforces modern auth (MFA, FIDO2, smart card) for admins,
# you MUST supply -UserPrincipalName with the Hybrid Identity Administrator UPN.

Set-AzureADKerberosServer `
  -DomainCredential (Get-Credential) `  # domain\username format works but see notes below
  -UserPrincipalName "admin@contoso.onmicrosoft.com" `
  -DomainName "contoso.corp.com"

Credential Format Nuances

Using domain\username format for the domain credential forces NTLM authentication to the DC, which will fail the RPC bind required for Kerberos key creation. Always use UPN format (user@domain.com) for the domain administrator credential to ensure Kerberos authentication. If the administering account resides in the Protected Users security group, sign in interactively on the Entra Connect server (or a machine with the RPC DLL) without supplying -DomainCredential; the current user’s Kerberos ticket will be used.

Verification

After creation, verify the object properties:

Get-AzureADKerberosServer -DomainName "contoso.corp.com" -UserPrincipalName "admin@contoso.onmicrosoft.com"

Review the output for correct domain mapping, key version, and publication status.

Key Rotation and Lifecycle Management

The Microsoft Entra Kerberos server object maintains a krbtgt secret shared between on-premises AD and Entra ID. This secret must be rotated on the same schedule as your domain controller krbtgt keys—typically every 180 days, aligned with your existing key rotation policy.

Critical: Only the tools in the AzureADHybridAuthenticationManagement module (specifically Rotate-AzureADKerberosServerKey) should be used for rotation. Third-party krbtgt rotation tools or manual AD operations will desynchronize the secret between on-premises and Entra ID, causing authentication failures.

To decommission the feature entirely, run Remove-AzureADKerberosServer, which removes the object from both on-premises AD and Entra ID.

Security and Governance Considerations

Authorization Remains On-Premises

The partial TGT issued by Entra ID contains only the user’s SID. Group memberships, device claims, and resource-specific authorization data are added by the on-premises DC during the TGT exchange. This preserves existing AD governance: group policy, DACLs, and privileged access management continue to function unchanged.

Protected Users Group Implications

Accounts in the Protected Users group cannot authenticate via NTLM and have constrained Kerberos behavior. Administrators in this group must use the interactive sign-in method described above (no -DomainCredential parameter) to avoid RPC bind failures.

FIPS Policy

If Federal Information Processing Standard (FIPS) policy is enforced on the administration machine, temporarily disable it during Kerberos server object creation and key rotation. Re-enable FIPS after completion. Persistent errors after FIPS re-enable typically indicate insufficient administrative permissions on the account used.

Expired Passwords Block FIDO2

If a hybrid user’s on-premises password has expired, FIDO2 sign-in is blocked. The user must reset their password (via self-service password reset, helpdesk, or on-premises change) before passwordless sign-in will succeed. This behavior applies equally to Windows Hello for Business Cloud Kerberos trust.

Group Membership Token Limits

The resulting access token supports up to 1,010 group memberships. Organizations with deeply nested group structures or excessive group assignments should audit token size to avoid authentication failures due to token bloat.

Operational Implications and Known Limitations

Hybrid Join Clean-Install Delay

When clean-installing a Microsoft Entra hybrid joined device, the device must complete domain join, restart, then sign in once with a password to allow group policy and device state synchronization. Only after this initial password sign-in will the FIDO2 security key become usable. This is a known limitation of the hybrid join workflow, not FIDO2-specific. Verify readiness with dsregcmd /status—both AzureAdJoined and DomainJoined must report YES.

Domain Controller Availability and Patching

The client exchanges the partial TGT for a full TGT against a writable DC. At least one writable DC per Active Directory site must be patched to Windows Server 2016+ with the required Kerberos updates. Verify DC readiness with: