Stage 1: Provisioning#

When Windows Hello is enabled for the first time, Windows performs several initialization tasks, including:

• Checking whether the device meets the deployment requirements;

• Checking whether policy allows Windows Hello to be enabled;

• Generating a new public/private key pair in the TPM or software key storage;

• Registering the public key with the identity system, such as Active Directory or Microsoft Entra ID;

• Completing Windows Hello initialization.

Only after all of these steps are complete can the user successfully create a PIN.

If provisioning fails, the sign-in process never begins.

The value I had found:

1
PreReqResult : WillNotProvision

confirmed that the process was stopping at this stage.

Stage 2: Authentication#

After provisioning is complete, Windows Hello enters its normal day-to-day use phase.

Each time the user enters the PIN, Windows uses the previously generated key to authenticate the user.

If this stage fails, the symptoms are different:

• The PIN can be created;

• Windows Hello appears to be enabled;

• The user still cannot sign in with the PIN.

This became the second problem later in the investigation.

For now, the immediate goal was to get Windows Hello to complete provisioning.

1
dsregcmd /status

1
+----------------------------------------------------------------------+
2

3
| Ngc Prerequisite Check                                               |
4

5
+----------------------------------------------------------------------+
6

7

8

9
            IsDeviceJoined : YES
10

11
             IsUserAzureAD : YES
12

13
             PolicyEnabled : YES
14

15
          PostLogonEnabled : YES
16

17
            DeviceEligible : YES
18

19
        SessionIsNotRemote : YES
20

21
            CertEnrollment : enrollment authority
22

23
          AdfsRefreshToken : YES
24

25
             AdfsRaIsReady : YES
26

27
    LogonCertTemplateReady : YES ( StateReady )
28

29
              PreReqResult : WillProvision
30

31
+----------------------------------------------------------------------+

Confirming the Authentication Failure in the Windows Hello Logs#

I did not use the Event Viewer GUI. Instead, I read the Windows Hello Operational log directly with PowerShell:

1
Get-WinEvent `
2

3
    -LogName "Microsoft-Windows-HelloForBusiness/Operational" `
4

5
    -MaxEvents 50 |
6

7
    Select-Object TimeCreated, Id, LevelDisplayName, Message |
8

9
    Format-List

The output included:

1
TimeCreated Id LevelDisplayName Message
2

3
----------- -- ---------------- -------
4

5
2026-07-17 10:17:39 AM 7001 Error A user failed to sign into the device with the following information:...
6

7
2026-07-17 10:17:39 AM 5702 Information Windows Hello wrote following protector properties to disk: HResult = 0...
8

9
2026-07-17 10:17:38 AM 5002 Information A user is signing into the device with the following gesture informatio...
10

11
2026-07-17 10:15:34 AM 5205 Information Windows Hello for Business on-premise authentication configurations: ...
12

13
2026-07-17 10:12:26 AM 8045 Success Windows Hello processing completed successfully....
14

15
2026-07-17 10:12:26 AM 8510 Success Windows Hello key registration completed successfully.
16

17
2026-07-17 10:12:25 AM 3510 Information Windows Hello key registration started.
18

19
2026-07-17 10:12:25 AM 8225 Success Windows Hello key creation completed successfully....
20

21
2026-07-17 10:12:25 AM 8067 Success Windows Hello set a certificate property on a Windows Hello key....
22

23
2026-07-17 10:12:24 AM 5225 Information Creating a hardware Windows Hello key with result 0x0.
24

25
2026-07-17 10:12:24 AM 8632 Success Windows Hello for Business successfully added a user entry to the Usern...
26

27
2026-07-17 10:12:24 AM 5205 Information Windows Hello for Business on-premise authentication configurations: ...
28

29
2026-07-17 10:12:24 AM 5205 Information Windows Hello for Business on-premise authentication configurations: ...
30

31
2026-07-17 10:12:24 AM 3225 Information Windows Hello key creation started.
32

