Ever since the prescient Wired declared that passwords are passé, a natural question comes up around exploring alternative authentication schemes. While Windows has historically boasted smart card support since the days of Win2K, the catch is that capability gets classified under “enterprise feature.” This is short hand for medium or large company, with managed computing environment and dedicated IT staff. Translated into technical terms, the “managed” requirement implies an Active Directory installation, with centralized servers responsible for administering resources remotely and individual user PCs joined to a domain under the oversight of these servers.
At first blush that rules out consumer scenarios. Most home users do not even have the right edition of Windows to join a domain if one existed. For example, anyone running Windows 7 Home Basic or Home Premium editions is out of luck. For users on a more advanced version of the OS that meets the prerequisites, a more fundamental problem looms: it requires a Windows server class machine to create a domain. At best home PCs are likely to be members of a home group, introduced in Windows 7. Home groups can be created without a dedicated server and function as rudimentary AD domains, with support for cross-machine authentication and file sharing. But they still lack the more advanced capabilities of an enterprise domain including support for strong authentication.
Shifting our attention to third-party solutions, the picture becomes more complicated:
- Several custom schemes exist for smart card logon to stand alone computers
- Caveat emptor: it turns out the benefits for doing that are marginal for the typical home user scenario, when the machine only permits local access.
In this post we tackle the first point. EIDAuthenticate is a popular example of freely available third-party solution that permits local logon using a wide range of card types including the European eID cards and US PIV standard. EIDAuthenticate is based on the idea of associating a smart card with an existing local account that has been already setup with a password. After completing installation, a new control panel option appears for configuring smart-card logon, as shown in the screenshot on the right.
Selecting this new option brings up a window with three options, one of which is initially grayed out first time around (“Disable smart card logon”) since the functionality is already disabled. Assuming that we already have a compatible smart card such as PIV, we can choose the first option and follow the setup sequence:
- Insert/tap a compatible smart card
- Choose one of the X509 certificates located on the card
- Fix any certificate validation errors. Since there is no prior trust relationship with Active Directory is assumed, the certificate on the card could have been issued by a certificate authority that is not recognized by the machine.
- Enter current Windows password for the user account
- [Optional] Dry run, by simulating a login with the selected card to verify that everything is working as intended. The experience here depends on the card profile. For example in the case of PIV cards, a dialog will be displayed to collect the PIN.
- On successful completion of the dry run, the control panel displays a confirmation page.
After this association is created between a particular card (more precisely, a certificate on that card since there can be more than one usable) that card can be used to login to Windows by selecting one of the “Other credentials” or “Insert smartcard” buttons on the logon screen, or simply inserting/tapping a card to implicitly select the smart card path. Case in point: the screenshots from November post on using Android devices as smart cards were captured on a machine with EIDAuthenticate installed.