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.
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
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
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.
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:
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.
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
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.
Open Server Manager (Start, All Programs, Administrative Tools, Server Manager).
In the Nodes pane, select Roles, and then click the Add Roles link in the tasks pane.
Click Next at the welcome page.
On the Select Server Roles page, check the box for Active Directory Certificate Services, and then click Next.
Review the information about AD CS on the Introduction page, and click Next to continue.
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.
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.
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.
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.
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.
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.
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
Specify a location for the certificate database and log locations, and click Next to continue.
Review the installation selections on the confirmation page, as shown in Figure 4, and click Install.
Figure 4. Reviewing AD CS installation options.
Click Close when the wizard is complete.
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,
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