Security: Beyond the Basics
Get Smart! Boost Your Network's IQ With Smart Cards
Brian Komar
At a Glance:
- Using smart cards in an Active Directory environment
- Smart card implementation requirements
- Planning a smart card deployment
- Defining smart card usage within an organization
Kerberos Authenti-cation
Public Key Infra-structure
Smart Card Deployment
Many organizations are implementing two-factor authentication solutions to increase network security. Two-factor authentication increases security by requiring something you have, such as a smart card or other device with a smart card chip (like a
USB token), and something you know, such as the personal identification number (PIN) for the smart card or USB token. To initiate a smart card program, an organization must deploy the related hardware and software to each desktop. The required hardware includes a smart card reader, as well as a smart card that is on the Windows® hardware compatibility list or that includes drivers for Windows 2000, Windows XP, or Windows Server™ 2003 clients on your network. As an alternative, you can use a USB token, which is a combination USB reader and card. For software, you will need a smart card cryptographic service provider (CSP) that allows the Microsoft® cryptographic application programming interface (CryptoAPI) to interact with the smart card.
Windows currently ships with default CSPs for GemPlus, Infineon, and Schlumberger, though these CSPs do not work with all versions of these manufacturers' smart cards. You must determine if updated CSPs are required for the smart cards selected by your organization.
Both Windows 2000 and Windows Server 2003 Active Directory® environments support smart card authentication, an extension to Kerberos authentication. This means that only Windows 2000, Windows XP, and Windows Server 2003 client computers can be used with smart cards in an Active Directory environment.
Smart cards allow Kerberos authentication through Public Key Initialization (PKINIT) extensions to the Kerberos protocol. PKINIT extensions allow a public/private key pair to be used to authenticate users when they log onto the network.
Requirements for Smart Card Certificates
To deploy smart cards in a Windows 2000 or Windows Server 2003 Active Directory environment, the following requirements must be met:
- All domain controllers and computers in the forest must trust the root Certification Authority (CA) of the smart card certificate's certificate chain.
- The CA that issues the smart card certificate must be included in the Active Directory NT Authority (NTAuth) store. When a CA certificate is added to the NTAuth object in Active Directory (CN=NTAuthCertificates, CN=Public Key Services, CN=Services, CN=Configuration, DC=ForestRootDomain, where ForestRootDomain is the LDAP distinguished name of the forest's root domain), the thumbprint of the CA's certificate is automatically distributed to all Windows 2000 and later domain members in the HKEY_LOCAL_MACHINE\Software\ Microsoft\EnterpriseCertificates\NTAuth\ Certificates registry key. You can verify the CA certificates included in the NTAuth store by using the PKI Health Tool (pkiview.msc) included in the Windows Server 2003 Resource Kit.
- The smart card certificate must contain the Smart Card Logon (1.3.6.1.4.1. 311.20.2.2) and Client Authentication (1.3.6.1.5.5.7.3.2) object identifier (OID) in the Enhanced Key Usage (EKU) extension or in the Application Policies extension. The Smart Card Logon and Client Authentication OIDs must be valid in the entire certificate chain.
- The smart card certificate must contain the user's UPN in the subject alternative name extension.
- All domain controllers must have a Domain Controller or Domain Controller Authentication certificate installed. Smart card authentication requires mutual authentication of the user and the domain controller involved in the Kerberos authentication.
A Windows Server 2003 Enterprise Edition CA meets these requirements. Alternatively, a third-party CA can issue a smart card certificate, as long as the requirements are met. The requirements are detailed in Knowledge Base article 281245, "Guidelines for Enabling Smart Card Logon with Third-Party Certification Authorities".
Planning Smart Card Deployment
Let's begin with determining the assurance level required for smart card issuance. A smart card increases protection for a certificate's private key. To compromise a smart card's private key, an attacker must obtain the smart card and know the associated PIN. As added protection, a smart card blocks access to the smart card's private key(s) after a designated number of PIN failures. The private key can only be accessed after the smart card is unlocked. You can increase the security of the smart card distribution by requiring face-to-face interviews during enrollment. This requires the user to meet with either the enrollment agent requesting the smart card certificate or with another person, sometimes referred to as a local registration authority (LRA), who verifies the user's identity.
Smart Card Deployment
Planning a smart card deployment involves several interrelated steps, including:
- Determining the assurance level required for smart card issuance
- Identifying the required certificate templates
- Determining certificate distribution methods
- Designing and configuring the required certificate templates.
- Deploying a smart card management system.
- Identifying when smart cards can and cannot be used
To indicate that you have performed a face-to-face interview before issuing a smart card, you can add a custom certificate policy OID to the Issuance Policies extension that indicates the measures taken to validate the smart card holder's identity before issuance.
To deploy smart card certificates by using face-to-face validation of the user's identity, your organization must provide certificates for the two roles in smart card deployment: the enrollment agent and the smart card holder.
An enrollment agent must hold a certificate that allows them to request a smart card certificate on behalf of another user. This is made possible by including the Certificate Request Agent OID (1.3.6.1.4.1.311.20. 2.1) in the EKU or Application Policies extension of the certificate. This functionality is provided in the default version 1 Enrollment Agent certificate template.
The smart card holder must, at a minimum, have a certificate that includes the Smart Card Logon (1.3.6.1.4.1.311.20.2.2) and Client Authentication (1.3.6.1.5.5.7.3.2) OIDs in the certificate's EKU or Application Policies extension. This functionality is provided in two default version 1 certificate templates: Smart Card Logon and Smart Card User.
Some organizations choose to implement version 2 certificate templates based on the default version 1 certificate templates. Version 2 templates allow an organization to require validation of an enrollment agent's identity, enable autoenrollment for certificate renewal, add a certificate policy to describe the issuance method of the smart card certificate, add application policies to the smart card certificate, and enforce the use of a specific smart card CSP.
Once you determine which certificate templates to implement for enrollment agents and smart cards, the next step is to decide how to distribute the certificates to the desired holders. There are three common methods for deploying smart card certificates: implementing enrollment agents, using autoenrollment for initial distribution of certificates, and using autoenrollment for smart card certificate renewal.
An enrollment agent requests a smart card certificate on behalf of each user. The enrollment agent signs the certificate request with a certificate that includes the Certificate Request Agent object identifier in the EKU or Application Policy extension of the enrollment agent's certificate. In addition to issuing the smart card certificate to a user, the enrollment agent also validates the identity of the requesting user by inspecting identification such as a driver's license or a passport.
The enrollment agent must use the Certificate Services Web Enrollment pages to request the smart card certificate on behalf of another user. The Smart Card enrollment pages must be added to the Local intranet security zone and allow untrusted ActiveX® controls to be downloaded.
Autoenrollment can be used in implementations where additional identity validation measures are not required. When autoenrollment is used, you must ensure that smart cards, smart card readers, and support software such as smart card management software and CSPs are distributed to the users before autoenrollment is initiated. In this solution, the user will be prompted to input their smart card during the autoenrollment process.
Under the default settings, the process of smart card certificate renewal is the same process used for initial enrollment. In other words, if you have to undergo a background check to receive your initial smart card, you must undergo the same background check to renew the certificate. However, you can reduce the security requirements for smart card renewal. For instance, if you can provide evidence that you have already undergone the background check, there is no need to undergo it again. Two solutions exist to meet this type of deployment:
- You can configure the certificate template to renew the certificate automatically if users hold existing certificates based on the existing version of the certificate template. By holding an existing certificate, users provide evidence that they have undergone the required validation process.
- You can require users to sign the certificate renewal request with the existing smart card certificate. By signing the certificate request, the requestors prove they can access the private key of the previous smart card certificate, thus proving that they are the same person that requested the original certificate.
Certificate Template Design and Configuration
Once you determine how smart cards are to be used in your organization and how the certificates are to be deployed, you can define the certificate templates. Most organizations use the default Enrollment Agent certificate template. If you implement this template, my only recommendation is that you modify the permissions to allow a custom global or universal group (in the case of a multiple domain forest) only Read and Enroll permissions. Remove the Enroll permission assignment for members of the Enterprise Admins and forest root domain's Domain Admins groups to prevent unauthorized registration of the Enrollment Agent certificate template.
If you want to implement certificate manager approval for enrollment agent certificates, you must create a version 2 certificate template based on the version 1 Enrollment Agent certificate template. In the version 2 certificate template definition, configure the Issuance Requirements tab (see Figure 1).
Figure 1** Issuance Requirements **
In addition, it is recommended that you add the version 1 Enrollment Agent certificate template to the Superseded Templates tab and restrict enrollment permissions to a custom universal or global group that contains all designated enrollment agents.
Once the required enrollment agents have obtained their Enrollment Agent certificates, consider removing the Enrollment Agent certificate templates from all CAs in the organization. To help prevent unauthorized certificate enrollment of Enrollment Agent certificates, only publish the certificate template on a CA when a new enrollment agent must be designated or when certificate renewal is required.
When you are using smart cards, it is recommended that you create a custom version 2 certificate template based on either the default Smart Card Logon or Smart Card User version 1 certificate templates. The version 2 certificate templates give you greater flexibility in the configuration of the certificate contents.
Figure 2 lists the recommended modifications to the version 2 certificate template. This certificate template can be published at multiple CAs for fault tolerance and must be available at all times to allow an enrollment agent to create a smart card for any user at any time.
Figure 2 Custom Initial Smart Card Certificate Template
| Tab | Recommendations |
| General | Create a custom Template Display Name and Template Name, based on the organization name, that specifies that the certificate template is for enrollment agents. The validity period is typically no longer than one year. |
| Request Handling | Make the following changes on the Request Handling tab:
|
| Subject Name | The only requirement here is that you ensure that the UPN option is enabled. You should enable the e-mail name options if you intend to use the smart card for S/MIME e-mail purposes. |
| Issuance Requirements | In order to enable enrollment by an enrollment agent, you need to configure the certificate template to require one authorized signature, with the signing certificate containing the Certificate Request Agent OID. |
| Superseded Templates | Add both the Smart Card User and Smart Card Logon certificate templates, designating that the custom version 2 certificate template is the organization's preferred version. |
| Extensions | For application policies, include the Smart Card Logon and Client Authentication. If you want to use the smart card for signing e-mail, include the Secure E-mail OID. In addition, add a custom application policy OID that indicates that the certificate is YourOrganization's smart card. This OID can be used in applications, such as the Microsoft RADIUS server, to restrict certificate usage to only certificates with this custom OID. Add a custom certificate policy OID that defines the process used for the smart card certificate. The custom issuance policy OID can also include a Web URL reference that provides a text description of the process. |
| Security | Modify the permissions for the certificate template so that only a custom global or universal group that contains all enrollment agents has Read and Enroll permissions. Consider removing the Enroll permission assignment from the Enterprise Admins and forest root's Domain Admins groups. |
If your organization's security policy requires the same subject validation process for initial smart card enrollment and renewal, you can use the custom certificate template just described. When a smart card certificate is expiring, users can return to the enrollment agent, who can re-enroll on their behalf and provide them with a replacement certificate. If your company has standardized on machines running Windows XP, there is an alternative option that takes advantage of autoenrollment and the ability to sign a certificate by using the initial smart card certificate.
To take this route you create a custom version 2 certificate template that enables autoenrollment if the certificate request is signed with a previous smart card certificate. At the time the previous smart card certificate nears expiration, the autoenrollment process will prompt the user to sign the certificate request with his existing smart card certificate. When the renewal is performed, the previous smart card certificate is archived and the updated certificate remains as the active certificate.
Figure 3 explains how to configure a version 2 certificate template to use autoenrollment for smart card certificate renewal. The certificate template can be based on either the Smart Card Logon or Smart Card User certificate template.
Figure 3 Custom Renewal Smart Card Certificate Template
| Tab | Recommendations |
| General | Create a custom Template Display Name and Template Name, based on the organization name, that specifies that the certificate template is for smart card renewal only. Set the validity period to no longer than one year. To prevent the user from continually requesting the replacement smart card certificate, enable Publish Certificate in Active Directory and Do Not Automatically Re-Enroll if a Duplicate Certificate Exists in Active Directory. This publishes the issued certificate in the userCertificate attribute of the user account and prevents re-enrollment if a certificate is already published to the user account. |
| Request Handling | Change the Purpose dropdown list to Signature and Smart Card Logon, increase the minimum key size to 1,024 bits if using smart cards with 8KB or more storage space, and define the smart card CSP you want to use with the certificate template. |
| Subject Name | The only required name format for smart card login is to ensure that the UPN option is enabled. Also, enable the e-mail name options if you intend to use the smart card for S/MIME e-mail. |
| Issuance Requirements | Configure the Issuance Requirements tab to require one authorized signature, with the signing certificate containing the Smart Card Logon OID. If you have implemented a custom application policy OID based on your organization, require this custom application policy OID for signing instead of the Smart Card Logon OID. |
| Superseded Templates | Add the initial smart card logon certificate template defined in Figure 2. The addition of the superseded template allows autoenrollment to initiate. |
| Extensions | For application policies, ensure that you include the Smart Card Logon and Client Authentication. If you want to use the smart card for signing e-mail, include the Secure Email OID. In addition, continue adding a custom application policy OID that indicates that the certificate is YourOrganization's Smart Card to allow continued autoenrollment processing for certificate renewal when the certificate expires. For issuance policies, add a custom certificate policy OID that defines the process used for the smart card certificate. The custom issuance policy OID can also include a Web URL reference that provides a text description of the process. |
| Security | Modify the permissions for the certificate template so that only a custom global or universal group that contains all smart card holders has Read, Enroll, and Autoenroll permissions. |
The renewal smart card certificate template can be published at multiple CAs for fault tolerance and must be available at all times to allow an enrollment agent to create a smart card for any user at any time.
Deploying a Smart Card Management System
A smart card deployment must look beyond the issuance of smart card certificates. In addition to getting the smart cards to the users, the deployment must address the customization of the smart card enrollment pages and smart card PIN resets.
First of all, you can customize the default enrollment pages with modifications that can include such things as adding your organization's logo, changing the signing requirements for a smart card certificate, or simplifying the user experience by removing the multitude of options available when the user requests a certificate.
In terms of pin resets, most smart cards (by default) prevent the user from accessing the smart card's private key if the smart card PIN is entered incorrectly three consecutive times. Your organization must develop custom software or use commercial software to allow the remote reset of a user's smart card. For these solutions, look to the software development kits for the specific smart card vendor or to third-party management systems, such as those available from Alacris and from Spyrus.
You should remember that smart cards are not a panacea for authentication security. And, there are some applications that cannot use smart cards as an authentication mechanism. During a recent smart card pilot project at Microsoft, where users were required to use smart cards for all forms of authentication, several applications would not work with the updated smart card authentication.
Outlook Web Access, for example, does not support smart card authentication. You must type credentials into a form or use basic authentication protected by Secure Sockets Layer (SSL).
Some Exchange Server deployment scenarios contain configuration options that do not support the use of smart card authentication. For example, if the user account and the mail box are situated in different forests, smart card authentication is not possible. Another option that does not support smart card authentication is the implementation of Remote Procedure Calls over HTTP in Microsoft Outlook®.
Service accounts and batch files also cannot use a smart card for authentication. A scheduled task that implements a service's account will not prompt for smart card insertion or for the input of a PIN to access the private key material on the smart card.
If a workstation is not joined to a domain, Windows NT Lan Manager (NTLM) authentication is used to authenticate the account and password combination required. Since smart cards require Kerberos authentication, they cannot be used in this scenario. If an application uses Basic Authentication or NTLM authentication, smart cards cannot be used for authentication purposes. Only applications using Kerberos that support PKINIT extensions will work with smart cards.
Defining Smart Card Usage in Your Organization
Once you have deployed smart cards to the users in your organization, you can fine-tune security settings in Active Directory and other services to define how the smart cards are to increase network security. The settings that you can define include:
- Requiring smart cards for interactive logon
- Requiring smart cards for remote access logon
- Defining smart card removal behavior
- Using smart cards for the various administrative tasks
Through group policy, you can define whether smart cards are required for interactive logon by using the Interactive Logon: Smart Card Required Group Policy setting. This setting, defined in Computer Settings | Windows Settings | Security Settings | Local Policies | Security Options, enforces smart card logon for all users on computers where the Group Policy setting is defined.
Alternatively, you can enable the "Smart Card Is Required For Interactive Logon" option on the Account tab of the user's object in Active Directory. This method gives you more flexibility in that you can enforce smart cards on a user-by-user basis.
Do not enable the Smart Card Is Required For Interactive Logon and the User Must Change Password At Next Logon options for a user account. When you enable the Smart Card Is Required For Interactive Logon option in a Windows Server 2003 environment, the operating system takes over user password management. The operating system assigns a maximum-length password that is equivalent to 255 characters and ensures that the password meets complexity requirements, effectively blocking the user from logging onto the network by using a password.
When you enforce smart card logon in your domain, you must also ensure the validity and availability of the CRL Distribution Point (CDP) and Authority Information Access (AIA) URLs in the smart card certificates as well as all CA certificates in the certification chain. The domain controller accepting the smart card authentication attempt will perform a revocation check on the smart card certificate during the logon process.
To enforce smart card authentication for remote access, you must configure a remote access policy at a remote access server or a RADIUS server to require Extensible Authentication Protocol with Transport Layer Security (EAP/TLS) authentication in the profile settings.
When you enforce EAP/TLS authentication, you can elect to restrict client certificates to a smart card or other certificate. The only additional configuration required at the Routing and Remote Access (RRAS) server or the Internet Authentication Services (IAS) server is to designate the Server Authentication certificate used by the server for mutual authentication.
Group Policy also allows you to define the action that takes place when users remove their smart cards from a smart card reader by using the Interactive Logon: Smart Card Removal Behavior Group Policy setting. This setting, defined in Computer Settings | Windows Settings | Security Settings | Local Policies | Security Options, ensures that smart card removal behavior is consistent for all computer accounts in the OU or domain where the Group Policy is applied.
In this Group Policy setting, you can define the removal behavior one of three ways:
No Action The default setting. The removal of the smart card does not lock the workstation or log off the current user.
Lock Workstation The removal of the smart card causes the workstation to lock. The user must press Log On Interactively or provide the PIN for the smart card to unlock the workstation.
Force Logoff The user currently logged on is automatically logged off.
In a pure Windows 2000 network, it was not possible to use smart cards for all administrative tasks. Several tasks still required the input of user credentials and passwords, reducing the security gains accomplished through the issuance and usage of smart cards. Windows XP and Windows Server 2003 offer enhancements that enable additional usage of smart cards in administrative activities, including the RunAs, Net Use, and DCPromo commands, and Terminal Services.
The RunAs command allows you to run a program in a security context other than that of the currently logged on user. For example, if administrators have day-to-day accounts and smart cards for administrative tasks, they can use the RunAs command to run administrative tasks with their smart cards, whether accessed via the GUI or from the command line. From the command line, you can add the /smartcard switch; from the GUI, you can elect to use a smart card for authentication.
Like the RunAs command, you can choose to use a smart card to provide credentials for network drive mapping. From the command line, you must use the /smartcard switch to designate that the credentials are read from a smart card. Likewise, from the GUI, you can choose to connect with a different user name and then select the smart card from the list of available credentials.
If the computer you are promoting to a domain controller is already a member of the forest, you can use a smart card to validate your identity in the DCPromo wizard. The computer must be a member of the forest before running DCPromo; otherwise the option is not available. This option is only available on computers running Windows Server 2003.
A user can use her smart card to connect to the Remote Desktop Service (or Terminal Services) running on Windows XP or Windows Server 2003, as long as the host computer is a member of an Active Directory domain. The Windows XP and Windows Server 2003 Remote Desktop client accepts smart cards as a form of authentication and passes the credentials to the remote computer.
If you are using a third-party CSP, it must be loaded at both the remote client and the remote desktop server so that the smart card is recognized at each end of the Terminal Services connection.
Conclusion
A successful smart card deployment is dependent on proper planning and design. By putting the effort up front during the design process, making sure that you review all aspects discussed in this article, you will ensure a successful smart card deployment for your organization.
Brian Komar, president of IdentIT Inc, is a principal consultant specializing in PKI consulting engagements. He has authored MCSE Training Kits, Microsoft Prescriptive Architecture Guides, PKI white papers, and is the coauthor of the Microsoft Windows Security Resource Kit. Contact Brian at bkomar@identit.ca.
This article is an excerpt from the book Microsoft Windows Server 2003 PKI and Certificate Security (Microsoft Press, 2004).
© 2008 Microsoft Corporation and CMP Media, LLC. All rights reserved; reproduction in part or in whole without permission is prohibited.