Active Directory Certificate Services provide a
variety of services regarding public key infrastructures and certificate
usage in general. Using Windows Server 2008 R2 and AD CS, you can
support the following certificate usage scenarios:
You can encrypt all
data files. One of the most common problems in IT today is the loss or
theft of mobile computer systems. If data is encrypted, the loss is
minor, but if data is unprotected, it could affect your ability to do
business. With Windows Server 2008 R2 and Windows 7, you can encrypt all
user data files automatically through Group Policy objects and enforce
the strong passwords required to protect them further. The Encrypting
File System (EFS) relies on certificates to lock and unlock encrypted
encrypt all remote communications. Windows Server 2008 R2 includes both
IPSec and Secure Sockets Tunneling Protocol (SSTP) virtual private
network connections. Both rely on certificates to authenticate the start
and end points of the communication.
can secure all email messages. Windows Server 2008 R2 includes support
for Secure Multipurpose Internet Mail Extensions (S/MIME), the standard
email security protocol. Signed messages are protected from tampering
and prove they originate from the correct person.
can secure all logons. Using smart cards, you can use certificates to
support the logon process and ensure that all users, especially
administrators, are who they say they are.
can secure all websites. Using Windows Server 2008 R2 and Internet
Information Services (IIS) 7.0, you can secure all communications to
your websites, ensuring the safety of all your client transactions.
can secure servers to validate their authenticity. For example, when
you assign certificates to servers in a Network Access Protection (NAP)
infrastructure or in any other secure service, computers in your network
know they are working with your own servers and not with other servers
trying to impersonate yours.
can secure all wireless communication. Using Windows Server 2008 R2 and
Windows 7, you can ensure that all wireless communication originates
from trusted endpoints.
can protect all data from tampering. Using Active Directory Rights
Management Services (AD RMS), you can rely on Windows Server 2008 R2 to
protect from tampering with or misuse of the information you generate.
In addition, consider
issuing a certificate to all your employees to help them certify who
they are in all their Internet transactions. Remember that all external
certificates should include a trusted CA within them to allow them to
work automatically with any browser.
1. Understanding AD CS
Directory Certificate Services is the engine that Windows Server 2008
R2 relies on to manage public key certificates. By using AD CS, you can
build a comprehensive PKI hierarchy that can be used to issue and manage
certificates within your organization. AD CS is composed of several
CAs are the servers that you use to issue and manage certificates.
Because of the hierarchical nature of a PKI, AD CS supports both root
and subordinate or child CAs. The root CA usually issues certificates to
subordinate CAs, which enables them in turn to issue certificates to
users, computers, and services. The subordinate CA can issue
certificates only while its own certificate is valid. When this
certificate expires, the subordinate CA must request a certificate
renewal from its root CA. For this reason, root CAs often have
certificate durations that are much longer than any of their
subordinates. In turn, subordinate CAs usually have certificate
durations that are longer than those they issue to users, computers, or
CA Web Enrollment By using Web
Enrollment, users can connect to the CA through a web browser to
request certificates, perform smart card enrollments, or obtain
Certificate Revocation Lists (CRLs). CRLs
provide users of your public key infrastructure with a list of
certificates that have been invalidated or revoked by your organization.
Systems that rely on PKI poll CA servers to obtain CRLs each time a
certificate is presented to them. If the certificate presented to them
is on this list, it is automatically refused.
Online responder This service is designed to respond to specific certificate validation requests through the Online
Certificate Status Protocol (OCSP). Using an online responder (OR), the
system relying on PKI does not need to obtain a full CRL and can submit
a validation request for a specific certificate. The online responder
decodes the validation request and determines whether the certificate is
valid. When it determines the status of the requested certificate, it
sends back an encrypted response containing the information to the
requester. Using online responders is much faster and more efficient
than using CRLs. AD CS includes online responders as a new feature in
Windows Server 2008 R2.
MORE INFO ONLINE RESPONDERS
Online responders are often an alternative to or an extension of CRLs that support the certificate
revocation process. Microsoft online responders comply with request for
comments (RFC) 2560 for OCSP. For more information about this RFC, go
Network Device Enrollment Service Devices that use low-level operating systems, such as routers and switches, can also participate in a PKI through the Network Device Enrollment Service (NDES) by using the Simple
Certificate Enrollment Protocol (SCEP), a protocol developed by Cisco
Systems, Inc. These devices usually do not participate in an AD DS directory
and, therefore, do not have AD DS accounts. However, through the NDES
and the SCEP, they can also become part of the PKI hierarchy that is
maintained and managed by your AD CS installation.
These four components form the core of the AD CS service in Windows Server 2008 R2.
MORE INFO NEW FEATURES IN AD CS
For more information on the new features that AD CS supports in Windows Server 2008 R2, go to http://technet.microsoft.com/en-us/library/dd448537%28WS.10%29.aspx.
1.1. Stand-alone vs. Enterprise CAs
Your biggest concern when
preparing to deploy an AD CS is how to structure the four basic services
that AD CS offers. Initially, you should be concerned about the first
role: the CAs you need to deploy. AD CS supports two CA types:
A CA that is not necessarily integrated in an AD DS directory service. A
stand-alone CA is a CA running either on a member server or on a
stand-alone server—a server in a workgroup. Stand-alone CAs are often
used as internal root CAs and are taken offline for security purposes
after they have been used to generate certificates for subordinate
servers. Certificate issuing and approval are performed manually, and
certificates are based on standard templates, which you cannot modify.
The clients of a stand-alone CA can be members of an AD DS directory,
but AD DS directory membership is not a requirement. Stand-alone CAs can
run Windows Server 2008 R2 Standard edition, Windows Server 2008 R2
Enterprise edition, or Windows Server 2008 R2 Datacenter edition.
A CA that is integrated in an AD DS directory service. Enterprise CAs
are usually member servers and are often used as issuing CAs—CAs that
are subordinate to another CA in a hierarchy but that actually provide
certificates to end users and endpoint devices. Issuing CAs are usually
online at all times and must be highly available. Because they are
integrated in AD DS directories, enterprise CAs automatically issue and
approve certificates when requested by members of the directory.
Certificate templates are more advanced and can be edited to meet
specific requirements. All encryption keys are protected through
directory integration. Enterprise CAs can run only on Windows Server
2008 R2 Enterprise edition or Windows Server 2008 R2 Datacenter edition.
Table 1 outlines the features supported by stand-alone versus enterprise CAs.
Table 1. Comparing Standalone and Enterprise CAs
|Publish CA configuration to Active Directory Domain Services directories.||Optional||Mandatory|
|CA certificate data integration with AD DS forests.||Optional (manual process)||Mandatory and Automatic|
|Certificate Revocation List publication in AD DS forests.||Optional (manual process)||Mandatory and Automatic; also includes Delta CRLs and cross certificates|
|AD DS forest publication assigned on a per-template level as an attribute of the template.||n/a||Supported|
|Web enrollment for certificate requests and validation.||Supported||Supported|
|Certificate Microsoft Management Console (MMC) for certificate requests and validation.||n/a||Supported|
|Certificate requests through HTTP or HTTPS.||Supported||Supported|
|Certificate requests through the remote procedure call (RPC) along with the Distributed Component Object Model (DCOM).||n/a||Default mode|
|V1 templates with custom object identifiers (OID) as source for certificates.||Default||n/a|
|V2 and V3 customizable templates as source for certificates. Templates can also be duplicated.||n/a||Default|
|User input during certificate requests.||Manual||Retrieved from AD DS|
|Supported enrollment methods.||Automatic or Pending for all templates||Automatic or Pending and applied on a template basis|
|Certificate approval process.||Manual||Manual or Automatic through AD DS authentication and access control|
|Certificate publishing.||Manually to client or CA; can be to AD DS but only through custom policy module||Depends
on certificate type and template settings but can be automatically
enrolled in client’s certificate store and published in AD DS|
|Certificate publishing and management through AD DS.||n/a||Supported|
|Deployment options.||Domain controller (DC), member server, or stand-alone server||DC or member server only|
As you can see in Table 15-1,
stand-alone CAs are focused on delivering specific services and should
be considered mostly for stand-alone environments where automation is
not required. Good examples are root CAs or CAs located in a perimeter
network and offering services to the Internet.
Enterprise CAs should be
considered mostly as issuing CAs in internal networks that also include
AD DS forest structures. Enterprise CAs automate the certificate
allocation process and are very useful when you need to issue
certificates to devices for wireless networks or to users for smart card
integration. Imagine managing the entire request and approval process
manually when you have thousands of users and devices. It could easily
Learn the differences
between stand-alone and enterprise CAs well. These topics are an
important part of the AD CS coverage on the exam.
1.2. Creating the CA Hierarchy
A second consideration
when planning your CA hierarchy is security. Because a CA hierarchy is
based on certificate chaining, any compromise of a top-level or root CA
automatically compromises all the certificates that are based on it.
This is one reason you must secure root CAs as much as possible. In
fact, a common practice is to create a tiered CA hierarchy and take the
top members of a tiered architecture offline. The logic is that if a
server is offline, it is as secure as it can be.
However, determining the
number of tiers in your AD CS architecture depends on several other
factors as well. You need to consider the size and geographic
distribution of your network. You also need to identify the trust
relationship that you require between CAs and the certificate
holders. Keep in mind that each time a certificate is presented, it
must be validated through either a CRL or an online responder, so to use
certificates, you must have connectivity of some sort.
Consider also the
potential scenarios you intend to support with your AD CS deployment.
Will you be interacting with people or partners outside your network?
Will you be using smart cards? Will you be using wireless networks? Will
you be using IPSec or the new SSTP? Basically, anytime you need to
certify the identity of a device, an application, or a user, you must
rely on AD CS and, potentially, third-party commercial certificate
When you have the answers to these questions, you can proceed with the planning of your AD CS hierarchy. When you do so, consider:
Creating a single-tiered
hierarchy with a single root CA only in very rare situations in which
you feel the root CA will not be compromised under any circumstance.
a two-tiered hierarchy with a root CA and issuing CAs when you need to
protect the root CA but your organization size and the purpose of the
hierarchy does not warrant a more complex hierarchy. In this model, you
can take the root CA offline to protect it. (See Figure 1.)
Figure 1. A two-tiered hierarchy
Creating a three-tiered hierarchy
with a root CA, intermediate CAs, and issuing CAs when you need higher
levels of security and high availability for the issuing CAs, and your
administration model, user population, and geographic scope warrant the
extra cost of the additional tier. Multiple intermediate CAs are often
used to support different policies in different environments in this
model. If you use this model, take both the root and intermediate CAs
offline to protect them, as shown in Figure 2.
Figure 2. A three-tiered hierarchy in a geographic deployment
more than three tiers only in highly complex environments that require
the utmost security where the CA infrastructure must be protected at all
As you can see, the more tiers
you create in a hierarchy, the higher the level of complexity in terms
of management and administration. However, the more complex your
hierarchy, the more secure it can be. In addition, consider which type
of CA you need to deploy in each tier. Table 2 outlines the CA type based on the tier model.
Table 2. Assigning CA Type Based on Tier Model
|CA TYPE||ONE-TIER HIERARCHY||TWO-TIER HIERARCHY||THREE-TIER HIERARCHY|
|Root CA||Enterprise CA (online)||Stand-alone CA (offline)||Stand-alone CA (offline)|
|Intermediate CA|| || ||Stand-alone CA (offline)|
|Issuing CA|| ||Enterprise CA (online)||Enterprise CA (online)|
Keep these hierarchies in mind when you take the exam. CA hierarchies are an important aspect of any AD CS deployment.
1.3. Best Practices for AD CS Deployments
Architectures using two
or more tiers represent the most common deployments of AD CS. When you
plan for your AD CS infrastructure, keep the following in mind:
Avoid single-tiered hierarchies as much as possible, because they are very difficult to protect.
and intermediate CAs (if implemented) should be taken offline as soon
as possible after the infrastructure is in place. For this reason, these
CAs are excellent candidates for virtualization through Windows Server
2008 R2 Hyper-V. Create a virtual machine (VM), install the AD CS
Stand-alone CA role, and then save the machine state as soon as you can.
removing the VM files for the root CA from the host server as soon as
it is taken offline. Store the secured VM in a vault of some type.
you use virtualization in support of your AD CS deployment, secure the
VMs as much as possible. It is a lot easier to walk away with a VM than
with a physical server.
creating VMs that do not have network connections or that have disabled
network connections for the root and intermediate CAs. This ensures an
even higher level of protection. Certificates are transferred from these
servers through either USB devices or floppy disks.
Control the removable
devices on root and intermediate CAs through device protection settings
in the Local Security Policy console. This adds a further layer of
sure your CA administrators are highly trustworthy individuals. They
control the entire CA hierarchy and, because of this, they are in a very
high position of trust.
secure the data center that hosts the CAs. Control access to the data
center, and use smart card administrative logons as much as possible.
using a single root CA, but adding availability through multiple CA
installations as soon as you reach the intermediate and issuing tiers of
cannot change the name of a server after the AD CS service is
installed, so plan your server names carefully and make sure you can
keep them for a very long time.
You cannot change a CA from stand-alone to enterprise or vice versa after AD CS is installed. Once again, plan accordingly.
a general practice, do not install AD CS on a DC. Although it can be
done, endeavor to keep the AD DS server role independent of all other
roles except the Domain Name System (DNS) role.
These guidelines will assist you in your AD CS deployment planning phase.
MORE INFO BEST PRACTICES FOR PKI DEPLOYMENTS
information on PKI deployments with Windows infrastructures, read “Best
Practices for Implementing a Microsoft Windows Server 2003 Public Key
Infrastructure” at http://technet.microsoft.com/en-us/library/cc772670(WS.10).aspx, or “Designing and Implementing a PKI: Part 1 Design and planning” at http://blogs.technet.com/b/askds/archive/2009/09/01/designing-and-implementing-a-pki-part-i-design-and-planning.aspx.
They refer to Windows Server 2003 rather than Windows Server 2008 R2,
but the practices are valid for any newer version of Windows.
1.4. Additional Planning Requirements
You’re almost ready to
proceed. However, as mentioned earlier, planning and deploying a CA
hierarchy is not only a technical activity. You need to have the
appropriate administrative processes to support the use of certificates
in your network. Three additional considerations must be covered before
you can move on to installing AD CS:
You must consider how you will support certificate enrollment.
You must consider how you will renew certificates.
You must create a certificate practice statement (CPS).
The first consideration
focuses on how you plan to support certificate requests and
distribution. As mentioned earlier, a certificate identifies its holder
thoroughly whether it is a user, a machine, or an application.
Therefore, you must put in place a requester identification validation
process. You don’t want to issue a certificate to John Kane when you’re
not sure the requester is actually John Kane. Third-party certificate
authorities use several types of processes for this validation, the most
stringent of which involves a visit to the person requesting the
certificate by an authorized legal representative of the CA. This means a
face-to-face meeting; after the requester is validated, you can provide
him or her with a certificate in that name. To protect the certificate
further, you can store it on a hardware token such as a smart card and
provide that to the requester. It then becomes the responsibility of the
requester to protect the certificate and the token that contains it.
However, if you plan
to use automatic enrollment through enterprise CAs, you need to make
sure that users are properly validated before giving them access to your
network. Rely on some form of official identification such as a
passport or other governmental ID mechanism. This should already be part
of your human resources processes and policies.
consideration involves certificate lifetimes. Certificates usually
include two key pairs: a private key and a public key. When you encrypt
data, you use the private key. When others decrypt the data, they
usually use your public key. The longer you use a certificate key pair,
the more prone it is to attack or compromise. When you renew a
certificate, the renewal generates a new key pair for the certificate.
Therefore, you must plan certificate lifetimes and renewals carefully.
In fact, you must temper key pair life with the risk of compromise.
In addition, you must ensure
that your tiered hierarchy also includes tiered lifetimes. Root CAs
should have the longest lifetime, then intermediate CAs if you use them,
then issuing CAs, and then issued certificates. For example, you might
use a gap of 10 years for each tier in your architecture; that is,
assign 10 years per each level in the tier. In a three-tier
architecture, use 30 years for the root CA, 20 years for the
intermediate CAs, and 10 years for issuing CAs. Then you can assign one
or two years to the certificates you issue. The reason for this
hierarchy of durations is that each time a certificate expires for a
server, all subordinate certificates expire as well. To protect against
this eventuality, you give very long durations to servers.
Finally, you must
plan and prepare your certificate practice statement. CPSs are based on
the certificate policies you create. Policies define the issuing
organization’s responsibilities in terms of each of the certificate
types it issues. The issuing organization is ultimately responsible for
any wrongdoing or misuse of the certificates it issued. Because of this,
involve the legal, human resources, and security departments of your
organization to assist you in defining the policies you use for each
certificate type, and then generate your CPS from that. The CPS should
include several items, such as a clear definition of who you are; a list
of your certificate policies; a general statement of the procedures you
use to issue, assign, and revoke certificates; a description of the
method used to protect your CAs; and so on.
Another important item that must be included in your CPS is the revocation
policy you use. Revocation occurs when you need to cancel a certificate
for any reason, usually when someone does not adhere to the policy you
defined for that particular certificate type. Remember that revocation
is the only method you have of invalidating a certificate when it is
The CPS should be publicly
available to both your internal and external CA users. This usually
means making it available in some form on the Internet or through
Familiarize yourself with
certificate policies and certificate practice statements, because they
are a definite part of the exam topics for AD CS.