Lesson 3: Using Certificates for Authentication

One of the primary functions of certificates in a PKI is the mutual authentication of a client and a server. This lesson examines two of the most common deployments of certificates for authentication purposes: smart card logon and Web-based authentication.

After this lesson, you will be able to

  • Design the necessary components to support smart card logon and Web authentication using certificates

Estimated lesson time: 40 minutes

Planning Smart Card Logon

Smart card logon provides stronger security than the default authentication process in Windows 2000 because password information isn't transmitted across the network. As a review, Figure 10.23 shows the smart card logon process:

click to view at full size.

Figure 10.23 The smart card logon process

  1. The user starts the logon process by inserting the smart card into the smart card reader and entering the PIN code. The smart card contains the user's public key credentials, private/public key pair, and certificate.
  2. A modified Kerberos Authentication Service Request (PA_PK_AS_REQ) message is sent to the Key Distribution Center (KDC). This request contains the user principal name and time stamp and a copy of the user's certificate. The user's principal name and time stamp are signed by the private key.
  3. The KDC validates the request by verifying the user's certificate and the digital signature with the CA that issued the certificate.
  4. The KDC queries Active Directory to determine the mapping between the certificate included in the PA_PK_AS_REQ and a Windows 2000 security identifier (SID). When it determines the mapping, the KDC issues a Ticket Granting Ticket (TGT) for the corresponding SID.
  5. The KDC sends the TGT back to the user in a modified Kerberos Authentication Service Response (PA_PK_AS_REP). Within the response, the session key is encrypted with the user's public key, ensuring that only the correct user can decrypt the session key.
  6. The user retrieves the session key by decrypting the session key with the private key located on the smart card.

Planning Smart Card Deployment

Take the following steps to ensure that smart cards are integrated successfully into your organization's security model:

  1. Define which users can enroll for the required types of certificates.
  2. Define a CA to issue the required certificates.
  3. Configure a computer and user account to function as the smart card enrollment station and smart card enrollment agent.
  4. Define the physical process for smart card enrollment.

The following sections outline the design decisions you face during each step of the smart card deployment.

Defining Permissions for Certificate Templates

Smart card logon requires the use of several certificate templates. Define security for each of the required templates so that only the desired security groups have the permission to enroll for the required certificates. The required certificates include

  • EnrollmentAgent. The person performing smart card enrollment on behalf of other users requires this certificate. Define the enrollment agent certificate permissions carefully so that only a designated administrator who performs smart card enrollment can acquire an EnrollmentAgent certificate. A user with this certificate might generate a certificate for another user and act as that user on the network.
  • MachineEnrollmentAgent. The computer functioning as the smart card enrollment station requires this certificate. This certificate enables the enrollment station to prove its identity to a remote computer and ensure the identity of a remote computer. The computer account that enrolls for the MachineEnrollmentAgent certificate requires the Read and Enroll permissions for the MachineEnrollmentAgent certificate template.


    You can also use a multipurpose certificate template in place of the MachineEnrollmentAgent certificate as long as you include the ability to provide mutual authentication in the certificate template definition.

  • SmartcardUser. This certificate provides the user with the ability to authenticate with a smart card and to send encrypted e-mail. The enrollment agent and the user account that use the smart card must have Read and Enroll permissions for the SmartcardUser certificate template.
  • SmartcardLogon. This certificate only gives the user the ability to authenticate with the network. The certificate can't be used for other purposes, such as secure e-mail. The intended user account and the enrollment agent account must have both the Read and Enroll permissions to acquire a SmartcardLogon certificate.


A smart card deployment requires either a SmartcardUser or a SmartcardLogon certificate to be issued. The choice of which one is issued depends on whether smart cards are used only for network authentication (SmartcardLogon) or also for e-mail purposes (SmartcardUser). You don't require both certificates to use a smart card on the network.

The permissions for each of the certificate templates is defined in Active Directory Sites And Services by exposing the Services node. You can find the certificate templates in Active Directory Sites and Services\Services\Public Key Services \Certificate Templates.


Don't delete any certificate templates in Active Directory Sites And Services. This action removes the certificate template from your forest and makes it unavailable for all users in the forest. The only way to reinstall the templates is to uninstall and reinstall an Enterprise CA.

Configuring CAs to Issue the Required Certificates

After defining permissions for the required certificate templates, you must configure one or more CAs to issue the certificate templates. By default, CAs don't issue any of the required certificate templates for smart card logon. Only Enterprise CAs can issue the certificate templates. You should select an Enterprise CA that's located near the smart card enrollment station because all requests will be generated at this workstation.

