Here is the link: Cross Forest - Certificate Enrollment | Microsoft Community Hub

PKIsync.ps1 script

At this time, we’re going to keep things simple.

The goal is to create an Active Directory resource Forest (Source Forest) that will host an Enterprise CA; it will be responsible for issuing all certificates.

This approach should allow us to get everything up and running quickly, so those certificates can be requested and issued from a target Active Directory Forest.

With that said, let’s take a closer look at how the PKIsync.ps1 script works and its flow.

Understanding the flow of PKIsync.PS1 script

The PowerShell script is designed to synchronize certificate templates and PKI configuration information between multiple forests ensure consistency across forests.

1.      Locate the DC on the target forest or server on the target forest and Run PKISync.PS1

Locate the Domain Controller or member server where the script is located to start copying the Active Directory objects from the Source Forest to the Target Forest. In this scenario, the source forest is “Contoso.com” to target forest “Fabrikam.com” We then run the “PKISync.PS1” script on the “Fabrikam.com”.

2.      Copying AD Objects

The script will start copying (Or Sync) the following AD objects: “pKICertificateTemplate, pKIEnrollmentService, and msPKI-Enterprise-Oid” to the target forest.

3.      Objects Copied/synced and Ready for the Computers/Users.

After some time is allowed for AD replication to converge, “Fabrikam.com” will have these PKI AD objects Sync’d into its AD database on every domain controller thus allowing “Users or Computers” in the target forest to enroll for certificates from the CA in the Source Forest. Then we will want to wait until computer certificate autoenrollment has ran.  This is going to be upwards of 8 hours before all systems in the forest will have the updated certification authority objects.

4.      Windows Client Does a Request to the DC

Now, imagine a Windows Client in “Fabrikam.com” that needs to enroll a certificate using “Certlm.msc”. The client will perform an LDAP lookup on a Domain Controller in the Fabrikam.com domain to discover all the PKI-related AD objects that were previously Sync’d over to the target forest.

5.      Windows Client sends a Request to Source Forest CA

With the information gathered from the “Fabrikam.com” Domain Controller through an LDAP query, the Windows client uses TCP port 135 (RPC endpoint mapper) to connect to the CA and obtain the location of the CA’s iCertRequest DCOM interface. After the endpoint mapper provides the dynamic port for the iCertRequest DCOM interface, the client establishes a TCP connection to that interface on the CA in the source forest.

6.      Template configuration

If a template is configured with “Build from Active Directory”, the CA will immediately look up the user’s or computer’s domain specified in the request. If the requester belongs to a different AD forest, Kerberos tickets must be obtained from each domain in the trust path, which is why a Forest Trust is required. A Forest Trust is the only trust type that fully supports Kerberos. Once the CA validates the information with the “Fabrikam.com” Domain Controller, it signs the certificate request and returns the signed certificate to the Windows client. The certificate is then placed in the user’s Certificate Store.

Configure the environment for cross forest enrollment

Choose a Source Forest and Target Forest.

The Source Forest will be the forest where the Certification Authority exists and where all the certificate templates are configured.  The Target Forest will be where the users and computers that need to enroll for certificates exist.

Two-way forest trust between the Source Forest and Target forests 

It is required to have a Two-Way Forest Trust in place (See Create a two-way, forest trust for both sides of the trust for additional guidance). To limit clients from either forest to only certain resources in the other Selective authentication can be enabled to limit the scope of the cross-forest authentication that is allowed.  Selective authentication is administratively intensive and requires careful consideration for configuration before implementation.

Configure your Certificate Authority

Before we can enroll for certificates from across the forest, a certificate authority needs to exist in the Source Forest.

If you would like guidance on installing a two-tier PKI hierarchy, see this wiki content: AD CS Step by Step Guide: Two Tier PKI Hierarchy Deployment

Enable LDAP referral support on Enterprise CA from Source Forest