33
2026-07-17 10:12:24 AM 8055 Success Windows Hello container provisioning completed successfully....
34

35
2026-07-17 10:12:24 AM 5702 Information Windows Hello wrote following protector properties to disk: HResult = 0...
36

37
2026-07-17 10:12:24 AM 5702 Information Windows Hello wrote following protector properties to disk: HResult = 0...
38

39
2026-07-17 10:12:24 AM 5225 Information Creating a software Windows Hello key with result 0x0.
40

41
2026-07-17 10:12:24 AM 5225 Information Creating a software Windows Hello key with result 0x0.
42

43
2026-07-17 10:12:24 AM 5555 Information Windows Hello is validating that the device can satisfy all applicable ...
44

45
2026-07-17 10:12:24 AM 5702 Information Windows Hello wrote following protector properties to disk: HResult = 0...
46

47
2026-07-17 10:12:17 AM 5004 Information Windows Hello for Business Enabled Policy successfully enforced for the...
48

49
2026-07-17 10:12:17 AM 3055 Information Windows Hello container provisioning started.
50

51
2026-07-17 10:12:17 AM 6611 Warning Windows Hello could not delete the container as no container currently ...

The log showed that Windows Hello had successfully completed the earlier stages, including key creation and key registration.

I then queried Events 7001 and 5205 directly:

1
Get-WinEvent -FilterHashtable @{
2

3
    LogName = "Microsoft-Windows-HelloForBusiness/Operational"
4

5
    Id      = 7001
6

7
} -MaxEvents 3 |
8

9
Format-List TimeCreated, Id, LevelDisplayName, Message

1
Get-WinEvent -FilterHashtable @{
2

3
    LogName = "Microsoft-Windows-HelloForBusiness/Operational"
4

5
    Id      = 5205
6

7
} -MaxEvents 5 |
8

9
Format-List TimeCreated, Id, Message

Event 7001 showed:

1
TimeCreated : 2026-07-17 10:17:47 AM
2

3
Id : 7001
4

5
LevelDisplayName : Error
6

7
Message : A user failed to sign into the device with the following information:
8

9
Username: SYSTEM
10

11
User SID: S-1-5-18
12

13
Credential Type: Software Key
14

15
Deployment Type: Key Trust
16

17
Software Lockout Counter: 0
18

19
Authentication Error Status: 0xC000006D
20

21
Authentication Error Substatus: 0xC0000380

The error codes did not identify the exact configuration problem, but they confirmed two important facts:

• The active deployment type was Key Trust;

• The failure occurred during authentication, not provisioning.

The next step was to inspect the Key Trust authentication chain itself.

Confirming That the Windows Hello Public Key Was Written to Active Directory#

The basic Key Trust workflow is:

1. The client generates a public/private key pair;

2. The private key remains on the client and is unlocked by the PIN;

3. The public key is written to the user’s Active Directory object;

4. During sign-in, the domain controller uses that public key to verify the client’s signature.

I therefore checked the user’s msDS-KeyCredentialLink attribute:

1
Get-ADUser test.user `
2

3
    -Properties msDS-KeyCredentialLink |
4

5
    Select-Object -ExpandProperty msDS-KeyCredentialLink

The output contained multiple Key Credential entries.

The complete values were very long and followed a structure similar to:

1
B:828:00020000200001...
2

3
B:828:00020000200001...

This was an important result.

It proved that:

• The Windows Hello key had been generated successfully;

• The public key had been written to Active Directory;

• Key registration had completed;

• Entra Connect and the AD user object were not the current blocking point.

At this stage, the client had completed almost everything expected of it.

The investigation began to point toward the domain controllers.

Why Does Key Trust Depend on a Domain Controller Certificate?#

Key Trust does not require each user to receive a sign-in certificate, but that does not mean the environment can operate without PKI.

In a hybrid Key Trust deployment, the KDC on the domain controller still requires a suitable Kerberos certificate to complete the initial public-key-based authentication.

In other words:

The user does not need a certificate, but the KDC does.

I then examined the KDC Operational log on the domain controllers:

1
Get-WinEvent `
2

