Windows Hello for business PIN and Kerberos

[Jack_Chen1780]

I would like to get some help to troubleshoot WHfB PIN authentication and Kerberos.

I have deployed WHfB with Key trust model in our environment.  It is working as supposed and I have configured two Windows 10 machines with WHfb PIN:

machine 1:  Windows 10 enterprise (2004) laptop , Hybrid joined.

machine 2: a virtual machine running on machine1, Windows 10 enterprise (20H2) with bridged network, AAD joined. 

I can login into both machine with PIN, in office and in home.

Problem: when I am in office and connected to on-premises network with wire,

machine 1: I can login with my AD credential or the PIN, after login, I can see shared disks. 

klist shows Kerberos tickets.

Machine 2: 

If I login with AD credential ( UPN and password), klist shows one ticket after login, and I can access shares.

If I login with PIN, klist show 0 ticket, and I can't access share ( when I tried, it popup login window and ask to login with pin, then it failed again and claim I don't have permission ).

nltest /sc_query:mycompany.local
I_NetLogonControl failed: Status = 1722 0x6ba RPC_S_SERVER_UNAVAILABLE

I think PIN should also grant me access to Kerberos for AAD joined machines, not sure where to start look at.

our DC environment:

2 old Windows 2012R2 DC.

2 new Windows 2019 DC.

klist

Current LogonId is 0:0x1ceb8a

Cached Tickets: (0)

nltest /sc_query:mycompany.local
I_NetLogonControl failed: Status = 1722 0x6ba RPC_S_SERVER_UNAVAILABLE

[#2]

followed https://docs.microsoft.com/en-us/windows/security/identity-protection/hello-for-business/hello-deplo... and enabled

Application and Services/Microsoft/Windows/Security-Kerberos/Operational.

saw event 102 in log:
Trust validation of the certificate for the Kerberos Key Distribution Center (KDC) DC01.mycompany.local failed: 0x800B010A. Use the CAPI2 diagnostic traces to identify the reason for the validation failure.

[#3]

Looks like the issue is related with our DC's certificate. We got 0x800B010A 80092013 error and they are related with Certificate chain. I tuned on CAPI2 and found

So we have a offline root CA and a issuing CA, the issuing CA 's CRL setting is configured properly and it passed pkiview test for CRL list.   The issue seems to be the Issuing CA's certificate, it is signed by the offline Root CA and it doesn't have valid http CRL. Not sure if I can regenerate the issuing CA's certificate without breaking all the certificate it signed. Maybe it can be done by renew issuing CA's certificate with existing keypair ?

[#4 · Accepted solution]

OK fixed it. first fix AIA and CDL from the offline Root CA, then issue a new sub CA to the issuing CA server with existing key ( so all existing certificates don't need to be regenerated ). Setup a new Intune profile to deploy the new intermediate sub CA to Windows devices, then it worked!