you how to plan for enrollment and distribution of certificates, including the use of certificate requests, role-based administration, and auto-enrollment deployment. Next, we’ll discuss how to implement the use of smart cards for authentication within the PKI. You’ll learn what smart cards are and how smart card authentication works, and we’ll show you how to deploy smart card logon on your network. We’ll discuss smart card readers and show you how to set up a smart card enrollment station. Finally, we’ll discuss the procedures for using smart cards to log on to Windows, for remote access and VPNs, and to log on to a terminal server. Planning a Windows Server 2003 Certificate-Based PKI Computer networks have evolved in recent years to enable an unprecedented sharing of information between individuals, corporations, and even national governments.The need to protect this informa- tion has also evolved and network security has consequently become an essential concern of most system administrators. Even in smaller organizations, the basic goal of preventing unauthorized access while still enabling legitimate information to flow smoothly requires the use of more and more advanced technology. In the mid-1990s, Microsoft began developing what was to become a comprehensive security system of authentication protocols and technology based on already developed cryptography stan- dards known as Public Key Infrastructure (PKI). With the release of Windows 2000 Server, Microsoft used various existing standards to create the first Windows-proprietary PKI – one that could be implemented completely without using third-party companies. Windows Server 2003 expands and improves on that original design in several significant ways, which we’ll discuss later in this chapter. Understanding Public Key Infrastructure To understand how a PKI works, you first need to understand what it is supposed to do.The goals of your infrastructure should include the following: ■ Proper authentication ■ Trust ■ Confidentiality ■ Integrity ■ Non-repudiation By using the core PKI elements of public key cryptography, digital signatures, and certificates, all of these equally important goals can be met successfully.The good news is that the majority of the work involved in implementing these elements under Windows Server 2003 is taken care of auto- matically by the operating system and is done behind the scenes. 826 Chapter 24 • Planning, Implementing, and Maintaining a Public Key Infrastructure 301_BD_W2k3_24.qxd 5/13/04 2:12 PM Page 826 The Function of the PKI Most of the functionality of a Windows Server 2003-based PKI comes from a few crucial compo- nents, which are described below. Although there are several third-party vendors, such as VeriSign (www.verisign.com), that offer similar technologies and components, using Windows Server 2003 can be a less-costly and easier-to-implement option – especially for small- and medium-sized companies. Components of the PKI Properly planning for and deploying a PKI requires familiarity with a number of components, including but not limited to the following: ■ Digital Certificates ■ Certification Authorities ■ Certificate Enrollment ■ Certificate Revocation ■ Encryption/Cryptography Services In the following sections, we will discuss each of these in more detail. Understanding Digital Certificates Think of a certificate as a small and portable combination safe.The primary purpose of the safe is to hold a public key (although quite a bit of other information is also held there). Someone you trust must hold the combination to the safe – that trust is the basis for the entire PKI system.The main purpose of certificates is to facilitate the secure transfer of keys across an insecure network. Figure 24.1 shows the properties of a Windows certificate. Notice that the highlighted public key is only part of the certificate. Planning, Implementing, and Maintaining a Public Key Infrastructure • Chapter 24 827 Figure 24.1 A Windows Server 2003 Certificate 301_BD_W2k3_24.qxd 5/13/04 2:12 PM Page 827 User Certificates Of the three general types of certificates found in a Windows PKI, the user certificate is perhaps the most common. User certificates are certificates that enable the user to do something that would not otherwise be allowed.The Enrollment Agent certificate is one example. Without it, even an adminis- trator is not able to enroll smart cards and configure them properly at an enrollment station. Under Windows Server 2003, required user certificates can be requested automatically by the client and sub- sequently issued by a certification authority (discussed below) with no user intervention necessary. Machine Certificates Also known as computer certificates, machine certificates (as the name implies) give the system – instead of the user – the capability to do something out of the ordinary.The main purpose for machine certificates is authentication, both client-side and server-side. As stated earlier, certificates are the main vehicle by which public keys are exchanged in a PKI. Machine certificates are mainly involved with these behind-the-scenes exchanges and are normally overseen by the operating system. Machine certificates have been able to take advantage of Windows’ auto-enrollment feature since Windows 2000 Server was introduced. We will discuss auto-enrollment later in this chapter. Application Certificates The term application certificate refers to any certificate that is used with a specific PKI-enabled appli- cation. Examples include IPSec and S/MIME encryption for e-mail. Applications that need certifi- cates are generally configured to automatically request them and are then placed in a waiting status until the required certificate arrives. Depending upon the application, the network administrator or even the user might have the capability to change or even delete certificate requests issued by the application. Understanding Certification Authorities Certificates are a way to transfer keys securely across an insecure network. If any arbitrary user were allowed to issue certificates, it would be no different from that user simply signing the data. For a certificate to be of any use, it must be issued by a trusted entity – an entity that both the sender and receiver trust. Such a trusted entity is known as a certification authority (CA). In a third-party, or external, PKI, it is up to the third-party CA to positively verify the identity of anyone requesting a certificate from it. Beginning with Windows 2000, Microsoft has allowed the creation of a trusted internal CA – possibly eliminating the need for an external third party. With a Windows Server 2003 CA, the CA verifies the identity of the user requesting a certificate by checking that user’s authentication credentials (using Kerberos or NTLM). If the credentials of the requesting user check out, a certificate is issued to the user. When the user needs to transmit his or her public key to another user or application, the certificate is used to prove to the receiver that the public key inside can be used safely. 828 Chapter 24 • Planning, Implementing, and Maintaining a Public Key Infrastructure 301_BD_W2k3_24.qxd 5/13/04 2:12 PM Page 828 CA Hierarchy For a very small organization, it might be possible under Windows Server 2003 for you to use only one CA for all PKI functions. However, for larger groups, Microsoft outlines a three-tier hierarchical structure starting at the top with a root CA, moving downward to a mid-level CA, and finally an issuing-level CA. Both the mid-level CA and issuing-level CA are known as subordinate CAs. Root CAs When you first set up an internal PKI, no CA exists.The first CA created is known as the root CA, and it can be used to issue certificates to users or to other CAs.As mentioned above, in a large orga- nization there usually is a hierarchy where the root CA is not the only certification authority. In this case, the sole purpose of the root CA is to issue certificates to other CAs to establish their authority. The question then becomes: who issues the root CA a certificate? The answer is that a root CA issues its own certificate (this is called a self-signed certificate). Security is not compromised for two reasons. First, you will only implement one root CA in your organization and second, configuring a root CA requires administrative rights on the server.The root CA should be kept highly secured because it has so much authority. Subordinate CAs Any certification authority that is established after the root CA is a subordinate CA. Subordinate CAs gain their authority by requesting a certificate from either the root CA or a higher-level subor- dinate CA. After the subordinate CA receives the certificate, it can control CA policies and/or issue certificates itself, depending on your PKI structure and policies. How Microsoft Certificate Services Works The Windows Server 2003 PKI does many things behind the scenes.Thanks in part to auto enroll- ment (discussed later in this chapter) and certificate stores (places where certificates are kept after their creation), some PKI-enabled features such as EFS work with no user intervention at all. Others, such as IPSec, require significantly less work than would be required without an advanced operating system. Even though a majority of the PKI is handled by Windows Server 2003, it is still instructive to have an overview of how certificate services work. 1. First, a system or user generates a public/private key pair and then a certificate request. 2. The certificate request, which contains the public key and other identifying information such as user name, is forwarded to a CA. 3. The CA verifies the validity of the public key. If it is verified, the CA issues the certificate. 4. After it is issued, the certificate is ready for use and is kept in the certificate store, which can reside in Active Directory. Applications that require a certificate use this central reposi- tory when necessary. In practice, it isn’t terribly difficult to implement certificate services. Configuring the CA requires a bit more effort, as does planning the structure and hierarchy of the PKI – especially if you Planning, Implementing, and Maintaining a Public Key Infrastructure • Chapter 24 829 301_BD_W2k3_24.qxd 5/13/04 2:12 PM Page 829 are designing an enterprise-wide solution. We’ll cover these topics later in this chapter.You can use the following steps to install Certificate Services in Windows Server 2003. Install Certificate Services 1. After logging on with administrative privileges, click Start | Control Panel, and then click Add/Remove Programs. 2. Click Add/Remove Windows Components, and then check Certificate Services. This selects both sub-components of certificate services, which are Certificate Services CA and Certificate Services Web Enrollment Support. 3. A warning dialog box appear, telling you that after certificate services have been installed, you will not be able to change the machine’s domain membership or change its computer name. Click Ye s to continue. 4. You now must choose the type of CA to establish.You have two decisions to make – that of root vs. subordinate and enterprise vs. standalone (discussed later in this chapter). For this example, click Enterprise root CA and click Next. If you checked the Use custom settings to generate the key pair and CA certificate, you would be prompted to choose a custom cryptographic service provider (CSP), a hash algorithm, and a key length.You could also elect to use an existing key or to use an imported one. 5. The next dialog box presented is the CA Identifying Information box. Enter a common name for the CA. For this example, type My Root CA.The distinguished name suffix is provided by the operating system and is used along with the common name you just typed in to form the distinguished name. Note that you can also change the default five-year validity period of the CA.You can set the validity period as a number of days, weeks, months, or years. Click Next to continue. 6. After the key pair is generated, the Certificate Database Settings dialog box appears. Notice that both the certificate database and certificate database log textboxes are already filled with default values.You may elect to Store configuration information in a shared folder, but do not check it for purposes of this example. Click Next to complete the installation. After Windows Server 2003 has completed its work (you might be notified during this process that the Internet Information Service (IIS) will stop if you have IIS running on this machine), click Finish. During the configuration process, you might be prompted to insert your Windows Server 2003 installation CD or enter the path to the installation files on the hard disk or on a network share.You will also be notified that Active Server Pages (ASP) must be enabled in IIS to provide Web enrollment services. Click Yes to enable ASP. Implementing Certification Authorities Planning a PKI structure that includes multiple CAs in a hierarchy with proper security can be a test in patience and fortitude.The actual implementation, however, is relatively simple. Before we 830 Chapter 24 • Planning, Implementing, and Maintaining a Public Key Infrastructure 301_BD_W2k3_24.qxd 5/13/04 2:12 PM Page 830 talk about the differences between enterprise and stand-alone CAs, and the security concerns involved, we’ll go over the many options you have control over in the following example. Configure a Certification Authority In this example, we’ll explore the different properties you have control over when configuring a CA. We won’t go over all the options now, but we will cover them all in this chapter. 1. Click Start | Administrative Tools | Certification Authority (note that certificate services must be installed before this step – see the example earlier in this chapter; other- wise, this choice will not appear in the Administrative Tools menu). 2. In the left pane of the Certification Authority snap-in, click My Root CA (or whichever CA name you have listed) and expand it.This is where you can view revoked and issued certificates, pending and failed certificates, and certificate templates (discussed later in this chapter). 3. Highlight My Root CA and right-click it. Click Properties. Figure 24.2 shows the General tab. Here, all installed CA certificates are listed as well as the CSP and hash algo- rithms used. Click View Certificate if you want to see the certificate itself. 4. Click the Policy Module tab. A policy module defines how the CA handles incoming certificate requests. Notice that the Windows default policy is listed.The Select button is used to choose a different policy module, usually a customized version. Click the Properties button.The default setting tells the CA to follow the settings in the certificate template if applicable and to automatically issue the certificate otherwise.The other setting tags all incoming requests to pending status, forcing the administrator to manually approve or deny each certificate request. Keep the default setting and click OK to return to the CA property sheet. Planning, Implementing, and Maintaining a Public Key Infrastructure • Chapter 24 831 Figure 24.2 General Tab of the CA Property Sheet 301_BD_W2k3_24.qxd 5/13/04 2:12 PM Page 831 5. Click the Exit Module tab. Whereas a policy module defines how a CA handles incoming certificate requests, an exit module defines what a CA does with certificates that it issues.The Windows default policy is listed. In addition to the Add and Remove but- tons, there is a Properties button. Click the Properties button.The only setting is to allow certificates to be published to the file system if a certificate template dictates, which the default policy does not allow. Again, keep the default setting and click OK to return to the CA property sheet. Skip the Extensions tab for now; we’ll discuss it when we talk about certificate revocations later in the chapter. 6. Click the Storage tab. Note that the default settings cannot be changed because Active Directory is being used. We’ll discuss more about the relationship between Active Directory and enterprise CAs later in this chapter. 7. Click the Certificate Managers Restrictions tab.The default setting here tells the CA to not restrict certificate managers. As an administrator, you can designate certificate man- agers by giving them the Issue and Manage Certificates permission. By changing the default, you can specifically restrict the users, groups, and computers over which a certifi- cate manager has control. 8. Click the Auditing tab. As seen in Figure 24.3, there are many events that you can mon- itor – each concerned with a different aspect of security. Especially important are the Change CA configuration, Change CA security settings, and Issue and manage certificate requests events. Skip the Recovery Agents tab; we’ll cover it during our dis- cussion of key archival and recovery. 9. Click the Security tab.The Security tab, shown in Figure 24.4, enables you to grant or deny access to users over several key areas of the CA. Note that the Issue and Manage Certificates permission denotes a certificate manager, whereas the Manage CA permission gives authoritative access to the entire CA. Click Cancel to return to the CA snap-in. 832 Chapter 24 • Planning, Implementing, and Maintaining a Public Key Infrastructure Figure 24.3 Auditing Tab of the CA Property Sheet 301_BD_W2k3_24.qxd 5/13/04 2:12 PM Page 832 Analyzing Certificate Needs within the Organization You’ve just concluded a tour of most of the properties associated with a CA, but knowing what you can do does not mean that you know what you should do.To find out more about what you should do, you need to analyze the certificate needs of your organization and then move on to create an appropriate CA structure. When designing a PKI/CA structure, you need to understand the different uses for certificates and whether your organization needs to use certificates for different purposes. Examples include SSL for a secure Web server, EFS for encryption of files, and S/MIME for encryption of e-mail mes- sages.The use of S/MIME might dictate that your CA hierarchy has a trust relationship with external CAs, and the use of SSL might lead you to implement a stand-alone CA instead of an enterprise CA.Thus, analyzing these needs before you implement your PKI can save you a lot of time and trouble. Determining Appropriate CA Type(s) For most administrators, the most significant factor in designing a CA structure is the amount of PKI-reliant traffic on the network. If you run a small organization without an Internet presence, for example, a single-root CA that issues certificates directly to users will probably fit the bill. However, in a larger organization, a CA hierarchy is likely to be more appropriate. The first choice when determining appropriate CA types for your PKI is how many subordina- tion levels to use. One level, the root, is of course required.Two, three, and even four subordination levels are relatively common, but the three-tier model is the one most referenced and most-fre- quently used. So how does the three-tier model work? We’ve discussed previously the differences between a root CA and a subordinate CA and that a root CA issues certificates to the second-tier subordinates. In the standard three-tier model, the root CA has the job of issuing certificates to the Planning, Implementing, and Maintaining a Public Key Infrastructure • Chapter 24 833 Figure 24.4 Security Tab of the CA Property Sheet 301_BD_W2k3_24.qxd 5/13/04 2:12 PM Page 833 second-tier.That’s all it really does. Certainly it has the capability of doing more – it could even issue certificates to users. However in a large company, the amount of traffic generated by even a few PKI-aware applications could easily overwhelm a single CA. Also, if you shift the responsibility of issuing certificates to subordinate CAs, you can take the root CA offline – meaning that you detach it from the network entirely.This provides a very high level of security, because attackers have no way of getting to the machine. When a subordinate CA requires a certificate from the root, you can either briefly connect the root CA to the network and then remove it again, or you can lit- erally use a floppy disk. The intermediate level of CAs, the one just below the root, has the responsibility for controlling certificate policy and issuing certificates to the bottom-level CAs.These bottom-level CAs are the ones that actually issue certificates to users, machines, and applications.The question then becomes: why don’t the intermediate CAs just issue the user certificates directly? The answer is that although they can, it just isn’t as scalable as the three-tier model. It is easier to add CAs to the hierarchy that are concerned only with issuing certificates and not involved with policies such as key length and CSP choice. After you have determined the hierarchical structure of your CAs, you will need to determine which CAs are set up as enterprise CAs and which ones are set up as stand-alone CAs before implementing them.You may recall that in the example earlier in this chapter you installed certifi- cate services and chose an enterprise root CA.The choice in your network will depend on several different factors, such as your needed level of security. Both enterprise and stand-alone CAs have advantages and disadvantages. We’ll explore some of them in the following sections. Enterprise CAs An enterprise CA is tied into Active Directory and is required to use it. In fact, a copy of its own CA certificate is stored in Active Directory. Perhaps the biggest difference between an enterprise CA and a stand-alone CA is that enterprise CAs use Kerberos or NTLM authentication to validate users and computers before certificates are issued.This provides additional security to the PKI because the validation process relies on the strength of the Kerberos protocol and not a human administrator. Enterprise CAs also use templates, which are described later in this chapter, and they can issue every type of certificate. There are also several downsides to an enterprise CA. In comparison to a stand-alone CA, enterprise CAs are more difficult to maintain and require a much more in-depth knowledge about Active Directory and authentication.Also, because an enterprise CA requires Active Directory, it is nearly impossible to remove it from the network. If you were to do so, the Directory itself would quickly become outdated – making it difficult to resynchronize with the rest of the network when brought back online.This forces an enterprise CA to remain attached to the network, leaving it vul- nerable to attackers. Stand-Alone CAs Stand-alone CAs do not require Active Directory (although they can use AD information if it is available), and are usually used as either secure root CAs or as an issuer to such applications as stand- alone Web servers. Stand-alone CAs are generally not suitable for enterprise-type applications. 834 Chapter 24 • Planning, Implementing, and Maintaining a Public Key Infrastructure 301_BD_W2k3_24.qxd 5/13/04 2:12 PM Page 834 Because certificate templates are not used on a stand-alone CA, a standalone is more basic and easier to maintain than an enterprise CA. A stand-alone CA keeps a copy of its CA certificate in a shared folder and if Active Directory is not used, users that need to request certificates need to know the location of the CA. Finally, stand-alone servers can be secured by removing them from the network. The disadvantages to a stand-alone CA are that an administrator must manually approve or deny every certificate request individually; a stand-alone CA cannot issue log-on certificates; and tem- plates cannot be used with a stand-alone CA, so a key recovery agent cannot be established (we dis- cuss the key recovery agent template below). Planning the CA Hierarchy There is more than meets the eye when planning a CA hierarchy. We’ve already discussed choices you will need to make between root and subordinate and between enterprise and standalone.You will also need to consider possible cross-trust hierarchies and the establishment of the key recovery agent. Cross-Trust Hierarchies For a PKI entity to use a certificate provided by a CA, the entity must trust that CA.This trust is established when the entity has a copy of the CA’s certificate located in its local certificate store. Using the public key contained in the certificate, the entity can verify the CA’s digital signature. How, then, does the certificate get from the CA to the entity’s local store? Unfortunately, there is not just one answer. Group policies under Active Directory, preloaded certificates in Windows Server 2003, and downloads from the Windows Update Web site are the most common ways. The chain of trust from an issuing CA all the way up to the root CA must be verified by an entity requesting a certificate for the certificate to be accepted. In a small, local network operation this is easy to accomplish. However, when your organization must exchange data with external par- ties, there needs to be a way to recognize and trust a third-party CA as if it were a part of your local chain of trust.There are two ways to do this: ■ You can use a certificate trust list, or CTL. ■ You can create a cross-trust hierarchy, which enables an external CA to be viewed as a subordinate CA in your local trust chain. Using a CTL or a cross-trust hierarchy under previous versions of Windows presented a central problem. When an external CA gained trust status, every certificate issued by it and all of its subordi- nate CAs were automatically trusted. New to Windows Server 2003 is a feature called qualified subordi- nation. Qualified subordination enables you to specify how many subordinates can be trusted and it also enables you to specify the purposes of certificates that can be accepted from the external CAs. Key Recovery Agent As when a person has locked his or her keys inside the car, lost encryption keys in a PKI can be troublesome. Luckily, Windows Server 2003 provides a locksmith of sorts (called a Registration Authority, or RA) that earlier versions of Windows did not have. A key recovery solution, however, is not easy to implement and requires several steps.The basic method follows: Planning, Implementing, and Maintaining a Public Key Infrastructure • Chapter 24 835 301_BD_W2k3_24.qxd 5/13/04 2:12 PM Page 835 . version. Click the Properties button .The default setting tells the CA to follow the settings in the certificate template if applicable and to automatically issue the certificate otherwise .The other setting tags. the name implies) give the system – instead of the user – the capability to do something out of the ordinary .The main purpose for machine certificates is authentication, both client-side and server- side possibly eliminating the need for an external third party. With a Windows Server 2003 CA, the CA verifies the identity of the user requesting a certificate by checking that user’s authentication credentials