3
    -LogName "Microsoft-Windows-Kerberos-Key-Distribution-Center/Operational" `
4

5
    -MaxEvents 50 |
6

7
    Select-Object TimeCreated, Id, LevelDisplayName, Message |
8

9
    Format-List

The log contained Event 200 with the following key message:

1
The Key Distribution Center (KDC) cannot find a suitable certificate
2

3
to use for smart card logons, or the KDC certificate could not be verified.

This was the first piece of evidence that pointed directly toward the root cause.

The client had a key, and Active Directory contained the public key, but the KDC did not have a suitable certificate and therefore could not complete the Kerberos public-key authentication required by Key Trust.

Checking the Domain Controller Certificates#

I checked the Local Computer certificate store on both domain controllers:

1
certutil -store My

The results were not good.

One domain controller had no certificate that the KDC could use.

The other had only an old self-signed certificate. It was not a valid Kerberos Authentication certificate issued by a currently trusted Enterprise CA.

I also could not find a valid certificate with:

1
Template: Kerberos Authentication

At this point, the failure chain was becoming clear:

1
Windows Hello provisioning
2

3
        ↓ Successful
4

5

6

7
Public key written to msDS-KeyCredentialLink
8

9
        ↓ Successful
10

11

12

13
Client attempts Key Trust PIN sign-in
14

15
        ↓
16

17

18

19
The KDC on the domain controller has no suitable Kerberos certificate
20

21
        ↓
22

23

24

25
Authentication fails

Discovering a Retired Enterprise CA#

Further PKI investigation showed that Active Directory still contained objects for old Enterprise CAs.

For example:

1
CONTOSO-DC02-CA
2

3
contoso.local

However, the corresponding CA servers had already been retired.

Active Directory still contained the published PKI information, but there was no functioning Enterprise CA capable of:

• Issuing new domain controller certificates;

• Processing certificate auto-enrollment;

• Renewing or replacing the certificates required by the KDC

This explained why the domain controllers had never received a valid Kerberos Authentication certificate.

The issue was no longer just one expired certificate. The Enterprise PKI itself was effectively no longer operational.

Redeploying the Enterprise CA#

Because the old CA no longer existed and there was no server available to recover, I deployed a new Enterprise Root CA.

1
Install-WindowsFeature ADCS-Cert-Authority -IncludeManagementTools

The new CA was configured with:

1
Install-AdcsCertificationAuthority `
2

3
    -CAType EnterpriseRootCA `
4

5
    -CACommonName "CONTOSO-ROOT-CA" `
6

7
    -CryptoProviderName "RSA#Microsoft Software Key Storage Provider" `
8

9
    -KeyLength 4096 `
10

11
    -HashAlgorithmName SHA256 `
12

13
    -ValidityPeriod Years `
14

15
    -ValidityPeriodUnits 10 `
16

17
    -Force

After AD CS was installed, I verified that the CA could be discovered from the domain:

1
certutil -config - -ping

The command returned:

1
DC01.contoso.local\CONTOSO-ROOT-CA

This confirmed that the new Enterprise CA was available.

Triggering Domain Controller Certificate Enrollment#

After the Enterprise CA was operational, I refreshed Group Policy and triggered certificate auto-enrollment:

1
gpupdate /force
2

3
certutil -pulse

I then checked the Local Computer certificate store on both domain controllers again:

1
certutil -store My

This time, both domain controllers had successfully obtained new certificates, including:

1
Kerberos Authentication
2

3
Domain Controller Authentication
4

5
Directory Email Replication

The issuer was:

1
CONTOSO-ROOT-CA

I also confirmed that the new CA certificate had been published to the Enterprise NTAuth store:

1
certutil -enterprise -verifystore NTAuth

The output contained:

1
CONTOSO-ROOT-CA

This step matters because a domain controller authentication certificate must chain to a CA that is trusted through NTAuth before it can be used for domain authentication.

Confirming That the KDC Loaded the New Certificate#

After certificate enrollment completed, I checked the KDC Operational log again:

1
Get-WinEvent `
2

