Planning a Windows Server 2003 Public Key Infrastructure (PKI)


So you want to install a Windows Server PKI on your network to issue and validate digital certificates? Great idea! But what exactly is a PKI, and what is it made up of? Before getting around to the planning and implementing of the often-misunderstood PKI, you should first have a good idea of what it is and how it works. After you've perused through an introduction to PKI, you then can more efficiently plan for, and subsequently implement, your PKI solution.

Introduction to the Public Key Infrastructure (PKI)

To combat the openness of TCP/IP without losing the functionality of the protocol, PKI has been developed in tandem with TCP/IP as a means of offering security for data sent between hosts on an intranet or on the Internet.

Using encryption, network administrators and security experts can ensure that the data is read only by the intended recipient and that data received has not been tampered with. The analogy of a physical signature and envelopes sealed with wax is an excellent parallel to how PKI is used today. In lieu of your "John Hancock" and sealing wax, you use a digital signature.

A digital signature ensures that the message is from the source it says it's from and that the message hasn't been digitally "steamed open ." In addition to digital signatures, you can implement digital identificationsthus, the digital certificate.

Certificates

What exactly is a digital certificate ? Essentially, it's the electronic version of your passport or employee identification card. It proves that you are who you say you are. This certificate is what ultimately allows you to access resources and data.

Certificates are issued not only to individuals, but also to organizations, businesses, routers, and other entities as a way of controlling and securing data. A digital certificate contains the following information:

  • The user 's name

  • The user's public key

  • Serial number

  • Expiration date

  • Information on the certificate itself

  • Information on the entity (called a certificate authority) that issued the certificate

When secure data is transferred, an electronic seal is inserted into the data through cryptography. When the recipient opens the data, a key verifies that the electronic seal exists and that it has not been tampered with. In addition, the recipient can be assured that the sender of the data is who he says he is.

Traditionally, when you want to send encrypted data to other users, you use your key to encrypt and secure the data. When the recipients want to open the encrypted data, they use their copy of the key to unlock the data. Should others without the key intercept the packets, they cannot decrypt the information. This method of security is not really very secure. The problem is that when unauthorized users gain access to the key, they gain access to the datanot unlike discovering your house keys in the outside lock of your door.

Digital certificates, however, use a slightly different method of locking and unlocking the data. With digital certificates, you no longer have to make copies of keys for others to unlock your data. Digital certificates use a private key to lock the data and then a different key, the public key, to unlock the data. No longer is the same key used to lock and unlock data.

With this two-key technology, your private key remains private. No one but the rightful owner should ever have access to it. However, by means of the digital certificate, you can disperse the public key to whoever may need it.

When Dick wants to send a private message to Jane, for example, Dick uses Jane's public key to encrypt the message. No one other than Jane can decrypt the message, but now the private key, Jane's key, is required to unlock the contents. When Jane responds to Dick, she can use Dick's public key to encrypt the response. Dick then uses his own private key to unlock the message.

Certificate Authorities (CAs)

All certificates are issued by a CA, such as VeriSign or one internal to your own network. The CA verifies that the owner of the certificate is who he says he is. A CA is a trusted third party that is responsible for physically verifying the legitimacy of the identity of an individual or organization before issuing a digital certificate. A CA is also responsible for issuing certificates, revoking certificates, and publishing a list of revoked certificates.

With Windows Server 2003, you can use a third-party CA, or you can create your own CA through Microsoft's Windows Server 2003 Certificate Services, which offers four distinct types of CAs: Enterprise Root CA, Enterprise Subordinate CA, Standalone Root CA, and Standalone Subordinate CA. We take a closer look at these types of CAs throughout the chapter.

If you elect to create an internal CA for your organization, you need to establish some rules and guidelines to verify that users are employees . You can use Social Security numbers , employee badges, or an even more secure methodsmart cards, which allow users to log in and access and send data, such as email and data on a network.

The Enterprise CA

A Windows Server 2003 Enterprise CA provides certificates for the internal security of an entire organization, whereas an external CA (such as VeriSign) provides security for external security needs. Microsoft provides support for both, and you can mix and match to fit your business needs.

If users request a certificate in a Windows Server 2003 environment, their user accounts can act as the credentials for the user because they are logged on and recognized in the Active Directory.

A Windows Server 2003 Enterprise CA has five key characteristics:

  • The CA server may run on any Windows Server 2003 server in the domain. You should plan for activity, network load, and physical placement of the server for best implementation. Note that you cannot use a Windows Server 2003 Web Edition server as a Certificate Authority.

  • Because the CA name is integrated into the certificates it assigns , the name of the server should be determined before implementing CA services.

  • The Enterprise CA Authority is integrated into the Active Directory.

  • When you've installed an Enterprise CA, a policy module is created. An administrator can edit the policy.

  • Because the CA is crucial for the successful implementation of the PKI, it must have a fault-tolerance scheme and a schedule of regular secure backups .

The Standalone CA

Another type of CA that Windows Server 2003 allows you to install is a Standalone CA . The Standalone CA doesn't require the interaction of Active Directory, but it can use Active Directory if it's available.

A Standalone CA is useful in issuing certificates and digital signatures, and it supports secure email (S/MIME) and Secure Sockets Layer (SSL) or Transport Layer Security (TLS).

A typical Standalone CA has these key characteristics:

  • It doesn't require Active Directory interaction.

  • It can be used with extranets.

  • It doesn't verify the requests for certificates. (All requests are pending until an administrator approves them.)

  • Users requesting a certificate from a Standalone CA must supply all user account information. This information is not required within an Enterprise CA because the user is recognized by the logon account in the Active Directory.

  • No certificate templates are used.

  • Windows Sever 2003 logon credential certificates are not stored on smart cards. Other certificates can be, however.

  • An administrator must distribute the Standalone CA certificate to the Trusted Root Certificate Store.

If Active Directory exists on the network and a Standalone CA can access it, additional options are available:

  • If a domain administrator with write access to Active Directory installs the Standalone CA, the standalone is added to the Trusted Root Certification Authorities Certificate Store. In this situation, you must make certain that the default action of pending requests isn't changed to allow the Standalone CA to automatically approve all requests for certificates. Do not change the default action of pending certificate requests on a Standalone CA.

  • If a domain administrator group member of the parent domain (or an administrator with write access to Active Directory) installs the Standalone CA, the Standalone CA will publish the certificate and the Certificate Revocation list to Active Directory.

EXAM TIP

CA types Ensure that you have a good understanding of the characteristics, abilities , and uses of the four different CA types.


With this brief PKI introduction out of the way, we can now move forward into the planning stages for your Windows Server 2003 PKI implementation.

