Understanding and Installing Active Directory Certificate Services (part 1) - Understanding AD CS

1. Understanding AD CS

Active 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 components:

• Certificate authorities 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 services.

• 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.

• 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.

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:

• Stand-alone CA 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.

• Enterprise CA 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

FEATURE	STAND-ALONE	ENTERPRISE
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 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 become overwhelming.

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 authorities.

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.

• Creating 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

• Creating more than three tiers only in highly complex environments that require the utmost security where the CA infrastructure must be protected at all times.

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)

Tip

EXAM TIP

Keep these hierarchies in mind when you take the exam. CA hierarchies are an important aspect of any AD CS deployment.

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.

• Root 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.

• Consider 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.

• If 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.

• Consider 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 protection.

• Make 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.

• Thoroughly secure the data center that hosts the CAs. Control access to the data center, and use smart card administrative logons as much as possible.

• Consider using a single root CA, but adding availability through multiple CA installations as soon as you reach the intermediate and issuing tiers of the hierarchy.

• You 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.

• As 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.

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.

The second 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 misused.

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 intranets.