After setting up the Certificate Authority, we need to allow configure AD CS to “chase the LDAP referrals”.  This allows the AD CS Service to traverse the forest trust to look up user or computer information to build the certificate. The steps to enable LDAP referral on an Enterprise issuing CA check below.

Steps to enable LDAP referral

1. Run the command as administrator:
   

   CertUtil -SetReg Policy\EditFlags +EDITF_ENABLELDAPREFERRALS
   

2. After modifying the LDAP referral setting, the Certificate Services service needs to be stopped and started:
   

   Net Stop CertSvc & Net Start CertSvc
   

3. To view the current value run the command below, If the value is not shown then it is not enabled.
   

   CertUtil -GetReg Policy\EditFlags

Add the Enterprise CA computer account to the Cert Publishers group in each target domain 

Add the Enterprise CA computer to the Cert Publishers group in each target domain. This allows the CA to write certificates to each user’s account in those domains if the User certificate template is configured for this.

1. Launch: dsa.msc
2. Click on the Users container.
3. Double click on the Cert Publishers group.
4. Click on Add…
5. Click on Locations… and select the Source Domain and click on OK.
6. Click on Object Types… and select the computer checkbox and click on OK.
7. On Enter the object names to select (examples): enter the name of the Enterprise CA from the Source Forest.
8. Click on OK.
   
   

Make sure that AIA and CDP locations on the source Forest are available.

Now, ensure that the AIA and CDP locations are properly configured and reachable. This means that workstations, member servers, domain controllers, and other devices that will enroll certificates must be able to access these AIA and CDP locations.

1. Open the PKIview.msc on the source forest.
2. PKIview.msc is an Enterprise PKI tool for checking PKI health. You can find more information about this tool at the following ADCS Health Using Enterprise PKI Tool (PKIVIEW)
3. Locate the CDP and AIA Locations make sure that the status of each is on “OK”.
4. Test from the target forest that the locations mentioned are reachable if you are using LDAP locations or HTTP location make sure that this is working, if you are having issues on this section refer to Configure the CDP and AIA Extensions on CA1 | Microsoft Learn
5. I tested access to the web service on my CA www.contoso.com/certenroll/contoso-content-ca01.crl from the target forest make sure is reachable.
   
   

Export and Publish the Root CA and the Enterprise CA certificate from the Source Forest to the Target Forest.

The certificate chain needs to be deployed to the target forest computers. Therefore, we need to export these certificates and publish them to the AD database of the target forest. If we have a two-tier hierarchy, both CA certificates need to be exported Root CA and Enterprise CA. On this case I used cmdlets, but you just need to make sure to export CA certificate and publish it in the Target Forest.

 

1. Connect to my Offline Root CA and export the certificate using the command below:

   certutil -ca.cert <c:\root-ca-cert-filename.cer>

2. Connect to my Enterprise CA and export the certificate using the same command:

   certutil -ca.cert <c:\Enterprise-ca-cert-filename.cer>

3. Copy the certificates “root-ca-cert-filename.cer” and “Enterprise-ca-cert-filename.cer” over RDP, SMB, Robocopy… to a domain controller in the target forest I save it on “C:\“ drive.
   
   
4. Login into a Target Forest domain controller as an Enterprise Admin account, then launch and elevated command prompt, and run the following commands to publish the PKI hierarchy chain to Active Directory.
   
   RootCA
   

   certutil -dspublish -f < c:\root-ca-cert-filename.cer> RootCA
   
   Publishes the certificate into the Certification Authorities container in Active Directory, which is used to distribute trusted root CA certificates to domain-joined machines. 

5. NTAuthCA

   certutil -dspublish -f < c:\enterprise-ca-cert-filename.cer> NTAuthCA

   Places the certificate in the NTAuthCertificates store in Active Directory. This store is used to confirm certificate-based authentication, such as smart card logon.