Initial Planning for the PKI

When you are preparing to install a CA, you should start by planning how to configure your PKI. Windows Server 2003 Group Policy can allow you to publish and revoke certificates directly to user accounts. This feature can allow you to change a user's digital information and enforce it for accessing and retrieving data. Finally, your PKI scheme should include measures for your enterprise to secure email using S/MIME and SSL and/or TLS.

Before you can install the PKI and your first CA, you need to have a plan that addresses these additional questions:

  • What type of CA or CAs do you require?

  • How many CAs total will you require?

  • How long will certificates be valid for?

  • Who will manage the security?

  • Will administrative duties be delegated?

  • How will the CA be monitored ? Who will monitor it?

  • What kind of auditing should be in place for the CA?

  • Where will the CA be located?

  • Will you be using smart cards?

After you've answered these questions and have documented your answers to formulate a plan, you're ready to move into the next stages of planning.

Planning the CA Hierarchies

Windows Server 2003 PKI allows for and encourages a dispersed hierarchy of CAs. Building a tree of CAs allows for scalability with other organizations, internal and external resources, and compatibility with third-party CA implementations .

It might seem to be the ideal solution to have only one CAat least in terms of ease of administration. This, however, is not a realistic solution for many reasons, including size and number of domains and physical locations, along with the number of users who must be serviced by the PKI infrastructure. Each CA hierarchy begins with the Root CA , and multiple CAs branch from this Root CA in a parent-child relationship. The child CAs are certified by the parent CA all the way back to the Root CA. The parent CAs bind a CA public key to the child CA's identity.

In this parent-child relationship, child CAs are trusted by the parent. That parent is, in turn , trusted by its parent CA, all the way back to the originating Root CA. Also in this model, when an organization trusts a CA by adding its certificate in the Trusted Root Certification Authorities Certificate Store, the organization therefore trusts every Subordinate CA in the hierarchy. Should a Subordinate CA have its certificate revoked by the issuing CA, the revoked CA is no longer trustworthy.

Hierarchies serve many purposes. Some of the reasons for creating a CA hierarchy include

  • Varying usages Certificates can be issued for a number of purposes, such as secure email, SSL, and TSL. Different CAs can be responsible for different areas of security.

  • Politics A hierarchy allows for various departments within an enterprise to use unique policies.

  • Geography In a wide area network (WAN) environment, a different CA may be needed in each physical location to save network resources.

  • Security The Root CA requires a very secure environment with fault-tolerant devices. Subordinate CAs do not require the same amount and type of security as the root.

  • Revocation Most organizations need to have the capability to revoke individual CAs rather than be forced to revoke an entire enterprise.

As you're planning your hierarchy, remember that a Root CA is a CA from which all Subordinate CAs branch. This CA should be the most secure and should probably be taken offline (in the case of a Standalone CA) after the installation to ensure the security of the originating certificate and keys. Figure 8.1 illustrates how you might have multiple branching CAs in your organization.

Figure 8.1. You can have certificate authorities arranged in any hierarchical order you require.

Planning Certificate Revocation and Renewal

CAs are not only responsible for issuing and signing digital certificates, but they are also responsible for maintaining an accurate and up-to-date listing of those certificates that are no longer valid and thus should not be trusted. This listing of invalid certificates is known as a Certificate Revocation List (CRL) and is itself digitally signed by the issuing CA to verify its authenticity.

When a certificate is issued, it has a set validity period attached to it, typically five years by default. Under normal circumstances the certificate can be used for this period of time and will cease to be valid automatically should it not be renewed before the expiration date has been reached. Thus, it is only necessary to place certificates that have been revoked early for some reason on the CRL; certificates that have expired (that is, have passed their expiration date) are automatically considered invalid and do not need to be placed on a CRL.

The real decisions that you must make in relation to certificate revocation are, in most cases, limited to determining what circumstances require a certificate revocation and how to publish the CRL. Some organizations might require a certificate to be revoked only when an employee leaves the company, whereas other organizations might require a certificate to be revoked for Acceptable Use Policy (AUP) violations and the like. Also, you may need to change the interval and location to which CRLs are published. You can publish the CRL as often as once per day to any combination of the following locations: Active Directory (the default), a URL for access via a Web browser, or a CRL file that can be transported to a different location.

In direct contrast to certificate revocation, certificate renewal is just as important to your PKI implementation. Will you allow certificates to be renewed after their initial validity period has passed? When will you allow certificates to be renewed? How much of their lifetime must have passed before they can be renewed? Will you be using the same key pair for the renewed certificateallowing users to extend the useable life of their keysor will you require a new key pair to be created for the renewalmaking any previously encrypted information unreadable?

Renewing CAs

In a parent-child relationship between CAs, the parent CA issues a certificate as part of the relationship to designate the child CA. Just like the certificate to a client, the certificate to a Subordinate CA includes a validity period.

When the validity period expires for a CA, its own certificate must be renewed before it can grant any certification requests from client computers. When organizing your PKI, take into account the time a certification in a parent-child relationship should last.

As a safety and security measure, Windows Server 2003 PKI is set up so that a CA cannot issue certificates to requestors that will last beyond its own certificate's expiration date. This measure is handy because it ensures, for example, that a CA scheduled to expire this October cannot issue a certificate that may expire later than October.

Even the Root CA's own certificate will eventually expire. Therefore, certificates that it issues to subordinates will be staggered from its own expiration date. In other words, when the Root CA expires, all Subordinate CAs will have expired as well. No Subordinate CAs are valid beyond the date of the originating CA.

Planning Certificate Template Usage

Windows Server 2003 comes with a wide range of preconfigured certificate templates that can be used to issue a variety of digital certificates. Although you do not need to decide which certificate templates to use before beginning your PKI implementation, you need to be aware of the certificate templates that are available and what purpose they serve. Certain applicationsExchange Server, for examplecannot be installed with full functionality unless certain optional certificate templates are made available first. Table 8.1 outlines the certificate templates that are available for use in Windows Server 2003.

Table 8.1. The Windows Server 2003 Certificate Templates

Template

Purpose

Issued To

Published to AD?

Administrator

Provides for trust list signing and user authentication

User

Yes

Authenticated Session

Allows the user to authenticate to a Web server

User

No

Basic EFS

Allows the user to encrypt data using the Encrypting File System (EFS)

User

Yes

CA Exchange

Provides for key storage areas that are configured for private key archival

Computer

No

CEP Encryption

Allows the computer to act as a registration authority (RA) for Simple Certificate Enrollment Protocol (SCEP) requests

Computer

No

Code Signing

Provides a means to digitally sign software

User

No

Computer

