Cross-forest and remote certificate enrollment

Name the enrollment design

“The CA is in another forest” leaves a few questions open. Which forest holds the account? Where is the client, which policy and enrollment endpoints does it use, and how does it authenticate? Ordinary AD/RPC enrollment with cross-forest directory publication and HTTPS enrollment through CEP/CES have different prerequisites.

Publishing another forest’s root certificate does not configure any of the other stages. A successful TLS connection to CEP likewise does not prove that CES can submit a request or that the resulting certificate will authenticate the intended account.

Check the account forest’s publication view

In a directory-publication design, clients need a coherent view of the issuing CA and templates. Compare the short name, OID, schema/revision and supersedence relationships rather than assuming two identically named templates are the same policy. Choose the authoritative forest for template changes and an intentional synchronization direction.

This reads selected publication objects from one explicit account-forest DC:

$dc = 'dc1.accounts.example.com'
$config = (Get-ADRootDSE -Server $dc).configurationNamingContext
$pki = "CN=Public Key Services,CN=Services,$config"
Get-ADObject -Server $dc -SearchBase $pki `
    -LDAPFilter '(|(objectClass=pKIEnrollmentService)(objectClass=pKICertificateTemplate))' `
    -Properties dNSHostName,certificateTemplates,msPKI-Cert-Template-OID,
        msPKI-Supersede-Templates,
        revision,msPKI-Template-Schema-Version,msPKI-Template-Minor-Revision |
    Select-Object Name,ObjectClass,DistinguishedName,dNSHostName,
        certificateTemplates,msPKI-Cert-Template-OID,msPKI-Supersede-Templates,
        revision,msPKI-Template-Schema-Version,msPKI-Template-Minor-Revision

Repeat against the intended CA-forest DC and preserve lookup failures. A complete template object in one forest says nothing about a stale copy in another. Microsoft documents template/OID synchronization, CA publication, LDAP referrals and certificate-publisher permissions in its multi-forest enrollment procedure. That procedure’s OTP/DirectAccess deployment is its own scope; do not copy its deletion or forced-overwrite steps into a general PKI consolidation.

Before overwriting a template, check name collisions, ACL translation, OID identity, dependencies and how to reverse the change. Copying the template won’t add it to every CA’s issuance list or grant the foreign requester permission to enroll.

Trace the CA’s directory access separately

The native directory-publication architecture introduced in Windows Server 2008 R2 requires a two-way forest trust between the resource forest and each account forest. The account forests don’t need trusts with one another for this design.

There are two authentication paths to check: the requester reaches the CA, and the CA reaches the requester’s directory. A working forest trust doesn’t guarantee both are authorized. With selective authentication, check the requester’s permission to authenticate to the CA and the CA’s permission to authenticate to the relevant account-forest DCs. Microsoft’s native cross-forest deployment guide describes these checks; its OS and installation examples are historical.

On the issuing CA, this reads the local policy module’s flags:

certutil -getreg Policy\EditFlags

Record whether LDAP referral support is configured for this design. Referral handling, DNS/DC reachability and directory authorization remain separate checks; adding a template ACL cannot repair a failed CA-to-directory lookup.

For a template that builds computer names from AD, inspect the actual requester object on an explicit account-domain DC:

Get-ADComputer -Server 'dc1.accounts.example.com' -Identity 'PILOT01' `
    -Properties dNSHostName,userPrincipalName |
    Select-Object DistinguishedName,SID,dNSHostName,userPrincipalName

Your administrative read can succeed while the CA service’s lookup fails. Match the CA’s failed request to its directory access. 0x8009480F (CERTSRV_E_SUBJECT_DNS_REQUIRED) can mean the required AD dNSHostName is empty or the computer object was not found. It doesn’t diagnose the client’s DNS A record. The MS-WCCE machine-template rule explains this distinction. Fix the lookup rather than switching an authentication template to requester-supplied identities to get around it.

Separate issuance from publication into the account

A CA can issue a certificate while publishing its public certificate into the account’s directory fails. Check whether that template/workflow expects AD publication, the target object’s ACL and the issuing CA’s computer identity. Cert Publishers is a domain-local group in current AD DS; inspect each relevant account domain rather than treating membership in one forest-root group as forest-wide permission. Current group definition, per-domain PKI delegation guidance.

In Microsoft’s native publication workflow, enrollment-service, template and OID objects are synchronized. Renewed CA certificates still need their own publication. Check template/OID state, CA issuance availability, trusted roots/NTAuth where required, and the validator’s actual chain separately.

Separate three kinds of trust

A forest trust permits specific authentication paths; it does not automatically grant template Read/Enroll or CA enrollment rights. Root trust permits chain validation; it does not make the CA authorized for every domain certificate-authentication use. NTAuth authorization adds another enterprise check for relevant authentication scenarios. Inspect these in the forest where authentication will occur, not only in the forest running the CA.

Certificate account mapping remains independently important. After account migration, an otherwise trusted certificate can retain the original account SID. Current strong-mapping enforcement cannot be repaired by copying only the public root certificate. See strong certificate mapping for the certificate/account comparison and KDC evidence.

Use a deliberately scoped pilot identity to test both required authentication paths and their endpoints. Keep the native design’s two-way trust prerequisite separate from the trust-independent key-based renewal case below. Do not broaden a trust, disable filtering, or authorize an issuing CA in NTAuth merely because another forest’s user cannot see a template.

CEP success and CES success are different observations

CEP supplies policy using directory information. CES accepts enrollment over HTTPS and submits to the CA using DCOM. Thus, opening HTTPS through the perimeter does not eliminate the service’s internal directory, authentication and CA dependencies. The CEP overview defines policy retrieval; the CES overview defines request submission.

Check each HTTPS endpoint’s actual server certificate, hostname, trust, authentication mode and application identity. A browser signed in as an administrator can exercise a different identity from machine autoenrollment. Capture the template, requester, endpoint, HRESULT and request ID. If the CA has no matching request, stay with policy, eligibility and transport evidence before changing issuance policy.

Delegation requirements depend on whether CES and the CA are separate, whether initial requests are accepted and how the client authenticated. For a remote CA, initial enrollment using integrated Windows or client-certificate authentication can require delegation; username/password and renewal-only designs have different behavior. Confirm the actual CES identity before configuring its computer or user account. Use the documented endpoint design and the second-hop diagnostic sequence, rather than enabling unconstrained delegation.

Renewal is not a bootstrap mechanism

Renewal-only service denies an ordinary new request. Key-based renewal depends on an existing valid certificate and usable private key; it can support clients outside a forest without a forest trust once the initial credential has been provisioned through the intended design. An expired or missing initial credential therefore needs a separately planned enrollment/recovery path.

Test initial enrollment, off-network renewal and recovery after expiry separately. Distinguish using the old key to authenticate a renewal from the application’s decision to reuse or replace the certificate’s key pair. Microsoft’s renewal workflow distinguishes same-key and new-key renewal and calls for testing actual private-key use.

Test from each network that will use the certificate. It might contain an internal LDAP CDP that an external validator can’t reach, or the validator might select a different chain from a cached store. Check the actual AIA/CDP/OCSP locations, trust and application identity with chain and revocation diagnostics.

For HTTPS-specific policy caches, advertised endpoints, failover and relay protection, continue with CEP/CES troubleshooting.