Acquiring the Required Certificates

Once you've defined permissions for the certificates and configured a CA to issue the certificates, the enrollment agent and the enrollment station can acquire their required certificates.

The enrollment agent must acquire an EnrollmentAgent certificate. This certificate gives the user the ability to request certificates on behalf of other users of the network. The EnrollmentAgent certificate can be requested using either the Certificate Services Web page or the Certificates MMC console.

The smart card enrollment station computer requires a MachineEnrollmentAgent certificate to allow the computer to mutually authenticate with the issuing CA to ensure that only an authorized computer performs the smart card request.


For details on the actual deployment of smart card logon, see "Q257480–Certificate Enrollment Using Smart Cards" on the Supplemental Course Materials CD-ROM (\chapt10\Q257480.mht).

Defining the Enrollment Process

You can build security into the smart card certificate distribution process. To ensure that the smart card is issued only to the required user, you can mandate that the user must meet face-to-face with the enrollment agent in order to obtain the card. By issuing smart cards only to validated users, the enrollment agent can define the validation criteria through Web-based questionnaires or personal interviews.

The enrollment process should include safeguards that ensure that only the smart card's user knows the associated PIN. Typically, the enrollment agent allows users to select their own PINs if the users are employees of the company and physically present during the certificate request. If the requestor isn't an employee, the enrollment agent can either reset the initial user PIN through smart card management software or assign a random PIN to each smart card and securely transmit the PIN to the required user.


The organization should also include provisions for what to do when a smart card needs to be reset. In the worst case, you need to plan what to do when a user leaves the smart card at home.

Making the Decision

Use the decision matrix in Table 10.8 to ensure that security is maintained at the highest level during a smart card deployment.

Table 10.8 Planning Smart Card Deployment

To Do the Following
Ensure that only authorized personnel can request certificates required for smart card authentication Configure the DACLs on the required certificate templates to grant Read and Enroll permissions to only authorized users for the certificate templates.

Restrict which CAs are allowed to issue the smart card-related certificates.

Restrict the smart card enrollment process to specific workstations Restrict which computers can Read and Enroll the MachineEnrollmentAgent certificate.

Install smart card readers only at workstations that act as the enrollment station or as workstations for smart card users.

Require smart card users to log on with smart cards Edit the properties of a smart card user to require a smart card for logon. Remember that this could effectively prevent users from accessing the network if they misplace their smart card.
Ensure that only authorized users obtain a smart card Allow smart cards to be issued only during face-to-face meetings.
Define what happens when a smart card is removed from the smart card reader Define the smart card removal action property in Group Policy under Security Options. You can define this policy for the site, domain, or OU.

Applying the Decision

Blue Yonder Airlines won't be able to require face-to-face interviews with Jenny Sax in all instances because their customers reside in many locations on the West Coast of the United States.

To ensure that smart cards are issued only to authorized users, customers must request the cards by filling out an extensive form. Jenny Sax will have to review each request and determine whether to issue a smart card to the customer. If she issues the card, she should send the card, the smart card reader, and the PIN in separate packages to minimize an attacker's ability to intercept the delivery. If an attacker acquires the smart card and the associated PIN, the attacker can act as the user.

For internal requests, such as the requirement for EAP logon over Virtual Private Networks (VPNs), Jenny can require face-to-face meetings before issuing a smart card. This process can be safeguarded by having users show Jenny a form of photo ID to prove their identity.

Planning Certificate-Based Web Authentication

Certificates also can provide authentication through Web services. When a user is connecting to a Web site protected by a Secure Sockets Layer (SSL) protocol, you also can configure the Web site to require certificates for user authentication. This requirement helps prevent a user name and password from being intercepted as they are transmitted across the network. Only the certificate is transmitted across the network.

The Web server receives the certificate and looks either at its own mapping table or at the mapping table in Active Directory to determine the user account associated with (or mapped to) the certificate. The certificate proves the user's identity.

Certificate mapping allows either a single certificate or multiple certificates with similar properties to be mapped to a single user account. These mappings are known as either one-to-one or many-to-one mappings.