Provides a means for a computer to authenticate itself on the network

Computer

No

Cross-Certification Authority

Used for cross-certification and qualified subordination of CAs

CrossCA

Yes

Directory E-mail Replication

Provides a means to replicate email within Active Directory

DirEmailRep

Yes

Domain Controller

Acts as a general purpose certificate used by domain controllers

DirEmailRep

Yes

Domain Controller Authentication

Allows computers and users to authenticate to Active Directory

Computer

No

EFS Recovery Agent

Allows the user to decrypt files that have been encrypted with EFS

User

No

Enrollment Agent

Allows a user to request certificates on behalf of another subject

User

No

Enrollment Agent (Computer)

Allows a computer to request certificates on behalf of another computer subject

Computer

No

Exchange Enrollment Agent (Offline request)

Allows Exchange Server to request certificates on behalf of another subject and supply the subject name in the request

User

No

Exchange Signature Only

Allows the Microsoft Exchange Key Management Service (KMS) to issue certificates to Exchange users for digitally signing email

User

No

Exchange User

Allows the KMS to issue certificates to Exchange users for encrypting email

User

Yes

IPSEC

Provides a means for a computer to use IP Security (IPSec) to digitally sign, encrypt, and decrypt network communication

Computer

No

IPSEC (Offline request)

Allows IPSec to digitally sign, encrypt, and decrypt network communication when the subject name is supplied in the request

Computer

No

Key Recovery Agent

Provides a means to recover private keys that are archived on the certifice authority

KRA

No

RAS and IAS Server

Provides a means for RAS and IAS servers to authenticate their identity to other computers

Computer

No

Root Certification Authority

Allows the Root CA to prove its identity

CA

No

Router (Offline request)

Allows a router to request a certificate when requested through Simple Certificate Enrollment Protocol (SCEP) from a certificate authority that holds a CEP Encryption certificate

Computer

No

Smartcard Logon

Allows a user to authenticate to the domain using a smart card

User

No

Smartcard User

Provides a means for a user to authenticate and protect email using a smart card

User

Yes

Subordinate Certification Authority

Provides a means to prove the identity of the root certificate authority

CA

No

Trust List Signing

Allows the user to digitally sign a trust list

User

No

User

Provides for users for email, EFS, and client authentication to Active Directory

User

Yes

User Signature Only

Provides a means for users to digitally sign data

User

No

Web Server

Allows a Web server to prove its identity

Computer

No

Workstation Authentication

Allows client computers to authenticate their identity to servers

Computer

No

With your basic PKI planning out of the way, you are now ready to move forward into more specific planning and implementation of your PKI solution.

EXAM TIP

Certificate Templates Don't worry too much about being tested on all the certificate templates Windows Server 2003 provides. This listing is provided primarily for completeness and as a reference for you to use when configuring a CA solution on your network.


Planning Appropriate Certificate Authority Types

Plan a public key infrastructure ( PKI ) that uses Certificate Services.

  • Identify the appropriate type of certificate authority to support certificate issuance requirements.

What exactly are the certificate requirements for your network? Will you be issuing certificates solely for use on your internal private network, or will you need to issue code signing certificates used to digitally sign applications that can be downloaded or otherwise distributed? The uses for digital certificates that you have ultimately determine the type of certificate authorities that you need to implement. Just as a note, CA types and certificate uses are directly related : The type of CA you install determines what your users and computers can do.

As a general review, let's examine each of the four basic CA types again briefly as you plan the needs for your network.

Enterprise Root CA

Recall that the Root CA is at the top of the CA chain, as shown previously in Figure 8.1; this holds true both for Enterprise and Standalone hierarchies. The Enterprise Root CA, then, is at the top of an EnterpriseActive Directorycertificate chain and is at the top of the hierarchy. In short, all other CAs trust this Root CA.

The Enterprise Root CA can issue any type of certificate desired, including those for Subordinate CAs, users, and computers. However, it is usually best (and most commonly implemented) to have the Root CA issuing certificates only to its Subordinate CAs; this preserves the hierarchical nature of the certificate chain and specifies a single point that is "all knowing," so to say.

The Subordinate CAs are then charged with the responsibility of issuing certificates directly to users and computers within the organization. By implementing this parent-child relationship, you can segregate different levels of authority, providing for an overall more robust and secure CA infrastructure.

Because the Enterprise Root CA sits at the top of the certificate chain, it must therefore sign its own certificate, asserting that it is the root of the certificate chain and that all other CAs are to trust it as such.

Enterprise Subordinate CA

The Enterprise Subordinate CA is the child in the parent-child relationship of CAs, as discussed previously. The Enterprise Subordinate CA does require Active Directory to function and can issue certificates to other (lower level) Subordinate CAs, users, and computers, as shown previously in Figure 8.1.

Enterprise Subordinate CAs can be implemented in various locations through the network to provide for increased performance and better load balancing among CAs. You can theoretically have as many Enterprise Subordinate CAs as you want, although practicality dictates that you should have only enough to ensure that all users can connect to a CA that is relatively nearby. Having unnecessary CAs on the network causes a security weakness in that a compromised CA may lead to further network compromises.

Standalone Root CA

Just as the Enterprise Root CA is at the top of the certificate chain in an Active Directory network, the Standalone Root CA is at the top of the chain in a network that might not be using Active Directory. If Active Directory is available, the Standalone Root CA can make use of it, however. Being independent from Active Directory provides the Standalone Root CA the advantage of being able to be removed physically from the network, thus greatly increasing its security.

You can actually use a Standalone Root CA effectively to increase the security of your network by issuing from it those certificates that are very important, such as those for Subordinate CAs and those used by developers for digitally signing applications for distribution.

Standalone Subordinate CA

The Standalone Subordinate CA behaves similarly to the Enterprise Subordinate CAwith one major difference. The Standalone Subordinate CA does not require the presence of Active Directory. Standalone Subordinate CAs are used to issue certificates directly to users; without Active Directory, you have no reason to issue certificates to computers.

IT MATTERS NOT WHAT TYPE OF CA YOU IMPLEMENT

because you must still take the required precautions to ensure that it is as secure as can be. You must ensure first, and foremost, that all your CAs are secure from physical access by unauthorized personnel. A commonly held belief among security administrators is that physical access is the most dangerous threat to any critical server in the network. You therefore should place your CAs in a locked and access-controlled server room. Additionally, you should place them inside locked server cabinets as an added layer of protection.

Of course, physically securing your CAs is of little use should they experience a disaster situation. As with any critical business data, you must ensure that CAs are being backed up regularly using an approved and effective backup plan. The most important part of any CA is the CA's private key. Without this key, the entire CA is useless, and every certificate it has issued will have to be reissued.

