What actually happens after you shove a smart card into the reader? These are my notes on the trip from PIN prompt to Kerberos tickets.

  1. Smart card is shoved into a card reader.

  2. Smart card signals an event that prompts the user for their personal identification number (PIN).

  3. The user enters the PIN. The credential provider passes the logon information to LSA, which calls the Kerberos authentication package.

  4. Windows uses the smart card provider to perform the required private-key operation on the card. The private key stays on the card. The PIN authorizes its use; Windows doesn’t extract the key and the domain controller doesn’t receive the PIN.

  5. The Kerberos security service provider on the client sends an Authentication Service (AS) request to the KDC service running on a DC to request authentication and a Ticket Granting Ticket (TGT). This request includes the user’s certificate (read from the smart card) in the pre-authentication data fields of the AS request. An authenticator, included in the pre-authentication data fields, is digitally signed by the user’s private key so that the KDC can verify the AS request originated from the owner of the accompanying certificate.

  6. The KDC checks the certificate’s validity, chain and revocation status, and checks that the issuing CA is trusted in the enterprise NTAuth store. A Microsoft Enterprise CA is a common way to arrange this, but third-party CAs can be configured too. Simply trusting a root certificate isn’t the whole setup.

  7. The KDC verifies the digital signature placed on the authenticator portion of the pre-authentication data in the AS against the public key sent included in the AS. Then, the KDC validates a timestamp in the authenticator to avoid a replay.

  8. The KDC maps the certificate to an AD account and builds the TGT, including the account and group information in its PAC. A UPN in the certificate was a common mapping in the original version of this flow; see the update below before troubleshooting a current domain on that assumption.

  9. There are two different encrypted things in the AS reply. The TGT is protected with the domain’s krbtgt key. The part the client needs to read, including its copy of the ticket session key, is encrypted with an AS reply key established through PKINIT. PKINIT supports Diffie-Hellman key agreement and public-key encryption; it isn’t always a case of encrypting a random key directly to the card.

  10. The client verifies the KDC’s signature by building a certification path from the KDC’s certificate to a trusted root CA certificate, and then using the KDC’s public key to verify the reply signature.

  11. The client obtains the AS reply key, decrypts its part of the response, and caches the TGT and ticket session key. It doesn’t decrypt the TGT itself. It presents that opaque ticket back to the KDC when it needs service tickets.

The card performs operations involving its private key. The later Kerberos exchanges use symmetric session keys on the client; the smart card doesn’t perform all the cryptography for the session.

The rest of the authentication process is the same as for a standard Kerberos logon. Microsoft’s smart card sign-in flow covers the Windows pieces; RFC 4556 explains the PKINIT exchange and the separate reply key.

Update, September 2026: a matching UPN alone is no longer enough on fully updated domain controllers. The changes in KB5014754 enforce strong certificate mapping, such as a matching SID extension or a supported explicit strong mapping. If the card works locally but domain logon fails, account mapping deserves its own check alongside trust and revocation.

Couple of troubleshooting tips:

  1. Check that the CSP package from the smart card vendor has successfully deployed to the endpoints.
  2. If you know the details of the CSP package you can check if the system also knows by using:
certutil /csplist
certutil /csptest

Certutil will probably be poking around in:

HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Cryptography\Defaults\Provider
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Cryptography\Calais\SmartCards

Also, remember to check that the smart card service (SCardSvr) isn’t disabled. A reader problem and a KDC rejection happen at different points: certutil -scinfo helps inspect the card and certificate locally, while the domain controller’s Kerberos events help with certificate validation and account mapping.

References