The Best Damn Windows Server 2003 Book Period- P87

Chia sẻ: Cong Thanh | Ngày: | Loại File: PDF | Số trang:10

Thêm vào BST

Báo xấu

56
lượt xem 3
download

Download Vui lòng tải xuống để xem tài liệu đầy đủ

The Best Damn Windows Server 2003 Book Period- P87:The latest incarnation of Microsoft’s server product,Windows Server 2003, brings many new features and improvements that make the network administrator’s job easier.This chapter will briefly summarize what’s new in 2003 and introduce you to the four members of the Windows Server 2003 family: the Web Edition, the Standard Edition, the Enterprise Edition, and the Datacenter Edition.

Chủ đề:

Bình luận(0) Đăng nhập để gửi bình luận!

Lưu

Nội dung Text: The Best Damn Windows Server 2003 Book Period- P87

836 Chapter 24 • Planning, Implementing, and Maintaining a Public Key Infrastructure 1. Create an account to be used for key recovery. 2. Create a new template to issue to that account. 3. Request a key recovery certiﬁcate from the CA. 4. Have the CA issue the certiﬁcate. 5. Conﬁgure the CA to archive certiﬁcates by using the Recovery Agents tab of the CA property sheet (shown in Figure 24.5). 6. Create an archive template for the CA. Figure 24.5 Recovery Agents Tab of the CA Property Sheet Each of these steps requires many substeps, but can be well worth the time and effort. It is worth noting again that key recovery is not possible on a stand-alone CA, because a standalone cannot use templates. It is also worth noting that only encryption keys can be recovered – private keys used for digital signatures cannot be. Planning CA Security As we have already discussed, conﬁguring the root CA as a standalone is probably the most impor- tant measure you can take to prevent accidental or intentional tampering. With no network connec- tivity, attacks become virtually impossible, as a user would have to log on while sitting at the physical location of the server. Other security considerations are really more a function of general server security – things such as requiring complex passwords, implementing ﬁle encryption and physically limiting access to the server. In guarding the hierarchy, you cannot solely concentrate on the root CA. After all, if a subordi- nate CA is tampered with, every entity below it in the PKI hierarchy becomes compromised. Most
Planning, Implementing, and Maintaining a Public Key Infrastructure • Chapter 24 837 subordinate CAs are attached to the network.This obviously increases their vulnerability. Beyond securing the network itself (by using IPSec and group policies, for example), there is another part of a standard PKI that helps maintain CA integrity.That part is certiﬁcate revocation, which we will go into in greater detail shortly. Certiﬁcate revocation enables an administrator to warn PKI clients about certiﬁcates that might not be authentic or that might have been issued by a rogue CA. Disaster recovery applies to every CA in the hierarchy, but especially at the root.That being said, the importance of performing proper backups cannot be overstated. Certiﬁcate Revocation A CA’s primary duty is to issue certiﬁcates, either to subordinate CAs or to PKI clients. However, each CA also has the capability to revoke those certiﬁcates when necessary.The tool that the CA uses for revocation is the certiﬁcate revocation list, or CRL.The act of revoking a certiﬁcate is simple: from the Certiﬁcation Authority console, simply highlight the Issued Certiﬁcates container, right-click the certiﬁcate and choose All | Revoke Certiﬁcate.The certiﬁcate will then be located in the Revoked Certiﬁcates container. When a PKI entity veriﬁes a certiﬁcate’s validity, that entity checks the CRL before giving approval.The question is: how does a client know where to check for the list? The answer is the CDPs, or CRL Distribution Points. CDPs are locations on the network to which a CA publishes the CRL; in the case of an enterprise CA under Windows Server 2003, Active Directory holds the CRL and for a standalone, the CRL is located in the certsrv\certenroll directory. Each certiﬁcate has a location listed for the CDP, and when the client views the certiﬁcate, it then understands where to go for the latest CRL. Figure 24.6 shows the Extensions tab of the CA property sheet, where you can modify the location of the CDP. Figure 24.6 Extensions Tab of the CA Property Sheet For a CA to publish a CRL, use the Certiﬁcation Authority console to right-click the Revoked Certiﬁcates container and choose All Tasks | Publish. From there, you can choose to publish either a complete CRL or a Delta CRL.
838 Chapter 24 • Planning, Implementing, and Maintaining a Public Key Infrastructure Whether you select a New CRL or a Delta CRL, you are next prompted to enter a publication interval (the most frequent intervals chosen are one week for full CRLs and one day for Delta CRLs). Clients cache the CRL for this period of time and then check the CDP again when the period expires. If an updated CDP does not exist or cannot be located, the client automatically assumes that all certiﬁcates are invalid. Planning Enrollment and Distribution of Certiﬁcates For a PKI client to use a certiﬁcate, two basic things must happen. First, a CA has to make the cer- tiﬁcate available and second, the client has to request the certiﬁcate. Only after these ﬁrst steps can the CA issue the certiﬁcate or deny the request. Making the certiﬁcate available is done through the use of certiﬁcate templates and is a topic that we discuss in detail below. As for the client, there are three methods of requesting certiﬁcates – all three of which are essential to a thorough under- standing of PKI: auto-enrollment, the Certiﬁcates snap-in, and the Certiﬁcates web page. We will discuss each in more detail in the section titled Certiﬁcate Requests. Certiﬁcate Templates A certiﬁcate template deﬁnes the policies and rules that a CA uses when a request for a certiﬁcate is received. Many built-in templates can be viewed using the Certiﬁcate Templates snap-in (see Figure 24.7).The snap-in can be run by right-clicking the Certiﬁcate Templates container located in the Certiﬁcation Authority console and clicking Manage.You can use one of the built-in templates or create your own. Figure 24.7 Certiﬁcate Templates Snap-In When creating your own template, you have multiple options that will guide the CA in how to handle incoming requests.The ﬁrst step in the creation process is to duplicate an existing template.
Planning, Implementing, and Maintaining a Public Key Infrastructure • Chapter 24 839 You do this by using the Certiﬁcate Templates snap-in, then right-clicking the template you wish to copy and selecting Duplicate Template. On the General tab that appears by default, there are time- sensitive options such as validity period and renewal period. Note the default validity period of one year and the default renewal period of six weeks.There are also general options such as the template display name and a check box for publishing the certiﬁcate in Active Directory. The Request Handling tab, shown in Figure 24.8, has options including minimum key size and certiﬁcate purpose.The certiﬁcate purpose can be encryption, signature, or signature and encryption.There is also an option to allow the export of the private key. Finally, you can instruct the CA how to act when the subject’s request is received and which CSPs to use. Figure 24.8 Request Handling Tab of the New Template Property Sheet The Subject Name tab seen in Figure 24.9 gives you the choice of obtaining subject name information from Active Directory or from the certiﬁcate request itself. In the latter case, auto- enrollment (which we’ll discuss later in the chapter) is not available. Figure 24.9 Subject Name Tab of the New Template Property Sheet
840 Chapter 24 • Planning, Implementing, and Maintaining a Public Key Infrastructure The Issuance Requirements tab enables you to suspend automatic certiﬁcate issuance by selecting the CA certiﬁcate manager approval check box. The Superseded Templates tab is used to deﬁne which certiﬁcates the current template supersedes. Usually, this tab is used to conﬁgure a template that serves several functions; e.g., IPSec and EFS. In this case, a template used only for IPSec or a template used only for EFS would be placed on the superseded templates list. The Extensions tab, as seen in Figure 24.10, can be used to add such things as the Application Policies extension, which deﬁnes the purposes for which a generated certiﬁcate can be used.The Issuance Policies extension is also worth mentioning, because it deﬁnes when a certiﬁcate may be issued. Figure 24.10 Extensions Tab of the New Template Property Sheet The Security tab is similar to the Security tab that we saw in an earlier example, except that this tab is used to control who may edit the template and who may request certiﬁcates using the template. Figure 24.11 shows the default permission level for the Authenticated Users group. For a user to request a certiﬁcate, however, the user must have at least the Enroll permission assigned to him or her for manual requests and the Autoenroll permission for automatic requests.
Planning, Implementing, and Maintaining a Public Key Infrastructure • Chapter 24 841 Figure 24.11 Security Tab of the New Template Property Sheet After you have conﬁgured a particular template, the CA still cannot use it to issue certiﬁcates until it is made available.To enable a template, use the Certiﬁcation Authority console and right- click the Certiﬁcate Templates container. Selecting New | Certiﬁcate Template to Issue completes the process. Certiﬁcate Requests A client has three ways to request a certiﬁcate from a CA.The most common is auto-enrollment, and we’ll discuss its deployment shortly. A client can also request a certiﬁcate by use of the Certiﬁcates snap-in. Clicking Start | Run and typing in certmgr.msc and pressing Enter can launch the snap-in. Note that the Certiﬁcates snap-in does not appear in the Administrative Tools folder as the Certiﬁcation Authority snap-in does after installing certiﬁcate services. Next, by expanding the Personal container and right-clicking the Certiﬁcates container beneath it, you can start the Certiﬁcate Request Wizard by choosing All Tasks | Request New Certiﬁcate. After the welcome screen, the ﬁrst screen of the wizard enables you to choose the cer- tiﬁcate type.You can only choose a type for which the receiving CA has a template. If you select the Advanced check box, the next screen (Figure 24.12) enables you to choose the Cryptographic Service Provider (CSP) and key length.You can also mark the key as exportable and/or enable strong private key encryption.
842 Chapter 24 • Planning, Implementing, and Maintaining a Public Key Infrastructure Figure 24.12 Cryptographic Service Provider Screen of the Certiﬁcate Request Wizard Continuing with the advanced options, you can choose Browse the domain to choose a CA to which you want to send the request. Finally, the wizard ﬁnishes by prompting you for a friendly name and description for the certiﬁcate.The last method for requesting a certiﬁcate is to use a Web browser on the client machine. Note that if you use this option, IIS must be installed on the CA. Auto-Enrollment Deployment Perhaps the most exciting new feature of the Windows Server 2003 PKI is the capability to use auto- enrollment for user certiﬁcates as well as for computer certiﬁcates.The request and issuance of these certiﬁcates may proceed without user intervention.There are, however, some strict requirements: I Only Windows Server 2003 clients or Windows XP clients can use auto-enrollment. I Windows Server 2003 Enterprise Edition or Datacenter Edition is required to conﬁgure auto-enrollment for version 2 templates. Group policies are used in Active Directory to conﬁgure auto-enrollment. In Computer Conﬁguration | Windows Settings | Security Settings | Public Key Policies, there is a group policy entitled Automatic Certiﬁcate Request Settings.The property sheet for this policy enables you to choose to either Enroll certiﬁcates automatically or not. Also, you will need to ensure that Enroll subject without requiring any user input option is selected on the Request Handling tab of the certiﬁcate template property sheet. Finally, be aware that doing either of the following will cause auto-enrollment to fail: I Setting the This number of authorized signatures option on the Issuance Requirements tab to higher than one. I Selecting the Supply in the request option on the Subject Name tab.
Planning, Implementing, and Maintaining a Public Key Infrastructure • Chapter 24 843 Role-Based Administration PKI administration, which can be as daunting as general network administration, can be divided among various groups or individuals. Microsoft deﬁnes ﬁve different roles that can be used within a PKI to facilitate administration: I CA Administrator I Certiﬁcate Manager I Backup Operator I Auditor I Enrollee At the top of the hierarchy is the CA administrator.The role is deﬁned by the Manage CA per- mission and has the authority to assign other CA roles and to renew the CA’s certiﬁcate. Underneath the CA administrator is the certiﬁcate manager.The certiﬁcate manager role is deﬁned by the Issue and Manage Certiﬁcates permission and has the authority to approve enrollment and revocation requests. The Backup Operator and the Auditor roles are actually operating system roles and are not CA speciﬁc.The Backup Operator has the authority to back up the CA and the Auditor has the authority to conﬁgure and view audit logs of the CA.The ﬁnal role is that of the Enrollees. All authenticated users are placed in this role and are able to request certiﬁcates from the CA. Implementing Smart Card Authentication in the PKI If security is a primary concern for your organization, you might want to consider the use of smart cards for both local and remote authentication.This adds a second level of security to the authenti- cation process. Whereas traditional authentication via password requires only “something you know” (the password), smart card authentication also requires “something you have” (the card). Along with biometric devices such as ﬁngerprint readers and retinal scanners, smart cards repre- sent a more secure way for users to gain access to the network. Smart cards are not as secure as most biometric devices, but they are more widely implemented and have a longer history of use (more than 11 years). In fact, there are many companies that issue smart cards and smart card readers, along with Windows Server 2003-compliant drivers and software. Primarily because of several competing standards, smart card adoption has been slow, but their popularity continues to grow and although they might not replace the standard log-on password anytime soon, smart card technology is full of potential. How Smart Card Authentication Works After setting up an enrollment station (described below), any user with the enrollment agent certiﬁ- cate can issue smart cards to users. Enrollment is the process by which a CA grants a certiﬁcate to the card.The card itself generates a public/private key pair, and the certiﬁcate is used to protect the
844 Chapter 24 • Planning, Implementing, and Maintaining a Public Key Infrastructure public key during transport. After enrollment, the user can insert the card at any workstation on the network, including terminal services clients and remote access clients, as long as a smart card reader is present. If possible, clients logging on to a Windows Server 2003 network will be authenticated with the Kerberos protocol. In traditional authentication, a username and password typed in via the keyboard are used to encrypt communication between the client and the Key Distribution Center (KDC). With smart cards, however, the private key stored in the card digitally automatically signs the timestamp that is sent to the KDC, eliminating the need for a password. In addition to the encrypted timestamp, the card’s certiﬁcate (including of course the card’s public key) is sent as well. When the KDC receives the package, known as a ticket-granting ticket (TGT) request, it veriﬁes the public key and then uses the public key to verify the digital signature on the request. If everything checks out, the server authenti- cates the client by returning a ticket that is also encrypted with the card’s public key. Finally, the ticket is decrypted at the client’s workstation by the private key stored in the smart card. Deploying Smart Card Logon Even though smart cards have been around for some time, many different standards still exist.This can complicate the deployment of a smart card solution, especially if Windows Server 2003 does not natively support the hardware you’ve chosen; in that case, several extra steps are required. Windows Server 2003, out of the box, contains drivers for two companies that manufacture smart cards and readers – Schlumberger and Gemplus. For any other vendor’s equipment, you’ll need to install drivers and the CSP that the vendor uses. The ﬁrst step in deployment is to prepare the appropriate certiﬁcate templates.These templates include the following: I Enrollment agent I Smart card logon I Smart card user certiﬁcates The templates are not enabled by default and require some conﬁguration. The second step is to issue the enrollment agent certiﬁcate. Finally, the smart cards need to be enrolled at the enrollment station. We’ll guide you through the step-by-step deployment process later in this chapter. Smart Card Readers Most smart card readers in today’s market attach to the computer’s USB or serial port. USB equip- ment is strongly recommended if your clients have USB ports. Readers are available in external or internal models, and many cost less than ﬁfty dollars at retail. Readers that are built into a keyboard are also gaining in popularity. Make certain that the readers you choose will read the kind of smart card you plan on issuing.
Planning, Implementing, and Maintaining a Public Key Infrastructure • Chapter 24 845 Smart Card Enrollment Station The enrollment station you choose should be a secure system and must be running Windows 2000 or higher. Of course a smart card reader must be installed, and appropriate drivers and CSPs loaded if necessary. Finally, you should install any vendor-supplied utility software. Using Smart Cards To Log On to Windows Smart cards can be used for more than secure authentication. In fact, there are two different tem- plates in Windows Server 2003 that are both used for smart card certiﬁcates.The ﬁrst is the smart card log-on certiﬁcate, which, as the name implies, is used only for logons.The second is the smart card user certiﬁcate, which, in addition to logons, provides secure e-mail services. For the following example, you’ll use the more common of the two, which is the smart card logon certiﬁcate.You will have to have a PKI implemented with at least one CA already running before beginning.You will also need a smart card reader and a smart card to complete this example. Implement and Use Smart Cards 1. On the system acting as the CA, log on as an administrator and open the Certiﬁcation Authority console by clicking Start | Programs | Administrative Tools | Certiﬁcation Authority. 2. Expand the appropriate CA container, right-click Certiﬁcate Templates, and choose New | Certiﬁcate Template to Issue. 3. Select Smartcard Logon and click OK. Repeat step 2 and select Enrollment Agent and then click OK. 4. Right-click Certiﬁcate Templates and choose Manage.This displays the Certiﬁcate Template snap-in. 5. Right-click the Smartcard Logon template and choose Properties. Click the Security tab. 6. For this example, assign the administrator the role of enrollment agent. Add the Administrator by clicking the Add button. After selecting the Administrator, select the Read and Enroll check boxes. Click OK to ﬁnish. Close the console. 7. Log on to the enrollment station system as an administrator. Click Start | Run, type certmgr.msc, and then click OK.This launches the Certiﬁcates snap-in. 8. Expand the Personal container, right-click Certiﬁcates, and choose All Tasks | Request New Certiﬁcate. Proceed past the Certiﬁcate Request Wizard’s opening screen by click Next. 9. The next screen shows the Certiﬁcate Types screen. Choose Enrollment Agent and click Next. On the next screen, do not type anything in for the Certiﬁcate Friendly Name and Description ﬁelds.These ﬁelds are optional, and you will not use friendly names or their descriptions in this example. Click Next, and then click Finish. A message appears when the certiﬁcate has been issued. Close the console.