Windows 2008 R2 AD LDS- Securing with SSL - The Simple,Ugly Truth

Blogging is supposed to be fun, right?  But what if, despite your usual inclinations toward keeping work at work, the tide of events seems to leave you no choice but to be a witness to what would otherwise be obscure geekery?

Let's be real... if you ask a Microsoft Server guy about his favorite thing to work on, and he tells you ADAM / LDS, there's a punchline to follow.  To make it useful requires significantly more grunt work than other Windows roles and features, and if you want it to synchronize with AD DS, hoo boy- bring a comfy cushion for your configuring keister, because you'll be wearing out a keyboard as you test-modify-test-modify.

What if you need to secure an instance of AD LDS using SSL? There are a bunch of links dedicated to the topic- believe you me, I've seen most all of them- but none got me where I needed to go.
It's important to have an overall idea of what needs to occur... that's why this link is good.  But there's a much simpler way to make this batch of sausage...

We're starting with a LDS instance on a domain member server.  It's running on a dedicated service account instead of the default 'NetworkService' account- it's better that way, trust me.

The domain contains an Enterprise issuing CA so there's a ready source for the cert needed for SSL.  This is where our process starts- so off to the 2003 CA box to launch the CA manager.

 Starting at Certificate Templates, right-click to select 'Manage'

For this cert to work once it's in place, its designated purpose is to provide server authentication.  The most basic pre-existing template for this is Web Server.  KEGGER AT MY PLACE TONIGHT!!!!

Ok- so that was crude (and misleading), but do I have your attention?  Here's what I found to be the linchpin for the entire process-  right-click the Web Server template and select 'Properties', and hit the 'Security' tab.  We need to add the LDS server's computer account to the template's access list - so make sure you expand the 'Object Types' in the selection box to include 'Computers'.

Once selected, ensure the computer account has both 'Read' and 'Enroll' permissions to the template or you will not see it when you generate the request back at the LDS server.  Select 'Apply' or 'OK' and we're done at the CA.

 Next step is to head back to the LDS server and generate the cert request.  An item of note is the two schools of thought concerning where the cert needs to be imported.  Most of the LDS over SSL links from MS tell you to import to the personal service account store (in this scenario, KUNG) but that plays out more like a MS test answer than a working solution.  For it to work, you have to import it to the personal computer store. So run MMC, add the 'Certificates' snap-in for the local  'computer account' and get ready to initiate the request:

Right-click 'Personal' - > All Tasks -> 'Request New Certificate...'

Accept the default and click 'Next'

Again, we're selecting Web Server for its simplicity in key usage purpose, as seen in the 'Details' field.  But before we can enroll, the cert has to be personalized for the server's usage- click on either area that is highlighted to edit the 'Subject' fields under 'Properties'.

 Once more, we come to a very important step- ensuring that we provide the canonical FQDN of the LDS server as it would appear in AD.  In this example I typed the following under 'Subject name', 'Full DN':

cn=R2ADAM-LDS,cn=computers,dc=win,dc=mit,dc=ed

And you see how it's displayed after selecting 'Add >'.  To guarantee assignment, I make sure we have an 'Alternate name' defined of type DNS, with the server common name entered just as it is shown after selecting 'Add >'. Now hit 'Apply' and/or 'OK' to close properties and return the the enrollment screen.

Note that 'Enroll' is no longer greyed out- it's time to get 'er done.  Select 'Enroll'.

Select 'Finish' to close it out, then return to the Certificates console.

How's about that for MS magic?  A shiny new computer cert for authentication to our LDS server- signed, sealed, delivered.

How about a test now?

A quick test can be conducted using LDP.exe, but that's all raw and LDAP-ish.  I'm going to use the preferred method for connecting to an LDS instance for management purposes- ADSIEdit.msc.

Our default naming context will be the LDS partition instance itself, and connecting to the LDS server via the default LDAPS port 636.  Select 'Use SSL-based Encryption' and click 'OK'.

<sniff> It's beautiful... <sniffsniff>

Granted, not all scenarios can claim a local issuing CA, particularly if you require public 3rd party certs.  But you won't find a more upfront and simple method to accomplish what can be a very, VERY nasty task on its face.

(major ups to Jay for this)