Active Directory domains and request-validation rules let a Skyrsoft CertOps template confirm that an enrolment request corresponds to a real, existing AD user or computer object before it issues — and, optionally, keep an issued certificate in step with that object’s lifecycle afterwards. Register the forests you want checked, attach validation rules to them, and bind a template to the result. Request validation itself carries no separate licence gate; it works the same on Free and Pro.
How it works
| Setting | Controls |
|---|---|
| LDAP host / port | Domain controller address — plain LDAP on 389, or LDAPS (typically 636) |
| Base DN | Search root, e.g. DC=corp,DC=example,DC=com |
| Bind account | DN or UPN and password used to query AD; left blank the bind is anonymous, which most environments reject |
| Query timeout | Per-request LDAP timeout in seconds (default 10) |
| AD sync interval | How often the disabled-object check re-queries the domain (default 300s) |
| Suspend on outage | Holds certificates rather than revoking them while the directory is unreachable |
| Outage tolerance | How long the directory may be unreachable before that hold applies (default 24 hours) |
Each forest to be queried is registered as its own entry, and more than one is supported. A template binds to a single AD domain, and every enabled validation rule for that domain then applies automatically, including ones added later.
Request validation rules
A rule performs a hard-match lookup against AD, given an object type (computer, user, or either) and a match field — the requesting device’s FQDN, the CSR’s subject CN, its first DNS SAN, or its UPN SAN. Rules for a domain run in priority order and the request passes as soon as any one matches; it is rejected only once every rule has failed to find one. Validation is fail-closed: an unreachable directory rejects the request, a match against a disabled account is a hard failure by default, and a request carrying no value for any field a rule matches on is rejected outright rather than silently skipping the check.
SID strong-mapping for NPS and 802.1X
A certificate issued through an AD-validated template carries the AD SID security extension,
binding it to the matched object’s objectSid. Since Microsoft’s KB5014754 hardening — enforced by
default on domain controllers since February 2025 — a domain controller will not map a certificate
to an account from its UPN alone, and a certificate without this extension is refused with no
corresponding entry in the NPS log at all. The issuing CA also has to be published to the domain’s
NTAuth store separately from ordinary trust, or AD will not accept its certificates for
authentication however they are built.
A resolved name still has to be one NPS can act on: it checks the certificate’s identity against a real account name before it ever looks at the SID. A Windows supplicant builds that name itself and this is invisible in practice; macOS’s own 802.1X client sends the certificate’s subject CN verbatim, so a machine certificate issued through AD validation carries the matched object’s UPN alongside it, which is what lets an AD-validated Mac authenticate against NPS at all.
Machines that are not domain-joined
A workgroup machine has no AD object, so there is no SID to embed and no directory check to run
against it. Its certificate is issued normally and is perfectly valid, but it cannot authenticate
against NPS — a property of how Windows maps certificates to accounts, not a limitation of the
certificate itself. Joining the domain is the only route to a SID; short of that, an
altSecurityIdentities entry per account works for a handful of machines but breaks on every
renewal, and a RADIUS server that authenticates against the issuing CA and revocation status
instead of a directory mapping sidesteps the problem entirely.
Live UPN fallback lookup
Both the per-user agent and the machine agent’s relay resolver read the signed-in identity’s UPN claim first, which a background service reading an ordinary interactive logon token rarely has populated. Each now falls back to a live, bounded AD lookup — a three-second timeout, cached once it succeeds — before falling back further to a bare account name if AD cannot be reached at all.
Revoke on account disable
Turning on Revoke certificates when the AD object is disabled starts a periodic scan that checks every active certificate issued against that domain against its backing AD account, and revokes one automatically, reason “privilege withdrawn,” once that account is found disabled or deleted. An unreachable directory is treated differently: nothing is revoked on the strength of a timeout, since an outage says nothing about any individual account. Past the outage tolerance, certificates are suspended instead — a hold that lifts automatically once the directory answers again and the account checks out.
Limits
A workgroup machine can hold a perfectly valid certificate and still fail 802.1X. No setting here changes that; it is a property of Windows account-to-certificate mapping rather than of request validation.
Test Connection proves the bind account can authenticate, not that a lookup will find anything. It does not check the base DN or the account’s search permissions.
The disabled-account scan is periodic, not event-driven. Expect up to about fifteen minutes between an account being disabled and its certificate flipping to Revoked — the scan runs on the domain’s own sync interval, but never faster than the revocation engine’s own cycle.
An unreachable directory blocks renewal as well as new issuance. A template bound to AD asked for its requests to be checked; if the directory cannot answer, that check has not happened, and nothing bound to it issues or renews until it can.