Export (0) Print
Expand All

AD CS: Deploying Cross-forest Certificate Enrollment

Updated: December 2, 2012

Applies To: Windows Server 2008 R2, Windows Server 2008 R2 with SP1

This topic provides guidance and procedures for deploying CAs and configuring AD CS for cross-forest certificate enrollment in a multiforest environment.

TipTip
  1. Starting with Windows Server 2008 R2, you can utilize Certificate Enrollment Web Services to provide certificates across forests that do not require forest trust relationships. For a lab demonstration of such a configuration using Windows Server® 2012, see the Test Lab Guide Mini-Module: Cross-Forest Certificate Enrollment using Certificate Enrollment Web Services.

  2. To download a copy of this document, see Active Directory Certificate Services (http://go.microsoft.com/fwlink/?LinkId=212919) at the Microsoft Download Center and download AD_CS Cross_Forest document in the file format you prefer. You may also use one of these direct links AD_CS_Cross_Forest.doc or AD_CS_Cross_Forest.pdf.

To deploy AD CS for cross-forest certificate enrollment, complete the procedures in the following sections of this guide:

  • Deploying AD CS for cross-forest certificate enrollment describes procedures for deploying and configuring AD CS and PKI objects in Active Directory (AD). Procedures in this section are used for both deployment scenarios.

  • Consolidating certificate templates from multiple forests describes procedures for consolidating certificate templates from multiple per-forest AD CS deployments into a single PKI. Consolidation tasks are not required for new AD CS deployments.

  • Copying PKI objects to account forests describes procedures and scripts for copying PKI objects from AD in the resource forest to account forests. The procedures described for copying PKI objects to account forests are required for new AD CS deployments and consolidated deployments. After deployment, the procedures for copying PKI objects can be used to distribute certificate templates from the resource forest to the account forests, which is necessary to maintain consistency of PKI objects in all forests.

Review this entire guide and plan your deployment.

Test your deployment plan in a lab or other non-production environment.

Review this guide again with the test results and improve your plan before production deployment.

Complete the procedure to deploy and configure AD CS for both cross-forest scenarios: New AD CS deployments and Consolidated AD CS deployments.

To deploy and configure AD CS

  1. Designate a resource forest. All other forests participating in cross-forest certificate enrollment are account forests. AD CS is deployed in the resource forest to provide certificate enrollment services to domain members in all account forests.

    When consolidating AD CS deployments from multiple forests, you can designate an existing account forest as the resource forest. In many cases, the forest with the largest number of CAs is the best candidate for being designated a resource forest.

    Alternatively, a resource forest can be used solely for management of account forests and hosting AD CS for cross-forest enrollment. Two-way trusts between the resource forest and each account forest are required but trust relationships between account forests are not required for cross-forest enrollment.

  2. Create a two-way forest trust between the resource forest and account forests. See Create a two-way, forest trust for both sides of the trust.

    noteNote
    If Selective Authentication is required for the forest trust, the following permissions are required:

    • Domain member computers and users in account forests must have Allow authenticate permissions to the enterprise CAs in the resource forest.

    • Enterprise CAs in the resource forest must have Allow authenticate permissions to the domain controllers in each account forest.

    • Administrators that run the scripts provided with this guide must have Allow authenticate permissions to the domain controllers in all forests. For example, if the scripts are run on a domain member computer in the resource forest, the administrator must have Allow authenticate permissions in each account forest.

  3. Establish a root CA in the resource forest by deploying a new root CA or by designating an existing standalone or enterprise root CA.

  4. Install or upgrade one or more enterprise CAs running on Windows Server 2008 R2 in the resource forest.

    noteNote
    Depending on your environment, the degree to which you are using existing PKI resources, and your level of experience with AD CS, the following references might be helpful for planning a new AD CS deployment or migrating existing AD CS deployments to Windows Server 2008 R2.

  5. Enable LDAP referral support on enterprise CAs. Start a command prompt, type certutil - setreg Policy\EditFlags +EDITF_ENABLELDAPREFERRALS, and press ENTER.

  6. Add enterprise CA computer accounts to Cert Publishers group in each account forest. See example procedures at Add a member to a group. Restart the CA by using net stop certsvc && net start certsvc.

  7. Configure authority information access and CRL distribution point locations. See Specify CA certificate access points in issued certificates. In addition to specifying the access point locations in certificate templates, you must ensure that the network locations specified in certificates are online and are accessible from domain members in all resource forests. The locations can be either LDAP or HTTP depending on your certificate template configuration. See Configuring Certificate Revocation.

  8. Publish the root CA certificate from the resource forest to the account forests by using Certutil.exe at a command prompt to run the following commands:

    1. certutil -config <Computer-Name>\<Root-CA-Name> -ca.cert <root-ca-cert-filename.cer>

      If you run the command on the root CA you can omit the connection information, -config <Computer-Name>\<Root-CA-Name>.

    2. certutil -dspublish -f <root-ca-cert-filename.cer> RootCA

  9. Publish enterprise CA certificates from the resource forest into the NTAuthCertificates and AIA containers in each account forest.

    1. certutil -config <Computer-Name>\<Enterprise-CA-Name> -ca.cert <enterprise-ca-cert-filename.cer>

    2. certutil -dspublish -f <enterprise-ca-cert-filename.cer> NTAuthCA

    3. certutil -dspublish -f <enterprise-ca-cert-filename.cer> SubCA

Next, you must prepare certificate templates for the certificates required by domain member computers and users in all forests.

If you are performing a new AD CS deployment, the default certificate templates in the resource forest can be used or custom templates can be created to meet your requirements.

Review the list of Default Certificate Templates.

Creating custom certificate templates requires that you have the required information and technical understanding to configure all required certificate template properties. For more information,

To use the default certificate templates in the resource forest, skip the section on Consolidating certificate templates and continue at Copying PKI objects to account forests.

To customize the default certificate templates, see Creating Certificate Templates. Continue at Copying PKI objects to account forests after you are finished customizing the certificate templates in the resource forest.

If you are consolidating AD CS from multiple forests that have custom certificate templates which you must continue to use, then review the next section, Consolidating certificate templates from multiple forests, and complete the procedures that best meet your requirements.

Because AD CS deployments can vary greatly, the exact steps you must take to consolidate your existing certificate templates cannot be described in this guide.

The goal is to reduce the number of CAs and certificate templates in a multiforest environment by creating a set of certificate templates issued by resource forest CAs that provide certificates to domain members in all forests.

Based on the number of forests and certificate templates in your environment, the timeframe you have to complete AD CS consolidation, and the requirements of your organization, you can use a combination of procedures described in this section to define the set of certificate templates issued by your resource forest CAs.

For each certificate template you plan to issue from the resource forest, consider which of the following methods best meets the goals and requirements of your organization and complete the procedures described in that section.

The procedures described in this section require the Windows PowerShell script PKISync.ps1. Complete the procedure To Save PKISync.ps1 to a file.

The simplest way to consolidate AD CS from multiple forests into a single resource forest is to copy the certificate templates from all account forests into the resource forest and configure AD CS to issue certificates from the resource forest. Because all certificate templates remain available, the rate of certificate enrollment remains steady and there is no impact to users.

This method reduces the number of CAs in the enterprise but the resource forest might have multiple certificate templates for some types of certificates; for example, if certificate templates for S/MIME certificates are copied from multiple account forests into the resource forest.

Complete the procedures from a domain member computer that has access to the resource and account forests. Log on using an account with permissions to update AD objects in resource and account forests. Members of Domain Admins and Enterprise Admins group have the required permissions.

The procedure must be completed for each certificate template you want to copy into the resource forest. You cannot copy multiple certificate templates simultaneously.

  1. Start Windows PowerShell. Change the current directory to the location of the PKISync.ps1 script.

  2. Copy the certificate template from the account forest by using the command .\PKISync.ps1 -sourceforest <account forest DNS> -targetforest <resource forest DNS> -type Template -cn <certificate template common name>.

    noteNote
    If a certificate template in the resource forest has the same name as the certificate template you want to copy from the account forest, you must rename the certificate template in the account forest before copying the template to the resource forest. See Rename a Certificate Template.

  3. Copy the OID container from the account forest by using the command .\PKISync.ps1 -sourceforest <account forest DNS> -targetforest <resource forest DNS> -type Oid –f and press ENTER.

  4. Grant administrators permissions on the certificate template in the resource forest. Grant Full control to Enterprise admins group, which is the equivalent of default certificate template permissions. Alternatively, you can define custom permissions according to your organization’s security policy. See the Security Tab section of Administering Certificate Templates.

  5. Grant domain members permissions on the certificate template in the resource forest. Grant Read, Enroll, and Autoenroll permissions to the intended users. The access control list defined on the certificate template in the account forest is preserved during the copy operation, but you should verify permissions are correct and grant permissions to additional users in other account forests as needed. See the Security Tab section of Administering Certificate Templates.

  6. Publish the root CA certificate from the account forest to the resource forest by using Certutil.exe at a command prompt to run the following commands:

    1. certutil -config <Computer-Name>\<Account-Forest-Root-CA-Name> -ca.cert <root-ca-cert-filename.cer>

      If you are logged on to the CA you can omit the connection information, -config <Computer-Name>\<Root-CA-Name> to connect to the local CA.

    2. certutil -dspublish -f <root-ca-cert-filename.cer> RootCA

  7. Publish enterprise CA certificates from the account forest into the NTAuthCertificates and AIA containers in the resource forest.

    1. certutil -config <Computer-Name>\<Account-Forest-Enterprise-CA-Name> -ca.cert <enterprise-ca-cert-filename.cer>

    2. certutil -dspublish -f <enterprise-ca-cert-filename.cer> NTAuthCA

    3. certutil -dspublish -f <enterprise-ca-cert-filename.cer> SubCA

      noteNote
      Steps 6 and 7 are required because renewal requests can be signed by certificates issued by CAs in the account forests. The CA certificates from the account forests are required for issued certificates from account forests to be valid in the resource forest.

  8. Assign the certificate template to an enterprise CA in the resource forest. See Add a Certificate Template to a Certification Authority.

  9. Copy the assigned enterprise CA object from the resource forest by using the command .\PKISync.ps1 -sourceforest <resource forest DNS> -targetforest <account forest DNS> -type CA -cn <enterprise CA sanitized name> –f. To determine the CA sanitized name, log on to the CA, start a command prompt, type Certutil.exe and press ENTER. The sanitized name is displayed in the command output.

  10. Copy the certificate template object from the resource forest by using the command .\PKISync.ps1 -sourceforest <resource forest DNS> -targetforest <account forest DNS> -type Template -cn <certificate template common name> –f.

  11. Remove the old certificate template from enterprise CAs in the account forest by using the Certification Authority snap-in. Click Certificate Templates, right-click the old certificate template, and click Delete.

Instead of combining certificate templates from all account forests and managing redundant certificate templates (as described in the previous section), you can minimize the number of certificate templates in the resource forest by reviewing the certificate templates issued in each account forest based on cryptographic purpose and certificate template properties. Define a set of certificate templates for the resource forest that can replace all certificate templates in the account forests.

When consolidating certificate templates from multiple account forests into a single set of templates in the resource forest, two approaches are available.

  1. Stop issuing certificates in account forests by removing all certificate templates from account forest CAs, and publish certificate templates in the resource forest for all certificate types required in the account forests. Because certificates issued in the account forest remain valid until they expire, this method does not cause a spike in certificate enrollment and has low user impact. However, until existing certificates issued by the account forest expire, two valid certificates for the same purpose are found in a user’s certificate store which might result in a user prompt for certificate selection and possibly increased help desk calls. Additionally, you must continue to publish CRLs and CA certificates for the account forest PKI.

  2. Publish certificate templates in the resource forest which supersede certificate templates in account forests, and force immediate reenrollment. This method causes a spike in certificate enrollment because all domain members will enroll for the new certificate within a short period of time. However, AD CS resources in account forests can be decommissioned sooner.

The procedure To consolidate certificate templates can be used for both approaches. Steps for superseding are noted.

Complete the procedures from a domain member computer that has access to the resource and account forests. Log on using an account with permissions to update AD objects in resource and account forests. Members of Domain Admins and Enterprise Admins group have the required permissions.

The procedure must be completed for each certificate template type you want to issue from the resource forest.

  1. Copy certificate templates from account forests by using the command .\PKISync.ps1 -sourceforest <account forest DNS> -targetforest <resource forest DNS> -type Template -cn <certificate template common name>.

  2. Copy the OID container from account forests by using the command .\PKISync.ps1 -sourceforest <account forest DNS> -targetforest <resource forest DNS> -type Oid –f.

  3. If you are superseding certificate templates from account forests, repeat steps 1 and 2 for all certificate templates in account forests that are superseded by the new certificate template in the resource forest.

  4. Duplicate a certificate template you copied from an account forest, and customize if necessary. See Creating Certificate Templates.

  5. Grant administrators permissions on the certificate template in the resource forest. Grant Full control to Enterprise admins group, which is the equivalent of default certificate template permissions. Alternatively, you can define custom permissions according to your organization’s security policy. See the Security Tab section of Administering Certificate Templates.

  6. Grant domain members permissions on the certificate template in the resource forest. Grant Read, Enroll, and Autoenroll permissions to the intended users. The access control list defined on the certificate template in the account forest is preserved during the copy operation, but you should verify permissions are correct and grant permissions to additional users in other account forests as needed. See the Security Tab section of Administering Certificate Templates.

  7. (Optional) Supersede certificate templates from account forests by using the Certificate Templates snap-in to add all superseded certificate templates from account forests to the Superseded templates tab on the certificate template properties sheet. See Supersede Templates.

  8. Assign the certificate template to an enterprise CA in the resource forest. See Add a Certificate Template to a Certification Authority.

  9. Copy the assigned enterprise CA object from the resource forest by using the command .\PKISync.ps1 -sourceforest <resource forest DNS> -targetforest <account forest DNS> -type CA -cn <enterprise CA sanitized name> –f. To determine the CA sanitized name, log on to the CA, start a command prompt, type Certutil.exe and press ENTER. The sanitized name is displayed in the command output.

    noteNote
    If you are superseding certificate templates from account forests, repeat steps 9 through 12 for each account forest you copied certificate templates from in step 1.

  10. Copy the certificate template object from the resource forest by using the command .\PKISync.ps1 -sourceforest <resource forest DNS> -targetforest <account forest DNS> -type Template -cn <certificate template common name> –f.

  11. Copy the OID container from the resource forest by using the command .\PKISync.ps1 -sourceforest <resource forest DNS> -targetforest <account forest DNS> -type Oid –f.

  12. Remove the old certificate template from enterprise CAs in the account forest by using the Certification Authority snap-in. Click Certificate Templates, right-click the old certificate template, and click Delete.

Because default certificate templates have the same names in all forests, the simplest approach to consolidating version 2 and version 3 default certificate templates from multiple forests is to use the default certificate templates in the resource forest and stop issuing certificates based on the default templates in the account forests. Because certificates issued in the account forest remain valid until they expire, this method does not cause a spike in certificate enrollment and has low user impact. However, until existing certificates issued by the account forest expire, two valid certificates for the same purpose in a user’s profile might result in a user prompt for certificate selection which could cause increased help desk calls. Additionally, you must continue to publish CRLs and CA certificates for the account forest.

Alternatively, you can supersede existing certificates in account forests by creating new certificate templates in the resource forest and configuring them to supersede certificate templates in all account forests. This method causes a spike in certificate enrollment because all domain members will enroll for the new certificate within a short period of time. This method causes a spike in certificate enrollment because all domain members will enroll for the new certificate within a short period of time, however AD CS resources in account forests can be decommissioned immediately.

  1. Duplicate a version 2 or version 3 default certificate template, and customize if necessary. See Creating Certificate Templates.

  2. Grant administrators permissions on the certificate template in the resource forest. Grant Full control to Enterprise admins group, which is the equivalent of default certificate template permissions. Alternatively, you can define custom permissions according to your organization’s security policy. See the Security Tab section of Administering Certificate Templates.

  3. Grant domain members permissions on the certificate template in the resource forest. Grant Read, Enroll, and Autoenroll permissions to the intended users in all account forests. See the Security Tab section of Administering Certificate Templates.

  4. (Optional) Supersede certificate templates from account forests by using the Certificate Templates snap-in to add all superseded certificate templates from account forests to the Superseded templates tab on the certificate template properties sheet. See Supersede Templates.

  5. Assign the certificate template to an enterprise CA in the resource forest. See Add a Certificate Template to a Certification Authority.

  6. Copy the assigned enterprise CA object from the resource forest by using the command .\PKISync.ps1 -sourceforest <resource forest DNS> -targetforest <account forest DNS> -type CA -cn <enterprise CA sanitized name> –f. To determine the CA sanitized name, log on to the CA, start a command prompt, type Certutil.exe and press ENTER. The sanitized name is displayed in the command output.

    noteNote
    If you are superseding certificate templates from account forests, repeat steps 6 through 9 for each account forest you copied certificate templates from in step 1.

  7. Copy the certificate template object from the resource forest by using the command .\PKISync.ps1 -sourceforest <resource forest DNS> -targetforest <account forest DNS> -type Template -cn <certificate template common name> –f.

  8. Copy the OID container from the resource forest by using the command .\PKISync.ps1 -sourceforest <resource forest DNS> -targetforest <account forest DNS> -type Oid –f.

  9. Remove the old certificate template from enterprise CAs in the account forest by using the Certification Authority snap-in. Click Certificate Templates, right-click the old certificate template, and click Delete.

For each version 1 default certificate you want to issue, complete the following procedure.

  1. Grant domain members permissions on the certificate template in the resource forest. Grant Read, Enroll, and Autoenroll permissions to the intended users in all account forests. See the Security Tab section of Administering Certificate Templates.

  2. Assign the certificate template to an enterprise CA in the resource forest. See Add a Certificate Template to a Certification Authority.

  3. Copy the assigned enterprise CA object from the resource forest by using the command .\PKISync.ps1 -sourceforest <resource forest DNS> -targetforest <account forest DNS> -type CA -cn <enterprise CA sanitized name> –f. To determine the CA sanitized name, log on to the CA, start a command prompt, type Certutil.exe and press ENTER. The sanitized name is displayed in the command output.

  4. Copy the certificate template object from the resource forest by using the command .\PKISync.ps1 -sourceforest <resource forest DNS> -targetforest <account forest DNS> -type Template -cn <certificate template common name> –f.

  5. Copy the OID container from the resource forest by using the command .\PKISync.ps1 -sourceforest <resource forest DNS> -targetforest <account forest DNS> -type Oid –f.

  6. Remove the old certificate template from enterprise CAs in the account forest by using the Certification Authority snap-in. Click Certificate Templates, right-click the old certificate template, and click Delete.

Certificate enrollment objects in Active Directory environments are stored in three containers which must be copied from the resource forest to account forests to maintain consistency across all forests that are participating in cross-forest certificate enrollment. A Windows PowerShellscript is provided for copying and managing the following PKI objects in AD.

  • Enrollment services

  • Certificate templates

  • OID

In cross-forest enrollment deployments described in this guide, the resource forest is the master copy of PKI objects. The PKI objects described in this section must be the same in all forests.

To maintain consistency across all forests, copy PKI objects in the resource forest should to account forests frequently. Scripts and examples for automated copying are described in AD CS: Managing Cross-forest Certificate Enrollment.

You can use PKISync.ps1 during initial deployment and to keep resource and account forest PKI objects synchronized.

PKISync.ps1 copies objects in the source forest to the target forest. Objects in the source forest are not changed by script operations.

CA certificates are not copied by PKISync.ps1. When CA certificates are renewed, you must manually publish the CA certificates to account forests by using the commands described in Deploying AD CS for cross-forest certificate enrollment.

First, complete the procedure to save PKISync.ps1 to a file, as described in AD CS: PKISync.ps1 Script for Cross-forest Certificate Enrollment

Next, complete the following procedure.

  1. Start Windows PowerShell.

  2. Type .\PKISync.ps1 -sourceforest <SourceForestDNS> -targetforest <TargetForestDNS> [-f] and press ENTER. When copying from the resource forest, <SourceForestDNS> is the DNS name of the resource forest and <TargetForestDNS> is the DNS name of an account forest.

    WarningWarning
    [-f] is an optional argument. When [-f] is used, objects in <TargetForestDNS> are deleted and replaced by objects with the same name from <SourceForestDNS>. When [-f] is not used, you are prompted to confirm before objects are deleted.

  3. Repeat for each account forest.

The following table describes the support for using CA web enrollment with CAs in the resource forest that are configured for cross-forest certificate enrollment.

 

Forest CA web enrollment is hosted in CA web enrollment installed on CA Type of delegation Is supported

Resource

Yes

Not required

Yes

Resource

No

Computer

Yes

Resource

No

Constrained

Yes

Account

No

Computer

Yes

Account

No

Constrained

No

A goal of deploying cross-forest certificate enrollment is to reduce the number of CAs in an enterprise.

After certificate templates have been removed from a CA in an account forest, the CA can be decommissioned.

Complete the procedures described in section Removing a CA from Active Directory in CA Maintenance.

Was this page helpful?
(1500 characters remaining)
Thank you for your feedback

Community Additions

ADD
Show:
© 2014 Microsoft