Welcome to part one of my blog series on Cross Forest Certificate Enrollment. Nowadays, businesses often run across multiple Forests for distinct reasons. You would like to ensure secure authentication using certificates spanning Active Directory Forests within your enterprise. Cross Forest Certificate Enrollment is one solution that can be leveraged to enable the centralized management of digital certificates while maintaining security.

In this blog, we will dive into Cross Forest Certificate Enrollment. We will explore its functionality, configuration, and best practice for companies of all sizes. We will also assess which of the available solutions can best suit your company's needs. 

You will find everything you need to correctly configure Cross Forest Enrollment, including:
•    Types of methodologies and requirements.
•    Pros & Cons of each solution type.
•    Best practice and recommendations.

An important reference that should also be reviewed with this blog is on the AD CS: Deploying Cross-forest Certificate Enrollment | Microsoft Learn

Types of methods

Cross-forest certificate enrollment offers two methods: The preferred choice involves using the “CEP & CES roles” in Windows Server's Active Directory Certificate Services, while the alternative method uses a “PowerShell script called PKISync (PKISync.ps1).”

NOTE: 

• PKISync.ps1: It was created originally to support Windows XP/Vista and Windows Server 2003/2008 clients to be able to support Cross Forest certificate enrollment and is considered a legacy solution but is still valid for newer operating systems.
• CEP & CES:    It was released with Windows 7/2008 R2 and is the preferred method to support Cross Forest certificate enrollment going forward.  Please understand that CEP & CES is NOT Certificate Services Web Enrollment.  For more on this role see the following - Certification Authority Web Enrollment Role Service in Windows Server | Microsoft Learn

Certificate Enrollment Policy (CEP) and Certificate Enrollment Service (CES)

Requirements

• Have at least “Windows 7 / Windows Server 2008 R2” or later as certificate enrollment clients.
• Have Windows server 2008 R2 (Currently supported Windows Server 2016) or higher Certification Authority.
• Set up and create AD CS environment in at least one of the forests to issue certificates.
• CEP and CES web service roles can be installed on the Certification Authority or on another member server in the same forest as the certification authority.
• Do not place AIA or CDP locations on LDAP; they must be available via HTTP.
• DNS name resolution should be correctly configured for resolution between forests and CEP/CES servers.
• Kerberos authentication cross forest boundaries REQUIRES a two-way forest trust.

High level overview of how CEP CES works:

1. The client begins by connecting with the Certificate Enrollment Policy (CEP) web service over HTTPS, which is configured to run on port 443 (it can be changed later), allowing certificate enrollment.
2. The CEP servers URI can be configured through either local or group policy. The CEP web service then queries the domain controller via LDAP for certificate templates (pKICertificateTemplate objects), enterprise CA services (pKIEnrollmentServices objects), and other relevant objects (msPKI-Enterprise-Oid objects). The collected data informs the client of the templates it can enroll for and the enterprise CAs available.
3. The client then connects to the Certificate Enrollment web service (CES) specified by the CA.
4. The CES impersonates the client's security context, requests a certificate from the certification authority via DCOM.
5. The issued certificate is returned to the client securely.

Representations of this functionality.

⚠️Note: While the image suggests that the CEP/CES roles run on different servers, it is common to have both roles installed on the same server.

Pros and Cons of CEP CES

Pros

• Efficiency and Synchronization of certificates: All certificate template, and certification authority management tasks can be done from the Active Directory Forest where the CA – CEP/CES servers exist. When a change is made to a certificate template it does not require any more action to get the template configuration change synchronized to the other forest.
• Web-Based technology: CEP and CES are web-based services, making them accessible over HTTPS. This can simplify cross-forest enrollment by only needing to have https-based ports opened between the forests.
• Certificate renewal enrollment CEP/CES can be used for certificate key-based renewal, reducing the need for manual certificate requests. This is particularly useful for large organizations with many users and devices.
• Scalability: These services are scalable and can manage a high volume of enrollment requests, making them perfect for large companies with multiple forests.
• Allow Non-Domain Joined Devices to enroll certificates: The CEP/CES method allows non-domain joined machines to enroll certificates. See the following for more information - Enabling CEP and CES for enrolling non-domain joined computers for certificates - Microsoft Community Hub
• Troubleshooting: For more precise troubleshooting within CEPCES, we can collect granular information from multiple logging sources—such as Event Viewer logs for the EnrollmentPolicyWebService and the EnrollmentWebService, along with CEP logs, CES logs, IIS logs, and other available debug logs—to identify and resolve issues more effectively.
• Security: Since communication is over HTTPS this method is secure, and the user never communicates directly either to a DC or the CA.

