Windows Autoenrollment

Domain-joined Windows clients enroll and renew user and computer certificates from a DuoKey CA through Group Policy — no Windows CA server required.

Gilt für:

DuoKey Cockpit v2Windows 10 / 11, Windows Server 2016+MS-XCEP · MS-WSTEP

Windows autoenrollment is validated end to end on Windows Server 2025 and Windows 11: policy retrieval, computer enrollment, renewal and refusal cases. As for any Group Policy change, roll it out to a pilot organizational unit first.

Overview

Windows can enroll certificates from a policy server and an enrollment web service over HTTPS, instead of from an Active Directory-integrated CA. DuoKey implements both services:

Service	Protocol	DuoKey URL
Certificate Enrollment Policy (CEP)	MS-XCEP GetPolicies (SOAP 1.2)	https://<origin>/ms-enroll/<endpoint-id>/cep
Certificate Enrollment Web Service (CES)	MS-WSTEP WS-Trust RequestSecurityToken	https://<origin>/ms-enroll/<endpoint-id>/ces

The client reads the policy (templates, CA certificate, CES address), builds a request for each template it is allowed to autoenroll, and posts it to the CES. No DCOM / RPC (MS-WCCE) is involved, so no Windows CA server is needed. The endpoint id in the URL is a routing identifier, not a secret.

What is supported

• Policy: one policy per template with template OID and name, validity and renewal period, enroll and autoenroll permissions, minimum key length, subject name and enrollment flags, and the key usage / extended key usage extensions. Users only see user templates; computers only see computer templates.
• Enrollment and renewal: PKCS#10, PKCS#7 and CMC requests. Requests are issued or refused immediately (there is no pending state); refusals return the standard Windows error codes (for example CERTSRV_E_TEMPLATE_DENIED, CERTSRV_E_KEY_LENGTH).
• Issuance policy belongs to the CA: only the public key is taken from the request. Subject, SANs, key usages, EKUs, validity and extensions come from the template.
• Certificate template extension: issued certificates carry the template extension, so Windows recognises the template and does not re-enroll, plus the CA's CRL distribution point and OCSP address when the CA has them.
• Inventory and audit: issued certificates appear in the certificate inventory and count towards the CA. Each policy request, enrollment and renewal is logged per endpoint (principal, template, outcome, serial) and shown on PKI > Windows.

Templates

Each Windows template is mapped to DuoKey settings:

Setting	Meaning
Name, OID, version	Template identity as Windows sees it (an OID is generated if you do not give one)
Enrollee	User or computer
Subject source	Build from identity: users get CN=<account> and a UPN SAN (optionally the e-mail), computers get CN=<DNS name> and a DNS SAN. Supply in the request: subject and SANs are copied from the request
Key usages, EKUs	Taken from the template, or from a linked DuoKey certificate profile
Validity, renewal period	Validity is capped by the linked profile and at 825 days
Minimum RSA key size, exportable key, autoenroll	Advertised to the client

Supply-in-request templates

With "supply in the request", anyone allowed to use the endpoint can name any subject. Windows does not autoenroll such templates; reserve them for restricted endpoints and manual enrollment.

Renewals copy subject and SANs from the certificate being renewed.

Authentication

Group Policy uses Kerberos (Windows integrated) by default. Cockpit does not terminate Kerberos itself; each endpoint uses one of three modes:

Mode	Windows authentication type	How the caller is identified
Trusted front-end (Kerberos)	Windows integrated	An authenticating front-end (IIS, or a reverse proxy with SPNEGO) performs Negotiate and forwards the principal in X-DuoKey-Enroll-Principal, with the endpoint secret in X-DuoKey-Proxy-Secret
Username / password	Username/password	WS-Security UsernameToken, checked against enrollment accounts defined on the endpoint (not against Active Directory). Passwords are at least 12 characters
Client certificate	X.509 certificate	The signature of a renewal request, or a TLS client certificate verified by the front-end and forwarded with the endpoint secret. The certificate is re-verified against the CA

The front-end secret is generated by Cockpit (256 bits), shown once and can be rotated. Without a valid secret the identity headers are ignored, so a client that reaches Cockpit directly cannot impersonate a user by setting headers. The front-end must overwrite (not append to) these headers.

Principals are accepted as DOMAIN\name, name@REALM or name; a trailing $ marks a computer account. A computer's DNS name comes from X-DuoKey-Enroll-Dns when forwarded, otherwise <host>.<AD DNS domain>. X-DuoKey-Enroll-Mail can supply the user's e-mail address.

Set up

1. Cockpit

1

Enable the feature

Windows autoenrollment must be enabled in the tenant's edition.

2

Create an endpoint

On PKI > Windows, create an endpoint with the issuing CA (a classical RSA or ECDSA CA; post-quantum CAs are refused), the authentication mode, the public HTTPS origin the clients reach (Windows requires HTTPS for CEP and CES) and the Active Directory DNS domain. Copy the front-end secret if one is shown.

3

Add templates

For example DuoKeyUser (user, built from identity) and DuoKeyComputer (computer, built from identity, client and server authentication). Optionally link each to a DuoKey certificate profile.

4

Add accounts (username / password mode only)

Create the enrollment accounts with their kind (user or computer) and UPN or DNS name.

2. Kerberos front-end

IIS (Application Request Routing + URL Rewrite) on a domain-joined server:

