Active Directory Certificate Services

Active Directory Certificate Services (AD CS) is an Identity and Access Control security technology that provides customizable services for creating and managing public key certificates used in software security systems that employ public key technologies.

What is a Certificate?

• An Electronic document which contains information
• Has an Issuer
• Contains who the certificate is issued to
• Contains an expiry date
• Contains a public key which allows data to be encrypted only by someone who has the Private Key
• Contains a digital signature which proves the certificate came from a trusted source and provides a checksum to the certificate for checking the certificate has not be altered

Features in AD CS

By using Server Manager, you can set up the following components of AD CS:

• Certification authorities (CAs). Root and subordinate CAs are used to issue certificates to users, computers, and services, and to manage certificate validity.
• Web enrollment. Web enrollment allows users to connect to a CA by means of a Web browser in order to request certificates and retrieve certificate revocation lists (CRLs).
• Online Responder. The Online Responder service decodes revocation status requests for specific certificates, evaluates the status of these certificates, and sends back a signed response containing the requested certificate status information.
• Network Device Enrollment Service. The Network Device Enrollment Service allows routers and other network devices that do not have domain accounts to obtain certificates.
• Certificate Enrollment Web Service. The Certificate Enrollment Web Service enables users and computers to perform certificate enrollment that uses the HTTPS protocol. Together with the Certificate Enrollment Policy Web Service, this enables policy-based certificate enrollment when the client computer is not a member of a domain or when a domain member is not connected to the domain.
• Certificate Enrollment Policy Web Service. The Certificate Enrollment Policy Web Service enables users and computers to obtain certificate enrollment policy information. Together with the Certificate Enrollment Web Service, this enables policy-based certificate enrollment when the client computer is not a member of a domain or when a domain member is not connected to the domain.

Benefits of AD CS

Organizations 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 organizations 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)
• Digital signatures.

Among the new features of AD CS are:

• Improved enrollment capabilities that enable delegated enrollment agents to be assigned on a per-template basis.
• Integrated Simple Certificate Enrollment Protocol (SCEP) enrollment services for issuing certificates to network devices such as routers.
• Scalable, high-speed revocation status response services combining both CRLs and integrated Online Responder services

Hardware and software considerations

AD CS requires Windows Server 2008 and Active Directory Domain Services (AD DS). Although AD CS can be deployed on a single server, many deployments will involve multiple servers configured as CAs, other servers configured as Online Responders, and others serving as Web enrollment portals. CAs can be set up on servers running a variety of operating systems, including Windows Server 2008, Windows Server 2003, and Windows 2000 Server. However, not all operating systems support all features or design requirements, and creating an optimal design will require careful planning and testing before you deploy AD CS in a production environment

A limited set of server roles is available for a Server Core installation of Windows Server 2008 and for Windows Server 2008 for Itanium-based systems. AD CS cannot be installed on Server Core or Itanium-based installations of Windows Server 2008.

Managing AD CS

You can use either Server Manager or Microsoft Management Console (MMC) snap-ins to manage AD CS role services. Use the following steps to open the snap-ins:

Installing Certificate Services. Setting up an Enterprise CA

• Select Role based or feature based installation

• Select Destination Server

• Select Active Directory Certificate Services

• Click Add Features

• Click Next on Select Features

• Read the Active Directory Certificate Services Page and click Next

• On the Select Role Services, select Certification Authority and Online Responder

• Read the Web Server Role (IIS) Page

• Select IIS Role Services

• Check the Confirm Installation Selections Page

• Finish
• On the Dashboard Page, you will see a warning triangle saying Further Configuration is needed
• Click Configure Active Directory Services

•  Specify the Credentials to configure Certificate Services

• Select Role Services to Configure

• Choose Enterprise CA

• Specify CA type. Choose Root CA

A root CA is the CA that is at the top of a certification hierarchy. It must be trusted unconditionally by clients in your organization. All certificate chains terminate at a root CA. Whether you use enterprise or stand-alone CAs, you need to designate a root CA.

Since the root CA is the top CA in the certification hierarchy, the Subject field of the certificate that is issued by a root CA has the same value as the Issuer field of the certificate. Likewise, because the certificate chain terminates when it reaches a self-signed CA, all self-signed CAs are root CAs. The decision to designate a CA as a trusted root CA can be made at the enterprise level or locally by the individual IT administrator.

A root CA serves as the foundation upon which you base your certification authority trust model. It guarantees that the subject’s public key corresponds to the identity information shown in the subject field of the certificates it issues. Different CAs might also verify this relationship by using different standards; therefore, it is important to understand the policies and procedures of the root certification authority before choosing to trust that authority to verify public keys.

The Root CA is the most important CA in your hierarchy. If your root CA is compromised, all CAs in the hierarchy and all certificates issued from it are considered compromised. You can maximize the security of the root CA by keeping it disconnected from the network and by using subordinate CAs to issue certificates to other subordinate CAs or to end users

• Specify the type of the Private Key
• Create a new Private Key

• Specify the Cryptographic Options
• Accept the default values

• Specify the name of the CA

• Specify the validity Period
• Defaults to 5 years

• Specify the Database Location

• Check the Confirmation

• Check Results
• Click on the Web Links to learn more

• Now you can hold down the Windows Key and Q which will open the Aero view
• Select Certificate Services which will open the below

Configure the CA

After a root or subordinate CA is installed, you must configure the Authority Information Access (AIA) and CRL distribution point (CDP) extensions before the CA issues any certificates. The AIA extension specifies where to find up-to-date certificates for the CA. The CDP extension specifies where to find up-to-date CRLs that are signed by the CA. These extensions apply to all certificates that are issued by that CA.

Configuring these extensions ensures that this information is included in each certificate that the CA issues so that it is available to all clients. This ensures that PKI clients experience the least possible number of failures due to unverified certificate chains or certificate revocations, which can result in unsuccessful VPN connections, failed smart card sign-ins, or unverified email signatures.

As a CA administrator, you can add, remove, or modify CRL distribution points and the locations for CDP and AIA certificate issuance. Modifying the URL for a CRL distribution point only affects newly issued certificates. Previously issued certificates will continue to reference the original location, which is why you should establish these locations before your CA distributes any certificates.

Consider these guidelines when you configure CDP extension URLs:

• Avoid publishing delta CRLs on offline root CAs. Because you do not revoke many certificates on an offline root CA, a delta CRL is probably not needed.
• Adjust the default LDAP:/// and HTTP:// URL locations on the Extensions tab of the certification authority’s Properties Extension tab according to your needs.
• Publish a CRL on an HTTP Internet or extranet location so that users and applications outside the organization can perform certificate validation. You can publish the LDAP and HTTP URLs for CDP locations to enable clients to retrieve CRL data with HTTP and LDAP.
• Remember that Windows clients always retrieve the list of URLs in sequential order until a valid CRL is retrieved.
• Use HTTP CDP locations to provide accessible CRL locations for clients running non-Windows operating systems.

Active Directory Certificate Services Best Practices

http://microsoftguru.com.au/2012/11/10/active-directory-certificate-services-best-practices/

Microsoft lab for building a two-tier certification authority PKI hierarchy

http://technet.microsoft.com/library/hh831348.aspx

Accessing the help files

• Click Start > Run > Type hh certmgr.chm