Chapter 9: Hardening Active Directory Certificate Services

  • Article

 

Active Directory® Certificate Services (AD CS) in Windows Server® 2008 provides services that you can customize to create and manage public key certificates in software security systems that employ public key technologies, including version 3 of X.509 certificates. Organizations can use AD CS to enhance security by binding the identity of a person, device, or service to a corresponding key pair. AD CS also includes features that allow you to manage certificate enrollment and revocation in a variety of scalable environments.

The role services available for the AD CS role are displayed in the following figure.

5062d77e-fa42-4795-bce2-4f69ce1e7d9a

Figure 9.1. Role services hierarchy for the AD CS role

This chapter can help you harden server computers that perform the AD CS role. This chapter provides prescriptive guidance for hardening each of the role services available for the AD CS role. Because each AD CS role service has a distinct function, identify those that you want to configure on your server computer, and then use the recommendations in this chapter to harden each role service.

Note The AD CS role service is not available on Server Core installations of Windows Server 2008 or Windows Server 2008 for Itanium-Based Systems.

For more information about the AD CS role service, see Active Directory Certificate Services.

Certification Authority Role Service

The Certification Authority role service allows you to install root and subordinate certification authorities (CAs) to issue certificates to users, computers, and services, and to manage certificate validity.

Requirements to install these CAs include the following:

  • To install a root CA, membership in the local Administrators group, or equivalent, is the minimum requirement to complete this procedure. If you are installing an enterprise CA, membership in Domain Admins, or equivalent, is the minimum requirement to complete this procedure. For more information, see "Implement Role-Based Administration" in the Help and Support for Windows Server 2008.
  • To install a subordinate CA, membership in the local Administrators group, or equivalent, is the minimum requirement to complete this procedure. If you are installing an enterprise CA, membership in Domain Admins, or equivalent, is the minimum requirement to complete this procedure. For more information, see "Implement Role-Based Administration" in the Help and Support for Windows Server 2008.

Attack Surface

The Certification Authority role service is susceptible to the same security attacks as any CA. To identify the attack surface for this role service, you need to identify the:

  • Installed files. These are files that are installed as part of the Certification Authority role service.

  • Running services. These are services that run as part of the Certification Authority role service.

Note You can use the RootkitRevealer and Sigcheck utilities that are part of Windows Sysinternals to verify the integrity of the installed files and the files that the services run.

  • Firewall rules. These are the Windows Firewall rules that the Certification Authority role service uses.

  • Role dependencies. These are the dependencies for the Certification Authority role service.

The details of the attack surface for the Certification Authority role service are included in the Windows Server 2008 Attack Surface Reference workbook that accompanies this Solution Accelerator. To view the attack surface for this role service, on the AD CS tab of the workbook, view the sections that correspond to each of the items in the previous list.

Security Measures

This section describes the security measures that you can incorporate into your Certification Authority role service configuration to protect the server against malicious attacks. The recommendations that follow assume that you have only selected the Certification Authority role service option on the Select Role Services page of the Add Roles Wizard. Recommendations for other role services are not included.

Configuration Checklist

The following table summarizes the recommended security configuration tasks for hardening servers performing the Certification Authority role service. If you need help to complete any of the checklist items, see the following sections in this chapter for additional details and recommendations.

Table 9.1. Configuration Checklist

Configuration tasks

 

Deploy an offline root certification authority (CA).

 

Protect CAs by using a hardware security module (HSM).

 

Deploy an offline policy CA.

 

Publish the certificates and CRLs in AD DS.

 

Deploy enterprise subordinate CAs.

 

Publish both CRLs and delta CRLs.

 

Limit the types of certificates that a CA can issue.

 

Implement role separation based on Common Criteria specifications.

 

Require multifactor authentication for users with PKI management roles.

 

Avoid placing policy OIDs and CDP or AIA certificate extensions in root certificates.

Note These recommendations are based on the assumption that your public key infrastructure (PKI) is based on the Rooted Trust Model.

Deploy an Offline Root CA