Lastly, you should ensure that your network provides adequate protection for the CAs against threats both internal and external. Viruses and other malicious code run rampant today on the Internet, so you must ensure that your network is protected against these threats. You must also implement access controls to prevent unauthorized access to a CA.


At this time, we need to go above and beyond the objectives for this exam so that you gain the required knowledge. Although you won't explicitly see installing and configuring a CA listed in the objectives, understanding all the points made in the following sections is going to be very difficult without your having seen a CA installed and configured first. To that end, we will examine the installation and initial configuration of an Enterprise Root CA in the next section.

WARNING

Internet Information Services (IIS) 6.0 in Windows Server 2003 Unlike IIS 5.0 in Windows 2000 Server, IIS 6.0 is not installed by default in Windows Server 2003, with the exception of Windows Server 2003 Web Edition. If you have not previously manually installed IIS, you need to install it from the Windows Component Wizard under the Application Server option group before you install the Enterprise Root CA.

For best results, you should install IIS before starting the installation of Certificate Services.


Installing and Configuring an Enterprise Root CA

Now that you've reached this point in the chapter, you are really ready to install and perform the basic configuration of your first CA. After you've done this, you can more easily move through the remaining sections of this chapter that relate to PKI. Step by Step 8.1 outlines the process to install an Enterprise Root CA.

You should be aware of the fact that you must provide the following information during the installation of your first CA:

  • CA type You need to indicate the type of CA you will be using.

    • Enterprise Root CA The Enterprise Root CA is the root of all CAs in your hierarchy. Typically, an enterprise has only one. It requires Active Directory. Intermediate Subordinate CAs branch off this server. The Enterprise Root CA can only be a parent.

    • Enterprise Subordinate CA A Subordinate CA must obtain its certificate from a CA higher in the hierarchy. It requires Active Directory. This is the child of another CA. This CA could also be a parent to another CA.

    • Standalone Root CA A Standalone Root CA is like an Enterprise Root CA, except that it does not require Active Directory but can use it if it exists. Often this CA is offline to protect the validity of the originating certificates and keys.

    • Standalone Subordinate CA This CA does not require Active Directory but may use it if Active Directory is available. The Subordinate CA must obtain its certificate from another CA. This is the child in the relationship but may become a parent if it supplies a certificate to another CA.

  • Advanced options If you enable advanced options during the CA installation, you must provide the following:

    • The Cryptographic Service Provider (CSP) The CSP enables you to generate the public and private keys.

    • Key length The longer the key, the more secure the key.

    • Hash algorithm This computation produces a hash value of some piece of data. The default is Secure Hash Algorithm (SHA)-1, which is a 160-bit hash value.

  • CA name You can use just about any character you want. The name you assign the CA will also be the common name (CN) of the CA's distinguished name in Active Directory. Special characters (nonASCII and ASCII punctuation) are stripped out in a sanitized name. Also, remember Active Directory is limited to 64 characters before it truncates names .

  • Organization You must provide the name of your organization as it is known throughout its community.

  • Organizational Unit You must indicate the division this CA manages .

  • City and State or Province You must indicate the city and state or province where the CA is located.

  • Country You need to indicate the X.500 two-character code for your country.

  • Location of the database By default, the database is stored in \%systemroot%\system32\certlog .

  • Shared folder You can create a shared folder for CA information if the CA is not participating in an Active Directory (such as a standalone server).

WARNING

Changing the CA name After you install Certificate Services on the server, you cannot change its name or domain membership without first removing Certificate Services. This is, of course, for a very good reason: Changing either of these items would destroy the CA hierarchy.


STEP BY STEP

8.1 Installing an Enterprise Root CA

  1. Log in to a Windows Server 2003 that is a member of the Active Directory domain with administrative permissions.

  2. From the Control Panel, double-click the Add or Remove Programs applet to open the Add or Remove Programs dialog box.

  3. Click the Add/Remove Windows Components button located on the left side of the Add or Remove Programs dialog box to open the Windows Components Wizard.

  4. Select the Certificate Services option, as shown in Figure 8.2.

    Figure 8.2. You need to select the Certificate Services option to install your CA.

  5. A warning dialog, as shown in Figure 8.3, informs you that you cannot rename the server after installing Certificate Services on it. Click Yes to continue.

    Figure 8.3. You cannot rename this server after installing Certificate Services on it.

  6. Click Next on the Windows Components Wizard dialog box to commence the installation process.

  7. On the CA Type dialog box, shown in Figure 8.4, select the type of CA you are installing. For this example, select Enterprise Root CA and click Next to continue. If you want to customize the key pair settings, you can do so by selecting the Use Custom Settings to Generate the Key Pair and CA Certificate option.

    Figure 8.4. You must select one of the four available types of CAs.

  8. If you selected to customize your key settings, the Public and Private Key Pair dialog box appears next, as shown in Figure 8.5. You have the opportunity to customize the installation by selecting the CSP and the Key Length. You can also use and import an existing certificate and key. Selecting the Allow This CSP to Interact with the Desktop option allows system services to interact with the desktop of the user who is currently logged on. Click Next to continue.

    Figure 8.5. You can specify custom public and private key pair settings during the installation of the CA.

  9. On the CA Identifying Information dialog box, shown in Figure 8.6, enter the common name of the CA. This name should be descriptive but should not contain any special characters. You also need to configure the Validity period; the default value is five years. After entering your selections, click Next to continue.

    Figure 8.6. Your common name should be short and descriptive to provide for easy identification of the CA.

  10. On the Certificate Database Settings dialog box, shown in Figure 8.7, enter the database and log locations or simply use the default selectionsusually the best option in most cases. If you have clients that are not using Active Directory, you may want to specify that the CA maintains a shared folder in which newly created certificates are placed; you can do so by selecting the Store Configuration Information in a Shared Folder option and entering the path of the shared folder. (If you are reinstalling Certificate Services onto a server that has already been a CA, the Preserve Existing Certificate Database option becomes available.) Click Next to continue.

    Figure 8.7. You can specify the location of the database and log files if desired.

  11. If IIS is running on the server, you are prompted to acknowledge that it will be stopped to perform the configuration of the CA. If IIS is not installed, you are prompted to install it before Web Enrollment can be used. Click Yes to acknowledge the warning.

  12. Click Finish to close the Windows Component Wizard. The CA is now ready and available for immediate use.


NOTE

The Key to Security When creating the Root CA, you also need to ensure a long validity period for the public and private key of this CA by using a long key length as a deterrent to hackers who make brute-force attacks. The longer the key, the longer you can use the private and public keys with confidence that the keys have not been compromised.

