Active Directory Domain Services remain the authoritative identity store for on-premises deployments. User accounts, group policies, and device computer accounts all reside in AD DS. In the WHfB context, AD DS is where the user’s credential public keys or certificate information are ultimately stored and used for authentication. Domain Controllers (DCs) must be running Windows Server 2016 or later to support Windows Hello for Business authentication, because WHfB relies on extensions to Kerberos (specifically, Kerberos PKINIT with public key or certificate) that are only available in modern DCs. A crucial requirement is that each domain controller is equipped with a certificate that proves its identity to clients during Kerberos PKINIT authentication. In other words, the domain controllers need Kerberos authentication certificates (often issued from the enterprise CA) so that Windows 10/11 clients trust the DC’s public key when the DC is presented as a Kerberos Key Distribution Center (KDC) in a certificate-based authentication flow^ [Plan a Windows Hello for Business Deployment – Microsoft Docs (2025) ^]. This certificate requirement is part of establishing a trust anchor: it prevents man-in-the-middle attacks by ensuring the client can verify that it is communicating with a legitimate DC during the Hello authentication process. Typically, enterprises configure an auto-enrollment policy so that all domain controllers enroll for a certificate on the “Kerberos Authentication” or “Domain Controller Authentication” template. These certificates include the proper Extended Key Usage (EKU) for KDC authentication and have the DC’s domain name in Subject or Subject Alternative Name, as required for Kerberos. In summary, AD DS provides the directory framework where credentials are checked, and it must be prepared with the right schema (Windows Server 2016 schema includes new attributes for WHfB) and PKI support (DC certificates) to handle passwordless authentication requests.

In a key trust deployment, Active Directory also stores each user’s public key in a special attribute on the user object (the msDS-KeyCredentialLink attribute). This attribute is populated during provisioning with the user’s Windows Hello public key and serves as the source of truth that domain controllers use to verify the user’s identity during logon. In a hybrid scenario, the public key is written to Azure AD and then synced to this attribute on-premises; however, in a purely on-premises scenario, as we have here, the public key is written directly into AD DS via the AD FS infrastructure (described below). Once stored, the public key in msDS-KeyCredentialLink allows the DC to authenticate the user via a Kerberos AS request that is signed by the corresponding private key (held in the user’s device). The DC retrieves the user’s public key from AD DS and uses it to validate the Kerberos pre-authentication data, effectively confirming the user’s identity without a password. In a certificate trust deployment, by contrast, the user’s credential is an X.509 certificate issued to the user. In that case, AD DS may store the certificate on the user object (in the userCertificate attribute) or simply validate it on the fly using standard smart card logon methods (which check the certificate’s signature and the presence of a mapped user principal name or other mapping to the user account). Either way, AD DS is the ultimate authority that verifies either the user’s public key (for key trust) or the user’s certificate (for certificate trust) and then allows Kerberos ticket issuance. The domain controllers thus must be configured to accept either method. Notably, both key trust and certificate trust use certificate-based Kerberos authentication under the hood – key trust essentially treats the user’s key as a virtual smart card certificate for Kerberos, while certificate trust literally uses a certificate – so domain controllers must trust the certificate issuer or the stored key likewise. In summary, AD DS’s main roles are to store credential material (keys or certs) and to perform authentication via Kerberos using that material.

Active Directory Federation Services is a required component in an on-premises WHfB deployment to handle processes that Azure cloud services would normally handle in a hybrid or cloud scenario. Specifically, AD FS functions as the device registration and key registration service for on-premises deployments. AD FS is responsible for onboarding the device into a state where it can use WHfB and for broker­ing the initial provisioning of the user’s credential. In a cloud or hybrid model, when a device is Azure AD joined, Azure AD performs device registration and accepts the Hello public key from the client. In an on-premises model, those tasks are performed by AD FS’s Device Registration Service (DRS). The AD FS server must be configured for Device Registration in your AD forest (often referred to as enabling the “Device Join” or “Workplace Join” functionality of AD FS). This allows domain-joined computers to register themselves as known devices in AD. Once device registration is enabled on AD FS and the necessary configuration (e.g. certificates and service accounts) is in place, domain-joined Windows clients can register with AD FS as part of the WHfB provisioning. During this registration, AD FS creates a device object in AD DS (under the Registered Devices container) or updates the device’s computer object to link it with the registration. In on-premises deployments, AD FS effectively stands in for Azure AD by providing an on-premises endpoint to which Windows Hello for Business clients can deliver the newly generated public key. According to Microsoft’s official guidance, *“for on-premises deployments, the server running the AD FS role is responsible for device ^ [Plan a Windows Hello for Business Deployment – Microsoft Docs (2025) ^].

Beyond device registration, AD FS plays another critical role depending on the trust model: it either handles key registration or acts as a Certificate Registration Authority. In a key trust model, AD FS receives the user’s newly created public key during provisioning and writes that public key to the user’s account in AD DS (into the msDS-KeyCredentialLink attribute). Essentially, AD FS bridges the gap between the Windows client and AD DS, since the client (as a regular domain user) does not itself have permission to add a value to its user object’s msDS-KeyCredentialLink. AD FS, running under a service account with elevated permissions for device registration, performs this directory update securely as part of the provisioning flow. In a certificate trust model, AD FS instead serves as a certificate broker: it runs as a Certificate Registration Authority (CRA) that can accept a certificate signing request from the Windows client’s Hello provisioning and forward it to an enterprise Certification Authority. Microsoft documentation notes that “Windows Hello for Business certificate trust deployments use AD FS as the certificate registration authority”^[Configure AD FS in an on-premises certificate trust model – Microsoft Docs^]. In this role, AD FS first verifies the user’s identity and device status (ensuring that the user completed MFA, etc.), then it takes the public key generated on the client and uses it to request a user authentication certificate from the CA. AD FS holds a special Enrollment Agent certificate that allows it to request certificates on behalf of a user – this is configured in advance as part of setting up the WHfB certificate trust deployment. Once the CA issues the certificate, AD FS returns that certificate to the client. This entire transaction happens during the user’s initial enrollment (provisioning) for Hello for Business.

It is important to highlight that AD FS in an on-premises WHfB scenario must be properly prepared with several configurations: the Device Registration Service must be enabled and configured (including providing an SSL certificate for the device registration endpoint and updating the AD FS configuration with an identifier for the device registrations), and if certificate trust is used, the AD FS server must have an Enrollment Agent certificate and be set up to communicate with the enterprise CA. AD FS also needs to be configured with an appropriate Multi-Factor Authentication adapter, because WHfB provisioning requires a second factor (discussed below). In summary, AD FS is the hub that facilitates the provisioning workflow: it authenticates the user (with MFA), accepts the device’s Hello public key, and either writes the key to AD or issues a certificate via the CA. It also maintains the federation service that can be used for other purposes (in a pure on-premises model, AD FS might primarily be used just for WHfB registration, but in some cases it could also be used for other federated applications; however those are outside the scope of Hello for Business itself).