Although all CAs in a public key infrastructure (PKI) are sensitive, the root CA is the most sensitive because if it is compromised, the entire PKI can be compromised. The root CA is the single point of trust for an entire organization for several organizations.

Important In larger environments, subordinate policy CAs may play the same role as a root CA for different divisions or business units. Deploy these subordinate policy CAs as offline CAs.

To help prevent the root CA from being compromised, Microsoft recommends taking the following security measures:

  • Deploy the root CA as an offline, stand-alone CA. Deploy the root CA as an offline CA to help prevent network attacks. To deploy an offline root CA, you must deploy the CA as a stand-alone CA because offline enterprise CAs are not supported. For more information about deploying stand-alone CAs, see the following topics in the Help and Support for Windows Server 2008:
  • "Stand-alone Certification Authorities."
    • "Enterprise Certification Authorities."
    • "Install a Root Certification Authority."
  • Protect the computer that is the root CA. To further protect the root CA, do one or more of the following security measures:
    • Store the offline CA computers in a physically secure room. Rather than storing offline CA computers in the standard server room, consider storing the offline CAs in a limited-access server room or in a safe. Allow only those with CA Administration roles to enter the server room or open the safe, and record all attempts to access the server room. Alternatively, you could enforce physical access logs, where any access to the CA computers is logged.
    • Store the CA computers in a secured cage. Certain models of server cages are available that require PIN codes to open. Some models even track all attempts to access the server cage and allow retrieval of the access logs via serial connections.
    • Store offline CA-related hardware in a separate, secured location. Some organizations remove the hard disk drives from the CA computers and store them in a remote safe, which requires an attacker to gain access to both the server computer and the hard disk drives before gaining access to an offline CA. This methodology allows companies to use the offline server computer for other uses when the CA is removed from the network.
    • Install the root CA in a virtual environment and store this virtual image in a separate, secured location. This is a variation of storing offline CA computers in a physically secure room. In this case, the offline CA computer is a virtual image instead of a physical computer.

Protect CAs by Using an HSM

Protect CAs, especially the root CA, using a hardware security module (HSM) with a HSM-operator hardware token to limit access to the CA private key. In addition to limiting access to the CA private key, most HSMs are also hardware cryptographic accelerators that provide better performance than a normal software-based cryptographic system. For more information about HSM, see "Set Up a Certification Authority by Using a Hardware Security Module" in the Help and Support for Windows Server 2008.

Deploy an Offline Policy CA

A policy CA is a type of intermediate CA that is typically used to separate classes of certificates that can be distinguished by policy. For example, policy separation includes the level of assurance that a CA provides or the geographical location of the CA to distinguish different end-entity populations. A policy CA can be online or offline.

Use secure procedures to publish the certificate and CRL of an offline CA. You only need to publish the certificate of the offline CA one time. However, the CRL for the offline CA must be published at regular intervals that correspond to the CRL publication interval value that is configured in the Revoked Certificates Properties of the offline CA.

If the offline CA is maintained in a secure location, such as a data center or vault, it is best if more than one administrator or trusted person publishes the offline CRL within that location, as prescribed in the certificate policy and certificate practice statements for your organization. After the CRL is published, you must transfer it manually from the data center or vault to a location where it can be distributed to your CRL distribution points.

Publish the offline CRL at least several days before the previously issued CRL is set to expire. This allows you to correct any hardware problems or publication failures in advance, ensuring that no interruption in service happens when your offline CRLs are published and replicated to all CRL Distribution Point (CDP) locations.

After the offline CA is installed, configure the various constraint and policy options for certificates that the offline CA issues. These extensions are necessary to ensure that the applications and clients that use the certificates in the hierarchy can perform revocation and chain building as needed.

Microsoft recommends to deploy an offline policy CA by using the same recommendations listed in "Deploying an Offline Root CA" earlier in this chapter. The offline policy CA should be treated similarly to the root CA from a security perspective. However, the policy CA will be brought online more frequently than a root CA.

Publish Certificates and CRLs in AD DS

