New ADCS templates from Lighthouse

Administrators can make a new Microsoft ADCS certificate template from Lighthouse, with what its certificates are for, where their names (subject and SANs) come from, validity, key size and who may enroll, and publish it on the CA, without opening the Certificate Templates console. This guide is for the Lighthouse administrator and for the AD team that sets up the account Lighthouse writes with.

In short

• Turn on Make templates on the CA under Settings, Features (Enterprise license). It starts off.
• Open an ADCS CA under Settings, CAs and press New template.
• Lighthouse copies a template Active Directory already has, as Duplicate Template does, and changes only what you set. The template it starts from is never changed, and Microsoft's own templates stay as they are.
• Lighthouse writes as a separate template account, never as its own service account (the gMSA). Without one, it prepares the same template as a PowerShell script for an AD administrator to run.
• Create also adds the Lighthouse template that issues from the new ADCS template, open to the teams and people you pick, so it shows under Templates & Policies and on Enroll straight away.
• Lighthouse refuses templates that would let someone get a certificate for another identity (see Guard rails).
• The rights each account needs are all in one place: Every permission, in full.
• Every create, and every failed one, is in the Keeper's Log (adcs-template-create, adcs-template-create-failed).

The form

Preview shows what will be made and changes nothing. Create in Active Directory makes it and adds the Lighthouse template. The Lighthouse template's maximum validity is the ADCS template's validity; change anything else about it (key types, domains, facts) under Templates & Policies. If the Lighthouse template cannot be added, for example because its name is taken (Preview says so first), the ADCS template stays made and Add a Lighthouse template opens the form with everything filled in.

Two lists of who may enroll. Lighthouse asks ADCS for certificates as its own account, so ADCS never sees the person. Who may enroll through Lighthouse is the Lighthouse template's teams and people. Who may enroll at the CA is only for people who go to ADCS directly.

ADCS takes as many DNS names and IP addresses as the request carries; it has no count like EJBCA's profiles. Limit them in the Lighthouse template (Templates & Policies) instead.

What Lighthouse writes

1. A new OID object (msPKI-Enterprise-Oid) in CN=OID,CN=Public Key Services,CN=Services,CN=Configuration,..., under the forest's own OID arc, so the template has its own OID.
2. The new template object (pKICertificateTemplate) in CN=Certificate Templates,..., with the attributes of the template it starts from and these changes:
   • template version 2 at least (msPKI-Template-Schema-Version), revision 100, and the general flags of a changed copy (not "default", "modified");
   • the extended key usages for the uses picked, in both pKIExtendedKeyUsage and msPKI-Certificate-Application-Policy, and key usage to match (digital signature, plus key encipherment for server and email on RSA);
   • msPKI-Certificate-Name-Flag for the names;
   • msPKI-Enrollment-Flag for manager approval and autoenrollment, with the SID security extension always kept;
   • pKIExpirationPeriod, pKIOverlapPeriod and msPKI-Minimal-Key-Size when asked or needed.
3. Read and Enroll (and AutoEnroll where asked) for each group on the template. The rest of the template's permissions are Active Directory's defaults for a new template: Domain Admins, Enterprise Admins and SYSTEM have full control and Authenticated Users read. The template account owns the template it made.
4. The template's name added to the CA's published templates.

If a step fails, Lighthouse takes away what it made before that step, and the error says what was done and what was undone. Active Directory copies the new template to every domain controller within minutes; the CA issues it once its domain controller has it.

Guard rails

Lighthouse refuses, and says what to change:

Always, without asking:

• nobody but the groups you list gets more than Read, and nobody gets write (ESC4);
• the SID security extension stays in certificates, even if the start template left it out (ESC9);
• the copy is version 2 at least, since version 1 templates take names from the request without checks (ESC15);
• the minimum RSA key size is at least 2048.

Setting up the template account (once, by the AD team)

Certificate templates live in the forest's Configuration partition, which by default only Enterprise Admins may change. Lighthouse needs much less, and only for a separate account. It takes about ten minutes.

1. Make the account. On a domain controller, as an administrator:

   $pw = Read-Host -AsSecureString "Password for svc-lh-templates"
   New-ADUser -Name "svc-lh-templates" -SamAccountName "svc-lh-templates" -UserPrincipalName "[email protected]" `
     -AccountPassword $pw -Enabled $true -PasswordNeverExpires $true -CannotChangePassword $true `
     -Description "iRonShore Lighthouse: New template on ADCS (delegated, no admin rights)"
   

   A gMSA cannot be used, since Lighthouse signs in to LDAP with a name and password. It does not need to sign in anywhere interactively, so you can set Deny log on locally and Deny log on through Remote Desktop Services for it by Group Policy. Do not add it to any group.

2. Give it its three rights. In Lighthouse, open the ADCS CA, press New template and open Set up the template account. Press Copy setup script and run it in PowerShell as an Enterprise Admin, on a domain controller or a computer with the AD tools. It is written for your forest, CA and account, adds each right to that one object only, and prints a line per right:

   OK       CreateChild,DeleteChild for pKICertificateTemplate on CN=Certificate Templates,CN=Public Key Services,...
   OK       CreateChild,DeleteChild for msPKI-Enterprise-Oid on CN=OID,CN=Public Key Services,...
   OK       ReadProperty,WriteProperty for certificateTemplates on CN=Contoso Issuing CA,CN=Enrollment Services,...
   

   Any line that says MISSING did not take. Running the script again is safe. To give the rights by hand instead, see Giving the rights by hand.