3
    -LogName "Microsoft-Windows-Kerberos-Key-Distribution-Center/Operational" `
4

5
    -MaxEvents 50 |
6

7
    Where-Object Id -in 200, 302 |
8

9
    Select-Object TimeCreated, Id, Message |
10

11
    Format-List

Previously, Event 200 had reported:

1
No suitable certificate

Now Event 302 appeared and showed that the KDC had selected the new certificate:

1
Issuer    : CONTOSO-ROOT-CA
2

3
Template  : Kerberos Authentication
4

5
Thumbprint: <REDACTED>

This confirmed that the PKI and KDC portions of the authentication chain had been repaired.

At this point, all major Key Trust requirements were satisfied:

• Windows Hello provisioning had completed;

• The public key had been written to Active Directory;

• The client was using Key Trust;

• The domain controllers had received Kerberos Authentication certificates;

• The KDC had loaded and was using the certificate.

Root Cause#

The incident was caused by several overlapping problems:

1. Cloud Trust had been enabled in Intune even though the environment was not ready for it, preventing Windows Hello from provisioning initially;

2. After Cloud Trust was disabled, Windows Hello successfully created and registered Key Trust credentials;

3. The old Enterprise CA had been retired, but related AD objects still remained;

4. The domain controllers did not have valid Kerberos Authentication certificates;

5. The KDC therefore could not complete Key Trust authentication;

6. After the Enterprise CA was rebuilt and new domain controller certificates were issued, the KDC began functioning normally again;

7. The client still retained authentication state from before the repair, and a reboot was required before the corrected state was fully loaded

1. Check Device Join and Windows Hello Status#

1
dsregcmd /status

Review these fields:

1
AzureAdJoined
2

3
DomainJoined
4

5
DeviceAuthStatus
6

7
NgcSet
8

9
AzureAdPrt
10

11
CloudTgt
12

13
OnPremTgt

Windows Hello provisioning status appears under:

1
+----------------------------------------------------------------------+
2

3
| Ngc Prerequisite Check                                               |
4

5
+----------------------------------------------------------------------+
6

7

8

9
            IsDeviceJoined
10

11
             IsUserAzureAD
12

13
             PolicyEnabled
14

15
          PostLogonEnabled
16

17
            DeviceEligible
18

19
        SessionIsNotRemote
20

21
            CertEnrollment
22

23
          AdfsRefreshToken
24

25
             AdfsRaIsReady
26

27
    LogonCertTemplateReady
28

29
              PreReqResult

Common results:

1
NgcSet       : NO
2

3
PreReqResult : WillNotProvision

This indicates that Windows Hello provisioning has not completed.

1
NgcSet       : YES
2

3
PreReqResult : WillProvision

This indicates that the device meets the provisioning requirements or that Windows Hello has already been initialized.

For more detailed device registration information:

1
dsregcmd /status /debug

2. Check Windows Hello Policy Registry Values#

Check whether Windows Hello is configured to use Cloud Trust:

1
Get-ItemProperty `
2

3
    -Path "HKLM:\SOFTWARE\Policies\Microsoft\PassportForWork" `
4

5
    -ErrorAction SilentlyContinue

Review:

1
Enabled
2

3
UseCertificateForOnPremAuth
4

5
UseCloudTrustForOnPremAuth

The values can also be queried individually:

1
Get-ItemPropertyValue `
2

3
    -Path "HKLM:\SOFTWARE\Policies\Microsoft\PassportForWork" `
4

5
    -Name "UseCloudTrustForOnPremAuth" `
6

7
    -ErrorAction SilentlyContinue

1
Get-ItemPropertyValue `
2

3
    -Path "HKLM:\SOFTWARE\Policies\Microsoft\PassportForWork" `
4

