Active Directory Certificate Services

Let’s move on and briefly describe improvements to Active Directory Certificate Services (AD CS) in Windows Server 2008. We’ll focus on the following key improvements:

• Improvements to certificate Web enrollment support

• Support for Network Device Enrollment Service to allow network devices such as routers to enroll for X.509 certificates

• Support for the Online Certificate Status Protocol to easily manage and distribute certificate revocation status info

• The inclusion of PKIView for monitoring the health of Certification Authorities (CAs)

There are other improvements as well for AD CS-such as new Group Policy settings-but we’ll pass over these for now because they’ll be well documented once Windows Server 2008 RTMs. But we will also hear from the AD CS product group concerning some other enhancements to AC CS in Windows Server 2008.

Certificate Web Enrollment Improvements

Enrollment is the process of issuing and renewing X.509 certificates to users and computers when a PKI has been deployed in your enterprise. Users and computers belonging to an Active Directory domain can take advantage of a mechanism called autoenrollment, which allows them to automatically enroll domain-joined computers when they boot and domain users when they log on. Windows Server 2003 also includes a Certificate Request Wizard to enable domain users to request a new certificate manually when they need to.

Users and computers that are not domain joined or that run a non-Microsoft operating system can use Web enrollment instead. Web enrollment is built on top of Internet Information Services and allows a user to use a Web page to request a new certificate or renew an existing one over an Internet or extranet connection.

What’s changed with this feature in Windows Server 2008 is that the old XEnroll.dll ActiveX control for the Web enrollment Web application has now been retired for both security and manageability reasons. In its place, a new COM control named CertEnroll.dll is now used, which is more secure than the old control but whose use can pose some compatibility issues in a mixed environment. For reasons of time, we can’t get into these compatibility issues here, but see the “Additional Resources” section at the end of this chapter for more information on this topic.

Network Device Enrollment Service Support

Another enhancement in AD CS in Windows Server 2008 is the inclusion of built-in support for the Network Device Enrollment Service (NDES). Let’s listen to one of our experts at Microsoft briefly describe this new feature (and see the “Additional Resources” section at the end of the chapter for links to more information on the subject):

From the Experts: Network Device Enrollment Service

Network Device Enrollment Service is one of the optional components of the Active Directory Certificate Services (AD CS) role. This service implements the Simple Certificate Enrollment Protocol (SCEP). SCEP defines the communication between network devices and a Registration Authority (RA) for certificate enrollment.

SCEP enables network devices that cannot authenticate to enroll for x.509 certificates from a Certification Authority (CA). At the end of the transactions defined in this protocol, the network device will have a private key and associated certificate that are issued by a CA. Applications on the device can use the key and its associated certificate to interact with other entities on the network. The most common usage of this certificate on a network device is to authenticate the device in an IPSec session.

–Oded Shekel

Program Manager, Windows Security

Online Certificate Status Protocol Support

Another new feature of AD CS in Windows Server 2008 is support for the Online Certificate Status Protocol (OCSP). In a traditional PKI, such as one implemented using Certificate Services in Windows Server 2003, certificate revocation is handled by using certificate revocation lists (CRLs). There has to be a way of revoking certificates that expire or are compromised; otherwise, a PKI system won’t be secure. CRLs provide a way of doing this by enabling clients to download a list of revoked certificates from a CA to ensure the certificate they’re trying to verify (for example, a certificate belonging to a server the client is trying to connect to) is valid. Unfortunately, once a lot of certificates have been revoked in an enterprise, the CRL can become quite large and have an impact on performance when authenticating over slow WAN links or during peak traffic times, like the beginning of the workday when everyone is trying to log on to the network at the same time.

To improve performance in checking for revoked certificates and increase the scalability of a PKI system, Windows Server 2008 includes an optional Online Certificate Status Protocol role service you can install on a server by adding the Active Directory Certificate Services role using Server Manager. OCSP provides an Online Responder that can receive a request to check for revocation of a certificate without the client having to download the entire CRL. This speeds up certificate revocation checking and reduces the network bandwidth used for this process, which can be especially helpful when such checking is done over slow WAN links. AD CS in Windows Server 2008 even supports Responder arrays, in which multiple OCSP Online Responders are linked together to provide fault tolerance, increased scalability, or functionality needed for geographically dispersed PKI deployments.

OCSP support is described in more detail in one of the links in the “Additional Resources” section at the end of this chapter. Meanwhile, let’s hear from one of our experts at Microsoft concerning this new feature:

From the Experts: Online Responder

The Online Responder server rule implements the server component of the Online Certificate Status Protocol (OCSP).

OCSP uses Hypertext Transfer Protocol (HTTP) and allows a relying party to submit a certificate status request to an OCSP responder. This returns a definitive, digitally signed response indicating the certificate status. The Microsoft Online Responder was built with scalability, performance, security, and manageability in mind. It includes the following two components:

• Online Responder Web Proxy Cache First and foremost, this component is the service interface for the Online Responder. It is implemented as an Internet Server API (ISAPI) Extension hosted by Microsoft Windows Internet Information Services (IIS).

• Online Responder Service This component is a Microsoft Windows NT service (ocspsvc.exe) that is running with NETWORK SERVICE privileges.

• –Oded Shekel

• Program Manager, Windows Security

Enterprise PKI and CAPI2 Diagnostics