Microsoft recommends using a key length of at least 2048 bits. There is, however, a trade-off between key length and CA server performance because longer key lengths require more system resources.


With the knowledge of how to install the first CA in hand, you can now move forward into configuring Active Directory for certificate publication.

Configuring Active Directory for Certificate Publication

Configure Active Directory directory service for certificate publication.

By default, the Enterprise CA automatically publishes all certificates directly into Active Directory. As such, there really is no need for any additional configuration in that regard. You can, however, configure two other parts of Certificate Services that deal with the publication of Certificate Revocation Lists (CRLs) and which certificates a user is allowed to submit a new certificate request for.

Recall that a CRL is used to identify all certificates that have been revoked ( canceled ) before their normal end of validity period. The default behavior of an Enterprise Root CA is to publish the CRL to Active Directoryas you might well expect. You can, however, perform some modification of the CRL publishing configuration to suit the needs of your network, as outlined in Step by Step 8.2.

STEP BY STEP

8.2 Configuring CRL Publication Properties

  1. Select Start, Programs, Administrative Tools, Certification Authority to open your Certification Authority management console.

  2. Locate the CA of concern in the CA management console and expand its nodes.

  3. Right-click the Revoked Certificates node and select Properties from the context menu.

  4. The Revoked Certificates Properties dialog box opens, as shown in Figure 8.8. You can configure the CRL publication interval as well as the Delta CRL publication intervalor disable the use of Delta CRLs completely. Click Apply to set your changes.

    Figure 8.8. You can change the default values for CRL publication if you like.

  5. You can view CRLs that have been published by switching to the View CRLs tab, shown in Figure 8.9. You can examine the contents of a specific CRL by selecting it and clicking the View CRL or View Delta CRL button as applicable . After you have finished, click OK to close the Revoked Certificates Properties dialog box.

    Figure 8.9. The Certification Authority management console provides a way to view CRLs.

  6. To change the CRL publication location, right-click the CA name and select Properties from the context menu.

  7. After the CA Properties dialog box opens, switch to the Extensions tab, as shown in Figure 8.10. You can publish to Active Directory, a file system location, and an FTP or HTTP location. Note that not all options are available for each location. After making your configuration change, click OK. You are prompted to stop and restart Certificate Services to make the changes take effect.

    Figure 8.10. You can modify the locations to which the CRL is published from the Extensions tab of the CA Properties dialog box.

  8. After you've configured the CRL publication schedule and location to your liking, you may want to immediately publish the CRL manually to all CRL Distribution Points (CDPs). To manually publish the CRL, right-click again on the Revoked Certificates folder and select All Tasks, Publish. You are asked what type of CRL you want to publish, as shown in Figure 8.11. Select either a New CRL or a Delta CRL and click OK to publish it as you've previously configured.

    Figure 8.11. You can select from either a New CRL or a Delta CRL.


The only other configuration you may want to undertake in regards to certificate publication involves modifying the default configuration of the allowed certificate templates. You may want to perform the following additional actions from within the Certification Authority management console:

  • Specify the types of certificates that each of your CAs can issue. You do so by deleting or adding (as required) certificate templates in the Certificate Templates node of the CA.

  • Configure the Access Control List (ACL) for each template to limit its use to those users you specifically allow. To request a new certificate using a specific template, the user must have the Enroll permission enabled on the certificate template ACL.

EXAM TIP

Publishing the CRL What would you do after revoking a certificate to ensure that it could no longer be used? You would publish the CRL to all CRL Distribution Points, of course! Be on the lookout for scenarios that require you to revoke certificates because publishing the CRL is the next logical step you should complete.


Step by Step 8.3 outlines the process by which you can manage the certificate templates your CA is allowed to issue to your users.

STEP BY STEP

8.3 Managing Certificate Templates Available for Use

  1. Open the Certification Authority management console and expand the nodes under your CA.

  2. Click the Certificate Templates node, which allows you to examine the certificate templates that are currently available for your CA.

  3. To remove a certificate templateand thus prevent that CA from using it to issue new certificatesright-click the certificate template and select Delete from the context menu. Click Yes when prompted to confirm that you really want to remove the certificate template from the CA. Note that the certificate template is not deleted, just removed from use at that time.

  4. To add a new certificate template that is not currently listed, right-click the Certificate Templates node and select New, Certificate Template to Issue from the context menu.

  5. The Enable Certificate Templates dialog box, shown in Figure 8.12, opens allowing you to select the certificate template you want to make available for use. Select the certificate template and click OK. The selected certificate template now shows up in your Certificate Templates node.

    Figure 8.12. You can add additional certificate templates as you require.

  6. If you want to configure the ACL for a certificate template, you need to first open the Certificate Templates console by right-clicking on the Certificate Templates node and selecting Manage.

  7. The Certificate Templates console, new to Windows Server 2003 and shown in Figure 8.13, opens allowing you to configure the properties of all certificate templates installed on your CA.

    Figure 8.13. The Certificate Templates console allows you to manage the properties of your certificate templates from a centralized location.

  8. To modify the ACL of a certificate template, right-click it from within the Certificate Templates console and select Properties from the context menu.

  9. The certificate template Properties dialog box opens. Switch to the Security tab, shown in Figure 8.14, and select the Allow box for the Enroll permission for your users and groups as required. Click OK to close the Properties dialog box when you are done.

    Figure 8.14. You can control who can request a certificate using a specific template by configuring the ACL.


With the discussion of CRL publication and certificate template configuration behind us, we now move on to certificate enrollment and distribution planning.

Planning Certificate Enrollment and Distribution

Plan a public key infrastructure ( PKI ) that uses Certificate Services.

  • Plan the enrollment and distribution of certificates.

