Creating Custom Secure LDAP Certificates for Domain Controllers with Auto Renewal

Artikel
06/03/2016

Working with customers each week on securing their Active Directories, there are some procedures you end up doing regularly. Installing and configuring custom certificates onto Domain Controllers to enable LDAP over TLS for me is one of them. The primary reason for enabling this functionality is to allow third-party applications that aren’t capable of performing secure binds or encrypted LDAP sessions (over TCP 389) to connect securely. Trust me, there are plenty of applications that need it.

[caption id="attachment_415" align="alignright" width="516"] Custom LDAP Certificates Example Example Deployment Scenario[/caption]

Along with deploying these certificates, most customers like to place some form of load balancer in-front of these DCs to ensure applications will always have high-availability access. This method generally involves a custom alias such as "ldap.domain.com" targeted at the load balancers with connections then forwarded to a subset of DCs.

Important Note: The load balancer method of enabling highly available LDAP access is NOT supported by Microsoft, but it does work. To be fully supported, applications need to be using our documented methods to locating and binding to DC's. If an application is misbehaving, be ready to abandon this configuration if deeper application troubleshooting is required.

As with all TLS connections, if you attempt to connect to any server where the subject name mismatches, the connection will fail validation. Most admins are familiar with the errors associated with this scenario when deploying HTTPS. So to allow our application servers to bind securely to a custom LDAP DNS name and ensure connections are valid with the correct name, we need to ensure the custom LDAP DNS name is present in our Domain Controller certificates. Easy enough to do with some prep, impossible to do automatically. But that's why your here right?

Our Domain Controllers by default will use one of the 3 built-in certificate templates for LDAP over TLS purposes. These templates were introduced consecutively with each OS release. The templates are the:

Domain Controller (Windows Server 2000)
Domain Controller Authentication (Windows Server 2003)
Kerberos Authentication (Windows Server 2008 and above)

Our modern domain controllers can use any one these 3 certificate templates, however we really want your DC's to be using the Kerberos Authentication template. By default, it includes multiple SAN entries that represent the Domain Controller, Active Directory Domain FQDN and the Active Directory NetBIOS name. Additionally it contains a new Enhanced Key Usage to allow strict KDC validation to be enabled on all modern clients that are performing smart-card based (PKINIT) logons.

This walk through is going to leverage a fairly unknown feature of the auto enrollment component in Windows that allows certificates requested from an Offline Template (that is one where you provide the subject names in the Certificate Signing Request or CSR) to be automatically renewed without CA certificate manager intervention. The method described can actually be used for any certificate template where you want the auto enrollment component to automatically renew certificates and keep the existing subject names.

Note. This procedure only works for machines and Enterprise Issuing CA’s that are at least Windows 7 /2008 R2 or above.

Lets get started.

Certificate Authority - Certificate Template Prep

To make this work, we need a slightly modified version of the "Kerberos Authentication" template. In this example, we are going to configure a custom template for our "Special DCs" DC’s that are going to be targeted by our load balancers. All other DC’s will continue to use standard Kerberos Authentication template.

On your Enterprise Issuing CA, open "certsrv.msc" and right-click the "Certificate Templates" folder and select "Manage". This will show you all the templates present in the Active Directory forest.
Scroll down until your find "Kerberos Authentication " . Right-click it and select "Duplicate"
If you are on 2012/2012R2, you will be presented with the compatibility screen. Unless you know what you’re doing with version 3/4 templates, simply select "Windows Server 2008 R2" and "Windows 7/Windows Server 2008 R2" for both of the options and select OK on the confirmation prompts.
On the "General" tab, give your new template the name "Kerberos Authentication (Offline Request)". In production environments, prefixing the name with a few letters can help group your active templates together in the UI, recommended but optional.
Now, to make it an Offline Template, simply head over the "Subject Name" tab and select the top radio box "Supply in the Request". Click OK on the security warning prompt. Please read an understand this prompt. In our scenario, only DCs have the ability to request this certificate, but with other certificate templates, the ticking of this box should be done only if restricted and trusted users can request the template.

