Understanding Active Directory Certificate Services (AD CS) in Windows Server 2008 R2

- Free product key for windows 10
- Free Product Key for Microsoft office 365
- Malwarebytes Premium 3.7.1 Serial Keys (LifeTime) 2019
Windows 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 server.

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

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


Making 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:

  • Certification Authority— 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.

  • Online Responder— 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 server:


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.

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

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

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

Set 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 continue.

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.

After 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, Certification Authority).

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 Active Directory.

Top 10
Free Mobile And Desktop Apps For Accessing Restricted Websites
TOYOTA CAMRY 2; 2.5 : Camry now more comely
KIA SORENTO 2.2CRDi : Fuel-sipping slugger
How To Setup, Password Protect & Encrypt Wireless Internet Connection
Emulate And Run iPad Apps On Windows, Mac OS X & Linux With iPadian
Backup & Restore Game Progress From Any Game With SaveGameProgress
Generate A Facebook Timeline Cover Using A Free App
New App for Women ‘Remix’ Offers Fashion Advice & Style Tips
SG50 Ferrari F12berlinetta : Prancing Horse for Lion City's 50th
- Messages forwarded by Outlook rule go nowhere
- Create and Deploy Windows 7 Image
- How do I check to see if my exchange 2003 is an open relay? (not using a open relay tester tool online, but on the console)
- Creating and using an unencrypted cookie in ASP.NET
- Directories
- Poor Performance on Sharepoint 2010 Server
- SBS 2008 ~ The e-mail alias already exists...
- Public to Private IP - DNS Changes
- Send Email from Winform application
- How to create a .mdb file from ms sql server database.......
programming4us programming4us