1

Site and Windows Authentication

Create a site bound to HTTPS with a certificate for the public origin. Enable Windows Authentication (Negotiate; kernel-mode off, or an SPN HTTP/<host> registered for the application pool identity) and disable Anonymous.

2

Allow the server variables

In URL Rewrite, allow HTTP_X_DUOKEY_ENROLL_PRINCIPAL and HTTP_X_DUOKEY_PROXY_SECRET.

3

Reverse-proxy rule

Rule ^ms-enroll/(.*) to https://<cockpit>/ms-enroll/{R:1}, setting HTTP_X_DUOKEY_ENROLL_PRINCIPAL = {LOGON_USER} and HTTP_X_DUOKEY_PROXY_SECRET = the endpoint secret (keep the rule readable by administrators only).

4

Restrict the backend

Allow only the IIS server to reach /ms-enroll/ on Cockpit. The secret already protects the endpoint; network restriction is defence in depth.

Linux reverse proxy (nginx with an SPNEGO module, or Apache mod_auth_gssapi): authenticate with a keytab for HTTP/<host>, set X-DuoKey-Enroll-Principal from the authenticated user and X-DuoKey-Proxy-Secret from a protected include file. Always set the headers so a client-supplied value is replaced.

3. Group Policy

For computers: Computer Configuration > Policies > Windows Settings > Security Settings > Public Key Policies. For users: the same path under User Configuration.

1

Certificate Enrollment Policy

Certificate Services Client - Certificate Enrollment Policy: set Configuration Model to Enabled, add a policy server with the CEP URL https://<origin>/ms-enroll/<endpoint-id>/cep and the authentication type of the endpoint (Windows integrated, Username/password or X.509 Certificate), click Validate Server, tick Enable for automatic enrollment and renewal, then make it the default. Remove Active Directory Enrollment Policy if DuoKey should be the only source.

2

Auto-Enrollment

Certificate Services Client - Auto-Enrollment: Enabled, with Renew expired certificates, update pending certificates, and remove revoked certificates and Update certificates that use certificate templates.

3

Trust

Distribute the DuoKey root CA to Trusted Root Certification Authorities (and intermediates to Intermediate Certification Authorities), and make sure clients trust the TLS certificate of the public origin.

4

Username / password mode

The credential must be stored on each client so autoenrollment can run unattended: enter it when the client first contacts the policy server (Certificates console, Request New Certificate, enrollment policy properties, remember the credential), in the user or machine context. certutil -credstore lists stored credentials.

5

Test on a client

gpupdate /force, then certutil -pulse (machine) or certutil -user -pulse (user). certutil -policyserver * -template lists the templates the policy returns; the Application event log (source CertificateServicesClient-AutoEnrollment) shows the outcome.

Manual enrollment against the same policy:

Manual enrollmentPOWERSHELL

certreq -enroll -q -policyserver "https://<origin>/ms-enroll/<endpoint-id>/cep" DuoKeyComputer

Renewal

Windows renews certificates during the template's renewal period. A renewal request signed with the current certificate is accepted when that certificate chains to the endpoint CA, is within its validity period, was issued by Cockpit, is not revoked and comes from the same template. With key-based renewal enabled on the endpoint (the default), such renewals need no other credential, so certificates renew without a stored password. The policy then also advertises a renewal-only, certificate-authenticated CES address.

Revoking a certificate in Cockpit stops its renewal.

Limits

• No directory lookup. Subjects are built from the principal and the forwarded DNS / mail headers (or the account fields). Directory attributes such as department, the full directory DN or the security identifier (SID) extension are not added. Certificates used for smart card or Windows Hello logon on domain controllers that enforce strong certificate mapping therefore need explicit mapping, or are out of scope.
• No pending / manager-approval requests, key archival, enroll-on-behalf-of or template supersedence. Algorithm and provider lists (CNG schema 3/4 attributes) are left to the client.
• Kerberos requires the front-end described above.
• Post-quantum CAs cannot be used.
• Endpoints share the API rate limit of 300 requests per minute per client address. Clients usually arrive through one front-end address: if a large estate renews at once, spread the load on the front-end side.

Security

• XML documents with DTDs or entity declarations are refused; request sizes are capped.
• No secret travels in a URL. Account passwords are stored as Argon2id hashes and the front-end secret as a verifier; neither is logged or returned after creation.
• Protocol faults never return internal error details.
• The endpoint is subject to the CA's access policy and high-value issuance rules.

API

Method and path	Purpose
GET / POST /api/pki/ms-enrollment/endpoints	List / create endpoints
GET / PUT / DELETE /api/pki/ms-enrollment/endpoints/{id}	Read / update / delete an endpoint
POST /api/pki/ms-enrollment/endpoints/{id}/proxy-secret	Rotate the front-end secret
/api/pki/ms-enrollment/endpoints/{id}/templates, /api/pki/ms-enrollment/templates/{id}	Templates
/api/pki/ms-enrollment/endpoints/{id}/accounts, /api/pki/ms-enrollment/accounts/{id}	Enrollment accounts
GET /api/pki/ms-enrollment/endpoints/{id}/requests	Request log

Permissions: Operations.Pki.MsEnrollment.Read, .Create, .Update, .Delete.

Siehe auch

• Enrollment Protocols
• Intune & MDM Certificate Delivery
• PKI Governance
• CA Management