If your organization uses its PKI to provide certificates for domain users and computers, Microsoft recommends to publish certificates and CRLs in AD DS. AD DS provides a secured repository for certificates and CRLs. By default, the certificates and CRLs are accessed by using Lightweight Directory Access Protocol (LDAP). If the certificates and CRLs cannot be accessed by LDAP, then other methods are attempted if your PKI is configured to publish certificates and CRLs using other publishing methods, such as HTTP.

Both enterprise and stand-alone CAs can publish the certificates and CRLs to Active Directory. By default, enterprise CAs publish certificates and CRLs to the domain in which the CA is a member. You must manually publish certificates and CRLs to other domains and forests. You also must manually configure a stand-alone CA to publish certificates and CRLs in Active Directory.

To install a stand-alone CA so that it will publish its CA certificates and CLR to AD DS, you must be a member of the Domain Admins group of the parent domain in the enterprise, or an administrator with Write access to AD DS. For more information about how to publish a certificate or CRL to Active Directory on a stand-alone CA, see "To publish as certificate or CRL to Active Directory" in Certutil tasks for managing CRLs.

Deploy Enterprise Subordinate CAs

If your organization primarily uses its PKI in your intranet, deploy enterprise subordinate CAs because they automatically publish certificates and CRLs in AD DS. For more information about the advantages of publishing certificates and CRLs in AD DS, see the previous section "Publish Certificates and CRLs in AD DS" in this chapter.

For more information about deploying enterprise subordinate CAs, see the following topics in the Help and Support for Windows Server 2008:

  • "Enterprise Certification Authorities."
  • "Install a Subordinate Certification Authority."

Publish Both CRLs and Delta CRLs

CRLs can become very long on large CAs that have experienced significant amounts of certificate revocation. This can become a burden for client computers to download frequently. To help minimize frequent downloads of lengthy CRLs, you can publish delta CRLs. This allows client computers to download the most current delta CRL and combine that with the most current base CRL to maintain a complete list of revoked certificates. Because client computers normally store CRLs locally, using delta CRLs can potentially improve performance.

To use delta CRLs, the client application must be aware of and explicitly use delta CRLs for revocation checking. If the client computer does not use delta CRLs, it will retrieve the CRL from the CA every time it refreshes its cache, regardless of whether a delta CRL exists or not. For this reason, ensure to verify that the intended applications use delta CRLs and configure the CA accordingly. If the client computers do not support the use of delta CRLs, either do not configure the CA to publish delta CRLs or configure it so that CRLs and delta CRLs publish at the same interval. This allows new applications that support delta CRLs to use them, while providing current CRLs to all existing applications.

Note All applications that use CryptoAPI in Windows® XP, Windows Vista®, Windows Server® 2003, and Windows Server 2008 use delta CRLs.

Limit the Types of Certificate That a CA Can Issue

Deploy CAs that will issue a specific type of certificate. For example, if you need to issue certificates for smart card authentication or e-mail signing, deploy a CA dedicated to issuing smart card authentication certificates and another CA dedicated to issuing e-mail signing certificates. You can restrict the types of certificates that a CA may issue by using certificate templates. For more information about certificate templates, see Certificate Template Overview.

Implement Role Separation Based on Common Criteria Specifications

Role-based administration is used to organize CA administrators into separate, predefined task-based roles. Microsoft recommends to distribute the management roles among several individuals in your organization to ensure that a single individual cannot compromise PKI services. Role separation enables one person to audit the actions of another person.

Important Limit the number of users that manage your CAs because CAs play a critical security role in a PKI.

Some Common Criteria PKI management roles include the following:

  • PKI Administrator. Configures and maintains the CA, designates other CA administrators and certificate managers, and renews CA certificates.
  • Certificate Manager. Approves or denies certificate enrollment requests and revokes issued certificates.
  • Backup** Operator**. Performs backups of the CA database, the CA configuration, and the CA’s private and public key pair (also known as a key pair).
  • Audit** Manager**. Defines what events are audited for Certificate Services and reviews the security log in Windows Server 2003 for success and failure audit events that are related to Certificate Services.
  • Key Recovery Manager. Requests retrieval of a private key stored by the service.
  • Enrollee. Requests certificates form the CA.

