2. New AD CS Features in Windows Server 2008 R2
As with other AD technologies in Windows Server 2008 R2, AD CS has been updated to include additional features. Three new features are available:
Certificate Enrollment and Certificate Enrollment Policy Web Services Certificate enrollment across forests Better support for high-volume CAs
Each of these
features is focused on either better administration of your AD CS
deployment or better support for large AD CS deployments.
2.1. New AD CS Web Services
The new Web Services for AD CS feature provides support for certificate enrollment over the Hypertext
Transfer Protocol (HTTP). The Web Service acts as a proxy between the
client and the Certificate Authority. This makes direct communication
between the two unnecessary and facilitates certificate enrollment over
the Internet as well as across AD DS forests. Mobile workers, business
partners, and remote users can now enroll for certificates directly over
the Internet, making it simpler to support them. Large organizations or
organizations that must interact across AD DS forest boundaries can
also enjoy a simpler enrollment process through these Web Services.
Warning:
IMPORTANT CERTIFICATE ENROLLMENT WEB SERVICE IN EXTRANETS
For the Certificate
Enrollment Web Service to submit and support requests for new
certificates on behalf of clients, it must be trusted for delegation.
When you deploy the Web Service in an extranet, it may increase the
threat of a network attack. To protect your network, configure the Web
Service and the issuing CA to accept only renewal requests signed with
existing certificates. This provides a more secure deployment because it
no longer requires delegation. However, this configuration does not
support clients without existing certificates.
To work with the new AD CS Web Services, your network configuration must meet the following requirements:
The forest functional level must be Windows Server 2008 R2. Your enterprise CA must be running Windows Server 2008 R2, Windows Server 2008, or Windows Server 2003. Client computers must run Windows 7. To
support cross-forest enrollment, the enterprise CAs in each forest must
run either the Enterprise or Datacenter edition of Windows Server.
Rely on this feature if you need either cross-forest enrollment or enrollment over the Internet.
2.2. Enrollment across Forests
As mentioned earlier, cross-forest
enrollment is provided by the new AD CS Web Services. However, for
cross-forest enrollment to work, the forests must also include a two-way
trust relationship and the forest functional level must be at least Windows
Server 2003. If your organization must rely on multiple forests, and
you have PKI deployments within each forest, you can rely on this
feature to facilitate enrollments across your forests. Note that CAs can
now issue certificates across forests with a forest functional level of
Windows Server 2003, but for enrollment to work you need a forest
functional level of Windows Server 2008 R2. Client computers do not need
an update to work with this feature.
However, you can simplify
your CA deployments by removing CAs from other forests and centralizing
the issuing CA in one single forest. This provides support for
certificate use in multiple forests while running only one AD CS
deployment.
2.3. High-Volume CAs
Some organizations, such as those that have deployed the Windows Server Network
Access Protection (NAP) feature, may require higher volume certificate
management than others. When you use a technology such as NAP, your CAs
issue a vast number of health certificates. These are used each time a
client tries to connect to your network. NAP health certificates are
very short-lived and usually last only a matter of hours before they
expire. Because of this, a CA might issue several different certificates
per computer each day. This high volume of certificates can slow down
the CA and have an impact on performance overall.
With Windows Server 2008 R2,
organizations can choose to bypass certain CA database operations to
improve CA performance in these scenarios. By default, CAs store both a
record of each certificate request and the issued certificate in the CA
database. This means that the CA database can become quite bulky in
large NAP deployments. By bypassing the storage of certificates in the
database—in fact, not storing either the request records or the issued
certificates in the CA database—you can improve the CA’s performance and
reduce CA operational costs. This feature is called non-persistent
certificate processing.
Warning:
IMPORTANT BYPASSING CERTIFICATE STORAGE
When you bypass certificate
storage in the CA database, you can no longer revoke issued
certificates. Although NAP health certificates are short-lived and the
potential damage an unrevoked certificate can cause is minimal, be aware
that you cannot manage Certificate Revocation Lists after enabling the
high-volume feature on a CA.
3. Installing AD CS
Installing AD CS is a
much more involved process than installing Active Directory Lightweight
Directory Services (AD LDS). This is because of the choice between
stand-alone and enterprise CAs and the subsequent choices that ensue
from this original decision.
In most cases, you will
install at least a two-tiered structure, installing first a stand-alone
CA, then an enterprise CA. In larger organizations, you will deploy
several tiers and install several servers in each tier except the root.
Servers hosting the AD CS role should be configured with the following capabilities, whether they are physical or virtual:
Multiple processors, because this accelerates the certificate allocation process. Minimal amounts of RAM, because RAM has little effect on certificate processing. VMs need no more than 512 MB of RAM. Separate
disks for the certificate store. Ideally, you should have at least one
data disk and store the database on it. Issuing servers for large
communities should also have a separate disk for log files. Key
lengths kept to medium sizes, to obtain the best performance from the
server. Key lengths have an impact on CPU and disk usage. Short keys
require more disk overhead. Long keys require more CPU usage and less
disk activity. If
using physical systems, a redundant array of inexpensive disks (RAID)
level that is balanced between reliability and improved performance.
Warning:
IMPORTANT INSTALLATION ON WINDOWS SERVER 2008 R2
The AD CS role can now be
installed on Server Core in Windows Server 2008 R2. The installation is
provided by a Visual Basic script and installs all of the required
components to run a CA. This means that if you install CAs in perimeter
networks, you should consider installing it on a Server Core
installation to keep it more secure.
Different editions of Windows Server 2008 R2 offer different features in support of AD CS. Table 3 outlines the supported features based on the selected edition.
Table 3. AD CS Features per Windows Server 2008 R2 Edition| SUPPORTED COMPONENTS AND FEATURES | WEB | STANDARD | ENTERPRISE | DATACENTER |
|---|
| Stand-alone certificate authority | ☐ | ☑ | ☑ | ☑ | | Enterprise certificate authority | ☐ | ☐ | ☑ | ☑ | | Network Device Enrollment Service (NDES) | ☐ | ☐ | ☑ | ☑ | | Online responder service | ☐ | ☐ | ☑ | ☑ | | Key archival | ☐ | ☐ | ☑ | ☑ | | Role Separation | ☐ | ☐ | ☑ | ☑ | | Certificate Manager restrictions | ☐ | ☐ | ☑ | ☑ | | Delegated enrollment agent restrictions | ☐ | ☐ | ☑ | ☑ |
3.1. Preparing for AD CS Installation
You must prepare your environment before installing AD CS. The prerequisites for a typical AD CS installation include the following:
An AD DS forest with at least a forest root domain. Preferably, you also have a child production domain. Computers
to run the certificate authorities used in your hierarchy. In the
simplest typical deployment, this means at least two computers: one for
the root CA and one for the issuing CA. The issuing CA can also host the
online responder service and NDES. The issuing CA requires the
installation of IIS, but the AD CS installation process automatically
adds this feature during installation. Both computers should be members
of the production domain. In addition, these computers should include
the following settings: Remember
that the root CA can run Windows Server 2008 R2 Standard edition. In
addition, it should be disconnected from the network after the
installation is complete, for security purposes. The
enterprise issuing CA must run on either Windows Server 2008 R2
Enterprise edition or Windows Server 2008 R2 Datacenter edition. The
root CA needs at least two drives, and the issuing CA should have three
drives to store the certificate database and its logs.
A
special user account, if you choose to install the NDES service. Create
a domain account and make it a member of the local IIS_IUSRS group on
each server that will host this service. For example, you could name
this account NDESService. Because this account will be shared among
several computers, it should not be a managed service account. Client computers, ideally running Windows 7, to request and obtain certificates.
Now you can move on to the actual installation. To install a stand-alone root CA, use the procedure described in the following practice.
3.1.1. Practice Installing a CA Hierarchy
In this practice, you create a two-tier AD
CS hierarchy and install the NDES feature of AD CS.
Note:
WORKING WITH VIRTUAL MACHINES
It is easier to perform
these exercises with virtual machines than with physical machines, at
least for most readers. Note that when working with virtual machines,
many users tend to save the machine state instead of shutting it down.
It is a convenient way to work. However, for these exercises to work
best, it is highly recommended that you work with machines that have
been restarted rather than restored from a saved state. If you use
machines restored from saved states, you may experience erratic behavior
during these exercises.
EXERCISE 1 Install AD CS as a Stand-alone Root CA
In this exercise, you create a
stand-alone root CA, which will be used as the root of your CA
hierarchy. This task is performed on SERVER03. Make sure that SERVER01,
your DC, is also running and that SERVER03 is a member of the domain.
Log on to SERVER03 with the domain Administrator account. You
need local administrative credentials only, but for the purposes of
this exercise, it is fine to use the domain administrator account. This
server can be running Windows Server 2008 R2 Standard edition, Windows
Server 2008 R2 Enterprise edition, or Windows Server 2008 R2 Datacenter
edition.
Note:
STANDARD OR ENTERPRISE EDITION
To conserve costs in
production, the server you use for the root CA that will be taken
offline should be Standard edition. However, if you are using a virtual
machine, Enterprise edition can actually cost less.
Launch Server Manager from the Administrative Tools program group. Right-click the Roles node in the tree pane and click Add Roles. Review the Before You Begin information and click Next. On the Select Server Roles page, select Active Directory Certificate Services and click Next. On
the Introduction to Active Directory Certificate Services page, review
the information about the selected role and click Next. On the Select Role Services page, select Certification Authority and click Next. Because
this will be a root CA and you will take it offline as soon as you
create the issuing CA, you do not assign any other role features or
services. On the Specify Setup Type page, select Standalone and click Next. On the CA Type page, select Root CA and click Next. On the Set Up Private Key page, select Create A New Private Key and click Next. You need to create a new private key because you are creating a new root CA. However, if you were reinstalling a
CA because of a system failure, you would use an existing key, one that
was generated during the initial installation of the root CA. In
addition, if you were creating a root CA to be chained with an external
third-party CA, you would use the last option, to use the key provided
by the third-party CA. You must install the key on the server before you
begin the AD CS installation for the option to be available. Use the
instructions provided by your third-party CA to install the certificate. On
the Configure Cryptography For CA page, select the suggested
cryptographic service provider (CSP). Select a key character length of
2048. Select the sha1 hash algorithm for signing certificates issued by
this CA. Also select Allow Administrator Interaction When The Private
Key Is Accessed By The CA. There are several options on this page: CSPs
are the engines that the Microsoft Crypto application programming
interface (API) uses to generate the key pair for this root CA. CSPs can
be either software or hardware based. For example, the RSA#Microsoft
Software Key Storage Provider is software based, and the RSA#Microsoft
Smart Card Key Storage Provider is hardware based. Key
character length determines the length of the keys in the pair. Four
lengths are possible. Remember that the longer the key, the more
processing the server will require to decode it. Hash
algorithms produce and assign a hash value on the keys in the pair.
Because they are assigned to the keys, any tampering of the key will
change the hash value and invalidate the key. Hash values provide
further key protection. The algorithm you select will simply use a
different calculation method to generate the hash value. The
last option on the page provides further protection for the root CA. By
selecting this option, you ensure that use of the CA will require
administrative access and will work only with this level of access.
Click Next. On the Configure CA Name page, type Contoso-Root-CA as the common name, leave the distinguished name suffix as is, and click Next. The name you use will be embedded in every subordinate certificate issued by the chain. On the Set Validity Period page, change the year value to 20 and click Next. On
the Configure Certificate Database page, specify the storage locations
for the certificate database and the certificate database log. Because
this is a root CA that should be taken offline and should be used only
to generate certificates for the issuing CAs, you can place both on the D
drive. For the database location, click Browse, navigate to the D drive, click Make New Folder, type CertData, and press Enter. Click OK. For the logs, click Browse, similarly create a folder on the D drive and name it CertLogs, and then click OK. Click Next. Review
the information available on the AD CS page and click Install. When the
installation completes, review the installation results and click
Close. Your root CA is installed. Note
that you can no longer change the name of this server unless you
uninstall AD CS first. This is a good reason for not using a server name
in the CA name in step 12.
Tip:
EXAM TIP
Make sure you fully understand these installation choices, because they are part of the exam.
After your root CA is
installed, return to Server Manager and click Active Directory
Certificate Services under the Roles node to view the results of the
installation. For example, you should have an event ID 103, as shown in Figure 3,
listed on the summary page of the AD CS role. This event shows that the
CA name will be added to the Certificate Authorities container in your
AD DS domain. It also displays the command that you can use to view the
information in the directory after the name has been added.
In a production
environment, you should disconnect this CA from the network after the
Group Policy cycle has been updated (you can force it with the
gpudate.exe command) to provide further protection for this server.
You can now move on to installing
your first issuing CA. You should install more than one issuing CA to
provide high availability for your AD CS infrastructure, but each
installation uses the same process. Although you do this through network
connections in these exercises, in production you should use manual
transfer methods such as USB devices.
Note:
REVIEW THE AD CS INSTALLATION PROCESS
For a step-by-step guide to the installation of AD CS, go to http://go.microsoft.com/fwlink/?LinkId=90856.
EXERCISE 2 Install AD CS as an Enterprise Issuing CA
You should normally install
more than one issuing CA to provide high availability for your AD CS
infrastructure, but for the purposes of this exercise, one issuing CA is
sufficient. Make sure that SERVER01, SERVER03, and SERVER04 are all
running.
Log on to SERVER04 using the domain Administrator account. You
need local administrative access rights only, but for the purposes of
this exercise, the domain administrator account will also work. This
server can be running Windows Server 2008 R2 Enterprise edition or
Windows Server 2008 R2 Datacenter edition. Launch Server Manager from the Administrative Tools program group. Right-click the Roles node and click Add Roles. Review the Before You Begin information and click Next. On the Select Server Roles page, select Active Directory Certificate Services and click Next. On
the Introduction to Active Directory Certificate Services page, review
the information about the selected role and click Next. On
the Select Role Services page, select Certificate Authority and Online
Responder. When you select Online Responder, the wizard asks you to add
the Web Server role with the required features. Click Add Required Role
Services. You do
not select Certificate Authority Web Enrollment, because this is an
internal enterprise CA, and enterprise CAs rely on AD DS to distribute
certificates to users and devices. If you were installing
this CA in an external network, you might consider using Web Enrollment
to allow users to request certificates from your CA. You cannot choose the Network Device Enrollment Service (NDES) installation at this time because AD CS does not support installing
a CA at the same time as you install NDES. If you want to install NDES,
you must select Add Roles from Server Manager after the CA installation
has completed. On the Specify Setup Type page, select Enterprise and click Next. On the Specify CA Type page, select Subordinate CA and click Next. On the Set Up Private Key page, select Create A New Private Key and click Next. On the Configure Cryptography For CA page, accept the default values and click Next. Note
that you do not select the Allow Administrator Interaction When The
Private Key Is Accessed By The CA option for this installation, because
it is an issuing CA and must be able to interact with end users to issue
certificates. On the Configure CA Name page, type Contoso-Issuing-CA01 as the common name, leave the default distinguished name suffix as is, and click Next. You
use a valid name—one that has meaning for the people who interact with
the machine—and a number, because you should create additional issuing
CAs for redundancy purposes. For example, by naming one server Root-CA
and others Issuing-CA, you are aware of the CA’s role in the hierarchy
simply by looking at its name. On
the Request Certificate From A Parent CA page, select Save A
Certificate Request To File And Manually Send It Later To A Parent CA. Select
the certificate request name (excluding the path) from the File Name
field and copy it to the clipboard, and then click Browse and navigate
to your Documents folder. Paste the name in the File Name box, click
Save, and then click Next. You must do this; if you do not, the wizard
will place the request file on the root of the C: drive. On
the Configure Certificate Database page, specify the storage locations
for the certificate database and the certificate database log. Because
this is an issuing CA that will be used for testing only, you can place
the data and the logs together on the D drive. However, in a production
environment, issuing CAs are used heavily, so you should place the data
on the D drive and the logs on an E drive. For the database location, click Browse, navigate to the D drive, click Make New Folder, and name it CertData. Click OK. For the logs, click Browse, create a folder on the D drive, name it CertLogs, and click OK. Click Next when ready. Review the installation of IIS. Click Next. On the Web Server Role Services page, review the required services and click Next. Review
the information in the Confirm Installation Selections page and click
Install. When the installation completes, review the installation
results and click Close. The
subordinate CA setup is not usable until it has been issued a root CA
certificate and this certificate has been used to complete the
installation of this subordinate CA.
Tip:
EXAM TIP
Remember that you cannot install the CA and the NDES role features at the same time.
EXERCISE 3 Obtain and Install the Issuing CA Certificate
Now you obtain the
certificate to complete the installation of the issuing CA. You should
normally perform this procedure offline using a removable storage device
such as a floppy disk or a USB flash drive, but for the purpose of this
exercise, you use a shared folder to transfer the certificate request
and the certificate after it is issued.
On SERVER04, launch Windows Explorer and navigate to the C drive. Create a new folder and name it Temp. Right-click the Temp folder, point to Share With, and click Specific People. In the File Sharing dialog box, select Everyone in the drop-down list, and then click Add. In
the Permission Level column, from the drop-down list, assign the
Read/Write permission to Everyone and click Share. Click Done. Copy the certificate request you generated from your Documents folder to the Temp folder. On SERVER03, launch the Certification Authority console from the Administrative Tools program group. In
the Certification Authority console, right-click the root CA name in
the tree pane, point to All Tasks, and then click Submit New Request. In the Open Request File dialog box, in the File Name box, type \\SERVER04\Temp. Click Open, select the request, and then click Open again. Navigate
to the Pending Requests node in the tree pane, right-click the pending
request in the details pane, point to All Tasks, and then click Issue. Move to the Issued Certificates node in the tree pane, right-click the issued certificate in the details pane, and click Open. In the Certificate dialog box, click the Details tab, and then click Copy To File at the bottom of the dialog box. This launches the Certificate Export Wizard. Select
Cryptographic Message Syntax Standard – PKCS #7 Certificates (.P7B),
select Include All Certificates In The Certification Path If Possible,
and click Next. There are several supported formats: Distinguished
Encoding Rules (DER) Encoded Binary X.509 is often used for computers
that do not run the Windows operating system. This creates certificate
files in the DER format. Base-64
Encoded X.509 supports S/MIME, which is the format used to transfer
secured email messages over the Internet. On servers, it is usually used
for non-Windows operating systems. This also creates certificate files
in the DER format. Cryptographic
Message Syntax Standard (PKCS #7) is the format used to transfer
certificates and their chained path from one computer to another. This
format uses the P7B file format. Personal
Information Exchange (PKCS #12) is also used to transfer certificates
and their chained path from one computer to another, but in addition,
this format supports the transfer of the private key as well as the
public key. Use this format with caution, because transporting the
private key can jeopardize it. This format uses the PFX file format. Microsoft
Serialized Certificate Store is a custom Microsoft format that should
be used when you need to transfer root certificates from one computer to
another. This uses the SST file format.
In the File To Export dialog box, click Browse and save the certificate in the \\SERVER04\Temp folder. Name the file Issuing-CA01.p7b and click Save. Click Next when you return to the wizard. Review your settings and click Finish. Click
OK when the wizard tells you that the export was successful. Return to
SERVER04. Remember that, normally, you would use a removable device to
transport this certificate from one server to another. Go
to Server Manager and select Contoso-Issuing-CA01 in the tree pane
(Server Manager\Roles\Active Directory Certificate
Services\Contoso-Issuing-CA01). Right-click Contoso-Issuing-CA01, point to All Tasks, and then click Install CA Certificate. Move to the C:\Temp folder, select the certificate, and click Open. The
first time you enable an issuing CA, AD CS warns you that the root
certificate server is not trusted. Click OK to trust the root
certificate. This imports the certificate and enables the server. The
trusted root will now be registered in AD DS and you will no longer get
this message when you enable other issuing CAs. Right-click the server name, Contoso-Issuing-CA01, point to All Tasks, and then click Start Service. Your
issuing CA is ready to issue certificates. At this point, you should
normally take SERVER03 offline, but this is not necessary in a test
environment.
Warning:
IMPORTANT PROTECT THE CERTIFICATE
Now that the server is ready to
work, store the transferred certificate in a safe place. You should
also shut down the root CA after you have performed this task for all
the issuing CAs you require in your infrastructure. If the root CA is a
virtual machine, shut it down, and then remove the VM files from the
host server. For example, you could copy them to a DVD and then store
the DVD in a very safe place.
EXERCISE 4 Prepare to Install the NDES Feature
Now you install the NDES
feature. Again, this task is performed on SERVER04, but you must use
SERVER01 to create a user account first.
Log on to SERVER01 using the domain Administrator account. Launch Active Directory Users And Computers from the Administrative Tools program group. Create the following OU structure: Contoso.com\Admins\Service Identities. Right-click Service Identities, point to New, and then click User. Name the user NDESService, and use this name for both the logon and the pre-Windows 2000 logon names. Click Next. Assign a strong password. Clear User Must Change Password At Next Logon and select Password Never Expires.
Note:
LEGACY SERVICE ACCOUNTS
You must create the
service account according to the steps outlined here, because you cannot
use a managed service account in this instance. Managed service
accounts do not work when the account is shared by multiple computers or
when the account is used for a service running on multiple computers,
such as for a cluster.
Click Next, and then click Finish to create the account. Return to SERVER04 and log on as the domain Administrator. Launch Server Manager from the Administrative Tools program group. Expand Configuration\Local Users And Groups, and then click Groups. Double-click the IIS_IUSRS group. Add the NDESService account to this group and click OK.
EXERCISE 5 Install the NDES Feature
Now you’re ready to install the NDES service.
Right-click Active Directory Certificate Services in the tree pane of Server Manager and click Add Role Services. On the Select Role Services page, select Network Device Enrollment Service. This requires the addition of Windows Authentication to your IIS installation. Click Add Required Role Services and click Next. On the Specify User Account page, click Select User, enter NDESService with its password, and click OK. Click Next. On
the Specify Registration Authority Information page, you must enter the
information for your registration authority or the authority that will
assign and manage certificates assigned to network devices. Type Contoso-MSCEP-RA01 as the RA Name, select your country from the drop-down list, and leave all other information blank. Click Next. Normally,
you should enter all the required and optional information, but for the
purpose of this exercise, leaving them blank is fine. On the Configure Cryptography For Registration Authority page, keep the defaults and click Next. Keep
in mind that key length affects CPU usage; therefore, unless you have
stringent security requirements, keep the 2048 key length. Review the information about the installation of IIS. Click Next. On the Web Server Role Services page, review the required services and click Next. On the Confirm Installation Services page, click Install. Review the status and progress of the installation. Click Close. Your NDES service is now installed and ready to work. Your installation of the issuing server is complete.
|
