Skip to main content

LDAP and SAN Certificates

Hey everyone - I ran across an interesting problem with certificates and services. The problem was that I needed to see which certificate is being presented to the client on a non-HTTPS service; specifically - binding to LDAP over SSL (LDAPS). So the question is, how can you be sure what certificate is being presented?

Windows, so far as I've been able to find, does not offer any native help in this regard. Luckily there is a solution, but first let me give you a slightly longer description of the scenario so you can appreciate what we're talking about a little bit better.

An environment exists with some number of Domain Controllers, let's say ten. Within this environment, third party applications (think Java apps, Linux systems, etc) need to bind to LDAP to enumerate groups or validate authentication or whatever. These systems, however, can only have a single (or at best, two) LDAP hosts configured. What do you do? Pick two DCs? Round-Robin DNS?

Well, in my case, a load-balancer had been configured to direct LDAP(S) traffic to the various domain controllers and a DNS record configured for that load balancer.

This works great except that when using a load balancer, a generic name (like must be used since it is unknown which server will be connected to. This is a problem for SSL.

If I connect to and am presented with a certificate whose subject reads "" then my SSL bind will fail. The solution to that is to create certificates with Subject Alternate Names[1] such that the "" name exists in addition to each of the certificates used by each of the Domain Controllers.

Starting with Server 2008, you can bind certificates to specific services (though this was NOT true with Server 2003). So, after binding the SAN cert to AD DS, we want to verify which certificate we're seeing when binding to LDAPS. If you want to actually see the certificate details - here are the steps to view the presented cert:
  1. Install OpenSSL[2]
  2. Open a PowerShell session or Cmd prompt
  3. From the OpenSSL\bin directory, issue the following command:
  4. openssl s_client -connect server:port | openssl x509 -noout -text
(you may have to hit the space bar or enter key for the data to be displayed)

In my case, I wanted to verify that I was seeing the certificate with all the Subject Alternate Names. This proved to be exactly what I needed to see the certificate presented to a binding client. Sadly - I cannot give you screen shots since the data is private and I don't have a lab with all of the certificate infrastructure built. Feel free to comment though, if you need a hand with the commands.

G. Samuel Hays


Popular posts from this blog

Automating IP addresses with TMG

In the past few months I've had the "opportunity" (note the quotes, maybe I'll write a post about all the troubles I've run into) to deal with some Office 365 integration projects.

When integrating one or more cloud services with Office 365 or Office 365 with on-prem Exchange, it is typical to limit the IP addresses that are aloud to communicate between services. This is an important layer on the security model and obviously reduces the attack surface. Microsoft maintains lists of IP addresses for the various services here:

That page links to other pages with more specific information about various other Microsoft cloud services such as the link below for Exchange online. for example.

At the time of this writing, you'll notice that the lists are inconsistent between pages. >:-(

Microsoft on two separate Premier Support Calls has told me…

Windows Last Logon problem and solution

As someone who has been involved in Network Administration (in Microsoft Land) since Windows NT 4.0, I find it surprising that is still so difficult to get simple (yet important) information such as "When was the last time Joe User logged in?".

One would think that, with the fourth edition of Active Directory in production (Windows Server 2008 R2), a tool or set of tools would have been issued with Windows to provide those answers.  Well, because they don't, I've decided to go ahead and write one.  (Yes, I know that there are probably others out there to be downloaded or purchased but... you know, I don't care.)

All that is required: PowerShell 2.0 (and a functioning Active Directory).

Defining the Problem:
Active Directory stores numerous properties on objects in the Directory. Some of these properties are replicated amongst the Domain Controllers and some are not. Unfortunately, for some reason, one of the design decisions was to not replicate the "LastLogo…