The WebAuthn event log in Windows is a very useful resource to troubleshoot issues with FIDO2 security key use on Windows. But they can seem quite verbose and noisy at first glance.
It may help therefore to know the applications/processes that are the sources for the event log entries and the sequence of expects events. These are the most common sources for event log entries.
- User process/Web browser like Edge/Chrome/Firefox
- Credentialuibroker.exe – This is the GUI prompt users interact with when choosing to enter a pin (or a fingerprint)
- Bioenrollmenthost.exe – This is accessible via the settings app and is used to manage the key to add/change pin, add fingerprints or reset the key
- LogonUI.exe – UX for collecting credentials at interactive logon via FIDO2
- Cryptsvc/svchost.exe – Windows Service that handles the CTAP2 communication with the key
Here are some common scenarios where you may be reviewing the event log.
- Web browser logon to a website or credential provisioning.
This scenario involves events by the browser (msedge.exe), the credentialuibroker.exe and the cryptsvc/svchost.exe. - Interactive logon to Windows.
This scenario involves events by the logonui.exe and the cryptsvc/svchost.exe. - Managing FIDO2 key via Windows Settings app to reset key or add a pin.
This scenario involves events by the bioenrollmenthost.exe and the cryptsvc/svchost.exe.
Please note any activity done in a private mode browser is NOT logged by default in the event log. This is intentional and by design. So if you are troubleshooting some unexpected behaviour when using a browser, using a normal mode browser is encouraged.
Some of the activity in the event log will be quite clear to understand. This event below identifies the FIDO2 client app that is initiating a CTAP2 communication with a key. Looking at the process ID will help you identify which of the above common processes logged the event.
Log Name: Microsoft-Windows-WebAuthN/Operational
Source: Microsoft-Windows-WebAuthN
Date: 10/01/2024 16:37:21
Event ID: 2106
Task Category: Ctap Function
Level: Information
Keywords: Ctap
User: NETWORK SERVICE
Computer: maweeras2
Description:
Ctap Name: ImageName Value: C:\Program Files (x86)\Google\Chrome\Application\chrome.exe
Event Xml:
<Event xmlns=”http://schemas.microsoft.com/win/2004/08/events/event”>
<System>
<Provider Name=”Microsoft-Windows-WebAuthN” Guid=”{3ae1ea61-c002-47fb-b06c-4022a8c98929}” />
<EventID>2106</EventID>
<Version>0</Version>
<Level>4</Level>
<Task>503</Task>
<Opcode>12</Opcode>
<Keywords>0x8000000000000002</Keywords>
<TimeCreated SystemTime=”2024-01-10T16:37:21.6574939Z” />
<EventRecordID>1755</EventRecordID>
<Correlation ActivityID=”{4e644e15-4525-48e9-b91e-97b8e3d215ab}” />
<Execution ProcessID=”5464″ ThreadID=”15264″ />
<Channel>Microsoft-Windows-WebAuthN/Operational</Channel>
<Computer>maweeras2</Computer>
<Security UserID=”S-1-5-20″ />
</System>
<EventData>
<Data Name=”Name”>ImageName</Data>
<Data Name=”Value”>C:\Program Files (x86)\Google\Chrome\Application\chrome.exe</Data>
</EventData>
</Event>
For the most part I expect the CTAP2 communication with the key done by cryptsvc(svchost.exe) will be what you will want to decipher. Based on the protocol (USB,NFC,BLE or Hybrid) used to access the security key, you may decode the CTAP2 messages using something like https://cbor.me and reference the CTAP 2.1 spec for clarity on what the request generated by the platform (Windows) was and the response from the key.
I recently had to delve deep to troubleshoot an inability to provision credentials for Entra ID on a Yubikey which turned out to be a very simple root cause.
The customer claimed they were trying to provision credentials on the Yubikey for Entra at the https://aka.ms/mysecurityinfo page and had tried the same key via USB and NFC (via a HID Global OMNIKEY 5022 Smart Card Reader) to no avail.
Log Name: Microsoft-Windows-WebAuthN/Operational
Source: Microsoft-Windows-WebAuthN
Date: 04/01/2024 21:16:41
Event ID: 2225
Task Category: Ctap Usb Send Receive
Level: Verbose
Keywords: Ctap,Ctap
User: NETWORK SERVICE
Computer: C4LR9T2.#####
Description:
Ctap Usb Send Receive:TransactionId: {c2d7b486-d657-47a5-bb72-0063b5ff2027}
Request Command: 0x90 Response Command: 0x90
Request: 0x06A201020201
Response: 0x00A10300
The request decoded is 6, {1: 2, 2: 1}. This as per spec https://fidoalliance.org/specs/fido-v2.1-ps-20210615/fido-client-to-authenticator-protocol-v2.1-ps-errata-20220621.html#authenticatorClientPIN is a clientpin call using pin protocol 2 and a subcommand to get the number of pin retries back.
The response decoded is 0, {3: 0}. That means 0 attempts left for pin retries.
In a healthy unlocked key you would get something like
Log Name: Microsoft-Windows-WebAuthN/Operational
Source: Microsoft-Windows-WebAuthN
Date: 05/01/2024 14:56:01
Event ID: 2225
Task Category: Ctap Usb Send Receive
Level: Verbose
Keywords: Usb,Ctap
User: NETWORK SERVICE
Computer: maweeras2
Description:
Ctap Usb Send Receive:TransactionId: {3d9121d6-1b86-4946-8fe4-d10dee2e676e}
Request Command: 0x90 Response Command: 0x90
Request: 0x06A201020201
Response: 0x00A10308
Here is the response decoded is 0, {3: 8} meaning 8 attempts left.
But in the customer’s case as they had 0 attempts left in their response, they had locked the key which resulted in
Log Name: Microsoft-Windows-WebAuthN/Operational
Source: Microsoft-Windows-WebAuthN
Date: 04/01/2024 21:16:44
Event ID: 2212
Task Category: Ctap Usb Device Thread
Level: Error
Keywords: Ctap,Ctap
User: NETWORK SERVICE
Computer: C4LR9T2.s###
Description:
Ctap Usb device thread completed.TransactionId: {c2d7b486-d657-47a5-bb72-0063b5ff2027}
DevicePath: \\?\hid#vid_1050&pid_0407&mi_01#7&20e3b796&0&0000#{4d1e55b2-f16f-11cf-88cb-001111000030}
Manufacturer: Yubico
Product: YubiKey OTP+FIDO+CCID
AAGuid: {2fc0579f-8113-47ea-b116-bb5a8db9202a}
U2fProtocol: false
State: 6
Status: 0x43
Error: 0x8009030C. The logon attempt failed
As per the spec, this requires a complete reset of the key for security reasons which will result in wiping all credentials currently on the key. The key cannot be used while locked for any getassertion operations even if the correct pin is now known. So users need to be educated not to try lock their keys by making typographical errors.
It would have been arguably more intuitive to have an event indicating the key as locked and requiring a reset. But in the absence of more user friendly clarity in the event log, you may have to decode the CTAP2 messages using something like https://cbor.me to make head or tail out of what the platform/key conversation was. Especially when you are not sure who among many parties involved (the security key vendor, Microsoft for the Windows platform, Browser vendor or the relying party processing the makecredential response) is to blame.
maweeras.page 