3. Give Lighthouse's own account Request Certificates on the CA, if it does not have it yet: certsrv.msc, right-click the CA, Properties, Security, select the account (Object Types: tick Service Accounts for a gMSA), tick Allow Request Certificates. This is on the CA itself, not in Active Directory.

4. Tell Lighthouse. Settings, CAs, open the ADCS CA and fill in Template account (CONTOSO\svc-lh-templates) and Its password. The password goes to the server's secret store (encrypted with DPAPI for the service account) and is never shown again. Domain controller is optional; empty lets Windows pick one in the server's site.

5. Check it. Open New template again. Set up the template account now reads "The template account ... has its three rights", with a tick for each. A cross names the right that is missing.

6. Try it. New template, start from Web Server, Preview, Create. Wait a few minutes (or run certutil -pulse on the CA), then enroll a test certificate through the new Lighthouse template.

Clients who will not give any account these rights leave Template account empty. New template then prepares everything and gives the PowerShell (ActiveDirectory module and dsacls) for their own AD administrator to review and run. Add a Lighthouse template works the same afterwards.

Every permission, in full

Three accounts are involved. Only the template account gets anything new in Active Directory, and only on three objects.

The template account (such as CONTOSO\svc-lh-templates). <forest> is the forest root, such as DC=contoso,DC=com; <CA> is the CA's name, the part of its config after the backslash.

• Lighthouse does not give it Enroll anywhere. An Enroll entry on the CA's object is not right 3 and does not let it publish (in our lab a first try ended with only that).
• It owns the template and OID objects it creates, as their creator, so it can set their permissions (Read and Enroll for the groups you list) and delete them. It cannot change any other template.
• It is not an Enterprise Admin, Domain Admin or CA administrator, and needs no group. Full control on the containers works too, but gives far more than needed.
• Run right 3 once per CA that should publish Lighthouse's templates.

Lighthouse's own account (the gMSA, such as CONTOSO\gmsa-lighthouse$, or whichever account Lighthouse runs as):

Never give the gMSA the template account's three rights: then anything that runs as Lighthouse could make templates.

People who enroll through Lighthouse need nothing in Active Directory or on the CA. They are the Lighthouse template's teams and people and groups (Templates & Policies). ADCS only sees Lighthouse's own account.

The administrator who sets it up needs Enterprise Admins (or Full control on the three objects) for steps 1 and 2, and to be a Lighthouse administrator for New template.

Checking the rights

• In Lighthouse: New template, Set up the template account shows a tick or a cross for each of the three rights, read from the objects' permissions as Lighthouse's own account. Only rights given to the template account itself count; a right it has only through a group shows as missing. A question mark means Lighthouse could not read that object's permissions.

• In PowerShell, for one object (here the CA's):

  (Get-Acl "AD:CN=Contoso Issuing CA,CN=Enrollment Services,CN=Public Key Services,CN=Services,CN=Configuration,DC=contoso,DC=com").Access |
    Where-Object { $_.IdentityReference -like "*svc-lh-templates" } | Format-Table ActiveDirectoryRights, ObjectType
  

  Expect CreateChild, DeleteChild on the two containers and ReadProperty, WriteProperty on the CA's object.

• With dsacls: dsacls "<object>" | findstr /i svc-lh prints Allow CONTOSO\svc-lh-templates SPECIAL ACCESS for pKICertificateTemplate (or msPKI-Enterprise-Oid, or certificateTemplates). Nothing printed means the right is not there. Enroll alone on the CA's object means right 3 is still missing.

Giving the rights by hand

With dsacls, as an Enterprise Admin (for a forest contoso.com and the CA Contoso Issuing CA). Each line ends with "The command completed successfully"; check afterwards as above, since dsacls also says that when it added something else.

dsacls "CN=Certificate Templates,CN=Public Key Services,CN=Services,CN=Configuration,DC=contoso,DC=com" /G "CONTOSO\svc-lh-templates:CCDC;pKICertificateTemplate"
dsacls "CN=OID,CN=Public Key Services,CN=Services,CN=Configuration,DC=contoso,DC=com" /G "CONTOSO\svc-lh-templates:CCDC;msPKI-Enterprise-Oid"
dsacls "CN=Contoso Issuing CA,CN=Enrollment Services,CN=Public Key Services,CN=Services,CN=Configuration,DC=contoso,DC=com" /G "CONTOSO\svc-lh-templates:RPWP;certificateTemplates"

In ADSI Edit (adsiedit.msc), as an Enterprise Admin:

1. Action, Connect to, Select a well known Naming Context: Configuration, OK.
2. Open CN=Configuration, CN=Services, CN=Public Key Services.
3. Right-click CN=Certificate Templates, Properties, Security, Advanced, Add, Select a principal: the template account. Applies to: This object only. Clear the ticks it starts with, and tick Create pKICertificateTemplate objects and Delete pKICertificateTemplate objects. OK three times.
4. The same on CN=OID, with Create msPKI-Enterprise-Oid objects and Delete msPKI-Enterprise-Oid objects.
5. Open CN=Enrollment Services, right-click the CA's object, Properties, Security, Advanced, Add, the template account, Applies to: This object only. Clear the ticks it starts with, and on the Properties part of the same page (scroll down, or the Properties tab on older Windows) tick Read certificateTemplates and Write certificateTemplates. OK three times.

Changing the password

Change it in Active Directory, then type the new one under Settings, CAs, the ADCS CA, Its password. Lighthouse uses it only when an administrator presses Create, so nothing fails in between.

Common errors