Additional LDAPS Requirements from Vista/W2K8

We have an ADAM instance that is protected by an SSL cert (LDAPS), and load-balanced behind a Cisco hardware device.  As a standard offering, we receive an SSL cert and a DNS alias for our “website”[1].  The DNS entry is similar to the following, with our public-facing name as an alias to the load-balancer:

C:\>nslookup adam.ad.test
Server:  UnKnown
Address:  192.168.2.1

Non-authoritative answer:
Name:    adam.ciscogss.ad.test
Address:  192.168.8.21
Aliases:  adam.ad.test

The SSL cert is also issued with the public-facing name of adam.ad.test.

This configuration functioned perfectly, for a while.  Eventually, we started having a few new application begin migrating to Windows Server 2008[2].  About this same time I also switched over to a Vista-based laptop as part of a pilot program within IT.

Connecting to our ADAM instance from either of these platforms resulted in a failure.  But, connecting from XP or W2K3 continued to work flawlessly.

This was a highly unexpected failure.  I had no problems connecting to any SSL-protected website from Vista or W2K8.  Any of those websites had certs and DNS entries that would be identical to our own setup for ADAM.  If IE on Vista could connect to an https website whose name is an alias, why couldn’t LDP on Vista do the same?

It turns out, Microsoft decided to tighten-up the requirements just for creating LDAPS connections, starting from the Vista codebase.  The problem is the certificate name didn’t match the DNS response.  After getting a new SSL cert for the public-facing name that included the load-balancer name as a Subject Alternative Name (SAN), the connections from Vista and W2K8 started working.

So, if you ever run into the same situation, ADAM (or AD) must be protected with an SSL cert that matches all the names in the DNS resolution path.

[1] Since it was a standard hosting offering, it was a little tricky at first to get our hosting team to understand our requirement for hosting the SSL port on 636, rather than 443.

[2] Yes, my company can be a little slow at moving to new platforms.  We didn’t have anyone try and authenticate against the ADAM instance from Vista or W2K8 until about July 2009.