A Public Key Infrastructure is required for all on-premises deployments of Windows Hello for Business, regardless of trust model. This is because at minimum the domain controllers need certificates (as explained earlier), and in the certificate trust model, users will also get certificates for authentication. Microsoft’s planning guide explicitly states that all on-premises and hybrid deployments (except the new cloud trust model not applicable on-prem) *“depend on an enterprise PKI as a trust anchor for ^ [Plan a Windows Hello for Business Deployment – Microsoft Docs (2025) ^]. The PKI in an on-prem WHfB deployment typically consists of an enterprise Certification Authority (such as Active Directory Certificate Services) that issues certificates to both machines and users based on templates configured by the administrator. Key PKI requirements and components include:

• Domain Controller Certificates: As noted, each DC must have a certificate that includes the “Kerberos Authentication” EKU (or the older combination of “Client Authentication” and “Server Authentication” EKUs used for domain controller certs). These certificates are issued by the enterprise CA. The subject name or alternative names on the DC cert must include the DC’s identity in a form that the client recognizes. In particular, if a third-party (non-Microsoft) CA is used to issue the DC certificates, special care must be taken that the certificate’s subject contains the directory path of the DC’s AD object, or the SAN contains the correct DNS and NetBIOS names. Otherwise, Windows 10+ clients may refuse to use them for Kerberos authentication. (This is discussed more in the troubleshooting section; an incorrect DC certificate subject can lead to errors where the client “received a KDC certificate that does not have a matched domain name” and fails authentication.) In most cases, organizations use their Active Directory-integrated Certificate Services with the default Kerberos Authentication template to auto-enroll DCs, which ensures these requirements are met. The presence of valid DC certificates in their personal store is essential before WHfB can be used in the domain.

• User Authentication Certificates (Certificate Trust model only): In the certificate trust model, each user who enrolls in Windows Hello for Business will receive a certificate, typically called the “Windows Hello for Business Authentication Certificate.” The enterprise CA must have a certificate template configured for this purpose. According to Microsoft’s deployment guide, this user certificate template should be set to require an Enrollment Agent signature, meaning the CA will only issue the certificate if the request is signed by a trusted Registration Authority (in our case, AD FS) using its Enrollment Agent certificate^[Configure AD FS in an on-premises certificate trust model – Microsoft Docs^]. This template often has the Smart Card Logon and Client Authentication EKUs, allowing it to be used for logging into AD (just like a smart card cert). The certificate’s subject name or subject alternative name is usually the user’s UPN (User Principal Name) so that Active Directory can map the certificate to the correct user during logon. During provisioning, AD FS (as the RA) will sign the user’s CSR and the CA will issue the cert back to AD FS, which then delivers it to the user’s device. The user’s private key for this cert is the same generated key that would have been used for key trust – except here it gets certified by the CA. Once issued, the certificate is stored on the user’s device (in the user’s personal certificate store) and also is often published to Active Directory (auto-published to the userCertificate attribute). The certificate will have a finite lifetime (e.g., 1 or 2 years as set by the template), but Windows Hello for Business can silently renew it in the background via AD FS as long as the user continues to sign in with Hello credentials^ [Configure Windows Hello for Business in on-premises certificate trust – Microsoft Docs^].

• Enrollment Agent for AD FS (Certificate Trust model): In order for AD FS to request certificates on behalf of users, it needs an Enrollment Agent certificate issued to its service account (or to the AD FS server itself, if using a gMSA service account) that it uses to sign CSR requests. Part of the deployment involves duplicating the built-in Exchange Enrollment Agent template (or a similar Enrollment Agent template) to create one specifically for WHfB (for example “WHfB Enrollment Agent”), and then enrolling the AD FS service account for a cert from that template^ [Configure AD FS in an on-premises certificate trust model – Microsoft Docs^]. This allows AD FS to act as a trusted intermediary. This enrollment agent certificate must be kept updated (with a long validity or auto-renewal) because if it expires, AD FS will not be able to broker new certificate requests.

In summary, the PKI underpins trust in the system. Even in key trust deployments where users don’t get certificates, the enterprise PKI’s role in issuing DC certificates (and possibly providing a certificate for AD FS token signing or device registration as well) is non-negotiable. Administrators should have an enterprise CA available and properly configured before enabling WHfB on-premises. They should also note that any non-Microsoft CAs used for issuing DC or client certificates must adhere to specific certificate subject requirements for Kerberos and smart card logon to function (the Microsoft guidelines on smart card login with third-party CAs should be consulted to ensure compliance). Neglecting these PKI requirements can lead to authentication failures even if all other components are correctly set up.

On the client side, each Windows device (desktop or laptop) that participates in WHfB on-premises must be domain-joined (since we are dealing with an Active Directory on-prem scenario, not Azure AD join). Typically, the device will be running Windows 10 (version 1703 or later) or Windows 11, which have built-in support for WHfB. The device’s hardware should include a Trusted Platform Module (TPM) chip for secure key storage; while WHfB can technically use software-protected keys if configured, it is strongly recommended (and usually policy-enforced) to use a TPM – effectively treating it as a virtual smart card. A Group Policy or MDM policy will be used to enable Windows Hello for Business on the device. By default, Active Directory domain-joined machines do not automatically prompt users to set up WHfB; an administrator must enable the feature via policy. In an on-prem deployment, this is often done with Group Policy: enabling the policy “Use Windows Hello for Business” (under Computer or User configuration → Administrative Templates → Windows Components → Windows Hello for Business) ^[Configure Windows Hello for Business policy settings (Key Trust) – Microsoft Docs^]. This policy can be applied to all users or computers that should use WHfB. Additionally, in certificate trust deployments, a second policy “Use certificate for on-premises authentication” must be enabled so that the client knows it should obtain a certificate as part of Hello provisioning^ [Configure Windows Hello for Business policy settings (Certificate Trust) – Microsoft Docs^]. It is also recommended to require a hardware security device (TPM) via the “Use a hardware security device” policy to enforce key storage in hardware. Once these policies are in effect and the device has the necessary connectivity to the AD FS service and domain controllers, the user will be prompted to set up Windows Hello for Business (typically at first logon or next logon after policy applies).