Cons

• Complexity: The configuration and management of CEP and CES can be complex, especially for administrators who are not familiar with PKI implementations.
• Authentication: If there are Cross Forest enrollment implications, CEP & CES configured for Kerberos Authentication can only be used over a two-way forest trust.

PKI Sync Script (PKIsync.PS1)

Requirements

• It has been around since Windows Server 2003. Windows Server 2016 and newer operating systems are currently supported.
• Two-way Forest trust is MANDATORY between the source forest and target forest.
• ADCS environment configured with at least with one Enterprise CA on the source forest assigned.
• Uses PowerShell to synchronize the PKI objects between the source forest (Where CA exists) and the target forest (where the users/computers exist). Uses an Enterprise AD account to run the script, which interacts with Active Directory to synchronize certificates and templates. This requires permissions to access AD partitions on both the source forest and target forest. If we would like to automate the script, this would require task scheduler rules.

How it works:

It is a Script that synchronizes the PKI AD objects below from the source forest to the target forests:

• Certificate templates (pKICertificateTemplate).
• PKI enrollment Services objects (Enterprise CA objects) that are available (pKIEnrollmentService).
• Enterprise OID objects (msPKI-Enterprise-Oid).

The script copies the required Active Directory Certificate Services objects from one forest to another forest and will modify the number of objects underneath the Public Key Services container in the forest-wide configuration partition. This does require an elevated administrator account that is a member of the Enterprise Admins group in the target forest as this group is by default is allowed to write in the configuration partition.

Representations of this functionality and enrollment.

Here shows how does it works, to understand how it works in detail visit my other blog of PKIsync.ps1.

Representation of his flow

Pros and Cons of PKISync Script

Pros

• Simplified Deployment: It is a script that copies the necessary PKI AD objects from the source AD forest that has the CA to the target forest.
• Does not require extra servers/services: PKISync uses PowerShell scripting, which might save money and time at first compared to setting up CEP/CES, especially for smaller organizations with limited resources.
• Flexible: PKISync is a script that copies certificate-related information between forests. It does not require dedicated server roles.

Cons

• Lack of Authentication and impersonation: Since it is a script, it does not impersonate the client’s security context during the certificate enrollment process. This can lead to improper authentication and a failure to properly update the PKI objects.
• Logging: The script may not integrate with the normal logging and auditing features. There may be issues with success and failure logging into event viewer unless AD Object Auditing is enabled specifically.
• Management Issues: We have seen cases where PKISync has been used and the PKI Administrators have changed the CA settings, such as adding or removing a certificate template that the CA should issue. Or they have made a new certificate template, altered the settings of an existing one, or updated the permissions on the certificate template. Then the PKI Admin may not run the PKISync.ps1 file for all forests to apply the new configuration to them. This will cause inconsistencies and enrollment failures leading to case creation with Microsoft.
• Less Security: PKISync may not provide the same security as the CEP/CES does, since PKISync requires permanent two-way trust, with a manual or scheduled synchronization in between using the password of an elevated administrator account that runs periodically. This may be viewed as a potential security concern.
• Port Requirements: The script requires several ports to be opened to support communication between forests.  The port requirements are client to domain controller and client to the AD CS Certificate Authority.

See this article for general ports required for clients to communicate with Domain Controllers:  Configure firewall for AD domain and trusts - Windows Server | Microsoft Learn

See this article for general ports required for clients to communicate with Certificate Services:  https://learn.microsoft.com/en-us/troubleshoot/windows-server/networking/service-overview-and-netwo…

Conclusion CEP/CES vs PKISync

 In conclusion, cross-forest certificate enrollment is an important solution for modern businesses operating across multiple forests, ensuring centralized management and secure authentication. There are two main approaches:

• The CEP & CES solution – the preferred method, offering greater efficiency, scalability, and security via HTTPS.
• The legacy PKISync.ps1 script – while it may appear simpler to deploy, it presents significant security and management challenges and is generally not recommended in any scenario, including smaller environments (since they, too, must manage more than one forest).

Although both methods exist, the reality is that CEP & CES remains the better choice for organizations of all sizes, delivering robust security, efficient enrollment, and centralized oversight.