For more information on implementing role separation based on Common Criteria specifications, see Defining PKI Management and Delegation.

Require Multifactor Authentication for Users with PKI Management Roles

Human authentication factors are generally classified into the following cases:

  • The user knows specific information, such as a password, pass phrase, or personal identification number (PIN).
  • The user has a specific device, such as a smart card, security token, software token, phone, or cell phone.
  • The user provides a human attribute through an action, such as a fingerprint or retinal pattern, DNA sequence, signature or voice recognition, unique bio-electric signals, or another biometric identifier.

Often organizations use a combination of these methods. For example, a debit card and a PIN, which is also known as two-factor authentication.

You can use multifactor authentication to enhance the level of authentication in your organization, compared to only requiring users to provide a password. Multifactor authentication typically includes a physical device, such as a smart card reader, USB security token, or fingerprint reader. Selecting physical devices for multifactor authentication is based on nonsecurity related requirements.

For example, your organization could require smart cards for users that include picture identification, as you can print a picture and a name on the smart card. However, a smart card requires a reader, which may introduce additional costs. A USB token can include flash memory for storing documents and files, and users can plug a USB token into existing USB ports on their computers.

This form of security is recommended for accounts with PKI management roles. Specifically, require multifactor authentication for users who perform the following PKI management roles:

  • PKI Administrator
  • Certificate Manager
  • Backup Operator
  • Audit Manager
  • Key Recovery Manager

Note If possible, use multifactor authentication throughout the organization to ensure that the strongest possible passwords are required for user accounts. Using multifactor authentication causes the system to automatically generate cryptographically strong random passwords for accounts.

Avoid Placing Policy OIDs and CDP or AIA Certificate Extensions in Root Certificates

As a best practice, Microsoft recommends to avoid placing policy object identifiers (OIDs) in root certificates. By definition, a root CA implements all policies. This applies to both Enterprise and Stand-alone CAs.

At some point in the hierarchy, a CA can have one or more policies defined. When a CA certificate is encountered with any policy OIDs, all certificates below that CA in the hierarchy must also have a subset of those policy OIDs. A certificate chain with no valid policy set will be considered invalid, whereas one with no policy OIDs at all will be considered valid and match the "any policy" OID. This is valid only for Application Policies and not Issuance Polices. For issuance policy, the absence of the certificatePolicies extension in a non-root certificate implies no issuance policy.

In addition, avoid placing the CRL Distribution Point (CDP) and Authority Information Access (AIA) extensions in root certificates because some applications do not check for root CA revocation.

Relevant Group Policy Settings

There are no Group Policy settings available for the Certification Authority role service.

More Information

The following resources on Microsoft.com provide further security best practice information about how to harden server computers running the Certification Authority role service:

Certification Authority Web Enrollment Role Service

The Certification Authority Web Enrollment role service provides an enrollment mechanism for you to issue and renew certificates for the following resources:

  • Users and computers that are members of your domain.
  • Users and computers that are not joined to your domain.
  • Users and computers that are not connected directly to your intranet.
  • Users running operating systems other than Windows®.
  • Downloading certificate trust lists.

Instead of using the auto-enrollment feature of a CA or the Certificate Request Wizard, you can allow users to request and obtain new and renewed certificates over an Internet or intranet connection by using the Certification Authority Web Enrollment role service.

To install the Certification Authority Web Enrollment role service, membership in Domain Admins, or equivalent, is the minimum requirement to complete this procedure. For more information, see "Implement Role-Based Administration" in the Help and Support for Windows Server 2008.

For more information about the Certification Authority Web Enrollment role service, see AD CS: Web Enrollment.

Role Attack Surface

The Certification Authority Web Enrollment role service is susceptible to the same security attacks as any CA. To identify the attack surface for this role service, you need to identify the:

  • Installed files. These are files that are installed as part of the Certification Authority Web Enrollment role service.

  • Running services. These are services that run as part of the Certification Authority Web Enrollment role service.