5
    -Name "UseCertificateForOnPremAuth" `
6

7
    -ErrorAction SilentlyContinue

The final state in this case was:

1
UseCloudTrustForOnPremAuth   : 0
2

3
UseCertificateForOnPremAuth : 0

This means:

• Cloud Trust is not being used;

• Certificate Trust is not being used;

• The intended deployment model is Key Trust.

After changing the Intune policy, force a policy refresh:

1
gpupdate /force

3. Query the Windows Hello Operational Log#

List recent Windows Hello events:

1
Get-WinEvent `
2

3
    -LogName "Microsoft-Windows-HelloForBusiness/Operational" `
4

5
    -MaxEvents 100 |
6

7
    Select-Object TimeCreated, Id, LevelDisplayName, Message |
8

9
    Format-List

Show only warning and error events:

1
Get-WinEvent `
2

3
    -FilterHashtable @{
4

5
        LogName = "Microsoft-Windows-HelloForBusiness/Operational"
6

7
        Level   = 2, 3
8

9
    } `
10

11
    -ErrorAction SilentlyContinue |
12

13
    Select-Object TimeCreated, Id, LevelDisplayName, Message |
14

15
    Format-List

Query authentication failures:

1
Get-WinEvent `
2

3
    -FilterHashtable @{
4

5
        LogName = "Microsoft-Windows-HelloForBusiness/Operational"
6

7
        Id      = 7001
8

9
    } `
10

11
    -ErrorAction SilentlyContinue |
12

13
    Select-Object TimeCreated, Id, Message |
14

15
    Format-List

Important values observed during the incident included:

1
Deployment Type          : Key Trust
2

3
Authentication Error     : 0xC000006D
4

5
Authentication SubStatus : 0xC00002F9

A later test also produced:

1
Authentication Error : 0xC0000380

Query the event that confirms the deployment configuration:

1
Get-WinEvent `
2

3
    -FilterHashtable @{
4

5
        LogName = "Microsoft-Windows-HelloForBusiness/Operational"
6

7
        Id      = 5205
8

9
    } `
10

11
    -ErrorAction SilentlyContinue |
12

13
    Select-Object TimeCreated, Id, Message |
14

15
    Format-List

Important values:

1
Certificate Required : False
2

3
Use Cloud Trust      : False
4

5
Deployment Type      : Key Trust

Filter by relevant keywords:

1
Get-WinEvent `
2

3
    -LogName "Microsoft-Windows-HelloForBusiness/Operational" `
4

5
    -MaxEvents 200 |
6

7
    Where-Object {
8

9
        $_.Message -match "Authentication|Key Trust|Cloud Trust|Provision"
10

11
    } |
12

13
    Select-Object TimeCreated, Id, Message |
14

15
    Format-List

4. Check Whether the Windows Hello Key Was Written to Active Directory#

Import the Active Directory module:

1
Import-Module ActiveDirectory

Inspect the user’s msDS-KeyCredentialLink attribute:

1
Get-ADUser test.user `
2

3
    -Properties msDS-KeyCredentialLink |
4

5
    Select-Object SamAccountName, msDS-KeyCredentialLink

Show only the Key Credential values:

1
Get-ADUser test.user `
2

3
    -Properties msDS-KeyCredentialLink |
4

5
    Select-Object -ExpandProperty msDS-KeyCredentialLink

Count the number of Key Credential entries:

1
(
2

3
    Get-ADUser test.user `
4

5
        -Properties msDS-KeyCredentialLink
6

7
).msDS-KeyCredentialLink.Count

The output usually resembles:

1
B:828:00020000200001...

The values are long and normally do not need to be parsed manually.

If the attribute is not empty, the Windows Hello public key has been written to the user’s AD object.

5. Check Domain and Forest Functional Levels#

Check the forest functional level:

1
Get-ADForest |
2

3
    Select-Object Name, ForestMode

Check the domain functional level:

1
Get-ADDomain |
2

3
    Select-Object DNSRoot, DomainMode

The environment in this case reported:

1
Forest Functional Level : Windows2008R2Forest
2

3
Domain Functional Level : Windows2012R2Domain

