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.

Computers in space

If you want a fun, interesting read about the early days of computing, and how the requirements for manned-spaceflight helped push the state-of-the-art, you can find an insightful essay at http://history.nasa.gov/computers/contents.html.

Update on Exchange 2010 and AdminSDHolder

The Microsoft Exchange Team recently blogged on the ACEs being applied by Exchange 2010, that I discussed previously.

“[A]s some have correctly pointed out, that enables an elevation of privilege scenario that is unacceptable in any environment.  Microsoft agrees with this assessment and concurs that Exchange 2010 cannot ship with the permissions assigned to the AdminSDHolder role that allow for Active Directory forest privilege elevation.”

It’s great to see, especially this close to the planned release, that Microsoft realized what a critical controls issue this would have been, and is correcting the problem.

Bravo!