Feature Request: Add -Server / -Domain support to Get-CertificateTemplate and other template cmdlets (Management Forest → Resource Forest)

[bencoremans]

Problem

Get-CertificateTemplate and several other template-related cmdlets have no -Server, -ComputerName, -Domain or similar parameter.

They always operate in the domain context of the currently logged-on user.

This limitation is especially painful in the very common enterprise design where:

• Admins manage from a dedicated Management Forest (admin / bastion forest with privileged accounts)
• The actual Enterprise CA / AD CS and Certificate Templates live in a separate Resource Forest

In this setup the administrator’s logon domain (Management Forest) is different from the domain that stores the Certificate Templates (Resource Forest). PSPKI therefore cannot retrieve or manage the correct templates.

Root Cause

The cmdlets rely on the global variable $PkiConfigContext, which is set once during module import in PSPKI.psm1:

$Domain = (Get-ADRootDSE).defaultNamingContext   # ← NO -Server parameter!
$script:PkiConfigContext = "CN=Public Key Services,CN=Services,$Domain"

Get-CertificateTemplate.ps1 then uses:

$ldap = [ADSI]"LDAP://CN=Certificate Templates,$PkiConfigContext"

Broader issue in the underlying pkix.net library

The same root cause exists deeper in the .NET library (pkix.net). Multiple classes perform LDAP queries via RootDSE without any -Server or ConfigurationNamingContext parameter:

CertificateAuthority.cs → LoadDisplayName() (this causes issue #177: empty DisplayName in cross-forest)
CertificateTemplate.cs → constructor / Refresh()
OcspResponder.cs → LoadFromAD()
NDES.cs → several AD queries

This is a systemic design issue across the entire library, not just the PowerShell layer.

Affected cmdlets (all use $PkiConfigContext)

Cmdlet	Uses $PkiConfigContext	Notes
Get-CertificateTemplate	Yes	Main cmdlet
Get-ADKRACertificate	Yes	KRA certificates
Get-CertificateTemplateAcl	Yes	Read ACLs
Set-CertificateTemplateAcl	Yes	Modify ACLs
Add-CertificateTemplateAcl	Yes	Add permissions
Remove-CertificateTemplateAcl	Yes	Remove permissions

Expected behavior

Native support like the CA cmdlets already have:

Get-CertificateTemplate -Server dc-adcs.resourceforest.local
Connect-CertificationAuthority -ComputerName "ca01.resourceforest.local" -Server dc-adcs.resourceforest.local

Clean workaround (when running on a machine in the Resource Forest)

function Get-CertificateTemplateFromLocalMachineDomain {
    param([string]$DisplayNameLike = "*Web Server*")

    $DomainName = (Get-ADDomain -Current LocalComputer).DNSRoot

    Get-ADObject -LDAPFilter "(displayName=$DisplayNameLike)" `
        -SearchBase "CN=Certificate Templates,CN=Public Key Services,CN=Services,$((Get-ADRootDSE -Server $DomainName).configurationNamingContext)" `
        -Server $DomainName `
        -Properties Name, DisplayName, DistinguishedName
}

[Crypt32]

I never tested or designed PSPKI to work in cross-forest environments because of limitations of some underlying APIs, such as CA discovery using ICertConfig COM interface which is limited to current forest. In addition, this may cause side effect issues when you use Get/Add/Remove/Set-CATemplate when you can accidentally assign template to a CA from a different forest.

[bencoremans]

Thanks for the quick reply and for explaining the background and I fully understand your concerns.
The main issue we’re hitting (and why I opened the feature request) is a very common enterprise setup:

AD CS + Certificate Templates live in the Resource Forest
Admins are logged on with accounts from the User Forest.

Right now all PSPKI cmdlets (including the pure template ones) follow the user context, so they look in the wrong forest. That’s the mismatch we see.
For the CA-related cmdlets (Get/Add/Remove/Set-CATemplate) I completely agree that ICertConfig COM limitations make full cross-forest support risky and potentially dangerous and side effects are real.
However, the template-only cmdlets (Get-CertificateTemplate, Get-CertificateTemplateAcl, Add/Remove/Set-CertificateTemplateAcl, etc.) only do plain LDAP against the Configuration partition. Those should be relatively safe to extend.

Proposal
Add -Domain (and optionally -Server) parameters to the template cmdlets, with a default value based on the local computer, not the user:

$DefaultDomain = ([System.DirectoryServices.ActiveDirectory.Domain]::GetComputerDomain()).Name

This way the behaviour becomes consistent:

No parameter → cmdlets automatically use the forest the computer is joined to (exactly what most people in resource-forest scenarios want).
-Domain / -Server supplied → explicit override (for real cross-forest cases).

Would you be open to implementing this limited scope for the template cmdlets only?
Looking forward to your thoughts!