6. Check Local Certificates on the Domain Controllers#

View the Local Computer personal certificate store:

1
certutil -store My

Filter for Kerberos-related information:

1
certutil -store My |
2

3
    Select-String `
4

5
        -Pattern "Kerberos Authentication|Domain Controller Authentication|Issuer|Subject|Template"

Inspect certificates with PowerShell:

1
Get-ChildItem Cert:\LocalMachine\My |
2

3
    Select-Object Subject, Issuer, Thumbprint, NotBefore, NotAfter,
4

5
        EnhancedKeyUsageList

Find certificates with the Kerberos Authentication EKU:

1
Get-ChildItem Cert:\LocalMachine\My |
2

3
    Where-Object {
4

5
        $_.EnhancedKeyUsageList.FriendlyName -contains "Kerberos Authentication"
6

7
    } |
8

9
    Select-Object Subject, Issuer, Thumbprint, NotBefore, NotAfter,
10

11
        EnhancedKeyUsageList

Find certificates that expire within 60 days:

1
Get-ChildItem Cert:\LocalMachine\My |
2

3
    Where-Object {
4

5
        $_.NotAfter -lt (Get-Date).AddDays(60)
6

7
    } |
8

9
    Select-Object Subject, Issuer, Thumbprint, NotAfter

7. Query the KDC Operational Log#

List recent KDC events:

1
Get-WinEvent `
2

3
    -LogName "Microsoft-Windows-Kerberos-Key-Distribution-Center/Operational" `
4

5
    -MaxEvents 100 |
6

7
    Select-Object TimeCreated, Id, LevelDisplayName, Message |
8

9
    Format-List

Show only Events 200 and 302:

1
Get-WinEvent `
2

3
    -FilterHashtable @{
4

5
        LogName = "Microsoft-Windows-Kerberos-Key-Distribution-Center/Operational"
6

7
        Id      = 200, 302
8

9
    } `
10

11
    -ErrorAction SilentlyContinue |
12

13
    Select-Object TimeCreated, Id, LevelDisplayName, Message |
14

15
    Format-List

Event 200 indicates that the KDC cannot find a suitable certificate. A typical message is:

1
The Key Distribution Center cannot find a suitable certificate
2

3
to use for smart card logons, or the KDC certificate could not
4

5
be verified.

Event 302 indicates that the KDC has successfully loaded a certificate. Important fields include:

1
Issuer
2

3
Template
4

5
Thumbprint

Filter certificate-related KDC events:

1
Get-WinEvent `
2

3
    -LogName "Microsoft-Windows-Kerberos-Key-Distribution-Center/Operational" `
4

5
    -MaxEvents 200 |
6

7
    Where-Object {
8

9
        $_.Message -match "certificate|Kerberos Authentication|KDC"
10

11
    } |
12

13
    Select-Object TimeCreated, Id, Message |
14

15
    Format-List

8. Check Whether the Enterprise CA Is Available#

List Enterprise CAs available in the domain:

1
certutil -config - -ping

A working result should resemble:

1
DC01.contoso.local\CONTOSO-ROOT-CA

View Enterprise CA configuration:

1
certutil -config - -

Check the CA service:

1
Get-Service CertSvc

Start the CA service:

1
Start-Service CertSvc

Restart the CA service:

1
Restart-Service CertSvc

Check the AD CS role:

1
Get-WindowsFeature AD-Certificate

List installed AD CS role services:

1
Get-WindowsFeature |
2

3
    Where-Object {
4

5
        $_.Name -like "ADCS*"
6

7
    }

9. Check the Enterprise NTAuth Store#

Verify the Enterprise NTAuth store:

1
certutil -enterprise -verifystore NTAuth

Confirm that the new CA appears in the output:

1
CONTOSO-ROOT-CA

View all certificates published to NTAuth:

1
certutil -enterprise -viewstore NTAuth

The NTAuthCertificates object can also be read directly from Active Directory:

1
$configurationNamingContext = (
2

3
    Get-ADRootDSE
4

5
).configurationNamingContext
6

7

8

9
Get-ADObject `
10

