Using a Non-Microsoft CA with Smartcard Logon
Last updated: 10/12/2004
Microsoft Windows has the ability to use PKI smartcards and USB tokens for interactive logon authentication to Active Directory (AD).† This authentication is currently the strongest available for AD, and the use of PKI smartcards or USB tokens allows economical two-factor authentication for AD.† Institutions using Microsoftís Server 2003 CA product report that it is straightforward to make smartcard logon work with AD.† Other institutions using non-Microsoft CAs have encountered more difficulties.
The purpose of this document is to report what
This works for us using the following software:
We have not extensively tested this, but wanted to document it while it was still fresh in our minds.† We do not yet have hundreds of users using this on a daily basis.
Your mileage may vary with other versions of software.† In particular, some CA implementations may not have the flexibility required to generate all the required fields in the smartcard-enabled certificates.† You should check into this earlier rather than later.
We do not document the actual CA operations required to get the proper fields in the certificate.† Our CA is a discontinued commercial product, so our details probably wouldnít be very useful.† Instead, we present the details of the fields required so you can see what you need to make your CA do.
We found the Microsoft Knowledge Base article at: http://support.microsoft.com/default.aspx?scid=kb;en-us;Q281245 to be useful.† We are not allowed to copy it, so please refer to this URL for information that may not be included in this document.† Note: We did not do step 7 in this document Ė just having the certificate on the token is enough, and there is no need to install it in the computer beforehand.
There are three areas of work to make smartcard logon work:
We installed the Aladdin RTE (USB token) drivers and made sure we didnít have Aladdinís eGina product installed on the client.
Here is a certificate with the proper magic in it:
Base 64 encoded text:
We found it extremely valuable to have an example of a working smartcard-enabled certificate as we adjusted our CA to produce our own.† We referred to it frequently in order to get the proper fields in our own certificates.
Fields we had to add to our certificate are:
Note 1: We found that https on the URL for the CDP did not work.
Note 2: We have since implemented multiple URLs in this field, and this seems to work fine.
Enhanced Key Usage:
Note: We added the Secure Email and Client Authentication entries because Windows appeared to disregard the Key Usage bits once we added Smart Card Logon in Enhanced Key Usage.
Subject Alternative Name:
Note 1: The text needs to be formatted as ASN1 / UTF-8 or it will not be readable in the Certificate viewer as above and will not work properly for smartcard logon.
Note 2: We already had the RFC822 Name part in Subject Alternative Name.† Itís probably not necessary for smartcard logon purposes.
Microsoft requires a Subject field even though they also require the UPN in the Othername part of the Subject Alternative Name.† They say populating Subject is optional.† Most certificates have Subject, so this probably isnít an issue for you.
There are three certificate installation steps required.† Details about how to do all of these are in the Microsoft Knowledge Base article above, or consult your Active Directory documentation.
Once we had all the pieces in place, smartcard logon was automatically enabled by Active Directory and the Windows clients.
We didnít have to change anything about our root certificate (e.g. no smartcard key usage bits required).† Here is our root certificate:
The two error messages we encountered while debugging were reasonably descriptive.† The Microsoft Knowledge Base Article referenced above has quite a bit of troubleshooting information in it, but we didnít need most of it.