With explicit permission of the content owners, this article is republishing information.
This article is collecting and republishing updated information on Active Directory Certificate Services (AD CS) that has been published on Technet Library before.
For various reasons the product owners and/or documentation team have transferred (part of) the content to Technet Wiki, to ease content update.
Credits: Markus Vilcinskas, Kurt Hudson⁺, Carol Baily, Rashmi Jha
For every section that refers to Microsoft Technet Library content, the source reference has been added explicitly.
The complete list of source reference material has been added to the end of the article.
Source: [TechNet], [TechNet]
Active Directory Certificate Services (AD CS) provides customizable services for issuing and managing public key infrastructure (PKI) certificates used in software security systems that employ public key technologies. The digital certificates that AD CS
provides can be used to encrypt and digitally sign electronic documents and messages. Further, these digital certificates can be used for authentication of computer, user, or device accounts on a network. Digital certificates are used to provide:
These certificate services were available starting in Windows 2000 and continue to be available as a server role in Windows Server 2008 R2.
Important: By installing AD CS, you are either creating or extending a Public Key Infrastructure (PKI). A PKI structure that meets the requirements of most organizations is a multi-tier Certification Authority (CA) hierarchy that implements
an Offline Root CA. For more information, see the PKI
Design Brief Overview and the
Windows PKI documentation and reference library.
The sections in this overview of AD CS are:
↑ Back to top
AD CS provides the following features:
The following table describes features available to enterprise (not standalone) certification authorities:
Windows Server version and SKU
Role Services Available
Certificate Templates available
Auto-enrollment & Key Archival (comes with V2 Templates)
CA Features: SMTP Exit Module & Role Separation
(over DCOM protocol)
Windows Web Server 2008 R2
Windows Server 2008 R2 Standard or Foundation
-Certification Authority (CA)
-CA Web Enrollment
-Certificate Enrollment Web Services* (policy service and enrollment service)
V1, V2*, and V3* templates
Windows Server 2008 R2 Standard, Foundation, or Server Core ** installations
-Certification Authority (CA)*
Windows Server 2008 R2 Enterprise or Datacenter
-Online Responder (OCSP)
-Network Device Enrollment Service (NDES)
V1, V2, and V3 templates
Windows Server 2008 R2 Enterprise, Datacenter, or Server Core ** installations
Windows Server 2008 Standard Edition
Windows Server 2008 Enterprise or Datacenter Edition
Windows Server 2003 Standard Edition
Windows Server 2003 Enterprise or Datacenter Edition
(NDES available as “MSCEP” via resource kit)
V1 and V2 templates
- Certificate Enrollment Web Services (both policy and enrollment service)
-Network Device Enrollment Service
* new for Windows Server 2008 R2
** the SMTP Exit Module is not supported on Server Core installations
You can use AD CS to enhance security by binding the identity of a person, device, or service to a corresponding private key. AD CS gives you a cost-effective, efficient, and secure way to manage the distribution and use of certificates.
Applications supported by AD CS include Secure/Multipurpose Internet Mail Extensions (S/MIME), secure wireless networks, virtual private network (VPN), Internet Protocol security (IPsec), Encrypting File System (EFS), smart card logon, Secure Socket Layer/Transport
Layer Security (SSL/TLS), and digital signatures.
The AD CS server role in the Windows Server 2008 and Windows 2008 R2 operating systems provides customizable services for creating and managing public key certificates used in software security systems employing public key technologies. In addition to binding
the identity of a person, device, or service to a corresponding private key, AD CS also includes features that allow you to manage certificate enrollment and revocation in a variety of scalable environments.
Source: [TechNet], [TechNet]
Cryptography Next Generation (CNG) in the Windows Server® 2008 operating system provides a flexible cryptographic development platform that allows IT professionals to create, update, and use custom cryptography algorithms in cryptography-related applications
such as Active Directory® Certificate Services (AD CS), Secure Sockets Layer (SSL), and Internet Protocol security (IPsec). CNG implements the U.S. government's Suite B cryptographic algorithms, which include algorithms for encryption, digital signatures,
key exchange, and hashing.
CNG has the following capabilities:
Certificate revocation is a necessary part of the process of managing certificates issued by certification authorities (CAs). The most common means of communicating certificate status is by distributing certificate revocation lists (CRLs). In the Windows
Server® 2008 operating system, public key infrastructures (PKIs) where the use of conventional CRLs is not an optimal solution, an Online Responder based on the Online Certificate Status Protocol (OCSP) can be used to manage and distribute revocation status
The use of Online Responders that distribute OCSP responses, along with the use of CRLs, is one of two common methods for conveying information about the validity of certificates. Unlike CRLs, which are distributed periodically and contain information
about all certificates that have been revoked or suspended, an Online Responder receives and responds only to requests from clients for information about the status of a single certificate. The amount of data retrieved per request remains constant no matter
how many revoked certificates there might be.
In many circumstances, Online Responders can process certificate status requests more efficiently than by using CRLs. For example:
Changes in Functionality from Windows Server 2003 with SP1 to Windows Server2008], for download at:
The Network Device Enrollment Service (NDES) is the Microsoft implementation of the Simple Certificate Enrollment Protocol (SCEP), a communication protocol that makes it possible for software running on network devices such as routers and switches,
which cannot otherwise be authenticated on the network, to enroll for X.509 certificates from a certification authority (CA).
NDES operates as an Internet Server Application Programming Interface (ISAPI) filter on Internet Information Services (IIS) that performs the following functions:
Certificate Web enrollment has been available since its inclusion in Windows® 2000 operating systems. It is designed to provide an enrollment mechanism for organizations that need to issue and renew certificates for users and computers that are not
joined to the domain or not connected directly to the network, and for users of non-Microsoft operating systems. Instead of relying on the autoenrollment mechanism of a certification authority (CA) or using the Certificate Request Wizard, the Web enrollment
support provided by a Windows-based CA allows these users to request and obtain new and renewed certificates over an Internet or intranet connection.
For more information, see Web Enrollment and
Setup Certification Authority Web Enrollment Support on TechNet.
The certificate enrollment Web services are available starting with Windows Server 2008 R2 AD CS role services. These enable policy-based certificate enrollment over HTTP by using existing methods such as autoenrollment. The Web services act as a proxy
between a client computer and a CA, which makes direct communication between the client computer and CA unnecessary, and allows certificate enrollment over the Internet and across forests.
For more information see Certificate Enrollment Web Services on the askds blog
or Certificate Enrollment Web Services in Windows Server
2008 R2 (download).
Certificate settings in Group Policy enable administrators to manage the certificate settings on all the computers in the domain from a central location. Configuring the settings by using Group Policy can effect changes throughout the entire domain.
The following are a few examples where administrators can use the new certificate-related settings to:
The restricted enrollment agent is a new functionality in the Windows Server 2008 Enterprise operating system that allows limiting the permissions that users designated as enrollment agents have for enrolling smart card certificates on behalf of other
users. The following sections describe this change and its implications.
Enrollment agents are one or more authorized individuals within an organization. The enrollment agent needs to be issued an enrollment agent certificate, which enables the agent to enroll for smart card certificates on behalf of users. Enrollment agents
are typically members of the corporate security, Information Technology (IT) security, or help desk teams because these individuals have already been trusted with safeguarding valuable resources. In some organizations, such as banks that have many branches,
help desk and security workers might not be conveniently located to perform this task. In this case, designating a branch manager or other trusted employee to act as an enrollment agent is required to enable smart card credentials to be issued from multiple
On a Windows Server 2008 Enterprise-based certification authority (CA), the restricted enrollment agent features allow an enrollment agent to be used for one or many certificate templates. For each certificate template, you can choose which users or
security groups the enrollment agent can enroll on behalf of. You cannot constrain an enrollment agent based on a certain Active Directory® organizational unit (OU) or container; you must use security groups instead. The restricted enrollment agent is not
available on a Windows Server® 2008 Standard-based CA.
Monitoring and troubleshooting the health of all certification authorities (CAs) in a public key infrastructure (PKI) are essential administrative tasks facilitated by the Enterprise PKI snap-in. Originally part of the Microsoft® Windows Server® 2003
Resource Kit and called the PKI Health tool, Enterprise PKI is a Microsoft Management Console (MMC) snap-in for the Windows Server 2008 and Windows Server 2008 R2 operating systems. Because it is part of the core operating system, you can use Enterprise PKI
after server installation by simply adding it to an MMC console. It then becomes available to analyze the health state of CAs installed on computers running Windows Server 2008 R2, Windows Server 2008, or Windows Server 2003.
Enterprise PKI provides a view of the status of your network's PKI environment. Having a view of multiple CAs and their current health states enables administrators to manage CA hierarchies and troubleshoot possible CA errors easily and effectively.
Specifically, Enterprise PKI indicates the validity or accessibility of authority information access (AIA) locations and certificate revocation list (CRL) distribution points.
For each CA selected, Enterprise PKI indicates one of the CA health states listed in the following table.
CA has no problems
Once you add the Enterprise PKI snap-in to the MMC, three panes appear:
Depending on the item selected in either the tree or results pane, you can view more details about CAs and CA certificates including AIA and CRL information in the actions pane. You can also manage the enterprise PKI structure and make corrections
or changes to CA certificates or CRLs.
AD CS requires Windows Server 2008 or Windows Server 2008 R2 and for enterprise roles Active Directory Domain Services (AD DS) is also required. While AD CS can be deployed on a single server, many deployments will involve multiple servers configured as
CAs, which is recommended. Other servers could be configured as Online Responders, and still other servers acting as Web enrollment portals. CAs can be set up on servers running a variety of operating systems, including Windows Server 2008 R2, Windows Server
2008, Windows Server 2003, and Windows 2000 Server (although Windows 2000 is no longer supported by Microsoft). Not all operating systems support all features or design requirements (as discussed
previously), and creating an optimal design will require careful planning and testing before you deploy AD CS in a production environment.