[caption id="attachment_455" align="aligncenter" width="300"] Use Subject in Auto Enrollment Renewals[/caption]
Also on the "Subject Name" tab, tick the "Use subject information from existing certificate for autoenrollment renewal requests". This tick box is critical to the “magic sauce” that allows the CA Policy engine to reuse the existing certificate subject name values instead of being provided as brand new ones in the CSR. (This is an offline request, the names can't be built from Active Directory)
Next, open the "Security" tab and remove the “Enroll” security right from "Domain Controllers","Enterprise Domain Controllers" and "Enterprise Read-only Domain Controllers”.
Add new ACE’s for each of the special DC’s (or possibly a security group with them in) that are to receive the custom certificates and ensure they have the “Read" and "Enroll” security right only. Check that no other entries include Enroll or Autoenroll except administrative user groups. Make sure you enable "Computer Objects" in the select objects prompt.
Optional. For advanced players, head over to the "Superseded Templates" tab and add the "Domain Controller", "Domain Controller Authentication" and "Kerberos Authentication" templates to the list. This will "archive" any certificates from those templates when this new one is enrolled. Note. Archived = hidden, not deleted.
Close the new template to save it.
Now that our new template for the "special" DC's is ready to go, open the original “Kerberos Authentication” template and the security tab. Add the Deny “Enroll” and "Auto Enroll" right to the special DC’s you are giving custom certificates to. This will stop them from getting the standard Kerberos Authentication certificates during the auto enrolment process.
As per normal, we need to actually issue the template. Right-Click "Certificate Templates" again and select "New" and "Certificate Template to Issue"
From the list, select your newly minted "Kerberos Authentication (Offline Request)" template and click OK.
Optional - If both the original "Online" and our new "Offline Kerberos Authentication" templates are present in the issuance list, remove the older "Domain Controller" and "Domain Controller Authentication" templates. Simply right-click them and select "Delete". This doesn't remove template itself from Active Directory, just their issuance from this particular CA. If you have multiple CAs, it's a good idea to remove their issuance form them as well. Should you issue the "Kerberos Authentication" templates from multiple CAs? You can, but not really required.

Domain Controller - GPO Prep

OK, so I'm not going to into to much depth on this one as it's pretty simple. Auto Enrollment is usually configured in a Domain Controller Policy by the GPO settings at this location " \Computer Configuration\Windows Settings\Security Settings\Public Key Policies\Certificate Services Client – Auto-Enrollment". Most orgs already have this enabled and you simply need to confirm that both the first and second check box "Update certificates that use certificate templates" is enabled.

It's completely up to you if you want this GPO purely targeted at your special DCs or all of your DCs

Warning. If you are enabling Auto Enrollment for the first time, you may receive other "unexpected" certificates on your DC's. You can prevent this by analysing the security tab of all certificate templates currently being issued by your CAs and ensuring that any of the "Domain Controller" computer groups have not been granted the "Auto Enroll" security right. But that wouldn't happen because you know the security DACLS of all your templates right? No? ... well pencil some time for a quick review in the near future.

[caption id="attachment_425" align="aligncenter" width="300"] Auto Enrollment Group Policy Settings[/caption]

Domain Controller - Initial Enrollment

Because we need to provide the extra subject names, the initial certificate enrollment for our special DCs must be performed manually.

On one of our special Domain Controllers, Open "certlm.msc". If it's a 2008 R2 DC, you will need to open "mmc.exe" and add the "Certificates" snap-in targeting the local computer.
Right-Click the "Personal" store and select "Request New Certificate". Click "Next" twice until the screen with available templates appears. Select the check box next to our "Kerberos Authentication (Offline Request)" Template and then click the hyperlink "More Information is required ...." below the name.
Leave the "Subject Name" blank, but add the following to the alternative name section. The first 3 are the names that are added automatically with the built-int template. The last one is our new custom name. They are all of the type "DNS"FQDN of the AD Domain Controller
FQDN of the AD Domain
NetBIOS name of the AD Domain
Your new custom secure LDAP DNS name

[caption id="attachment_435" align="aligncenter" width="300"] Subject Alternative Names[/caption]
Click "OK" once you have finished adding the names and then "Enroll" to send the CSR to the Enterprise Issuing CA for issuance.
When complete, expand the Personal -> Certificates folder and check out your shiny new cert. Double-click the certificate to open it and confirm the names present in the Subject Alternate Name extension. If there are multiple certificates, you can scroll the console window to the right to see the template names.
Repeat the process on the other special DCs you wish to create a custom secure LDAP certificate for.

Domain Controller - Verifying renewal will work

So at this point, your special DCs should have the appropriate certificate, but we want to make sure our new automatic enrollment renewal plumbing works. We don't want auto enrollment renewal to fail in ~11 months’ time due to a slight mis-configuration. We can easily confirm that everything is configured well by increasing the "major version" of the certificate template. When we increase this value, it's a signal to the Auto Enrollment client on the machine that the CA administrator has requested re-issuance of certificates based on that particular template.

This is where the first and second tick boxes in the auto enrollment client GPO configuration is critical, without it, this particular logic branch will never execute. You may also remember we didn't initially allow auto enrollment for our special DCs from our new template, this was to stop them from attempting auto enrollment, we need to enable this now. (Sidenote, it's perfect valid configuration to enable auto enrollment for offline templates. The machines will simply show a balloon pop-up when an administrator logs requesting intervention to provide the subject names)

