Windows Server 2008 R2 Unleashed (93 page)

14

Reviewing the Certificate Authority Roles in AD CS

AD CS for Windows Server 2008 R2 can be installed as one of the following CA types:

.
Enterprise root certification authority—
The enterprise root CA is the most

trusted CA in an organization and should be installed before any other CA. All other

ptg

CAs are subordinate to an enterprise root CA. This CA should be highly physically

secured, as a compromise of the enterprise CA effectively makes the entire chain

compromised.

.
Enterprise subordinate certification authority—
An enterprise subordinate CA

must get a CA certificate from an enterprise root CA but can then issue certificates to

all users and computers in the enterprise. These types of CAs are often used for load

balancing of an enterprise root CA.

.
Standalone root certification authority—
A standalone root CA is the root of a

hierarchy that is not related to the enterprise domain information. Multiple stand-

alone CAs can be established for particular purposes. A standalone root CA is often

used as the root for other enterprise subordinate CAs to improve security in an envi-

ronment. In other words, the root is configured as standalone, and subordinate

enterprise domain integrated CAs are set up within the domains in a forest to

provide for autoenrollment across the enterprise.

.
Standalone subordinate certification authority—
A standalone subordinate CA

receives its certificate from a standalone root CA and can then be used to distribute

certificates to users and computers associated with that standalone CA.

446

CHAPTER 14

Transport-Level Security

CAUTION

Making decisions about the structure of AD CS architecture is no small task, and

should not be taken lightly. Simply throwing AD CS on a server as an enterprise CA and

letting it run is not the best approach from a security perspective, as compromise of

that server can have a disastrous effect. Subsequently, it is wise to carefully consider

AD CS design before deployment. For example, one common best practice is to deploy

a standalone root CA, then several enterprise subordinate CAs, and then to take the

standalone root CA physically offline and secure it in a very safe location, only turning it

on again when the subordinate CAs need to have their certificates renewed.

Detailing the Role Services in AD CS

AD CS is composed of several role services that perform different tasks for clients. One or

more of these role services can be installed on a server as required. These role services are

as follows:

.
Certification Authority—
This role service installs the core CA component, which

allows a server to issue, revoke, and manage certificates for clients. This role can be

installed on multiple servers within the same root CA chain.

.
Certification Authority Web Enrollment—
This role service handles the web-

ptg

based distribution of certificates to clients. It requires Internet Information Services

(IIS) to be installed on the server.

.
Online Responder—
The role service responds to individual client requests regard-

ing information about the validity of specific certificates. It is used for complex or

large networks, when the network needs to handle large peaks of revocation activity,

or when large certificate revocation lists (CRLs) need to be downloaded.

.
Certificate Enrollment Web Service—
This new service enables users and comput-

ers to enroll for certificates remotely or from nondomain systems via HTTP.

.
Certificate Enrollment Web Policy Service—
This service works with the related

Certificate Enrollment Web Service but simply provides policy information rather

than certificates.

.
Network Device Enrollment Service—
This role service streamlines the way that

network devices such as routers receive certificates.

Installing AD CS

To install AD CS on Windows Server 2008 R2, determine which server will serve as the

root CA, keeping in mind that it is highly recommended that this be a dedicated server

and also recommended that it be physically secured and shut off for most of the time to

ensure integrity of the certificate chain. It is important to note that an enterprise CA

cannot be shut down; however, a standalone root with a subordinate enterprise CA can be

shut down. If the strategy of having a standalone root with a subordinate enterprise CA is

taken, the root CA must first be created and configured, and then an enterprise subordi-

nate CA must then be created.

Understanding Active Directory Certificate Services (AD CS) in Windows Server

447

In smaller scenarios, an enterprise root CA can be provisioned, though in many cases,

those smaller organizations might still want to consider a standalone root and a subordi-

nate enterprise CA. For the single enterprise root CA scenario, however, the following

steps can be taken to provision the CA server:

CAUTION

After AD CS is installed onto a server, the name of that server and the domain status

of that server cannot change. For example, you cannot demote it from being a domain

controller, or you cannot promote it to one if it is not. Also, the server name must not

change while it is a CA.

1. Open Server Manager (Start, All Programs, Administrative Tools, Server Manager).

2. In the Nodes pane, select Roles, and then click the Add Roles link in the tasks pane.

14

3. Click Next at the welcome page.

4. On the Select Server Roles page, check the box for Active Directory Certificate

Services, and then click Next.

5. Review the information about AD CS on the Introduction page, and click Next to

continue.

ptg

6. On the Select Role Services page, shown in Figure 14.1, choose which role services

will be required. A base install will need only the Certificate Authority role. Click

Next to continue.

FIGURE 14.1

Installing AD CS.

448

CHAPTER 14

Transport-Level Security

7. Select whether to install an Enterprise (integrated with AD DS) CA or a Stand-alone

CA on the subsequent page. In this example, we are installing a domain-based enter-

prise root CA. Click Next to continue.

8. On the Specify CA Type page, specify the CA type, as shown in Figure 14.2. In this

case, we are installing a root CA on the server. Click Next to continue.

ptg

FIGURE 14.2

Specifying a CA type.

9. On the following Set Up Private Key page, you can choose whether to create a new

private key from scratch or reuse an existing private key from a previous CA imple-

mentation. In this example, we create a new key. Click Next to continue.

10. On the Configure Cryptography for CA page, enter the private key encryption

settings, as shown in Figure 14.3. Normally, the defaults are fine, but there might be

specific needs to change the CSP, key length, or other settings. Click Next to continue.

11. Choose a common name that will be used to identify the CA. Bear in mind that this

name will appear on all certificates issued by the CA. In this example, we enter the

common name CompanyABC-CorpCA. Click Next to continue.

12. Set the validity period for the certificate that will be installed on this CA server. If

this is a root CA, the server will have to reissue the certificate chain after the expira-

tion period has expired. In this example, we choose a 5-year validity period, though

many production scenarios will have a 20-year CA created for the root. Click Next

to continue.

13. Specify a location for the certificate database and log locations, and click Next to

continue.

Understanding Active Directory Certificate Services (AD CS) in Windows Server

449

14

FIGURE 14.3

Choosing cryptography settings.

ptg

14. Review the installation selections on the confirmation page, as shown in Figure 14.4,

and click Install.

15. Click Close when the wizard is complete.

FIGURE 14.4

Reviewing AD CS installation options.

450

CHAPTER 14

Transport-Level Security

After you install AD CS, additional CAs can be installed as subordinate CAs and adminis-

tration of the PKI can be performed from the Certification Authority console (Start, All

Programs, Administrative Tools, Certification Authority).

Using Smart Cards in a Public Key Infrastructure

A robust solution for a Public Key Infrastructure network can be found in the introduction

of smart card authentication for users. Smart cards can be microchip enabled plastic cards,

USB keys, or other devices.

User logon information, as well as certificates installed from a CA server, can be placed on

a smart card. When a user needs to log on to a system, she places the smart card in a

smart card reader or simply swipes it across the reader itself. The certificate is read, and the

user is prompted only for a PIN, which is uniquely assigned to each user. After the PIN

and the certificate are verified, the user is logged on to the domain.

Smart cards are a form of two-factor authentication and have obvious advantages over

standard forms of authentication. It is no longer possible to simply steal or guess

someone’s username and password in this scenario because the username can be entered

only via the unique smart card. If stolen or lost, the smart card can be immediately deacti-

vated and the certificate revoked. Even if a functioning smart card were to fall into the