Note You can use the RootkitRevealer and Sigcheck utilities that are part of Windows Sysinternals to verify the integrity of the installed files and the files that the services run.

  • Firewall rules. These are the Windows Firewall rules that the Certification Authority Web Enrollment role service uses.

  • Role dependencies. These are the dependencies for the Certification Authority Web Enrollment role service.

Security Measures

This section describes the security measures that you can incorporate into your Certification Authority Web Enrollment role service configuration to protect the server against malicious attacks. The recommendations that follow assume that you have only selected the Certification Authority Web Enrollment role service option on the Select Role Services page of the Add Roles Wizard. Recommendations for other role services are not included.

Configuration Checklist

The following table summarizes the recommended security configuration tasks for hardening servers performing the Certification Authority Web Enrollment role service. If you need help to complete any of the checklist items, see the following sections in this chapter for additional details and recommendations.

Table 9.2. Configuration Checklist

Configuration tasks

 

Enable Windows Authentication for intranet-based requests.

 

Protect certificate enrollment requests and responses by using Secure Sockets Layer (SSL) encryption.

 

Dedicate a computer to the Certification Authority Web Enrollment role service.

 

Perform the hardening recommendations for the Web Services (IIS) server role.

 

Configure a user account as the designated registration authority.

Enable Windows Authentication for Intranet-Based Requests

When you install the Certificate Web Enrollment role service, the CertSrv and CertEnroll virtual directories are created in the Default Web Site. By default, anonymous authentication is used to access these virtual directories. If the Certificate Web Enrollment role service only services intranet-based computers, you can configure these virtual directories to use Windows Authentication.

Windows authentication uses the NTLM or Kerberos protocols to authenticate client computers. Windows authentication is best suited for an intranet environment. Windows authentication is typically not suited for use over the Internet. Instead use either Basic or Digest authentication for use over the Internet and encrypt all traffic by using SSL.

Important Do not enable anonymous access to the CertSrv and CertEnroll virtual directories that are created in the Default Web Site.

For more information about configuring a Web site to use Windows Authentication, see IIS 7.0: Configuring Authentication in IIS 7.0.

Protect Certificate Enrollment Requests and Responses by Using SSL Encryption

By default, the CertSrv and CertEnroll virtual directories created in the Default Web Site use HTTP. The HTTP protocol sends the certificate enrollment requests and responses in plaintext. Microsoft strongly recommends that you protect this traffic by using SSL encryption.

For more information about how to configure a Web site to protect traffic by using SSL encryption, see "Encrypt data sent between the Web server and client" in the Help and Support for Windows Server 2008.

Dedicate a Computer to the Certification Authority Web Enrollment Role Service

Install the Certification Authority Web Enrollment role service on a computer dedicated to the role service. Although you can install this role service on the same computer that runs the Certification Authority role service, doing so increases the attack surface of the Certification Authority role service.

Installing the Certification Authority Web Enrollment role service on a dedicated computer diverts Web-based traffic from the computer running the Certification Authority role service.

You may want to install the Certification Authority Web Enrollment role service on more than one computer depending on the type of users you are supporting. For example, if you are supporting:

  • Users in your intranet, then you may want to install one or more computers running the Certification Authority Web Enrollment role service in your intranet.
  • Users on the Internet, then you may want to install one or more computers running the Certification Authority Web Enrollment role service in a perimeter network or extranet in your organization.

Perform the Hardening Recommendations for the Web Services (IIS) Server Role

Because this role service runs on IIS 7.0, ensure to perform the hardening recommendations for the Web Services (IIS) server role. For more information about hardening the Web Services (IIS) Server role, see Chapter 6, "Hardening Web Services" in this guide.

Configure a User Account as the Designated Registration Authority

The Certification Authority Web Enrollment role service needs a set of credentials that it uses to authenticate with the Certification Authority when requesting a certificate, which is known as the designated registration authority.