Open “certsrv.msc” on your Enterprise Issuing CA and right-click the “Certificate Template” folder and select "Manage" to open the Certificate Templates Console.
Open the security tab of our "Kerberos Authentication (Offline Request)" template and simply add the “Auto-Enroll” security right/flag to the existing ACEs for our special DCs. This will allow the auto enrollment client on our special DCs to now consider this template as part of its automatic renewal process and also monitor the template version for update requests. Close the certificate template properties to save it.
Right-click our "Kerberos Authentication (Offline Request)" template and select "Reenroll All Certificate Holders". If you have a keen eye, you will notice the version will change from something like 100.2 to 101.0. The minor version (the second number) will increase every time you make a change to the certificate template. Increasing the minor version won't affect already issued certificates. Increasing the major however instructs clients with the second auto enrolment client check box enabled to renew this certificate at their next update cycle. We want to trigger this to ensure everything works a treat.
Back on your DC, feel free to wait around until this occurs or you can run "certutil -pulse". If you really love your GUI, in the certificates console, right-click "Certificates - Local Computer" at the top of the left-hand tree and select "All Tasks" -> "Automatically Enroll and Retrieve Certificates"
It may take a few minutes, but once it's completed (all going well), you should be able to analyse the "Certificate Template" field in your "Kerberos Authentication (Offline Request)" certificate and see the major version field matches the increased version of your certificate template. If the version hasn't increased, confirm your GPO and certificate template settings. See below on how to view your older archived certificates (including any superseded ones)
Once again, validate all your subject names are correct and expected. The next section can make things a little easier.

[caption id="attachment_445" align="aligncenter" width="1024"] Old and New Template Versions[/caption]

LDAP/S (TCP 636) Validation

One of the good (or possibly bad?) functions of Domain Controllers is that they will pretty much immediately start using the brand new "Kerberos Authentication" certificates for their LDAP/S connections. Because of this, you can check immediately if the certificate is being presented correctly. The easiest way is to download my Domain Controller LDAP/S Certificate Audit script and directly query all of your DC's. The script will output both to screen and a .CSV for easy analysis.

We primarily want to check that our special DCs have the appropriate updated Subject, V2 Template and EKU extensions with our new values. Not a bad time to confirm the remainder of our DCs are using Kerberos Authentication template certificates as well.

Some Pre-emptive Q&A's

Q: I only have a few Domain Controllers, can I simply apply this guide to all of them?
A. Yup, even if you have 300 DCs, you can perform this guide on all of them if you wish. It will just take you a while.

Q. What if I want a number of custom LDAP DNS names? Say a unique one for multiple DCs in each of my data-centre locations?
A: Simple. The renewal will simply follow whatever name you enrol in the original enrolment, so simply configure the appropriate custom name on the appropriate DCs

Q: I'm feeling nostalgic and want view my older archived certificates, how can I see them?
A: In the certificates console, right-click the root of the tree then select "view" -> "options". Tick the "Archived Certificates" button. They will now show up in the personal store again with an "A" in the "Status" column. If you configured supersedence, those certificates will also be flagged as archived.