11
    -Identity "CN=NTAuthCertificates,CN=Public Key Services,CN=Services,$configurationNamingContext" `
12

13
    -Properties cACertificate

10. Check for Old CA Objects Published in Active Directory#

Get the Configuration Naming Context:

1
$configurationNamingContext = (
2

3
    Get-ADRootDSE
4

5
).configurationNamingContext

List Enterprise CAs registered under Enrollment Services:

1
Get-ADObject `
2

3
    -SearchBase "CN=Enrollment Services,CN=Public Key Services,CN=Services,$configurationNamingContext" `
4

5
    -LDAPFilter "(objectClass=pKIEnrollmentService)" `
6

7
    -Properties * |
8

9
    Select-Object Name, dNSHostName, DistinguishedName

Inspect the Certification Authorities container:

1
Get-ADObject `
2

3
    -SearchBase "CN=Certification Authorities,CN=Public Key Services,CN=Services,$configurationNamingContext" `
4

5
    -LDAPFilter "(objectClass=certificationAuthority)" `
6

7
    -Properties * |
8

9
    Select-Object Name, DistinguishedName

Inspect the AIA container:

1
Get-ADObject `
2

3
    -SearchBase "CN=AIA,CN=Public Key Services,CN=Services,$configurationNamingContext" `
4

5
    -LDAPFilter "(objectClass=certificationAuthority)" `
6

7
    -Properties * |
8

9
    Select-Object Name, DistinguishedName

Inspect the CDP container:

1
Get-ADObject `
2

3
    -SearchBase "CN=CDP,CN=Public Key Services,CN=Services,$configurationNamingContext" `
4

5
    -Filter * |
6

7
    Select-Object Name, ObjectClass, DistinguishedName

These commands help identify objects for retired CAs that may still remain in Active Directory.

Do not delete these objects without a backup and an impact assessment.

11. Trigger Certificate Auto-Enrollment#

Refresh computer Group Policy:

1
gpupdate /force

Trigger certificate auto-enrollment:

1
certutil -pulse

Check certificate auto-enrollment events:

1
Get-WinEvent `
2

3
    -LogName "Microsoft-Windows-CertificateServicesClient-AutoEnrollment/Operational" `
4

5
    -MaxEvents 100 |
6

7
    Select-Object TimeCreated, Id, LevelDisplayName, Message |
8

9
    Format-List

Show only warning and error events:

1
Get-WinEvent `
2

3
    -FilterHashtable @{
4

5
        LogName = "Microsoft-Windows-CertificateServicesClient-AutoEnrollment/Operational"
6

7
        Level   = 2, 3
8

9
    } `
10

11
    -ErrorAction SilentlyContinue |
12

13
    Select-Object TimeCreated, Id, Message |
14

15
    Format-List

After auto-enrollment completes, check the certificate store again:

1
certutil -store My

The domain controller should now have certificates such as:

1
Kerberos Authentication
2

3
Domain Controller Authentication
4

5
Directory Email Replication

Quick Diagnostic Order#

For similar incidents, use the following sequence:

1
1. Run dsregcmd /status
2

3
2. Check NgcSet and PreReqResult
4

5
3. Review the Intune Windows Hello policies
6

7
4. Query the HelloForBusiness Operational log
8

9
5. Check msDS-KeyCredentialLink
10

11
6. Query the KDC Operational log
12

13
7. Check the domain controller's Kerberos Authentication certificate
14

15
8. Check the Enterprise CA and NTAuth
16

17
9. Trigger domain controller certificate auto-enrollment
18

19
10. Confirm KDC Event 302
20

21
11. Reboot the client and test PIN sign-in again

The purpose of this sequence is not to run every command blindly. The first objective is to determine whether the failure occurs during:

1
Provisioning
2

3
        or
4

5
Authentication

Once the failed stage is identified, the investigation can be narrowed accordingly.