Microsoft recommends creating a user account to serve as the designated registration authority instead of using the network service account (NetworkService) for this purpose. This is because you can assign only the necessary rights and permissions to a user account, while the NetworkService account may have more rights and permissions than are necessary. In addition, you could affect other software running on the computer if you change the rights and permissions granted to the NetworkService account. The user account must be a member of the Domain and you must add it to the local IIS_IUSRS group.

Relevant Group Policy Settings

There are no Group Policy settings available for the Certification Authority Web Enrollment role service.

More Information

The following resources on Microsoft.com provide further security best practice information about how to harden server computers running the Certificate Authority Web Enrollments role service:

Online Responder Role Service

Certificate revocation is a necessary part of the process of managing the certificates issued by your CAs. The most common means of communicating certificate revocation status is by distributing certificate revocation lists (CRLs). However, in public key infrastructures (PKIs) where the use of conventional CRLs is not an optimal solution, the Online Responder role service can manage and distribute revocation status information by using the Online Certificate Status Protocol (OCSP).

The primary disadvantage of conventional CRLs is their potentially large size, which limits the scalability of the CRL approach. The large size adds significant bandwidth and storage burdens to the CA and relying party, and therefore limits the ability of the system to distribute the CRL. Bandwidth, storage space, and CA processing capacity can also be negatively affected if the publishing frequency gets too high.

Numerous attempts have been made to solve the CRL size issue through the introduction of partitioned CRLs, delta CRLs, and indirect CRLs. All these approaches have added complexity and cost to the system without providing an ideal solution to the underlying problem.

Another drawback of conventional CRLs is latency. Because the CRL publishing period is predefined, information in the CRL might be out of date until a new CRL or delta CRL is published.

Note Microsoft natively supports only CRL and delta CRL in operating systems prior to the Windows Vista operating system. Windows Vista and the Windows Server 2008 will natively support CRL, delta CRL, and OCSP as a method of determining certificate status. The OCSP support includes both the client component as well as the Online Responder, which is the server component.

The Online Responder role service decodes revocation status requests for specific certificates, evaluates the status of these certificates, and then sends back a signed response containing the requested certificate revocation status information.

To install the Online Responder role service, membership in local Administrators, or equivalent, is the minimum requirement to complete this procedure. To configure a CA to support the Online Responder role service, membership in Domain Admins or Enterprise Admins, or equivalent, is the minimum requirement to complete this procedure. For more information about these aspects of administering a PKI, see "Implement Role-Based Administration" in the Help and Support for Windows Server 2008.

For more information about the Online Responder role service, see AD CS: Online Certificate Status Protocol Support.

Attack Surface

The Online Responder role service is susceptible to many of the same security attacks as any server computer that publishes CRLs. To identify the attack surface for this role service, you need to identify the:

  • Installed files. These are files that are installed as a part of the Online Responder role service.

  • Running services. These are services that run as a part of the Online Responder role service.

Note You can use the RootkitRevealer and Sigcheck utilities that are part of Windows Sysinternals to verify the integrity of the installed files and the files that the services run.

  • Firewall rules. These are the Windows Firewall rules that the Online Responder role service uses.

  • Role dependencies. These are the dependencies for the Online Responder role service.

Security Measures

This section describes the security measures that you can incorporate into your Online Responder role service configuration to protect the server against malicious attacks. The recommendations that follow assume that you have only selected the Online Responder role service option on the Select Role Services page of the Add Roles Wizard. Recommendations for other role services are not included.

Configuration Checklist

The following table summarizes the recommended security configuration tasks for hardening servers performing the Online Responder role service. If you need help to complete any of the checklist items, see the following sections in this chapter for additional details and recommendations.

Table 9.3. Configuration Checklist

Configuration tasks

 

Enable Windows Authentication for intranet-based requests.

 

Protect certificate revocation status requests and responses by using SSL encryption.

 

Protect the OCSP signing keys by using an HSM.

 

Protect the Online Responder in extranet deployment scenarios.

 

Perform the hardening recommendations for the Web Services (IIS) server role.

 

Configure a user account as the designated registration authority.

Enable Windows Authentication for Intranet-Based Requests

