If you have commonly asked questions about certificate services or PKI that you think should be listed in the Active Directory Certificate Services Frequently Asked Questions (AD CS FAQ) list, I encourage you to submit them to the TechNet Wiki posting http://social.technet.microsoft.com/wiki/contents/articles/ad-cs-faq.aspx. Don't worry about the formatting, I can clean that up, if needed. Also, if you would rather have me add something for you, feel free to just reply to this blog. Thank you!

The following documentation updates have been recently made:

1. AD CS: Deploying Cross-forest Certificate Enrollment - updated with a link to the download center version of the document
2. Additional documents added to the "future" consolidated download center page for Active DIirectory Certificate Services (AD CS)@http://go.microsoft.com/fwlink/?LinkId=212919
3. Note added to Identify a Key Recovery agent to point to information about the differences between Certificate Template Versions
4. Added a question/answer about ADCS on ServerCore to the AD CS FAQ.
5. Removed port 440 from an older PKI blog entry: https://www.sysadmins.lv/retired-msft-blogs/pki/firewall-rules-for-active-directory-certificate-services.aspx
6. Modified the first note in Configure CRL and Delta CRL Overlap Periods for clarity.

An important security update, described in MS11-051 (http://go.microsoft.com/fwlink/?LinkId=217101) was released today. The update fixes a cross-site scripting vulnerability in the sample web enrollment ASP pages that are part of Active Directory Certificate Services Web Enrollment in Windows Server 2003, Windows Server 2008, and Windows Server 2008 R2.

Important: Back up any sample web enrollment sample pages you modified (%windir%\system32\Certsrv) before applying MS11-051. After you apply the security update, you can integrate any changes you made to the original sample files into the new secure ASP sample pages. For more information, see Microsoft Knowledge Base Article 2518295 (http://support.microsoft.com/kb/2518295).

LDAP over SSL(LDAPS)is becoming an increasingly hot topic - perhaps it is because Event Viewer ID 1220 is catching people's attention in the Directory Service Log or just that people are wanting the client to server LDAP communication encrypted. The quick summary of what this is all about is that when an LDAP client accesses an LDAP server, the information is transferred by default in clear text. The event warns IT Professionals of the potential for communications between clients and servers of being sniffed. Considering this issue, people often wonder if Active Directory replication is done in clear text and that is NOT the case. Active Directory replication uses Kerberos and so do client password changes. Therefore, you need not worry about full database sniffing during replication to a new domain controller or getting passwords when clients are changing their domain passwords.So, only when a client computer isquerying an LDAP server[Active Directory Domain Services (ADDS)or Active Directory Lightweight Directory Services (ADLDS)/Active Directory Application Mode (ADAM)] the network communication is done in clear text unless youimplement LDAP over SSL. An article on how to implement LDAP over SSL is posted to the TechNet Wiki and when it is fleshed out to an appropriate degree it will be imported into the TechNet Library (and noted on the TechNet Wiki article).

=====

I've tried to respond to the comment below multiple times, but my replies are not getting posted for some reason. I have already updated the article on the TechNet Wiki to discuss these items, but it makes sense to also address them here briefly.

1. LDAPS is best used to protect credentials during a simple LDAP bind. This is when a user name and password could be exposed.
2. MMC snap-ins use sign and seal.
3. There is no way to make clients prefer LDAPS because the type of connection depends on the application that is running on the client computer. For example, I wrote out steps on how to verify the connection using port 636 in ADSIEdit, but that would not stop you from typing 389 or trying any other port for that matter. The application has to support it and you would have to enable it in the application or in some cases the applications require it and that causes people to realize they need to enable it on their LDAP server (domain controller or AD LDS/ADAM).
4. Blocking port 389 is a typical thing to do on an external firewall, but is not something you would do on a domain controller. The Active Directory Domain Service administration tools still use port 389, but they are protected by the sign and seal binding.

Background

On December 1, 2010 the Federal PKI Management Authority (FPKIMA), in compliance with NIST guidance, created a new SHA-256 Federal Common Policy root certification authority. Windows Update will include the new Federal Common Policy Root CA (FCPCA) certificate as part of the Microsoft Root Certificate Program on March 22, 2011. The FPKIMA will not be publishing the FCPCA certificate to subordinate certificates’ Authority Information Access locations (http://http.fpki.gov/fcpca/caCertsIssuedTofcpca.p7c). Therefore it is critical that the FCPCA certificate is deployed to systems Trusted Root Certification Authorities store to enable U.S. Federal PKI applications. The goal of this blog entry is to explain the new Federal Common Policy CA architecture, the Windows Update Root Certificate deployment process, and methods used to deploy the new Federal Common Policy CA certificate within your enterprise environments.

Federal PKI Architecture

Click the picture to maximize it to its original size.

Federal Common Policy CA Certificate

AIA:

• http://http.fpki.gov/fcpca/caCertsIssuedTofcpca.p7c
• ldap://ldap.fpki.gov/cn=Federal%20Common%20Policy%20CA,ou=FPKI,o=U.S. %20Government,c=US

CRL:

• http://http.fpki.gov/fcpca/fcpca.crl
• ldap://ldap.fpki.gov/cn=Federal%20Common%20Policy%20CA,ou=FPKI,o=U.S. %20Government,c=US

Make sure your firewalls are configured to allow the downloading of these certificates and CRLs.

Legacy SHA1 Support

The FPKIMA has also stood up a new SHA-1 certification authority (SHA-1 FRCA), subordinate to the old Common Policy, to support legacy SHA-1 certificates (e.g. HSPD-12 SHA-1 smart cards). Existing subordinate CAs to the Common Policy whose users still require a pure SHA-1 certificate path have since been issued cross certificates signed by the SHA1-FRCA. The certificates issued to these CAs from the old Common Policy CA will be revoked and published to the final Common Policy certificate revocation list (CRL). The final Common Policy CRL will not have a Next Update field and will be removed when all SHA-1 authority to operate extensions have expired. The new Federal Common Policy CA has signed a cross certificate to the SHA-1 FRCA as well.

The SHA-1 FRCA certificate will not be distributed by the Windows Update program and the certificate should be placed in a computer requiring pure SHA-1 chaining Trusted Root Certification Authorities store.

Chaining to old Common Policy

The old Common Policy CA has issued a cross certificate to the new Federal Common Policy CA to allow for the chaining to a root trust point prior to the deployment of the new Federal Common Policy CA certificate.

Enhanced Key Usage

The Enhanced Key Usage field defines one or more purposes for which the public key may be used. RFC 5280 states “in general, [sic] the EKU extension will appear only in end entity certificates.” Certification authorities’ certificates may contain EKU entries. To allow smart card logon within an Active Directory domain the smart card’s chain of trust must support the Smart Card Logon (OID 1.3.6.1.4.1.311.20.2.2) and Client Authentication (OID 1.3.6.1.5.5.7.3.2) application policies. Active Directory smart card logon is supported with the following EKU configurations:

• All certificates in the chain of trust do not assert Enhanced Key Usage (except for the end entity certificate) the anyExtendedKeyUsage EKU is implied.
• All certificates in the chain of trust do not assert Enhanced Key Usage except for the root trust point certificate. Root trust point EKU field asserts Smart Card Logon (OID 1.3.6.1.4.1.311.20.2.2) and Client Authentication (OID 1.3.6.1.5.5.7.3.2).
• All certificates in the chain of trust Enhanced Key Usage field assert Smart Card Logon (OID 1.3.6.1.4.1.311.20.2.2) and Client Authentication (OID 1.3.6.1.5.5.7.3.2).

Best practice is for the root trust point certificate not to include an Enhanced Key Usage extension. The Federal Common Policy CA certificate does not assert an EKU; therefore all application policies are implied.

Deployment methods

Windows Update

The Microsoft Root Certificate Program is a mechanism Microsoft provides to distribute root certificates via the Windows Update program. The intent of the Program is to enable PKI scenarios for the mass consumer market such as e-commerce, secure e-mail, and code signing. It is not intended to enable enterprise-only scenarios (e.g. smart card logon). The Program attaches a certificate’s EKU as metadata in the Windows certificate store.

The behavior of Windows Update placing certificates in the Trusted Root Certification Authorities store can be controlled by the group policy setting Turn off Automatic Root Certificates Update (Computer Configuration -> Policies -> Administrative Templates -> System -> Internet Communication Management -> Internet Communication settings).

The Federal Common Policy CA certificate to be deployed via the Windows Update Root Certificate Program will not contain the smart card logon OID required to enable HSPD-12 smart card logon within an enterprise environment. The smart card logon purpose must be added to the Federal Common Policy CA certificate contained within the authenticating domain controller’s Trusted Root Certification Authorities store. The domain controller is the Kerberos Key Distribution Center and performs the certificate path / policy validation and certificate revocation checks. In large scale environments modifying every domain controller’s Federal Common Policy CA certificate EKU can become an arduous task.

Group Policy and Enterprise Root CA Store

There are two methods (Group Policy and Enterprise Trusted Root Certification Authorities store) available to enterprise administrators to distribute the Federal Common Policy CA certificate to all systems within an Active Directory domain. Both deployment methods use the auto-enrollment mechanism which is traditionally controlled within the Default Domain and Default Domain Controllers Policies (Computer Configuration -> Policies -> Windows Settings -> Security Settings -> Public Key Policies -> Certificate Services Client: Auto-Enrollment).

Group Policy publication of certificates to domain computers’ Trusted Root Certification Authorities certificate store provides the ability to manipulate a certificate’s Enhanced Key Usage field. This method of deployment must be used if the root trust point certificate does not contain the EKU OIDs necessary for smart card logon.

Since the Federal Common Policy CA certificate does not have an Enhanced Key Usage extension ‘any policy’ is implied (“All application policies”). This certificate can be published to the Active Directory forest’s Trusted Root Certification Authorities store. The Federal Common Policy CA certificate will then be pushed to all domain joined computers.

To publish a certificate to the Active Directory forest’s Trusted Root Certification Authorities store type the following command with Enterprise Administrator rights certutil -f -dspublish FederalCommonPolicyCA.cer RootCA. To view the contents of the Enterprise Trusted Root Certification Authorities store type certutil -viewstore -enterprise root.

Removal of the old Common Policy Certificates

The method of removal for the old Common Policy certificates is dependent upon how the certificates were originally placed in the store:

• Group Policy – remove the Common Policy certificates from the group policy that distributes them. The next group policy refresh will remove the certificates.
• Enterprise Certificate Store – with Enterprise Administrator rights type certutil -viewdelstore -enterprise root, select the Common Policy certificate and select OK.
• Windows Update
  • Manually remove certificates – MMC -> Add/Remove Snap-In -> Certificates -> Computer Account -> <select Local or remote computer> -> Certificates -> Trusted Root Certification Authorities -> Certificates -> Right click, Delete
  • Powershell– The following PowerShell script takes two command line arguments ComputerName and CertificateSerialNumber. Save the PowerShell script into a file named "delete_cert.ps1". For example to remove the Common Policy certificate from a computer named DC1 the command would be ./delete_cert.ps1 DC1 39e3815404c50ab247effef336cfc698

Automatic Root Certificates Update Behavior on Vista and Higher Operating Systems

If the group policy setting Turn off Automatic Root Certificates Update (Computer Configuration -> Policies -> Administrative Templates -> System -> Internet Communication Management -> Internet Communication settings) is not enabled on Vista and higher operating systems the new Federal Common Policy CA certificate will appear in the Trusted Root Certification Authorities store after a chaining event. If you delete the old Common Policy certificate it may reappear in the computer’s certificate store. When a chaining operation occurs and the root certificate is not in the computer’s Trusted Root Certification Authorities store, the system will call Windows Update to retrieve the root trust certificate. Even if there is no network connectivity to the Windows Update site the system’s crypt32.dll contains root certificates that were published via Windows Update when the operating system was released to market. The root certificate will be retrieved and placed in the computer’s Trusted Root Certification Authorities store.

Intermediate Certification Authorities

To facilitate chaining all intermediate certification authorities’ certificates can be distributed within the enterprise environment. Consult with your HSPD-12 Share Service Provider (SSP) before deploying to identify any potential chaining issues during this transition period.

More Information

• Microsoft officially supports SHA-256 starting with the Vista operating system. Here is a TechNet PKI Blog entry explaining what operating systems and applications work with SHA-256 prior to the release of Vista. Please note this is not an assertion of what is supported but more of what has been tested and works.
• How to configure your environment to support HSPD-12 smartcard logon.