With your CA installed and configured, now comes the question of how you will enroll and distribute (install) the newly requested certificates. Depending on the configuration of your network, you can choose from four different certificate enrollment options:

  • Certificate autoenrollment and renewal I mentioned at the beginning of this chapter that a Windows Server 2003 Active Directory domain with Windows XP Professional clients provides the most robust Certificate Services model. This is certainly the case when discussing certificate autoenrollment and renewal. Using these features, you can automatically issue certificates that enable PKI-based applications, such as smart card logon, EFS, SSL, and S/MIME to users and computers within your Active Directory environment. Through a combination of certificate template properties and Group Policy settings, you can opt to enroll computers when they start up and users when they log in to their domain on the network.

  • Certificate Request Wizard/Certificate Renewal Wizard Users of Windows 2000, Windows XP, and Windows Server 2003 computers can manually request certificates through the Certificates MMC snap-in. This snap-in can be added to any custom MMC. Alternatively, you can launch the Certificates console by entering certmgr.msc at the command prompt.

  • Web Enrollment Web pages You can connect to a CA by entering http:// CAname /certsrv in your browser. By default, the Web Enrollment pages, which consist of ASP and ActiveX controls and thus could be considered dangerous, are installed on a CA. You can, however, install these pages on any other Windows Server 2003 computer running IIS that you want. If you're up to it, you can also customize these Web Enrollment pages to suit your specific needs. The Web Enrollment pages provide an easy way to connect clients to your CA without using the Certificates management console. Although Standalone CAs also use the Web Enrollment pages, they cannot provide certificates for smart card logon and for autoenrollmentonly Enterprise CAs. Also, when Standalone CAs are used with Web Enrollment pages, the requester must specifically specify all required information because Active Directory is not available to provide the information for the certificate template. Windows 2000, Windows XP, and Windows Server 2003 computers support the use of Web Enrollment pages.

  • Smart Card enrollment station This is an advanced form of the Web Enrollment pages that allows trusted administrators to request and enroll smart card logon certificates for smart card users on the network. Only Windows XP and Windows Server 2003 computers support this form of enrollment.

Now that you've had a brief introduction into the various means available for your users to request and enroll new certificates, let's examine how the first three are used. Smart cards are discussed in the next section.

Configuring Certificate Autoenrollment and Renewal

As already mentioned, one of the new features of Windows Server 2003 Certificate Services is the concept of autoenrollment for new certificates and automatic renewal for those approved certificates. Through the combination of Version 2 certificate templates and Group Policy settings, Windows XP and Windows Server 2003 computers and their users may automatically request and enroll new and newly renewed certificates at every Group Policy refresh. Group Policy is refreshed during computer startup, user login, and on a configured refresh interval for the network.

If you've ever been responsible for managing a PKI infrastructure, you can quickly appreciate the value in users and computers being allowed to automatically enroll and renew the most commonly used certificate types, such as those for EFS, SSL, smart cards, and S/MIME. Although users must still request the certificates manually, the task of distributing (also referred to as enrolling or installing) an approved certificate occurs automatically, thus saving the PKI administrator time and effort as well as cutting down on the number of mistakes and errors made.

Step by Step 8.4 outlines the process to configure Group Policy for autoenrollment.

STEP BY STEP

8.4 Configuring Certificate Autoenrollment

  1. On a domain controller or domain workstation running the Administration Tools, select Start, Programs, Administrative Tools, Active Directory Users and Computers to open the Active Directory Users and Computers console.

  2. Expand the nodes of your Active Directory forest until you locate the specific site, domain, or Organizational Unit (OU) for which you want to configure certificate autoenrollment.

  3. Right-click the desired location and select Properties from the context menu.

  4. Switch to the Group Policy tab of the Properties dialog box, as shown in Figure 8.15.

    Figure 8.15. You need to select the GPO to be edited or create a new one.

  5. Either select an existing GPO to be edited for certificate autoenrollment options or create a new one as desired.

  6. Within the Group Policy Editor, expand the nodes as follows to configure certificate autoenrollment for computers: Computer Configuration, Windows Settings, Security Settings, Public Key Policies (see Figure 8.16).

    Figure 8.16. Certificate autoenrollment settings are located in the Public Key Policies node.

  7. Double-click the Autoenrollment Settings option and configure computers for autoenrollment as desired, as shown in Figure 8.17.

    Figure 8.17. You need to select the Enroll Certificates Automatically option to enable autoenrollment.

  8. Click OK to close the Autoenrollment Settings Properties dialog box.

  9. If you want to configure certificate autoenrollment settings for users, do so from the User Configuration\Windows Settings\Security Settings\Public Key Policies node of the Group Policy Editor.

  10. To refresh Group Policy immediately, run the gpupdate command from the command prompt. Figure 8.18 shows the update in action as the domain controller has received an autoenrollment certificate, as evidenced by Event ID 19 in the Application log of Event Viewer.

    Figure 8.18. Computers will begin using certificate autoenrollment immediately after the next Group Policy refresh.


Using the Certificate Request Wizard and Certificate Renewal Wizard

Although not as new and fancy as certificate autoenrollment, the Certificate Request Wizard and Certificate Renewal Wizard are effective ways for Windows 2000 computers (as well as Windows XP and Windows Server 2003 computers) to quickly request and renew certificates. Step by Step 8.5 outlines the use of the Certificate Request Wizard to request a new certificate from the CA.

STEP BY STEP

8.5 Requesting a New Certificate with the Certificate Request Wizard

  1. Open the Certificates console by adding it as a snap-in to a custom MMC or by entering certmgr.msc at the command prompt.

  2. Right-click the Personal node and select All Tasks, Request New Certificate, as shown in Figure 8.19, to start the Certificate Request Wizard.

    Figure 8.19. The Certificate Request Wizard allows you to quickly request a new certificate.

  3. Click Next to dismiss the opening page of the Certificate Request Wizard.

  4. On the Certificate Types dialog box, shown in Figure 8.20, select the type of certificate being requested. You can also configure advanced options, including the CSP to be used, by selecting the Advanced check box. Click Next to continue.

    Figure 8.20. You are limited in your request by what certificate templates are available.

  5. On the Certificate Friendly Name and Description dialog box, shown in Figure 8.21, enter a friendly name and description for your certificate to identify it more easily in the future. Click Next to continue.

    Figure 8.21. You should enter a description to help you determine what the certificate is used for.

  6. Click Finish on the Completing the Certificate Request Wizard dialog box to complete the process. If your request was approved, you see the dialog box in Figure 8.22. Click OK.

    Figure 8.22. The process to request a certificate is a very easy one to complete.


Using the Web Enrollment Web Pages

As an alternative, and sometimes more useful, means to request certificates, you can easily allow your clients to use the Certificate Services Web Enrollment pages. Assuming that you have IIS installed on the CAwhich you should do before installing the CA itselfyou can use Web Enrollment by connecting to the CA using the local Internet Web address http:// CAname /certsrv in your Web browser. It is recommended that you use a current version of Internet Explorer because other browsers or older versions do not always work properly.

Step by Step 8.6 outlines the use of the Web Enrollment pages to request a new certificate from the CA.

STEP BY STEP