When you install the Online Responder role service, the ocsp virtual directory is created in the Default Web Site. By default, anonymous authentication is used to access this virtual directory. When the Online Responder only services intranet-based computers, you can configure the ocsp virtual directory to use Windows Authentication.

Windows authentication uses the NTLM or Kerberos protocols to authenticate client computers. Windows authentication is best suited for an intranet environment. Windows authentication is typically not suited for use over the Internet. Instead use either Basic or Digest authentication for use over the Internet and encrypt all traffic by using SSL.

For more information about configuring a Web site to use Windows Authentication, see IIS 7.0: Configuring Authentication in IIS 7.0.

Protect Certificate Revocation Status Requests and Reponses by Using SSL Encryption

By default, the ocsp virtual directory created in the Default Web Site uses HTTP. The HTTP protocol sends the certificate revocation status requests and responses in plaintext. Microsoft strongly recommends that you protect this traffic by using SSL encryption.

For more information about how to configure a Web site to protect traffic by using SSL encryption, see "Encrypt data sent between the Web server and client" in the Help and Support for Windows Server 2008.

Protect the OCSP Signing Key by Using an HSM

OCSP digitally signs each successful request so that the requestor knows the revocation response came from a legitimate server. The Online Responder role service signs the responses by using an OCSP signing key. The signing key can be obtained from a CA or HSM.

An HSM can be a plug-in card (PCI) or external device, such as a USB, PCMCIA, SCSI, or RS232 device that generates and stores long term secrets for use in cryptography. An HSM also physically protects access to the secrets. The primary advantage of an HSM is that it provides stronger security for the signing keys that the Online Responder role uses because the HSM is a physical device.

Another advantage is that most HSMs are also hardware cryptographic accelerators. Since the HSMs do not allow the keys to be removed from the device in an unencrypted form, they must be able to perform common cryptographic operations, and they provide better performance than a normal software-based cryptographic system.