Provisioning Process on the Client: The WHfB provisioning is triggered after a user logs onto the machine with their AD domain password for the first time (following policy application) and meets the prerequisites (e.g. the machine can reach the AD FS service and the user has not already set up WHfB). The user will see a prompt to set up a PIN (and optionally biometrics) as part of the “Windows Hello” enrollment. The provisioning wizard will first verify that the environment is ready: it checks for device registration status, policy configuration, network connectivity, etc. If any prerequisite is not met, the provisioning will be aborted and an event is logged (for example, Event ID 362 in the User Device Registration log will detail which prerequisite failed – see Troubleshooting section). Assuming prerequisites are met, the client then proceeds: it prompts the user for a second factor authentication. In an on-premises model, this second factor is handled via AD FS: typically, AD FS will invoke an MFA adapter (for example, a third-party OTP token, smart card, or an on-premises MFA server if one was installed before deprecation) to verify the user’s identity beyond the password. Once the user completes the MFA challenge, the client is cleared to provision the Hello credential. The Windows system will generate a new asymmetric key pair that will serve as the user’s credential. The private key is created in the device’s TPM (or software key store if TPM is not available or not required by policy) and is marked as non-exportable, meaning it cannot be extracted from the device. The public key (or a certificate containing the public key, in certificate trust cases) is what will be sent to the server side. At this point, the client uses the previously established secure session with AD FS (from the MFA-backed logon) to send its freshly generated public key. If key trust is configured, the client transmits the public key itself to AD FS; if certificate trust is configured, the client actually generates a certificate signing request (CSR) for the public key.

During provisioning, AD FS and the client device perform the following interaction (key trust vs. certificate trust):

• Key Trust: The client sends the public key to AD FS’s device registration endpoint along with proof of the user’s identity (the AD FS security context established via MFA). AD FS then takes this public key and writes it into Active Directory (into the user’s msDS-KeyCredentialLink). After AD FS confirms the key registration is successful, the provisioning on the client completes. The user is informed that Windows Hello is set up, and they can now sign in with a PIN or biometric going forward. The next time the user signs in (or unlocks the device), WHfB will be used. The credential ID (Key ID) is associated with the user’s account and device, and AD now “knows” that this user has a valid key-based credential.

• Certificate Trust: The client sends a certificate request to AD FS’s certificate enrollment endpoint (still as part of device registration process). The request includes the public key and typically asks for a certificate based on the WHfB Authentication template. AD FS (as the Certificate Registration Authority) validates that the user has done MFA and that the device is a known, registered device (AD FS might verify a device certificate or device entry as well). It then signs the CSR using its Enrollment Agent certificate and forwards it to the enterprise CA. The CA issues the certificate (if the request meets the template requirements and the user is allowed to enroll – often the template is configured to allow enrollment only for users in a certain security group, etc., as an extra control). AD FS receives the issued certificate and passes it back to the client. The client then installs this certificate in the user’s certificate store. At this point, the provisioning is complete from the user’s perspective – they have a PIN/biometric set up and a certificate issued for authentication. The AD FS service might also publish the certificate to the user’s AD object (depending on configuration) so that it is available for easy retrieval by DCs, though DCs can also accept it directly at logon without needing it pre-published, as long as they trust the issuer.

It is worth noting that the Windows client does all of this automatically; the user’s experience is simply that they set up a PIN and perhaps their fingerprint. The exchange of keys, certificates, and contacting AD FS/CA all happens in the background. The client will report success or failure via on-screen prompts and also event logs. If anything fails (e.g., the AD FS service is unreachable or returns an error, or the CA denies the request), the provisioning will not finalize, and the user will not be able to use Hello – thus requiring troubleshooting.

Sign-in and Authentication: Once a user has successfully provisioned WHfB on a device, subsequent authentications use the WHfB credential. The user will see the option to input their PIN or use their biometric at the lock screen, rather than entering a password. When the user provides their PIN (which is verified locally by the TPM unlocking the private key), the Windows Hello authentication process uses the private key to perform a Kerberos logon to Active Directory: this is effectively a passwordless Kerberos AS-REQ. The details differ slightly by trust type:

• In a key trust scenario, Windows constructs a Kerberos AS-REQ (Authentication Service Request) for the user to the domain controller, but instead of including a password-derived hash for pre-authentication, it includes a signed blob proving possession of the user’s private key. The KDC on the domain controller identifies the user (by the account name the user is trying to log in as) and retrieves that user’s public key from the msDS-KeyCredentialLink attribute in AD. It then uses the public key to verify the signature in the Kerberos request. If the signature is valid, it means the holder of the private key (presumably the user via their device) is authenticating. Because the public/private key pair was set up with MFA during provisioning, this logon is considered two-factor authenticated and strong. The KDC then issues a Kerberos Ticket-Granting Ticket (TGT) for the user, as with a normal password logon, and the user is logged on to Windows. From there, the Kerberos TGT can be used to access network resources (file shares, etc.) seamlessly. This process is often called “private key Kerberos authentication” and is conceptually similar to smart card logon but without an actual certificate on the user – the public key in AD serves as the “smart card certificate.”

• In a certificate trust scenario, the user’s Hello private key is associated with an authentication certificate (as described). In this case, when the user signs in with the PIN, Windows uses the private key to sign a Kerberos AS-REQ using the user’s certificate (this is standard Kerberos PKINIT with a smart card certificate, technically). The domain controller receives the request, which contains the user’s certificate and the signature. It validates the certificate: since the certificate was issued by the enterprise CA, the DC will trust it (the DC’s own certificate store trusts the CA). The DC also maps the certificate to the user’s account – typically via the User Principal Name in the certificate or another defined mapping. If the certificate is valid (not expired, not revoked) and maps to the user, and the signature verifies (proving the user possesses the private key for the certificate), the DC considers this a successful logon attempt and issues a Kerberos TGT. In effect, this is identical to a smart card logon flow, except the “smart card” is virtual (the user’s key in the TPM and the Hello certificate). From the AD perspective, certificate trust WHfB logons are handled by the same mechanisms as smart card logons.

After the Kerberos TGT is obtained via either method, the user can access on-premises resources with SSO. For any given service (e.g., a file server), the user’s device will request a service ticket from the KDC as usual, and since they have a TGT, this proceeds normally. The user’s experience is a fast, password-free logon. It’s important to emphasize that both key trust and certificate trust authenticate the user via an asymmetric key proof to Active Directory (one directly with the key, one via a certificate). Because of this, both require the domain controllers to have the capability to handle certificate-based authentication (hence the need for DC certs and updated Kerberos support). Microsoft documentation confirms that “Key trust and certificate trust use certificate authentication-based Kerberos when requesting Kerberos ticket-granting tickets for on-premises authentication” ^[Plan a Windows Hello for Business Deployment – Microsoft Docs (2025) ^]. The difference is mainly in how the user’s public key is stored and managed (AD attribute vs. actual certificate).