8.6 Requesting a New Certificate via Web Enrollment

  1. Open a new Internet Explorer window and enter http:// CAname /certsrv in the address bar, where CAname represents the name or IP address of your CA, as shown in Figure 8.23. You may be asked to add this IP address to IE's trusted locations. Additionally, you may also be prompted to supply your network credentials for authentication.

    Figure 8.23. You can request new certificates, check the status of requests, and download the CRL from the Web Enrollment pages.

  2. Click the Request a Certificate Link to request a new certificate. You can, if desired, also check the status of a previous certificate request or download the current CRL from this CA.

  3. To request a basic user certificate, click the User Certificate link, as shown in Figure 8.24. If you want to request any other type of certificate, click the Advanced Certificate Request link. For this example, we want to request a smart card certificate, so click Advanced Certificate Request.

    Figure 8.24. You need to click the Advanced Certificate Request link to request any certificate type other than a user certificate.

  4. On the Advanced Certificate Request page, shown in Figure 8.25, click the Create and Submit a Request to This CA link to continue.

    Figure 8.25. You have several request options available for your selection.

  5. On the Advanced Certificate Request page, shown in Figure 8.26, select the type of certificate being requested and configure its properties as you require. After you have configured your certificate request as desired, click the Submit button located at the bottom of the page.

    Figure 8.26. You can change the key length and several other options using an advanced certificate request.

  6. As part of the enhanced security of Windows Server 2003 (and Windows XP), a warning dialog indicates that a Web page is requesting a certificate on your behalf, as shown in Figure 8.27. This is not a problem unless you see this warning while surfing the Internet! Click Yes to allow this certificate to be requested.

    Figure 8.27. Windows warns you of the fact that a Web page is requesting a certificate for you.

  7. If the request was successfully approved, you are next presented with the Certificate Issued page, as shown in Figure 8.28. Click Install This Certificate to install your new certificate.

    Figure 8.28. You are informed immediately as to the status of your certificate request.

  8. Again, Windows alerts you to the fact that the Web page is attempting to perform some action related to a digital certificate, as shown in Figure 8.29. In this case, the Web page is attempting to install the certificate for you. Click Yes to allow the certificate to be installed.

    Figure 8.29. You are warned again about the Web page's interaction with a certificate.

  9. Your certificate is now installed, and the Web Enrollment pages will reflect this fact.


GUIDED PRACTICE EXERCISE 8.1

In this exercise, you install and configure your first Enterprise CA with a validity period of three years. Your users need to be able to request certificates from their Web browsers. This Guided Practice helps reinforce the preceding discussion.

You should try completing this exercise on your own first. If you get stuck, or you would like to see one possible solution, follow these steps:

  1. Log in to a Windows Server 2003 computer that is a member of an Active Directory domain using an account that has administrative credentials.

  2. Using the Windows Components Wizard, install IIS 6.0 on a Windows Server 2003 computer that is a member of your Active Directory domain.

  3. Using the Windows Components Wizard, start the installation of Certificate Services on the server.

  4. Acknowledge the warning you are presented with about not being able to remain on the server after installing Certificate Services.

  5. Select to install an Enterprise Root CA.

  6. Supply the required identifying information about your CA. Change the validity period to three years.

  7. Provide the locations to store the database and log files.

  8. Acknowledge the warning that IIS will be stopped to complete the installation of the CA.

  9. Finish the Windows Component Wizard.


Planning a Smart Card Solution

Plan a public key infrastructure ( PKI ) that uses Certificate Services.

  • Plan for the use of smart cards for authentication.

EXAM TIP

Smart Card hardware You should not worry about being tested on the information presented in Tables 8.2 and 8.3. It is presented here for completeness and as a reference should you later decide to implement a Smart Card solution.


Introduced for the first time in Windows 2000, smart cards provided an alternativeand securemeans for user authentication. Smart cards are tamper-resistant hardware tokens that can be used to add an additional layer of security to the network. Although smart cards might at first be confused with standard credit cards, they have metallic contacts on them instead of the magnetic stripe found on a credit card. Smart cards also require specially designed readers that are attached to the computer being used for login.

Table 8.2 provides a full listing of the smart card readers that are supported in Windows Server 2003 by default.

Table 8.2. Windows Server 2003Supported Smart Card Readers

Smart Card Reader Brand

Smart Card Reader Model

Attachment Interface

Driver

American Express

GCR435

USB

Grclass.sys

Bull

SmarTLP3

Serial

Bulltlp3.sys

Compaq

Serial reader

Serial

grserial.sys

Gemplus

GCR410P

Serial

Grserial.sys

Gemplus

GPR400

PCMCIA

Gpr400.sys

Gemplus

GemPC430

USB

Grclass.sys

HP

ProtectTools

Serial

Scr111.sys

Litronic

220P

Serial

Lit220p.sys

Omnikey AG

2010

Serial

Sccmn50m.sys

Omnikey AG

2020

USB

Sccmusbm.sys

Omnikey AG

4000

PCMCIA

Cmbp0wdm.sys

Schlumberger

Reflex 20

PCMCIA

Pscr.sys

Schlumberger

Reflex 72

Serial

Scmstcs.sys

Schlumberger

Reflex Lite

Serial

Scr111.sys

SCM Microsystems

SCR111

Serial

Scr111.sys

SCM Microsystems

SCR200

Serial

Scmstcs.sys

SCM Microsystems

SCR120

PCMCIA

Pscr.sys

SCM Microsystems

SCR300

USB

Stcusb.sys

Systemneeds

External

Serial

Scr111.sys

Table 8.3 lists the smart cards that are supported by default in Windows Server 2003.

Table 8.3. Windows Server 2003Supported Smart Cards

Manufacturer

Model

Gemplus

GemSAFE 4k

Gemplus

GemSAFE 8k

Infineon

SICRYPT v2

Schlumberger

Cryptoflex 4k

Schlumberger

Cryptoflex 8k

Schlumberger

Cyberflex Access 16k

Smart cards are used to provide the highest level of user authentication available in Windows Server 2003 networks. For maximum security, a user can use a password or PIN to access the digital certificate on the smart card, thus further protecting the user's identity from rogue applications and attackers . Through the use of on-card digital signatures, smart cards can ensure that a user's private key is never exposed. Perhaps the single best feature of smart cards is that theyunlike software-based private keyscan be moved at will from one computer to another with ease. An administrator can prevent smart cards from being used to access the network after a preconfigured number of incorrect login attempts, protecting them further from dictionary attacksa type of password-guessing attack in which a password is guessed from a list, or dictionary, of common words and phrases.

When implementing a smart card system, you should consider making the following certificate templates available for use. Bear in mind that none of these certificate templates are made available for use by default; you must manually add them to the Certificate Templates node of the certificate authority, as discussed earlier in this chapter in the "Configuring Active Directory for Certificate Publication" section.

  • Enrollment Agent Allows authorized users to request smart card certificates on behalf of other users

  • Smartcard User Allows a smart card user to log on to the network and digitally sign email

  • Smartcard Logon Allows a smart card user the ability to log on to the network

