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

Windows Server 2008 R2 includes a built-in Certificate Authority (CA) technology that is known as Active Directory Certificate Services (AD CS). The first iteration of AD CS emerged with Windows Server 2008, though previous versions of the technology were simply known as Certificate Services. AD CS can be used to create certificates and subsequently manage them; it is responsible for ensuring their validity. AD CS is often used in Windows Server 2008 R2 if there is no particular need to have a third-party verify an organization’s certificates. It is common practice to set up a standalone CA for network encryption that requires certificates only for internal parties. Third-party certificate authorities such as VeriSign are also extensively used but require an investment in individual certificates.

Note

Although the term Active Directory has been incorporated into the name of the Windows Certificate Services function, it should be understood that AD CS does not necessarily require integration with an existing Active Directory Domain Services (AD DS) forest environment. Although this is commonly the case, it is important to understand that AD CS has independence over AD DS forest design.

Windows Server 2008 R2 introduced a few additions to AD CS features, including the following:

• Certificate Enrollment Web Service and Certificate Enrollment Policy Web Service— This is the most significant improvement, essentially allowing certificates to be enrolled directly over HTTP, enabling non-domain or Internet-connected clients to connect and request certificates from a CA server.

• Improved support for high-volume CAs used for NAP— AD CS in Windows Server 2008 R2 improves the database performance when high-volume scenarios such as NAP are utilized.

• Support for cross-forest certificate enrollment— AD CS in Windows Server 2008 R2 allows for CA consolidation across multiple forests.

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 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 standalone 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 environment. 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.

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-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 regarding 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 computers 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 subordinate CA must then be created.

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 subordinate 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.
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.
6.	On the Select Role Services page, shown in Figure 1, choose which role services will be required. A base install will need only the Certificate Authority role. Click Next to continue. Figure 1. Installing AD CS.
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 enterprise root CA. Click Next to continue.
8.	On the Specify CA Type page, specify the CA type, as shown in Figure 2. In this case, we are installing a root CA on the server. Click Next to continue. Figure 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 implementation. 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 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. Figure 3. Choosing cryptography settings.
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 expiration 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.
14.	Review the installation selections on the confirmation page, as shown in Figure 4, and click Install. Figure 4. Reviewing AD CS installation options.
15.	Click Close when the wizard is complete.

After you install AD CS, additional CAs can be installed as subordinate CAs and administration 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 deactivated and the certificate revoked. Even if a functioning smart card were to fall into the wrong hands, the PIN would still need to be used to properly access the system. Smart cards are fast becoming a more accepted way to integrate the security of certificates and PKI into organizations.

Using the Encrypting File System (EFS)

Just as transport information can be encrypted via certificates and PKI, so too can the NT File System (NTFS) on Windows Server 2008 R2 be encrypted to prevent unauthorized access. The Encrypting File System (EFS) option in Windows Server 2008 R2 allows for this type of functionality and improves on the previous EFS model by allowing offline folders to maintain encryption sets on the server. EFS is advantageous, particularly for laptop users who tote around sensitive information. If the laptop or hard drive is stolen, the file information is worthless because it is scrambled and can be unscrambled only with the proper key. EFS is proving to be an important part of PKI implementations.

Windows 7 and/or Windows Vista BitLocker go one step further than EFS, allowing for the entire hard drive, aside from a few boot files, to be encrypted. This also requires PKI certificates to be set up.

Integrating PKI with Non-Microsoft Kerberos Realms

Windows Server 2008 R2’s Active Directory component can use the Public Key Infrastructure, which utilizes trusts between foreign non-Microsoft Kerberos realms and Active Directory. The PKI serves as the authentication mechanism for security requests across the cross-realm trusts that can be created in Active Directory.