Multi-Factor Authentication integration: A brief note on MFA: Windows Hello for Business provisioning requires two-factor authentication at setup time. In cloud or hybrid deployments, Azure MFA or other methods can be used. In an on-premises deployment, AD FS must have an MFA method configured because the user’s second factor will be invoked via AD FS during enrollment. The available options include third-party MFA adapters (RSA SecurID, Duo, etc.), or the now-legacy Microsoft Azure MFA Server (on-premises). However, Microsoft no longer offers Azure MFA Server for new deployments and support for it is ending – indeed, as of September 30, 2024, the Azure MFA Server will stop servicing requests^[Plan a Windows Hello for Business Deployment – Microsoft Docs (2025)^]. Therefore, organizations implementing WHfB on-premises today should plan to use either a third-party on-prem MFA solution that plugs into AD FS, or consider a hybrid approach using cloud-based Azure MFA via AD FS (this would involve AD FS redirecting the MFA to Azure – though this starts to introduce a cloud dependency). The key point is that on-premises WHfB deployments must present the user with an MFA challenge through AD FS during provisioning^ [Plan a Windows Hello for Business Deployment – Microsoft Docs (2025) ^]. If no MFA is configured, the provisioning will not proceed – the system will treat it as not satisfying security requirements and log an error. Once provisioning is complete, daily logons with WHfB do not require an additional MFA because the Hello credential itself (TPM-bound key + PIN) is considered two-factor (something you have – the device/key, and something you know or are – the PIN or biometric).

To summarize the two trust models in an on-premises context:

• Key Trust: Simpler in that the user does not need a certificate; the infrastructure needs are AD DS (with schema updates and msDS-KeyCredentialLink), AD FS (for device and key registration), and CA for DC certificates only. The user’s public key is stored in AD. The authentication uses that key via Kerberos. Key trust requires Azure AD Connect in hybrid scenarios to sync keys, but in pure on-prem, AD FS directly populates the keys in AD. Key trust deployments were once affected by certain Windows Server bugs (as we’ll see in troubleshooting) but are generally the recommended model if certificate-based apps are not needed, because they avoid managing user certificates^[Windows Hello for Business Cloud Kerberos Trust Overview – Microsoft Docs^].

• Certificate Trust: Requires a full PKI deployment for issuing user certificates in addition to DC certs. AD FS must be set up as a registration authority with an enrollment agent. Users get a certificate for logon, which some organizations prefer for compatibility with existing smart card mandates or where a certificate might be used for other purposes (VPN, etc.). The authentication is basically smart card logon. This model has more moving parts (CA, templates, certificate lifecycles) but is necessary if, for example, you want WHfB to also cover scenarios where a certificate is explicitly required for application authentication (some legacy systems might only accept certificate auth, not key-based Kerberos).

Both models deliver the same end-user experience: a PIN or biometric sign-in to AD. The choice often comes down to infrastructure readiness and long-term maintenance considerations. Notably, if an organization deploys one model and later wants to switch (for instance from on-premises to hybrid cloud trust, or from key trust to cert trust), it generally requires re-provisioning the credentials for users – there is no seamless in-place switch, because the credential type and trust anchor differ (the Microsoft documentation warns that migrating from an on-premises model to hybrid, for example, requires redeployment of WHfB credentials)^[Plan a Windows Hello for Business Deployment – Microsoft Docs (2025)^]. Therefore, choosing the trust model up front is an important architectural decision.

1. WHfB Provisioning not initiated (no prompt for PIN setup): Symptoms: A user logs onto a domain-joined Windows 10/11 device but is never prompted to configure Windows Hello for Business. In the Event Viewer, under User Device Registration/Admin, you might find an event (e.g., Event ID 362) indicating “Windows Hello for Business provisioning will not be launched” with details of prerequisites. The event details may show lines such as “Windows Hello for Business policy is enabled: No” or other prerequisites marked as “No” or “Not Tested.” Typically, Event 362 is a warning event that enumerates a checklist of conditions (device join state, credentials used, policy enabled, hardware requirements, etc.) and if one of them is failing, the provisioning is skipped. For instance, if the policy “Use Windows Hello for Business” is not enabled, the log will show “policy is enabled: No” and thus “provisioning will not be launched.” Another line in this event is “User has successfully authenticated to the enterprise STS: No”, which specifically pertains to AD FS (enterprise STS) connectivity, discussed separately below.

Cause: If no Hello enrollment is offered, it usually means a prerequisite was not met. The most common cause is policy misconfiguration – the device or user is not targeted by the WHfB enable policy. By default, WHfB is not mandated for domain-joined devices; an administrator must explicitly enable it via Group Policy or MDM. If neither is done, the client will simply not initiate enrollment. Another cause could be that the device is not Azure AD joined or registered (in a hybrid scenario event 362 would flag “Device is Azure AD joined: No” – but for a pure on-prem deployment, Azure AD join isn’t required; however the device must be domain-joined and should be registered with AD FS via DRS, which the client checks). If AD FS Device Registration is not working, the client might not consider the device “enterprise authenticated,” resulting in no prompt. Additionally, if the user did not log on with domain credentials (for example, using a local account or caching an old credential) the system might not trigger WHfB setup.

