Forcing the usage of smart cards for logons inside enterprise networks provides enhanced security and a stronger authentication as the user PIN directly depends on the presence of another physical layer, the smart card itself. Also it is a pretty functional method of supplying couple of different AAA requirements in a single user device for multiple access types such as VPN (such like I have explained here before), remote desktop connections, digital signing or a local encryption (~ EFS).
Smart card authentication leans upon certificates in order to verify the authenticity of users while issuance and the validity of these certificates lean upon CA (Certificate Authority). Many companies have CA already installed on their Windows Domain Controller (Active Directory) even they are not conscious of it or actually using it. Here it is the leading service to generate heap of certificates to internal users and to save a lot of expense because purchasing them from a 3rd party CA will be very pricey for even small or mid-sized enterprises with limited number of employees.
On the other hand, using an internal CA infrastructure will bring additional liabilities and the need for vigilance of security measures along with it as the upper-level and subordinate CAs
will play the key part in company’s network and data security needs. So deploying a strict security policy in terms of CA administration and smart card usages shall be one of the primary tasks in parallel with private CA integrations. Policy must cover management of CA, maintenance of CRL (Certificate Revocation List) and CTL (Certificate Trust List), certificate renewals as well as the immediate intervention for physical issues like lost, compromised or stolen smart cards. Otherwise generating and distributing certificates arbitrary will never be the way of increasing company security but contrarily will be a total frustration.
Planning and configuring a private company CA infrastructure is a fairly extensive subject and beyond the scope of this post so we’ll engage in our title assuming you have at least one Windows Server 2003 or above with Active Directory up and running that is also established as a stand-alone CA and you also have your smart card(s) (or a USB token) with you. I highly recommend you to read “Installation and Configuration of Active Directory Certificate Services on Windows Server 2008 R2” which has recently been written by M. Bora Teoman, if you want to obtain more detailed information about Certificate Services.
Picking and purchasing pack of plug-and-play smart cards which are already supported under Windows Server will ease your implementation. Corresponding device drivers shall be automatically installed along with the manufacturer’s PKI client software installation on both your domain controller server and all your client workstations. Otherwise you have to follow the special instructions provided by the manufacturer’s manual. Right after completing PKI client software installation, open your smart card PKI software interface, initialize and give a new PIN code to them in order to prepare your smart cards for logon.
Now log on to your domain controller server as usual and click Start -> Administrative Tools -> Certification Authority to open Certification Authority snap-in. Navigate to Certificate Templates under Computer Name. Right click and select New -> Certificate Template to Issue
Select Enrollment Agent, Smartcard Logon and Smartcard User tamplates holding CTRL and click OK.
Enrollment Agent: This template is used to create certificates that allow a server to act as an enrollment station for issuing certificates on behalf of smart card users that will access network.
Smartcard Logon: This template is used to create certificates to enable your clients to authenticate within Active Directory by using their smart cards.
Smartcard User: This template provides Secure Email feature in addition to Smartcard Logon template.
Now that you have your three security templates in place, open Active Directory Users and Computers management console and create a new user account that is going to be responsible from enrollment role (I created “eagent” user account as an example to use in this document). Or you may just continue by picking an existing user account to commit the enrollment tasks. After determining the user account, click Start -> Run, type certtmpl.msc and hit OK. to open certtmpl – [Certificate Templates] snap-in. Navigate to Enrollment Agent template, right click and select Properties. Go to Security tab menu, add your user account that you have created and grant the Enroll permission for your user account.
If you’ve promoted the user account you’ve created as a member of Domain Admins Security Group, you don’t need to grant this permission to your user account as domain administrators are granted permission to request a certificate based on the Enrollment Agent template by default.
Now log off and log on to server with the new user account who will be installing the certificates.
Click Start -> Run, type mmc and hit OK. to open blank MMC console. Click File -> Add/Remove Snap-in… then select Add, select Certificates snap-in and click Add. Select My user account option and hit Finish button. Click Close and OK. in turn.
Expand Certificates – Current User and navigate to Personal, right click on Certificates and follow All tasks -> Request New Certificate…
Bypass the welcome screen and select Enrollment Agent certificate type and click Next.
In the next screen enter a friendly name such as “Smart Card Enrollment” and complete the certificate request. Right after the completion of wizard, you’ll notice that issued certificate appears in the right pane and its intended purpose is designated as Certificate Request Agent.
Once an account has an Enrollment Agent certificate, it can enroll for a certificate and generate a smart card on behalf of anyone in the organization. Then that smart card could be used to log on to the network and impersonate the real user.
Because of the privileged capabilities of the Enrollment Agent certificate, organization has to enforce strong security policies over who has this type of certificate. A methodology to minimize the potential risks of Enrollment Agent certificate misuse might be to deploy a subordinate CA which is only used to issue Enrollment Agent certificates along with the strict administrative controls.
After issuing Enrollment Agent Certificate and installing smart card readers on all client workstations, it’s time to begin the process of issuing the smart card certificates. Log on to a workstation with the user account that is issued an Enrollment Agent Certificate above or just stay on the console of your CA and open Internet Explorer. Browse to http://yourcaserver/certsrv/ and enter the account access details when asked.
Select “Request a certificate” task
Select “submit an advanced certificate request” option.
Select “Request a certificate for a smart card on behalf of another user by using the smart card certificate enrollment station.” but before make sure that you have enabled all activex controls by following Tools -> Internet Options -> Security -> Custom Level menus. Otherwise you’ll encounter a faulty page and your browser will not be able to communicate and get CSP list, certificate template list and CA list.
In the final screen select the Certificate Template as Smartcard Logon and select the name of the CA for your domain in the Certificate Authority drop-down box. In the Cryptographic Service Provider drop-down box, select your smart card’s manufacturer. Administrator Signing Certificate section will automatically display the user account that the Enrollment Agent Certificate was issued to. Then click Select User button to pick the user account which you’re associating the smart card certificate with.
Finally you’ll notice the “Please insert the user’s smart card into a reader and then press ‘Enroll’.” message below the form. Insert a smart card into the smart card device attached to system and click Enroll button.
You will be prompted to enter the PIN code of the smart card. After entering the code, hang on while the keys are being generated.
You may perform these enrollment processes via remote desktop connection if the user account that is issued an Enrollment Agent Certificate is also a member of Remote Dektop Security Group.
Usage of smart cards for logons will not offer the intended security level if it’s not forced to be used throughout the whole organization without exception. In order to accomplish this,
open Active Directory Users and Computers management console and mark “Smart card is required for interactive logon” option below Account Options under Account tab menu inside the user account properties.
Finally don’t forget to train your users on the procedure to log on to smart card protected workstations since CTRL + ALT + DEL key sequence will no longer be needed.
RSS feed for comments on this post.
