Smart Card Logon Checklist

Page Header
I have set up Smart Card Logon numerous times in a variety of Windows environments.

Sadly, it is still a complicated process. Mainly because there are so many moving parts.

If you’re enabling it for a Microsoft Certificate Authority (CA), and you don’t plan on having your certificates trusted (or visible) outside your network, it’s actually fairly straightforward and Microsoft are kind enough to do most of the work for you when you install Active Directory Certificate Services (ADCS).

But, if you’re using a 3rd Party CA it gets a little more frustrating fun to implement.

Here’s a basic checklist of things to look at when Smart Card Logon isn’t working. And I should add, this is by no means a complete list.

1) Trust

  • Is your CA trusted?
  • Is your CA trusted across the whole domain?
  • Is your CA installed into Active Directory correctly?
    • Did you use certutil -dspublish to install the CA cert into AD?
    • Did you publish your CA certs into the NTAuth store as well?
  • Do you have old CA Certificates in the domain? Remove any that aren’t required.
  • Are your End-Entity Certificates building the Trust Chain properly?
    • Use certutil, or just inspect the certificate in Windows Certificate Viewer to see what certificate path has been built.

2) Revocation

  • Can CRLs be downloaded?
    • Use certutil -URL [url] to open the CDP/AIA checker.
  • Can all the CRLs be downloaded?
    • Don’t forget to check every CRL Distribution Point.
  • Are the CRLs valid?
    • Are the CRLs valid all the way up the trust chain as well? Don’t forget to check your Root CA.
  • OCSP: If you’re using it, can it also be accessed?
    • Are the OCSP Signing keys up to date?
      • Use OpenSSL to send test queries to it.
    • Don’t forget, in Windows XP/Server 2003 OCSP won’t be used for Logon.
  • Are CRLs being published when they’re issued?
    • Yes, it might be fine now with you manually publishing them but once they’ve expired you’ll be locked out.

3) CA Certificate Publication

  • Tying in with trust, are the CA Certificates available in your AIA Extensions?
    • This will affect trust-chain building if they aren’t available.

4) Active Directory Configuration

  • Do your Domain Controllers have a Kerberos signing certificate?
    • This doesn’t need to be the same as the Kerberos Certificate Template that comes with ADCS, but it still needs to be a valid DC Certificate for the KDC to use it.

5) Machine Configuration

  • Is the Smart Card Service running on the desktop/server?
    • You won’t get far without it.
  • Do you have the correct middleware installed on the machine?
    • Non PIV or .NET Cards generally need some form of middleware/driver installed on the machine to function.
    • If the necessary software/middleware isn’t installed, you won’t even get the PIN prompt appearing, so that’ll be your first clue.

6) Card Configuration

  • Are the Smart Cards personalised correctly?
    • Do they have the Certificate loaded into the “Default” key container?
      • Or if it’s a PIV card, is the correct certificate loaded into the “Authentication” key container?
  • Is the card locked?
    • Try performing other operations with the card (like signing an email or document), to determine that it can operate correctly.

7) Certificate Configuration

  • Does the Certificate on the card contain the correct configuration?

    • You’ll need the certificate to be configured like in this Microsoft Article:

      Key Usage = Digital Signature
      Basic Constraints [Subject Type=End Entity, Path Length Constraint=None] (Optional)
      Enhanced Key Usage =
          Client Authentication (1.3.6.1.5.5.7.3.2)
          (The client authentication OID) is only required if a certificate is used for SSL authentication.)
          Smart Card Logon (1.3.6.1.4.1.311.20.2.2)
      Subject Alternative Name = Other Name: Principal Name= (UPN). For example:
          UPN = user1@name.com
          The UPN OtherName OID is : "1.3.6.1.4.1.311.20.2.3"
          The UPN OtherName value: Must be ASN1-encoded UTF8 string
      Subject = Distinguished name of user. This field is a mandatory extension, but the population of this field is optional.
  • Does the User Principal Name in the Certificate match the account you’re trying to log in with?

Some Further Reading

Microsoft has a couple of great articles on setting up Smart Card Logon:

Brian Komar’s book on PKI is really good as well, covering more than just setting up PKI in Windows Server 2008.

Anything I’ve missed? Let me know and I’ll add it to the list.