6. SubCA

   certutil -dspublish -f < c:\enterprise-ca-cert-filename.cer> SubCA

   Places the certificate in the Certification Authorities container under the Subordinate CA section.

 

Please keep in mind that the above commands have added the certificates to the “Active Directory Enterprise store”. 

Over the next 8 hours if computer certificate autoenrollment is enabled in the forest, domain joined computers will pull down the Root CA certificate and add it to the Enterprise Trusted Root store, and the Issuing CA certificate will be added to the Enterprise NTAuth and Enterprise CA stores. When the computer autoenrollment runs it also checks to see if it needs to update certificates maintained in the “Enterprise” store. 

⚠️ If you need to test this before the 8-hour window you can run the below CertUtil command to have the computer “Pulse” its autoenrollment code.

certutil -pulse

Understanding how clients enroll certificates

After setting up the environment, it's important to understand the PKISync method thoroughly, especially considering it is a legacy enrollment approach. In simple terms, PKISync involves copying a predefined set of configurations from the source forest to the target forest. This method relies on the following objects being copied as explained above:

• pKICertificateTemplate objects (Certificate Templates):
  These contain which certificate templates are available and their associated permissions. Anytime a change happens to a certificate template (including permissions) this object type will need to be ‘synced’ over to the target forest.
  
  
• pKIEnrollmentService objects (Enterprise CAs):
  These specify the Enterprise Certificate Authorities (CAs) that manage enrollment requests. These objects could reference an Enterprise Root or an Enterprise Issuing certification authority.  Anytime permissions on the CA change, a certificate template is added or removed from the CA to issue, Key Recovery Agent configuration is changed, or the CA’s certificate has been renewed this object type will need to be ‘synced’ over to the target forest.
  
  
• msPKI-Enterprise-Oid objects:
  These have intended purposes values for certificates. Anytime a new certificate template is created, a new Application Policy is created or a new Issuance Policy, this object type will also need to be ‘synced’ over to the target forest.

Once these objects are copied to the target forest, clients needing enrollment do an LDAP query to their local forest domain controllers configuration partition to look up these three AD object types. With this information, clients can directly communicate with the Certificate Authority in the source forest using RPC/DCOM protocols.

This PKISYNC activity ensures that the necessary configurations are replicated to the target forest, enabling the cross-forest enrollment interaction between clients and the source forest's Certificate Authority.

Legacy enrollment flow on the same forest

 

Cross forest enrollment – Client simplified flow when the ADObjects are already downloaded

PKISYNC.PS1 Script Overview

Microsoft has documented the script at the link below. You may simply copy and paste it. 
The plain text script can be found on: AD CS: PKISync.ps1 Script for Cross-forest Certificate Enrollment | Microsoft Learn
Official Microsoft Documentation: AD CS: Deploying Cross-forest Certificate Enrollment | Microsoft Learn

Copy Command:

.\PKISync.ps1 -sourceforest <SourceForestDNS> -targetforest   <TargetForestDNS> [-sourceDC <SourceDCDNS>] [-targetDC <TargetDCDNS>] [-type <CA|Template|OID> [-cn <ObjectCN>]] [-f] [-whatif]

 Delete Command:

.\PKISync.ps1 -targetforest <TargetForestDNS> [-targetDC <TargetDCDNS>] [-type <CA|Template|OID> [-cn <ObjectCN>]] [-deleteOnly] [-whatif]

Arguments Explained:

• sourceforest  Specifies the DNS name of the forest from which objects will be processed
• targetforest  Specifies the DNS name of the forest to which objects will be processed.
• sourcedc      Specifies the DNS name of the Domain Controller (DC) in the source forest responsible for processing objects.
• targetdc      Specifies the DNS name of the Domain Controller (DC) in the target forest responsible for receiving processed objects.
• type  Specifies the type of object to process. Valid options are:
• CA: Process Certificate Authority objects.
• Template: Process Certificate Template objects.
• OID: Process OID (Object Identifier) objects.
•  

 