Q: OK, I'm feeling both nostalgic AND I really want to reactivate my old certificates (for various reasons)
A: No problems, open up a PowerShell prompt and do the following. You should also prevent the template from being re-issued otherwise it will just come back.

 cd Cert:\LocalMachine\My
ls -force
$Cert = Get-Item <ThumbprintOfNewCert>
$Cert.Archived = $True
$Cert = Get-Item <ThumbprintOfOldCert>
$Cert.Archived = $False

Wrapping Up

Not much more to it then that. Your special DCs will now have TLS certificates that have your extra secure LDAP DNS name included and your remaining DCs will have a vanilla Kerberos Authentication certificate with names automatically generated from Active Directory. The critical part of this process is to confirm that the renewal component works as expected. If this section fails, your going to have an outage in 12 months when your certificates expire because they don't renew correctly.

If you have gotten this far, you should also check out my other blog post on CRL-Freshness for ensuring the CRLs that support your Domain Controllers certificates are always fresh and up to date.

As always, leave a comment if you found this useful or something doesn't work as expected

Russ @russelltomkins

Comments

Anonymous
June 04, 2016
nice onethanks
Anonymous
July 14, 2016
Sorry if this is a double post. For the certificate that gets installed on the load balancer appliance, does it need to use the Kerberos Authentication (Offline Request) template or does it just need to use a standard web server template that is used for Server Authentication? Which common names/subject alternate names need to be setup on the certificate on the load balancer? Just ldap.contoso.com or does it need contoso.com, CONTOSO, and every fqdn of the domain controllers being load balanced?
- Anonymous
  July 19, 2016
  Hi JoeIf your load balancer is simply directing the traffic to "healthy nodes", then the it is the DC's that need the specialised certificates and there are no certificates required on the load balancer.If your load balancers are terminating the TLS traffic and re-establishing a secondary connection to the DC, your load balancer should only need a server authentication certificate with "ldap.contoso.com" as this is the name your clients will be looking for when establishing connections. In this configuration, if your load balancer is smart enough (and it should be) you may not need to configure any custom certs on your DCs as they will able to direct traffic to the appropriate IP with a subject name of "contoso.com". All DC's that use kerberos authentication template certificates by default will have that name already present in their subject extensions.HTH - Russ
Anonymous
July 21, 2016
Actually I've answered my owner question and yes it works fine if I fill in the extra info. Great article and a really handy tip to save my skin when certs expire with custom names.
- Anonymous
  July 21, 2016
  Thanks, glad it was useful. The process simply duplicates what would occur during an auto enrollment so as long as the standard values stay there, you can add others if needed.
  - Anonymous
    August 23, 2016
    Once the AutoEnrollment DACL gets added, you say ' balloon pop-up when an admin logs in'. Will the admin need to re-input the custom SANs each renewal or by default will AE know to just re-use the SANs that were set during the ME?Fantastic useful article!Thanks!
    - Anonymous
      August 24, 2016
      Only for the initial enrollment will the balloon pop up because it needs the subject details. The process is exactly the same as a manual one, just the entry point into the process is via the balloon. Happy the article was valuable.
      - Anonymous
        August 25, 2016
        Oh ok so on the server desktop interactively right? I figured the initial ME admin experience would be more like the ME all within the MMC snap-in similar to say an SSL cert. T hanks so much for the reply Russell!
      - Anonymous
        August 30, 2016
        Hi Russell,Hoping you had further thoughts on this matter?Thanks!
Anonymous
October 10, 2017
Hi Rusell, Incase of applications having hostname verification enabled for LDAPS Binding. Do you suggest to have a SAN certificate including all the Domain controllers hostname ? Does it automatically update the SAN entries from enterprise ?
- Anonymous
  October 25, 2017
  Hi Deva, Can you explain your scneario a little more? If the client is connecting to the server name of "ldaps.domain.com", the TLS client will only care about the name in the request, it will have no knowledge of the actual real servers name.
Anonymous
October 23, 2017
Great article, exactly what I was looking for. Very straight forward and easy to follow, worked the first time!Thanks!!Darhl

Freigeben über