The Smart card logon process goes like this:

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. User enters PIN, and credential manager sends the PIN to LSA Server.

4. The LSA Server uses the PIN for access to the smart card, then it extracts the user’s private key.

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 verifies the certification path of the user certificate using the CryptoAPI. (The root certificate must be trusted, revocation checking must occur). It then checks to see if the issuing CA is authorized to issue domain authentication certificates (the requirement is that the CA must an enterprise CA published in AD).

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 finds the user in AD based on the UPN (user principal name) in the certificate and constructs a TGT, which will include the user’s Security ID (SID), the SIDs for any domain groups to which the user belongs, and potentially the SIDs for any universal groups in which the user is a member. This info is returned in the authorization data fields of the TGT.

9. The KDC encrypts the TGT with a random session key, and then encrypts this random key with the user’s public key from their certificate (sent in the AS). The KDC then signs the reply with its private key (from domain controller certificate) so that the client can verify the reply is from a trusted KDC. The KDC also signs the TGT’s authorization data using the server’s key that is then signed with the KDC’s secret key so that a rogue service cannot alter the authorization data after the TGT has been issued.

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 then uses their private key to decrypt the logon session key and TGT. Both the client and the KDC then use this logon session key in all future communications with one another.

All cryptographic operations that use these keys take place on the smart card.

The rest of the authentication process is the same as for a standard logon session.

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) is running. If SCardSvr service is disabled you’ll always get the result, “no smart card inserted”.