Autoenrollment from EJBCA
Windows computers and people can get and renew certificates from EJBCA by themselves, the way they autoenroll from ADCS, through EJBCA Enterprise's Microsoft Auto-enrollment (MSAE). Lighthouse makes the two things each template needs, the certificate template in Active Directory and the EJBCA profiles it maps to, and lists the steps that remain in EJBCA's admin web and Group Policy. This guide is for the Lighthouse administrator, the EJBCA administrator and the AD team.
How it works
- Group Policy tells Windows to ask EJBCA's enrollment policy server (
https://<EJBCA host>/ejbca/msae/CEPService?<alias>) which certificates it should have, signing in with Kerberos. - EJBCA reads the certificate templates in Active Directory, keeps those it has a mapping for, and checks who may enroll and autoenroll (the template's Read, Enroll and AutoEnroll permissions).
- Windows makes the key, sends the request, and EJBCA issues it with the end entity profile and certificate profile the template is mapped to. Names come from the computer's or person's account in Active Directory.
- Windows renews by itself before expiry (the template's renewal period). Lighthouse sees each certificate on the CA's next read.
The template is in Active Directory but no ADCS CA publishes it, so only EJBCA issues it. An ADCS CA can keep issuing its own templates beside it.
In short
- Turn on Make templates on the CA under Settings, Features (Enterprise license).
- On the EJBCA CA under Settings, CAs, set the template account (the same kind of separate AD account New template uses on an ADCS CA; it needs only two rights) and, if they differ from the defaults, the autoenrollment alias (
msae) and the policy server address. - Do the setup once in EJBCA and Active Directory.
- Press Autoenrollment on the EJBCA CA, fill in the form, Preview, then Create. Lighthouse makes the template and the profiles, then lists what is left for that template.
- Every create, and every failed one, is in the Keeper's Log (
ejbca-autoenrollment-create,ejbca-autoenrollment-create-failed).
The form
| Field | What it sets |
|---|---|
| Name, Display name | The template's name in Active Directory and what the Certificate Templates console and EJBCA's template list show |
| Start from | A template Active Directory already has, such as Computer, User or Web Server. It is copied, never changed |
| Use | Server, Client or Email. Computers often take Client (and Server); people Client and Email |
| Names from Active Directory | DNS name (computers), UPN and email (people). Autoenrollment cannot type names, so they always come from the account |
| Validity, renewal period, minimum RSA key size | As in New template; empty keeps the template's own. The certificate profile gets the same validity |
| Groups that autoenroll | Each gets Read, Enroll and AutoEnroll on the template, and nothing else |
| Copy the end entity profile | An EJBCA end entity profile to copy. Its certificate profile is copied too |
| New profiles' name | The new end entity and certificate profiles' name; empty uses the template's name |
| CAs | The EJBCA CAs the profiles may issue from; the first ticked is the default |
The new end entity profile has one SAN field for each name picked (a DNS name for computers, a UPN or email for people). A UPN can sign in to Windows; here it always comes from Active Directory, never from a requester.
Create makes the template first, as the template account, then the profiles with the CA's profile certificate. If EJBCA refuses the profiles (a profile of that name exists, say), Lighthouse takes the template and its OID away again and says so. Without a profile certificate, Lighthouse makes the template and lists the profiles as steps for EJBCA's admin web.
Lighthouse adds no Lighthouse template: Windows asks EJBCA directly, not Lighthouse.
Rights
The template account (Settings, CAs, the EJBCA CA): an ordinary AD user with a password, never the gMSA. It needs only Create and delete certificate templates and Create and delete OID objects, the first two of New template's three rights; there is no ADCS CA to publish on. The form's Set up the template account has the PowerShell for an Enterprise Admin, which prints OK or MISSING for each right, and ticks or crosses what the account has. If an ADCS CA in Lighthouse already uses the same account, it already has both.
The profile certificate (same place): as for New profile, an EJBCA role that may view and edit certificate and end entity profiles, with REST ConfigDump on. See New EJBCA profiles in docs/server.md.
Group Policy: someone who may edit the GPO for the computers or people. Lighthouse never changes Group Policy.
Once, before the first template
The form lists these with your names filled in. In EJBCA's admin web and Active Directory:
- System Configuration, Protocol Configuration: enable MSAE.
- System Configuration, Custom Certificate Extensions: add OID
1.3.6.1.4.1.311.21.7, label Certificate Template Information, encoding DEROBJECT, Dynamic on. It tells Windows which template a certificate came from, so it can renew it. - Active Directory: an ordinary user account for EJBCA's policy server, such as
ra-service(not a gMSA, not in Protected Users), and an account EJBCA reads Active Directory with (it can be the same one). The policy server's host needs an A record; a CNAME breaks Kerberos. - On a domain controller, as a Domain Admin:
setspn -s HTTP/<host> ra-service, thenktpass /out ra-service.keytab /mapuser ra-service@<domain> /princ HTTP/<host>@<REALM> /pass * /ptype KRB5_NT_PRINCIPAL /crypto AES256-SHA1. Keep the keytab safe; it is the account's key. - System Configuration, Autoenrollment Configuration: Add the alias (
msaeunless you set another under Settings, CAs): Forest Root Domain, a domain controller, Policy Name, Service Principal NameHTTP/<host>@<REALM>, the keytab, a krb5.conf with your realm, the AD user login and password, and the Default CA. Press Test Connection, then Save. - Group Policy: EJBCA's root and issuing CA certificates in Trusted Root Certification Authorities and Intermediate Certification Authorities for the computers that autoenroll.
For each template, after Create
The result lists these with the template's and profiles' names:
- CA Functions, Certificate Profiles, Edit the new certificate profile: under Used Custom Certificate Extensions add Certificate Template Information. Lighthouse cannot set this, because the extension's number in the profile is EJBCA's own.
- System Configuration, Autoenrollment Configuration, Edit the alias: under MS Auto Enrollment Templates pick the template, the new end entity profile and certificate profile, press Add, then Save. If the template is not listed yet, wait a few minutes for Active Directory to copy it, then Edit and Save the alias again.
- Group Policy for the groups (Computer Configuration for computers, User Configuration for people), Policies, Windows Settings, Security Settings, Public Key Policies:
- Certificate Services Client - Certificate Enrollment Policy: Enabled, Add the policy server address, Validate Server, Add, and make it the default. Keep Active Directory Enrollment Policy while an ADCS CA still issues to these computers.
- Certificate Services Client - Auto-Enrollment: Enabled, with Update certificates that use certificate templates ticked.
- Try it on one member:
gpupdate /force, thencertutil -pulse(computers) orcertutil -user -pulse(people). The certificate shows in certlm.msc (certmgr.msc for people), and in Lighthouse after the CA's next read.
Undo
Delete the template in the Certificate Templates console (its OID object goes with it, or delete it under CN=OID in ADSI Edit), remove the mapping from the alias, and delete the two profiles in EJBCA. Certificates already issued stay valid until they expire or are revoked.
Not checked live yet
Lighthouse's EJBCA steps follow Keyfactor's EJBCA 9.x Microsoft Auto-enrollment guide. Making profiles over ConfigDump has not been tried on the lab's EJBCA yet, and EJBCA's menus can move between versions; check the names against the version you run.