Resolution: Ensure that the Group Policy “Use Windows Hello for Business” is set to Enabled for the intended scope (either at the computer level for all users of the device, or at the user level). Microsoft documentation notes that at least one of these must be enabled for enrollment to start^ [Configure Windows Hello for Business policy settings (Key Trust) – Microsoft Docs^]. Use the gpresult tool or Intune’s device configuration reporting to verify the setting is applied. If using on-premises certificate trust, also enable “Use certificate for on-premises authentication” policy for those same users or devices, otherwise the client will not know to attempt certificate enrollment. Next, confirm that the device is properly registered with AD FS. On the AD FS server, the Device Registration status can be checked (for AD FS 2016+, use PowerShell Get-AdfsDeviceRegistration to ensure it’s enabled). If device registration was not enabled, enable it with Invoke-AdfsDeviceRegistration. Then join a test device to the domain and see if an AD device object appears in the RegisteredDevices container after first sign-in. If the event log indicates “Enterprise user logon certificate enrollment endpoint is ready: Not Tested” or “User has successfully authenticated to the enterprise STS: No” in Event 362, this means the client could not reach or authenticate with AD FS – possibly due to AD FS service being down or unreachable (DNS or network issues) or because the user’s logon did not go through AD FS. In an on-prem scenario, the user’s initial logon is with a password against AD (not via AD FS), so how do we get “authenticated to STS”? This refers to the step where the client, after first logon, contacts AD FS to do device registration and MFA. If that step fails (e.g., AD FS requires something that wasn’t met), the client logs that as “did not successfully authenticate to STS.” To fix this, ensure the AD FS service is accessible (the device should be able to reach the AD FS URL, typically something like https://fs.company.com), and that AD FS is configured to allow the device registration and the authentication of the user. If AD FS has strict access policies, adjust them to allow intranet device registration. Also check that the MFA adapter on AD FS is working – if MFA is not reachable, the AD FS might not complete the auth, causing the client to log that line. In summary, to resolve lack of provisioning prompt: set the required GPOs, verify device registration is enabled and functioning, and verify connectivity/MFA with AD FS. Once these are corrected, a user logging in interactive should trigger the WHfB setup. Clearing the User Device Registration cache (via certutil -delstore commands for the Ngc keys) can force retriggering if needed, but usually not necessary if configuration is corrected.

2. Failure during provisioning – “That option is temporarily unavailable” error: Symptoms: The user is prompted to set up Windows Hello for Business, enters the PIN (and possibly performs MFA), but at the final stage, it fails. On the client, after entering the second factor, the error “That option is temporarily unavailable. For now, please use a different method to sign in.” may be displayed. This error might appear either during provisioning or on the next login attempt using Hello. In event logs, if the user tries to sign in with Hello and it fails, there may be events in User Device Registration or Security-Kerberos logs. Specifically, Microsoft documentation notes that on a client, authentication failing with "That option is temporarily unavailable" is often associated with a problem in key trust deployments where the user’s public key was not yet replicated or recognized by the domain controller at the time of login^[Windows Hello for Business known issues – Microsoft Docs (2025)^]. One known scenario is in hybrid or on-premises key trust: if the user’s public key was not present on the particular domain controller that processes the logon (due to replication latency or not being written at all), the DC cannot validate the Hello key, and the login fails with this message. In the event log, you might see a corresponding Kerberos error on the DC side or an indication of missing credentials. Additionally, a network trace of the Kerberos flow might show a specific error code such as KDC_ERR_CLIENT_NAME_MISMATCH if the DC couldn’t find a matching key. In the AD FS Admin logs (if the error occurred right after provisioning), there might not be much since this is more of a post-provision sign-in issue. However, one particular known cause of this error was a bug in early Windows Server 2019 domain controllers where key trust authentication would intermittently fail. This bug manifested as the DC incorrectly deleting the user’s public key from AD or otherwise not handling it, leading to the client being unable to authenticate via Hello until a sync or a certain condition was met. Microsoft documentation identified this as an issue where “networks traces report KDC_ERR_CLIENT_NAME_MISMATCH” and the client shows “That option is temporarily unavailable” on sign-in for key trust deployments with Server 2019 DCs^ [Windows Hello for Business known issues – Microsoft Docs (2025) ^].

Cause: The general cause is that the user’s Hello credential was not fully ready or available to the DC at the time of logon. In hybrid key trust, this can be due to Azure AD Connect not yet syncing the key to AD. In a purely on-prem scenario, this could be due to AD FS not writing the key or the key not replicating to a global catalog DC in time. The specific Windows Server 2019 issue was a bug in the OS: certain builds of Server 2019 had a flaw where after a user’s initial WHfB logon, subsequent logons would fail because the DC had removed the key (essentially requiring the key to be written again via a sync). This bug affected on-premises key trust as well, not just hybrid, and led to exactly the scenario of initial success then “temporarily unavailable” on second attempt. Another related cause documented is the user’s public key getting deleted from AD prematurely. Microsoft noted that in some WS2016/2019 builds, “the user’s Windows Hello for Business key is deleted after they sign-in. Subsequent sign-ins will fail until the user’s key is synced during the next sync cycle” (or until re-provisioned) ^[Windows Hello for Business known issues – Microsoft Docs (2025) ^]. Essentially, a race condition or bug caused the attribute msDS-KeyCredentialLink to be emptied after first use, so the next login doesn’t find the key.

Resolution: First, determine if you are hitting the known Windows Server bug or a general sync issue. If you have domain controllers on Windows Server 2019 or 2016, apply the latest patches. Microsoft provided specific updates that fix the key deletion issue: for Windows Server 2016, the fix was in build 14393.4104 (KB4593226), and for Windows Server 2019, in build 17763.1637 (KB4592440) and later builds^ [Windows Hello for Business known issues – Microsoft Docs (2025) ^]. Ensure all domain controllers are updated beyond these versions so that the bug is resolved. If the environment is hybrid (though this guide assumes on-prem, some may have had an Azure AD Connect even if primarily on-prem), ensure that Azure AD Connect’s Device write-back is configured (in a federated scenario) and that a sync has occurred to populate the key. In a pure on-prem key trust, since AD FS writes the key, check that AD FS indeed wrote the msDS-KeyCredentialLink attribute correctly. You can use Get-ADUser <username> -Properties msDS-KeyCredentialLink to see if the user’s object has a value. If after first sign-in the attribute is blank, something went wrong (or the bug triggered deletion). If it has a value, but the user still can’t log in, perhaps the DC they hit did not replicate it yet – try logging in again or force AD replication. If the error persists across all DCs, re-enroll the user’s Hello credential: you may have to reset WHfB for that user on that device (this can be done by deleting the contents of %ProgramData%\Microsoft\NGC on the device after disabling WHfB via policy, or using the “Reset security key” option if available, then re-enabling). However, with the WS2019 issue, simply resetting wouldn’t help until DCs are patched. Thus patching is priority. For immediate relief (for a user locked out of Hello), they can always fall back to using their password (the error explicitly suggests using a different method, i.e., password). Another potential cause, KDC_ERR_CLIENT_NAME_MISMATCH, specifically was reported with early Server 2019 builds and is resolved by those updates^ [Windows Hello for Business known issues – Microsoft Docs (2025) ^]. Summarily: update domain controllers to fix known issues, verify the public key is present in AD, ensure it is not being removed (monitor the attribute before and after a Hello login attempt), and confirm AD FS is not overwriting or removing it incorrectly (there’s usually no reason AD FS would delete it; it was the DC code bug). After applying fixes, users should be able to consistently sign in with Hello.

3. Certificate enrollment failures during provisioning (Certificate Trust): Symptoms: In deployments using certificate trust, users may report that during WHfB setup, the process fails at the step where it would enroll for a certificate. The user might see a generic error that provisioning failed. On the client side, Event ID 362 in User Device Registration/Admin could appear, similar to the key trust case, indicating something like “Enterprise user logon certificate template is : No (StateNoPolicy)” or “Certificate enrollment method: enrollment authority” followed by “User has successfully authenticated to the enterprise STS: No.” Additionally, on the AD FS server, you may find errors in the AD FS/Admin log. A known specific issue on AD FS 2019 (Server 2019) is that device authentication to AD FS fails due to an “invalid check of incoming scopes in the request.” This was documented by Microsoft: AD FS on Windows Server 2019 could reject the certificate enrollment request with an error MSIS9368, logging an event ID 1021 in AD FS/Admin that says the client is forbidden to access the resource http://schemas.microsoft.com/ws/2009/12/identityserver/selfscope with scope ugs^[Windows Hello for Business known issues – Microsoft Docs (2025)^]. In other words, AD FS erroneously blocks the request necessary for WHfB certificate enrollment. When this happens, the client’s provisioning is blocked waiting for AD FS to succeed. The client’s Event 362 (as given in Microsoft documentation) would explicitly say “Enterprise user logon certificate enrollment endpoint is ready: Not Tested” and eventually “User has successfully authenticated to the enterprise STS: No”, which indicates that the step of obtaining the certificate didn’t complete. Essentially the user never gets the authentication certificate. This issue was specific to Server 2019 AD FS, and presumably fixed in later versions.

Other symptoms of certificate enrollment failure might include no certificate present in the user’s personal store after supposed provisioning, and possibly errors in the CA logs if the request reached the CA and was denied. If AD FS is functioning but the CA template is misconfigured, the CA might reject the request, leading to failure. In such a case, AD FS might log an error that enrollment failed (though AD FS’s logging for enrollment might be limited – one might have to infer from CA logs or lack of issuance).

Cause: For the specific AD FS 2019 issue, the cause is a bug in AD FS where it did not recognize the scope “ugs” (which stands for user global scope, used internally for device authentication). This caused AD FS to treat the Hello certificate enrollment request as unauthorized. Microsoft categorized this as “AD FS fails to complete device authentication due to an invalid scope check” on Windows Server 2019, affecting both hybrid and on-prem certificate trust deployments^[Windows Hello for Business known issues – Microsoft Docs (2025)^]. The broader cause category could also be misconfiguration: for example, if AD FS does not have the Enrollment Agent certificate or permissions to enroll it, it cannot obtain a user cert. Or if the certificate template “Windows Hello for Business Authentication” is not properly configured (for instance, if the template isn’t published on the CA or the AD FS service account lacks enroll permissions), the enrollment will fail. In those cases, AD FS might log event ID 364 (token issuance failure) or the CA might log an unsuccessful attempt.

Resolution: If running AD FS on Windows Server 2019, ensure you have installed at least Windows Server version 1903 or later (or installed the specific update that fixes this issue). Microsoft noted that the issue is fixed in Server 2019 if you update to 1903 (a semi-annual channel) or apply the patch; in lieu of updating, they provided a workaround: manually add the missing scope to AD FS^[Windows Hello for Business known issues – Microsoft Docs (2025)^]. The workaround steps are: in AD FS Management, under Services > Scope Descriptions, add a new scope named “ugs”. Then, using PowerShell, find the ObjectIdentifier of the application permission that matches client role ID 38aa3b87-a06d-4817-b275-7a316988d93b for the selfscope resource, and add the “ugs” scope to it using Set-AdfsApplicationPermission. These steps essentially tell AD FS to allow that scope for the WHfB enrollment client. After adding the scope and restarting AD FS, clients should be able to proceed with certificate enrollment successfully^ [Windows Hello for Business known issues – Microsoft Docs (2025) ^]. (It’s important to note that this ID and scope are internal to WHfB’s use of AD FS and come from Microsoft’s guidance; doing this without Microsoft’s documentation would be obscure, so the cited fix is critical.)

For other potential causes: verify that AD FS has an Enrollment Agent certificate and that it’s valid (not expired). Ensure the AD FS service account (or computer account if running as gMSA) is added to the appropriate security groups (like the Key Admins group, if required, and allowed to enroll for that Enrollment Agent template). Also verify the user certificate template: it should allow enrollment by the Enrollment Agent (usually this means in the CA template’s security, the AD FS service account has “Enroll” permission and the template is set to require an RA signature). If using a standalone or 3rd-party CA, ensure AD FS’s requests are being honored. Check the CA’s issuance log for any failures at the time of user enrollment. If found, adjust template settings accordingly.

After applying the AD FS scope fix or other configuration fixes, test again: have a user attempt provisioning. On the client, Event ID 362 should now show “Enterprise user logon certificate template is : Yes” (or similar) and “User has successfully authenticated to the enterprise STS: Yes”, and the user should then be prompted to set a PIN and complete enrollment. The AD FS log should no longer show event 1021 errors. The user’s certificate should appear in their certificate store. If everything succeeds, the final confirmation is that the user can sign-in with the new PIN and the domain controller accepts the certificate for logon.

4. Post-enrollment sign-in issues for certificate trust (unable to authenticate with certificate): Symptoms: A user has successfully enrolled in WHfB with certificate trust (no errors during provisioning; a certificate was issued and is present on the device), but when attempting to log on or unlock the computer with their PIN, the logon fails. They might be prompted unexpectedly for their password again. If the user switches to using the certificate (like a smart card logon interface), it might also fail. On the domain controller’s Security log, there may be an event for failed logon (Event ID 4771 or 4768 in Security, indicating Kerberos pre-auth failed) with error code corresponding to “Bad certificate” or “Certificate not found”. Alternatively, in the Kerberos Operational log on the client, you might see Event ID 27 or 26 indicating PKINIT failed. One known cause in certificate scenarios is if the domain controller certificates themselves are not set up correctly to support certificate logons. For instance, if a third-party CA issued the DC cert and did not include the proper Subject Alternative Name (SAN) entries, the Windows client can reject the KDC’s certificate. A specific symptom of this (mentioned earlier) is Event ID 107 in the Kerberos Operational log on the client, which states: “The Kerberos client received a KDC certificate that does not have a matched domain name. Expected Domain Name: <your domain>… Error Code: 0xC000006D”^[Windows Hello for Business known issues – Microsoft Docs (2025)^]. This occurs when the DC’s certificate subject/SAN doesn’t contain the AD domain fully, so the client doesn’t trust it for Kerberos. Another possibility is that the client’s certificate (for the user) cannot be validated or mapped: e.g., if the CA’s root is not trusted by the client or the DC, or if the user certificate’s UPN doesn’t match the user, etc.

Cause: For the KDC certificate name mismatch: many non-Microsoft CAs issue certificates with a subject name that doesn’t exactly match the directory tree. Microsoft’s guidelines for smart card logon with third-party CAs specify that the DC certificate’s subject should include the directory path (e.g., “CN=DC1, OU=Domain Controllers, DC=example, DC=com”) or at least the SAN should include the domain DNS name and short name. If not, the Kerberos client on Windows will refuse to use the certificate for fear it’s not the correct KDC. The error 0xC000006D (which is a logon failure) with the description about expected domain name is a clear indicator of that configuration issue^[Windows Hello for Business known issues – Microsoft Docs (2025)^]. In short, the domain controllers were not configured in accordance with WHfB’s certificate requirements. Another cause could be the certificate revocation checking: if the client cannot check the revocation status of the DC’s cert (e.g., CRL not accessible), it might also fail. Or if the DC’s cert has the wrong EKUs (not including KDC Authentication), that’s a cause. On the user certificate side, an incorrect UPN in the certificate (or missing mapping) would cause the DC to not find the user account for the certificate, resulting in logon denial.

Resolution: To resolve the KDC certificate name mismatch issue, update the domain controller certificates to comply with the recommended subject naming. According to Microsoft’s documentation, one solution is to ensure the Subject of the DC cert contains the distinguished name (DN) of the DC’s AD object (for example: CN=DC1,OU=Domain Controllers,DC=ad,DC=contoso,DC=com)^[Windows Hello for Business known issues – Microsoft Docs (2025)^]. This embeds the domain context into the certificate. Alternatively (or additionally), configure the Subject Alternative Name (SAN) on the DC cert to include: the fully qualified domain name of the DC (e.g., dc1.ad.contoso.com), the domain DNS name (ad.contoso.com), and even the NetBIOS domain name (CONTOSO or ad in the example)^[Windows Hello for Business known issues – Microsoft Docs (2025)^]. Many enterprise CA templates (like “Kerberos Authentication”) will by default include the DNS name of the DC in the SAN. If a third-party CA is being used, explicitly request these SAN entries. Essentially, the client expected the domain name in the certificate and didn’t find it, so we put it there. After updating and reissuing DC certificates with correct names, clients should accept the KDC cert and proceed with authentication.

Additionally, ensure that the domain controller certificates have the proper cryptographic algorithms supported by the client (e.g., RSA 2048 with SHA-256, since older algos might be not accepted or cause warnings). Also verify that all domain controllers in the domain have certificates; if one DC did not, then if a user is served by that DC for authentication, WHfB logon would fail entirely (since that DC can’t do PKINIT without a cert). The user might succeed on some occasions (when a certificate-enabled DC responds) and fail on others (with a non-enabled DC), leading to intermittent issues.

For user certificate mapping issues: confirm the user’s WHfB authentication certificate has a Subject Alternative Name (UPN) matching their AD user UPN. Normally, the template should be configured to use the user’s UPN for the SAN. If it’s missing or wrong, the DC might not map it. You can configure alternate mappings via the altSecurityIdentities attribute, but it’s easier to reissue the cert with correct SAN. Make sure the certificate chain (root and intermediate CA certificates) is trusted by all clients and DCs in the domain (they should be if it’s an enterprise CA or if third-party, you must import the chain into Trusted Roots on all machines via Group Policy). If CRL distribution is an issue (client or DC can’t reach CRL), consider publishing CRLs to a location both can access or disabling CRL check for Kerberos (less ideal). In summary, treat the Hello certificate as you would a smart card logon cert and ensure all those requirements are met.

Once the certificates (both DC and user) are correctly configured and trusted, attempts to log on with WHfB should succeed. A successful logon will result in security log event 4768 (TGT issued) with no errors, and the user can then use resources normally.

1. Device registration failures on AD FS (no device object, errors 3036 or similar): Symptoms: AD FS is responsible for device registration. If device registration fails, users might find that WHfB provisioning doesn’t happen or their device isn’t recognized. On the AD FS server, you might see AD FS Admin log events (event ID 364 or others) indicating an error during device join. There is a known error code AD FS can log: event ID 3036 in AD FS/Admin, which has been observed when device registration issues occur (often related to certificates or authentication at AD FS). If AD FS cannot write the device to AD (perhaps permission issues), it might log an error. From the client side, this typically would manifest as the device never getting to the point of asking for a PIN (tying back to issue #1 in client section) or as an error after MFA. In the context of on-prem, device registration is somewhat straightforward (the device is already domain-joined, so AD FS just needs to register it for additional capabilities). A specific forum case mentioned error 3036 related to AD FS User Device Registration, meaning AD FS had trouble finalizing the registration of the device (possibly certificate or attribute issue) – though official documentation on AD FS event 3036 is scarce.

Cause: Potential causes include: AD FS Device Registration Service (DRS) not fully configured or enabled (for example, the SSL certificate for device registration might be missing or the service not initialized with Initialize-ADDeviceRegistration properly). Another cause could be the AD FS service account lacking permissions to create the device object in AD. By default, enabling DRS should configure the proper permissions in AD (creating a container and giving the service account rights). If AD FS is on 2016/2019 and your AD is at 2012 R2 functional, sometimes there could be mismatches. Also, if the certificate used by AD FS for device registration (the DRS certificate) is not trusted by the client or is expired, the device might not connect properly. Error 3036 might indicate a failure in the TLS or authentication process for device registration.

Resolution: Verify AD FS Device Registration Service is enabled: run Get-AdfsDeviceRegistration on the AD FS server, which should show the DRS configuration (like the DRS identifier, the location in AD where devices register, etc.). If not enabled, run Initialize-ADDeviceRegistration -ServiceAccountName "domain\ADFSservice" to set it up (this creates the container and grants rights). Ensure the AD FS service account is a member of the Device Registration Admins (or has permissions as needed) or was added to the AD FS config. Also ensure AD FS’s SSL certificate includes the DRS hostname (which is often the same as the AD FS service name for on-prem or enterpriseregistration.domain.com for some setups). On the client, check that the Workplace Join process is hitting AD FS – you can see in Event Viewer > User Device Registration events like 304, 305 which might show attempts to reach enterpriseregistration. If there is a failure, try browsing from the client to https://<adfsname>/EnrollmentServer/contract (or similar DRS endpoint) to see if it’s accessible and using a valid cert. If you get certificate warnings, fix the certificate chain. If AD FS logs show access denied writing to AD, adjust the permissions: the AD FS service account should have create/delete child objects in the RegisteredDevices container in AD (which is created under the AD FS config partition). Microsoft documentation on enabling device write-back in AD FS can help. In many on-prem scenarios, device registration is simpler because the device is domain joined (DJ). But double-check AD FS’s event log for any clues around the time of provisioning attempts, and address accordingly – e.g., an error about being unable to retrieve attributes might mean the AD FS service account isn’t in the **KeyAdmins** or **Enterprise Key Admins** groups if trying to write user keys (for key trust, AD FS service account typically needs to be in **Key Admins** to write the msDS-KeyCredentialLink on user objects)^[Configure AD FS in an on-premises certificate trust model – Microsoft Docs^]. Indeed, Microsoft’s deployment guide explicitly says to add the AD FS service account to the KeyAdmins group as a prerequisite^[Configure AD FS in an on-premises certificate trust model – Microsoft Docs^] (even for key trust cases likely the same). If that step was missed, AD FS wouldn’t be able to populate the user’s key attribute, causing provisioning to fail. So ensure AD FS service account is in **KeyAdmins** (for user object writes) and in **Device Registration** config for device objects. After making these adjustments, try again – the device registration portion should succeed (and AD FS event 3036 should no longer appear). You can verify a successful device registration by checking AD: the user’s device object or attribute (for DJ in on-prem, check the computer account’s msDS-DeviceID or see if a new object was created under CN=Device Registration Configuration).

2. User’s public key not present or removed in AD (infrastructure issue): Symptoms: This is closely related to the earlier client-side issue of “temporarily unavailable” but from the server perspective. On examining Active Directory, an admin finds that a given user’s msDS-KeyCredentialLink attribute is empty or missing the expected entries for WHfB keys, even after the user has supposedly enrolled. This can be discovered by running PowerShell or ADSI Edit on a user object. Perhaps you compare a working user vs a non-working user and notice the attribute is not set for the latter. If it was set and then got removed, that indicates an infrastructure bug or replication issue. There might not be direct AD logs for attribute removal unless auditing is enabled. However, if you suspect this, you can query the attribute before and after a logon attempt. Microsoft documented a scenario (the user public key deletion issue on Server 2016/2019 DCs) where “after the initial sign-in attempt, the user’s WHfB public key is deleted from the msDS-KeyCredentialLink attribute” and they even suggest verifying this by querying the attribute before and after sign-in^[Windows Hello for Business known issues – Microsoft Docs (2025)^]. If you observe that behavior, it confirms the known bug. Another potential cause is replication: maybe the user’s key was written to one DC but another DC without the key serviced the logon. In that case, eventually consistency would resolve it but in the interim it’s “missing” from perspective of one DC.

Cause: The known cause was the bug in certain builds of Windows Server (as discussed, fixed in late 2020 updates) that caused the DC to erroneously remove the key credential link attribute under some conditions. This was an implementation error in the KDC code. If that bug is ruled out (i.e., all DCs patched), the cause could be that the key was never written in the first place (perhaps AD FS failed to do so due to permission issue, so it’s not present, causing failure). Or replication latency in multi-DC environments. If AD FS writes to a particular DC (the one it’s connected to), but the user logs on immediately and hits a different DC before replication, that DC doesn’t see the key yet. Normally, AD FS should be writing to the global catalog, but immediate logon might race ahead of replication. That’s a timing issue, not permanent deletion.

Resolution: For the bug scenario: as stated previously, update your domain controllers to incorporate the fixes (at least WS2019 build 17763.1637 or later, WS2016 build 14393.4104 or later)^[Windows Hello for Business known issues – Microsoft Docs (2025)^]. This will stop the inadvertent deletion of the key from AD. If the environment was suffering from that, after patching you may need to re-register keys for those users (which might happen automatically on next successful Hello logon with a good DC, or by user re-enrolling Hello by removing and adding it). For the case of the key never being written: ensure AD FS service account belongs to KeyAdmins (which grants permission to write msDS-KeyCredentialLink). Also verify that no AD permission or schema issues exist with that attribute (by default, Key Admins can write it). If needed, you can manually populate the attribute via Azure AD Connect’s device write-back in a hybrid scenario, but in pure on-prem AD FS is the writer. So focusing on AD FS logs if key not written: AD FS might log an error if it tried and failed to update AD. Check AD FS Debug logs or enable auditing on directory service changes to see if a write was attempted/denied. Fix any permission problems. If replication is the only issue, a simple solution is to instruct users to wait a brief period between initial setup and first logon, but that’s not ideal. Instead, ensure that the AD site topology and AD FS usage are such that AD FS talks to a DC that the user will likely authenticate against. Or simply accept that first logon after setup might hit a not-yet-replicated DC and fail once – in which case the user can try again and possibly hit a DC where it is present. But again, after patching, even if a DC doesn’t have it and tries, it should no longer delete anything; it would just fail. Eventually it would succeed once the key is everywhere. However, to minimize user impact, you could force a replication after a user enrolls (maybe script AD FS to trigger a sync of that user’s object across DCs – not a typical solution though). Usually, AD object replication in a single domain is quick (seconds to a minute).

In summary, keep DCs updated, verify AD FS can write the user’s key to AD, and verify it stays there. The presence of the user’s key in msDS-KeyCredentialLink is a strong indicator the system is configured correctly. Each entry is a blob that corresponds to one device’s key. If a user has multiple devices, you’ll see multiple entries. If none appear after enrollment, something in the chain is broken and must be addressed with the above steps.

3. Domain controller or service not accepting Hello authentication (general): This is a catch-all scenario: everything is set up, but a particular site or subset of infrastructure isn’t working. For example, one specific domain controller never allows WHfB logons (maybe its certificate is bad, or it’s not patched). Or perhaps AD FS in a farm has one node not configured with the Enrollment Agent cert. The approach to troubleshooting these is to isolate where the failure is happening by using the logs:

• If all users/devices fail at provisioning time, focus on AD FS and CA.

• If provisioning works but logons fail across the board, focus on DC configurations (certs, patches, trust).

• If only some users or some devices fail, compare their attributes and certificate details with working ones (maybe a specific hardware TPM issue or a group policy difference).

• If only some domain controllers cause failures, check those DCs’ event logs for Kerberos errors, and ensure their certificates and patch levels are correct.

One useful technique is to enable Kerberos debugging logs on the client (by enabling “Kerberos client event logging”). The Kerberos Operational log (as mentioned with event 107, 27, etc.) gives granular info about why a Kerberos attempt failed – e.g., “no matching certificate found” or “KDC name mismatch.” This often directly points to a certificate trust issue.

Another area is the AD FS and device registration: enabling AD FS debug logging might provide deeper insight if the above event logs are not enough.

For maintenance: Ensure certificates (DC and Enrollment Agent, user certs) are renewed on schedule. Domain controllers will auto-enroll new certificates before expiry if configured, but Enrollment Agent cert on AD FS might not auto-renew depending on setup – mark calendar reminders to renew it. Also keep an eye on any changes via Windows Updates: new updates occasionally introduce new features (like the Cloud Trust model in newer versions) but also sometimes come with toggles or registry settings (e.g., post-2021, Microsoft made some changes to Kerberos encryption and certificate mapping due to security advisories – ensure none of those mitigate settings are interfering with WHfB certificate logon; usually they do not if defaults are kept).

Finally, consult Microsoft’s official “known issues” documentation for WHfB deployments for any emerging issues beyond those covered here. The issues we discussed – AD FS scope bug, DC certificate naming, key deletion bug – are documented known issues as of the last updates^ [Windows Hello for Business known issues – Microsoft Docs (2025) ^]. By systematically verifying each component (policy, AD FS config, CA templates, DC certificates, patch levels, network connectivity, MFA availability), one can resolve nearly all Windows Hello for Business on-premises deployment problems and achieve a stable passwordless authentication environment.