Smart cards can provide you with a great benefitif they are implemented properly in your network. As you might have guessed, that means more planning for you! You should consider the following items during your smart card planning:

  • Smart card distribution requirements

  • Smart card enrollment options

  • Smart card user education

  • Smart card Group Policy options

Smart Card Distribution Requirements

The most difficult aspect of implementing a new smart card system is determining how smart cards will be distributed. What happens if a user has a lost, damaged, or stolen smart card? What about when commonplace occurrences such as name changes, job changes, or department changes occur? All these issues need to be addressed in your smart card issuance and distribution plan. How do you handle these situations for your Windows user accounts? Perhaps you can model your smart card solution in part after your network password solution.

Another critical question that must be answered for smart cards to be a valid solution is how you will ensure that you are giving the correct credentials to the correct person. Will you require users to present validated photo identification such as corporate employee badges or driver's licenses to ensure users really are who they claim to be? What will you do if you have users who are geographically distant from your location? An ideal solution may be to issue blank smart cards to authorized users and then let them autoenroll (and thus install) the certificate to their smart card. In this way, only the authorized user has access to the smart card and the PIN required to access it. Your smart card distribution solution will be unique to the needs and organization of your company but in any case must ensure that the security of the smart card program is maintained at all times.

Although these things may not seem as though they should be part of the distribution planning, you must also ensure that you have adequately planned for public key length values, certificate validity periods, and certificate renewal policies. Be aware, however, that the memory capacity of the smart card you use can dictate the length of the public key; larger, more secure public keys require larger amounts of storage space, as you might imagine.

EXAM TIP

Smart Card enrollment Make sure you understand the basic options available to you related to Smart Card distribution and user enrollment.


Smart Card Enrollment Options

As briefly mentioned previously, you need to ensure you have a method in place to actually enroll the smart card certificates that will be required. You can choose from two basic options when you want to enroll smart card certificates:

  • Use an enrollment agent . The use of an enrollment agent allows a trusted administrator to process all smart card certificate requests and ensures that smart cards and their certificates are created and installed properly. Although this can be a good thing from a user's point of view, it can quickly become an overwhelming task if too few enrollment agents are designated.

  • Allow self-enrollment by smart card users . Although using enrollment agents is usually the best (and by far the most secure) method to enroll smart cards, in some cases you may need or want to have users perform this task themselves . In cases in which you cannot physically (and safely) distribute fully ready smart cards, you may want to consider issuing blank smart cards and allowing the users to self-enroll. Should you think that self-enrollment is completely insecure , recall that you can configure your CA to hold all new requests pending a manual administrative approval, thus allowing you a chance to examine and validate the request before allowing the smart card to be enrolled with its certificate.

Smart Card User Education

What would any security plan be without a good dose of user education? Smart cards are still a rather esoteric feature in the majority of networks today; therefore, you should take steps to ensure that your users thoroughly understand what a smart card is, how it works, and what it provides for the network. Although not an all-inclusive listing, the following points should definitely be in your user education plan for a new smart card implementation.

  • Ensure that users understand what special hardware and/or software they need to use their smart cards properly.

  • Ensure that users know where to get this hardware and/or software. Additionally, ensure users know who to contact when they run into problems with their smart cards.

  • Ensure that users understand that smart cards need to be protected from scratching, chipping, denting, and other forms of damage on the external chip area. These sorts of damages can prevent the card from being read properly, rendering it unuseable.

  • Ensure that users understand that the card should not be exposed to temperature extremes, direct sunlight, or magnetic sourcesas with any form of magnetic media.

  • Ensure that users are instructed not to fold, spindle, or mutilate (yes, I had to say this!) their smart cards. Smart cards are fairly rugged, but they contain several internal components that can be broken by slipping the smart card into a back pocket, using the smart card to open a locked door (yes this happens), or performing other abusive actions.

NOTE

Form of a Smart Card Without really thinking about it, you have most likely already been using a Smart Card in one way or another. ATM cards, building and parking garage access cards, and other cards with magnetic stripes are all just different forms of a Smart Card.


Smart Card Group Policy Options

When you are using smart cards for increased security of your network, you can configure several Group Policy options to further enhance the security of your smart card implementation:

  • Interactive logon: Require smart card This option, located in the Computer Configuration\Windows Settings\Security Settings\Local Policies\Security Options node of the Group Policy Editor can be used to prevent users from logging in to the domain by using a standard Windows username and password. Although this setting provides enhanced security, it can leave users without network access if their smart cards become unavailable for any reason. You should apply this policy at the OU level, making each smart card user a member of a domain local group and placing that group within the OU. Mistakenly applying this setting to non-smart card users will have disastrous effects.

  • Interactive logon: Smart card removal behavior This option, also located in the Security Option node, can be used to define what Windows should do when a smart card is removed from its reader with the user logged in. Possible options include No Action, Lock Workstation, and Force Logoff. This option again presents both benefits and dangers. A user who mistakenly removes her smart card with open documents may well lose any changes made since the document was last saved. On the other hand, for computers located in kiosks or other insecure areas, this setting can greatly increase the security of the computer and your network. This Group Policy setting requires training on your part to ensure that your smart card users understand the consequences of their actions. Again, this setting should be configured on an OU containing only those users who have been issued smart cards.

  • Do not allow smart card device redirection This option, located in the Computer Configuration\Administrative Templates\Windows Components\Terminal Services\Client/Server data redirection node of the Group Policy Editor, can be used to prevent users from logging in to a Terminal Server with a smart card. This can increase security and decrease loading on your Terminal Servers.

  • Account Lockout Policy The Account Lockout Policy node, located at Computer Configuration\Windows Settings\Security Settings\Account Policies\Account Lockout Policy in the Group Policy Editor, contains three useful Group Policy settings that you can use to enhance both smart card and standard Windows logins. The Account Lockout Threshold setting can be configured to specify how many failed logon attempts should be allowed before that user account is locked out. The Account Lockout Duration setting specifies how long the account is to be locked out (barring an administrator's unlocking the account early). The Reset Account Lockout Counter After option specifies how much time must pass before failed logon attempts are no longer counted against the Account Lockout Threshold setting. These policies are typically applied at a high level in your organization, such as the root of a domain to cause them to apply to all users within the domain.



MCSE Windows Server 2003 Network Infrastructure (Exam 70-293)
MCSE 70-293 Exam Prep: Planning and Maintaining a Microsoft Windows Server 2003 Network Infrastructure (2nd Edition)
ISBN: 0789736500
EAN: 2147483647
Year: 2003
Pages: 151
Authors: Will Schmied

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