Monitoring the health of CAs in an enterprise PKI deployment is important to prevent problems from arising and to troubleshoot issues when they arise. The Windows Server 2003 Resource Kit included a tool called PKI Health that could be used to display the status of each CA in a chain of CAs; in Windows Server 2008, this tool has been renamed Enterprise PKI (PKIView) and has been re-implemented as an MMC snap-in. Using PKIView, enterprise PKI admins can check the validity or accessibility status of authority information access (AIA) locations and certificate revocation list (CRL) distribution points (CDPs) for multiple CAs within an enterprise that has a Windows Server–based PKI deployed:

PKIView isn’t the only way of troubleshooting problems with a Windows Server 2008–based PKI, however. Another useful tool is CAPI2 Diagnostics, which is described in the next sidebar contributed by one of our experts:

From the Experts: Troubleshooting PKI Problems on Windows Vista and Windows Server 2008

Microsoft Windows Vista and Microsoft Windows Server 2008 have a new feature- CAPI2 Diagnostics-that can help you with PKI troubleshooting. This feature enables administrators to troubleshoot PKI problems by collecting detailed information about certificate chain validation, certificate store operations, and signature verification. In case of errors in PKI-enabled applications, detailed information-such as the low-level API results and errors, objects retrieved, and status flags raised at different steps-is available in the logs. This functionality can help reduce the time required to diagnose problems. For troubleshooting purposes, enable CAPI2 logging, reproduce the problem, and use the data in the logs to identify the root cause. To enable logging, follow these steps:

1. Open the Event Viewer, and go to Application And Services Logs\Microsoft\ Windows\CAPI2 to get the CAPI2 channel.

2. Right-click Operational, and select Enable Log to enable CAPI2 Diagnostics logging.

3. To save the log to a file, right-click Operational and select the Save Events As option. You can save the log file in the .evtx format (which can be opened through the Event Viewer) or in XML format.

4. If there is data present in the logs before you reproduce the problem, it is recommended that you clear the logs before the repro. This allows only the data relevant to the problem to be collected from the saved logs. To clear the logs, right-click Operational and select the Clear Log option.

5. The default size for the event log is 1 MB. For CAPI2 Diagnostics, the logs tend to grow in size quickly, and it is recommended that you increase the log size to at least 4 MB to capture relevant events. To increase the log size, right-click Operational and select the Properties option. In the log properties, increase the maximum log size.

   To learn more about CAPI2 Diagnostics, check out the whitepaper titled “Troubleshooting PKI Problems on Windows Vista” at http://www.microsoft.com/downloads/details.aspx?FamilyID= & displaylang=en.

   –Yogesh Mehta

   Program Manager, Windows Security

Other AD CS Enhancements

Finally, let’s briefly hear from one of our experts on the product team at Microsoft concerning two more enhancements to AD CS in Windows Server 2008. Our first sidebar outlines some important changes to V3 certificate templates and the cryptographic algorithms they support in Windows Server 2008 (and in Windows Vista):

From the Experts: V3 Certificate Templates

One important change in Windows Server 2008 and Windows Vista is the support for CNG (Suite-B). With Suite-B algorithms, it is possible to use alternate and customized cryptographic algorithms for encryption and signing certificates.

To support these algorithms, a new certificate template version was added-V3. A V3 certificate template is enhanced in the following ways:

• Support for asymmetric algorithms implemented by a Key Service Provider (KSP) for CNG. By default, Windows implements the following algorithms: DSA, ECDH_P256, ECDH_P384, ECDH_P521, ECDSA_P256, ECDSA_P384, ECDSA_P521, and RSA.

• Support for hash algorithms implemented by a KSP. By default, Windows implements the following algorithms: MD2, MD4, MD5, SHA1, SHA256, SHA384, and SHA512.

• A discrete signature (PKCS#1 V2.1) can be required for certificate requests. Activating this option forces a client that uses the certificate autoenrollment functionality or enrolls a certificate through the Certificates MMC snap-in to generate a certificate request that carries a discrete signature. Selecting this option does not mean that a certificate that is issued from this template also carries a discrete signature. The setting applies to the certificate request only. Also, the setting is not relevant for certificate requests that are created with the certreq.exe command-line tool.

• The Advanced Encryption Standard (AES) algorithm can be specified to encrypt private keys while they are transferred to the CA.

• For machine templates, read permissions on the private key can be added to the Network Service so that services such as IIS have permission to use certificates and keys that are available in the computer’s certificate store. In previous versions of Windows, manually adjusting permissions on the computer’s certificate store is required.

• The list of asymmetric algorithms is filtered based on the template purpose in the Request Handling tab.

  –Oded Shekel

  Program Manager, Windows Security

And our second sidebar describes the new restricted enrollment agent functionality in Windows Server 2008’s implementation of Enterprise CA:

From the Experts: Restricted Enrollment Agent

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 certificates on behalf of users. Enrollment agents are typically members of the corporate security, 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.

The Windows Server 2003 Enterprise CA does not provide any configurable means to control enrollment agents except from enrollment agents’ certificates enforcement. The enrollment agent certificate is a certificate containing the Certificate Request Agent application policy extension (OID=1.3.6.1.4.1.311.20.2.1).

The restricted enrollment agent is a new functionality that allows limiting the permissions that enrollment agents have for enrolling on behalf of other users. On a Windows Server 2008 Enterprise CA, an enrollment agent can be permitted for one or many certificate templates. For each certificate template, you can configure 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. As mentioned previously, you must use security groups. Note that the restricted Enterprise enrollment agent is not available on a Standard CA.

–Oded Shekel

Program Manager, Windows Security