WHFB Cloud Trust Sign-in Failure | 0xc000006d
The symptom is receiving the error message “This sign-in option is temporarily unavailable” when trying to log in to the account. This error is actually a false error because the WHFB PIN Sign-in logic first attempts Cloud Trust. However, if Cloud Trust fails, it falls back to Key Trust. If we have not configured Key Trust, then it is not possible to authenticate using KDC certificates.
To examine the entire authentication process, check the kerberos.etl file in the Authlog package:
Initially, if Cloud Trust is enabled, you will see that NGC Cloud Trust is enabled.
According to the flow, we need to contact the AAD Kerberos Provider to obtain a Partial TGT. You can search for the keyword “mcticket.” If you find the field “using the McTicket to get TGT,” it means that the cloud-side TGT has been obtained, and you need to contact the local Kerberos provider to exchange it for TGT.
However, the actual problem we encountered is as follows:
We found that we could locate the DC, and calling the KDC was successful. However, the redeeming of the AS_REP ticket was not successful.
[KerbGetTicketGrantingTicketFromAsRepCallback_New] Failed to redeem AS_REP ticket (McTicket) for Hub TGT: 0xc000006d (STATUS_LOGON_FAILURE).
Let’s start with the actual reason:
The KDC always performs a check to see if the RODC (AzureADKerberos) has the capability to cache the principal’s credentials, which determines if it can issue the TGT.
Note that RODC does not cache the credentials itself; it only checks the user’s permissions to see if it has the qualifications to issue the TGT.
The actual problem we encountered is that the user has too many permissions, and the RODC cannot issue this TGT. The solution is actually documented in the FIDO2 Key documentation:
FAQs for hybrid FIDO2 security key deployment – Microsoft Entra | Microsoft Learn
So, how do we identify the this issue?
You need to capture the log script on each DC simultaneously and check on the client-side which DC is located. The following error represented the KDC cache ability check by the branch krbtgt.
[2] 028C.0D10::09/28/22-13:47:27.5505718 [dll] gettgs_cxx8727 HandleTGSRequest() – Ruian.Ding
[2] 028C.0D10::09/28/22-13:47:27.5505722 [dll] gettgs_cxx8728 HandleTGSRequest() – Realm AD
[2] 028C.0D10::09/28/22-13:47:27.5505779 [commoniumsafe] tickets_cxx1254 KerbPackTicketEx() – KerbPackTicket: Using KeyVersion 0x41 and Algorithm 18 to encrypt ticket
[2] 028C.0D10::09/28/22-13:47:27.5505968 [commoniumsafe] tickets_cxx1857 I_GetASTicket() – KerbPackKdcReplyBody: KeyVersion 0x0 Algorithm 18 KerbErr 0x0
[2] 028C.0D10::09/28/22-13:47:27.5512652 [dll] tktutil_cxx8911 KdcEnforceRodcCachability() – TGT for user Ruian.Ding(0x376F) not cacheable by branch krbtgt_279(0x117)
[2] 028C.0D10::09/28/22-13:47:27.5512669 [dll] tktutil_cxx8309 KdcVerifyKdcRequest() – Decrypted ticket failed to verify: 0x14
[2] 028C.0D10::09/28/22-13:47:27.5512714 [dll] gettgs_cxx7883 HandleTGSRequest() – HandleTGSRequest KLIN(4041ecb) Failed to verify TGS request: 0x14
In the future, if you encounter errors related to 0x14, always check the roles assigned to the user. The solution is the same as mentioned in the FIDO2 key document:
Get-ADPrincipalGroupMembership <Username> | select name
Remove the Domain Admins, Enterprise Admins, and Administrators roles. This way, the RODC can issue TGT to high-privileged users.