- cn    Specifies the common name of the specific object to process. Do not include "cn=" in the name.

This choice is only valid when -type is specified and is used to process a specific object within that type.

- f     Forces the overwrite of existing objects in the target forest during the copying process. This choice is ignored if objects are being removed

- whatif Displays a preview of objects that will be processed without performing any actions.

- deleteOnly    Delete objects in the target forest if they already exist, without copying new objects.

Examples of how to use PKISync.PS1

Example 1: Copy all templates

Copy all templates from the source forest to the target forest, with the "-F" option forcing overwrite if templates already exist. It includes copying the Enrollment Services Container, Certificate Templates Container, and OID Container from the source forest to the target forest.

 Command:

.\PKISync.ps1 -sourceforest contoso.com -targetforest Fabrikam.com -f

 

If we want to make sure that all these distinguished names were copied from the Source Forest to the Target Forest and we can use the ADSIedit.msc console to see this by opening the configuration partition and going to CN=Public Key Services,CN=Services,CN=Configuration,DC=Fabrikam,DC=com.

Figure: Illustration of the Objects copied from the Source Forest to the Target Forest. 

Example 2: Copy specific templates

If you are looking to update a particular "Certificate template" use the following command to copy the template from the source forest using its specific Common Name (CN). If a template with the Canonical Name "User" already exists in the target forest, it will not be copied. To overwrite an existing template, append the”-F” argument at the end of the command.

Note: it is important to run in this command with argument to copy the OID if we are planning to copy a duplicate template.

 Command:

.\PKISync.ps1 -sourceforest contoso.com -targetforest Fabrikam.com –type template –cn user

Example 3: Copy AD Object Containers

This example will copy the AD Containers from the source forest to the target forest with all the AD objects into the selected one. In this example copy of all Enterprise-OID objects from the existence will not be completed however if we need to add the "-F" argument.

 Command:

.\PKISync.ps1 -sourceforest contoso.com -targetforest Fabrikam.com –type oid

Best practice

As discussed, the recommendation is to use the CEP/CES method due to its advantages: enhanced security and scalability. This method aligns with current best practices, even though PKISync was designed for Windows Server 2003/XP and is considered outdated. However, if you choose to go ahead with PKISync, here are some recommended guidelines to follow:

• Automate the synchronization process by creating a Scheduled task that runs the PKISync script. But this also comes with a significant risk as by default writing these objects in the target Forest the account running the script MUST be an Enterprise Admin level account. This can be mitigated to some extent by giving a lower-level admin account permission to create and delete objects at the “CN=Public Key Services,CN=Services,CN=Configuration,DC=ForestRoot” container level and below.

The simplest method for keeping updated AD objects is to run the PKISync.ps1 script in a scheduled task. To have the best results the task should be run often.

Schedule Task Automatization

To automate the script, create a scheduled task on the target domain controller. For example, configure it to run every hour

Program/Script: Powershell.exe

Arguments: -file C:\Users\Administrator\Desktop\.\PKISync.ps1 -sourceforest contoso.com -targetforest Fabrikam.com -f

Once configured, the task will run automatically.

 

And the Schedule task should be done; I hope this information were helpful for you.

Conclusion

The PKISync.ps1 script might be old, but it still does what it’s supposed to syncing PKI objects across forests so clients in the target forest can grab certificates from the source forest. It’s not fancy, and it’s definitely considered legacy, but if you set it up right and automate it, it works.

That being said, for new or long-term environments I’d recommend looking at CEP/CES since it’s the modern and more secure way forward. Still, PKISync can save the day in certain cases where you just need something simple that works.

At the end of the day, the key is keeping your configs updated, making sure the right trusts are in place, and staying mindful of security. If you’ve made it this far thanks for reading, and good luck with your own PKI adventures! 🚀

👉 Stay tuned for the third part, where I’ll dive into CEP/CES.!