Your design for the mapping of certificates to user accounts includes the following decision points:

  • Determine where to perform the mapping. Certificate mapping can be performed in both Active Directory and within the properties of the local Web server. If an administrator performs the mapping in Active Directory, the mapping is available to all other Web servers in the corporate network. If the administrator performs the mapping at the IIS server, the mapping is recognized only at the IIS server. If the same mappings are required at other IIS servers, the mappings must be repeated at each IIS server.
  • Determine the type of mapping to implement. The certificate administrator has the option to perform either a one-to-one or a many-to-one mapping. One-to-one mappings are required whenever users have unique permissions or unique levels of access within a PKI-aware application. If there isn't a requirement to identify each participant in the PKI uniquely, a many-to-one mapping allows multiple certificates to be mapped to a single user account.
  • Ensure that all certificates are issued from trusted root CA hierarchies. The Web servers that you deploy must trust the CAs that issue the certificates to the users. If the certificate isn't from a trusted CA, the Authentication dialog box won't present a certificate to choose for authentication.

When certificate-based authentication is enabled for an IIS Web site, you can change the Web site's authentication configuration to allow only certificate-based authentication. You do this by configuring the supported authentication methods, as shown in Figure 10.24.

Figure 10.24 Restricting authentication to support only smart card authentication

Configuring authentication in this manner prevents IIS from presenting the user with an Authentication dialog box if certificate-based authentication fails. Therefore, only certificates can be used to authenticate users.

Making the Decision

Use the decision matrix shown in Table 10.9 when deciding how to implement account mapping to provide certificate-based authentication for Web applications.

Table 10.9 Mapping Certificates to User Accounts

Choose the Following Account-Mapping Strategy When
One-to-one mappings You must differentiate access levels based on different users.

All users who must access the Web-based application are assigned or will be assigned their own certificates.

Varying levels of access must be granted to the same Web site.

The number of users requiring account mappings is relatively small. You wouldn't want to define one-to-one mappings for a project that supports a million users.

All certificates must be issued by a trusted root CA hierarchy.

Many-to-one mappings All users from the same business unit, partner organization, or department require the same level of access to a Web site.

The certificates involved in the mapping have similar attributes or similar values that can easily be mapped to a single user account.

The CA that issued the certificates is configured as a Trusted Root Certification Authority and all certificates from the CA will be trusted.

You can easily define a set of rules that describe all certificates that will be mapped to the single user account.

All certificates must be issued by a trusted root CA hierarchy.


You can improve the process of performing one-to-one mappings by creating a custom Web enrollment page that automates the mapping process.

In addition to determining what type of mappings to perform, you also must decide where to perform the mappings. The design matrix shown in Table 10.10 will assist you in determining the best location to perform the account mappings.

Table 10.10 Planning Where to Configure Account Mapping

Choose When the Following Conditions Exist
Active Directory mappings The certificate mapping is required for more than one application.

You don't want to define identical certificate mappings at multiple servers.

IIS mappings The IIS server isn't a member of any domain, but rather a member of a workgroup and can't access Active Directory to determine certificate mappings.

Authentication takes place against the IIS server's local account database, rather than against Active Directory.

The account mapping is used only at the IIS server where the mapping is defined.

Applying the Decision

Blue Yonder Airlines requires one-to-one mappings. Even though a large number of user accounts might require certificate mappings, the need for credit card information and personal data confidentiality far outweighs the costs involved in setting up certificates for each individual user.

In addition to creating one-to-one mappings for each user account, Blue Yonder Airlines must determine where to perform the mappings. The easiest place to perform the mappings is in Active Directory. Because each account acquires its certificate from an Enterprise CA, there's no need to redo the same mappings that exist in Active Directory at the IIS server.

If the certificates were acquired from a private CA on the Internet, you might decide to define the certificate mappings at the IIS server. Since the certificates are mapped only to a single smart card, there's no reason to input the data into the IIS server. By using Active Directory, you also ensure that the certificate mappings won't have to be reentered for an additional IIS server if the same certificate mappings are required for separate applications.

Lesson Summary

This lesson described two common methods of authentication. A major part of your security plan will be identifying where certificate-based authentication is used on the network. Identifying who uses PKI-based authentication will make your job easier when you design secure access to the network.

Microsoft Corporation - MCSE Training Kit (Exam 70-220. Designing Microsoft Windows 2000 Network Security)
MCSE Training Kit (Exam 70-220): Designing Microsoft Windows 2000 Network Security: Designing Microsoft(r) Windows(r) 2000 Network Security (IT-Training Kits)
ISBN: 0735611343
EAN: 2147483647
Year: 2001
Pages: 172

flylib.com © 2008-2017.
If you may any questions please contact us: flylib@qtcs.net