For more information about how to configure the Online Responder to use an HSM to protect OCSP signing keys, see "Using an HSM to protect OCSP signing keys" in Installing, Configuring, and Troubleshooting the Microsoft Online Responder (Microsoft's OCSP Responder).

Protect the Online Responder in Extranet Deployment Scenarios

When you deploy extranet-facing Online Responders, one of the design considerations is to define the level of protection to provide for the Online Responder signing key. The following figure shows two options for protecting the Online Responder.

78f5dbc9-52f1-4f58-9786-852583cea27e

Figure 9.2. Extranet deployment options

In diagram 1 of the previous figure, the Online Responder is located in a protected local area network (LAN), while all requests are redirected by an authenticated server that is running IIS, which is located in a perimeter network (also known as DMZ, demilitarized zone, and screened subnet).

The advantage of such a deployment model is that the firewall configuration requires only pass-through traffic for TCP port 80 for HTTP traffic or TCP port 443 for HTTPS traffic between IIS and the Online Responder. You can achieve similar results by using the reverse-proxy capability of Microsoft Internet Security and Acceleration (ISA) Server as demonstrated in diagram 2 in the previous figure.

For more information about how to protect the Online Responder in extranet deployment scenarios, see "Using an HSM to protect OCSP signing keys" in Installing, Configuring, and Troubleshooting the Microsoft Online Responder (Microsoft's OCSP Responder).

Perform the Hardening Recommendations for the Web Services (IIS) Server Role

Because this role service runs on IIS 7.0, ensure to perform the hardening recommendations for the Web Services (IIS) server role. For more information about hardening the Web Services (IIS) server role, see Chapter 6, "Hardening Web Services" in this guide.

Configure a User Account as the Designated Registration Authority

The Online Responder role service needs a set of credentials that it uses to authenticate with the Certification Authority when requesting a certificate, which is known as the designated registration authority.

Microsoft recommends creating a user account to serve as the designated registration authority instead of using the network service account (NetworkService) for this purpose. This is because you can assign only the necessary rights and permissions to a user account, while the NetworkService account may have more rights and permissions than are necessary. In addition, you could affect other software running on the computer if you change the rights and permissions granted to the NetworkService account. The user account must be a member of the Domain and you must add it to the local IIS_IUSRS group.

Relevant Group Policy Settings

There are no Group Policy settings available for the Online Responder role service.

More Information

The following resources provide further security best practice information about how to harden server computers running the Online Responder role service:

Network Device Enrollment Service Role Service

The Network Device Enrollment Service (NDES) role service allows routers and other network devices that do not have Windows accounts to obtain certificates. 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 that cannot otherwise be authenticated on the network, to enroll for X.509 certificates from a CA.

To configure the Network Device Enrollment Service role service, membership in the Administrators group is the minimum requirement to complete this procedure. For more information, see "Implement Role-Based Administration" in the Help and Support for Windows Server 2008.

For more information about this role service, see the following resources:

Attack Surface

The NDES role service is susceptible to many of the same security attacks as any CA. To identify the attack surface for this role service, you need to identify the:

  • Installed files. These are files that are installed as part of the NDES role service.

  • Running services. These are services that run as part of the NDES role service.

Note You can use the RootkitRevealer and Sigcheck utilities that are part of Windows Sysinternals to verify the integrity of the installed files and the files that the services run.

  • Firewall rules. These are the Windows Firewall rules that the NDES role service uses.

  • Role dependencies. These are dependencies for the NDES role service.

Security Measures

This section describes the security measures that you can incorporate into your NDES role service configuration to protect the server against malicious attacks. The recommendations that follow assume that you have only selected the Network Device Enrollment Service role service option on the Select Role Services page of the Add Roles Wizard. Recommendations for other role services are not included.

Configuration Checklist

The following table summarizes the recommended security configuration tasks for hardening servers performing the NDES role service. If you need help to complete any of the checklist items, see the following sections in this chapter for additional details and recommendations.

Table 9.4. Configuration Checklist

Configuration tasks

 

Configure a user account as the designated registration authority.

 

Configure the strongest possible security for the Registration Authority.

Configure a User Account as the Designated Registration Authority

The NDES role service needs a set of credentials that it uses to authenticate with the Certification Authority when requesting a certificate, which is known as the designated registration authority.

If you use the NDES role service, Microsoft recommends creating a user account to serve as the designated registration authority instead of using the network service account (NetworkService) for this purpose. This is because you can assign only the necessary rights and permissions to a user account, while the NetworkService account may have more rights and permissions than are necessary. In addition, you could affect other software running on the computer if you change the rights and permissions granted to the NetworkService account. The user account must be a member of the Domain and you must add it to the local IIS_IUSRS group.

For more information about how to configure a user account as the designated registration authority, see "Configure the Network Device Enrollment Service" in the Help and Support for Windows Server 2008.

Configure the Strongest Possible Security for the Registration Authority

The NDES role service uses two certificates and their keys to enable device enrollment. One certificate and key is used to avoid repetition of communication between the CA and the Registration Authority. The other certificate and key are used to secure communication between the Registration Authority and the network device.

Organizations might want to use different Cryptographic Service Providers (CSPs) to store these keys, or they may want to change the length of the keys used by the service. You can specify the configuration for the Registration Authority when you install the NDES role service on the Configure Cryptography for Registration Authority page. Microsoft recommends that you keep the default settings unless you have specific requirements otherwise.

Note Only Cryptographic Application Programming Interface (CryptoAPI) Service Providers are supported for the Registration Authority keys. Cryptography API: Next Generation (CNG) providers are not supported.

Relevant Group Policy Settings

There are no Group Policy settings available for the NDES role service.

More Information

The following resources provide further security best practice information about how to harden server computers running the NDES role service:

More Information

The following resources on Microsoft.com provide further security best practice information about how to harden server computers running AD CS role services:

This accelerator is part of a larger series of tools and guidance from Solution Accelerators.
Download

Get the Windows Server 2008 Security Guide

Get the GPOAccelerator
Solution Accelerators Notifications

Sign up to learn about updates and new releases
Feedback

Send us your comments or suggestions