That title is a mouthful, and there’s probably a better way to say it, but here’s the situation:

1. You have test infrastructure available that you connect to with a weird name; the namespace has nothing to do with the namespace you are building. IaaS is a good example. You might connect to something like ec2-101-114-192-110.ap-southeast-1.compute.amazonaws.com over the Internet.
2. You’ve deployed Active Directory Domain services onto that IaaS host.
3. However you do it, somehow, you have full layer 3 network connectivity to the machine. Hopefully via a private connection, but this should also work if you are opening up all the domain services to the Internet for a quick and awful test.
4. You need a client to connect to the domain with LDAPS (port 636).

Since this is a lab scenario, you can be very lazy in your approach for enabling LDAPS on the new domain controller.

Simply:

1. Install Certificate Services Role on the domain controller.
   1. When configuring the role, accept the defaults but ensure you choose an ‘Enterprise CA’
   2. Root CA
   3. Leave everything else default.
   4. Reboot the domain controller.

The domain controller has automatic enrollment rights for a certificate type that includes ‘server authentication’.

It will pick up the new certificate on reboot and the LDAPS port should be bound to the new certificate like magic.

1. Test by opening ‘ldp.exe’ on the domain controller.
   1. Choose to “connect”
   2. Choose port 636
   3. Tick the SSL box.

If everything works here (it should), the server is ready to serve up LDAPS and is doing so.

The outstanding problems for external clients are:

1. Clients currently connect via ec2-101-114-192-110.ap-southeast-1.compute.amazonaws.com, so the certificate subject name wont match.

2. The crappy default install of the Certificate Authority mentioned above wont put the CRL anywhere that the client can access. Some LDAP clients, including LDP are going to be upset about that.

Fortunately, you can solve the issues pretty fast.

The first one is easy right? Its a lab, for your name resolution woes, just update your hosts file. On Windows this is going to be “C:\Windows\System32\drivers\etc\hosts” and you are just going to include a mapping for the domain name and the IP address of your test server.

The second one is still reasonably straightforward.

All we need to do is make that CRL available. To do this in a lab:

1. Add the Web Server role on the Domain controller with all the defaults.
2. Under c:\inetpub\wwwroot add a new folder called ‘CertEnroll’. (The folder name is important because the certificate is already configured with this path with the default install)
3. Just to make things easy to see,test and poke open IIS manager, navigate to the default web site, CertEnroll, then enable directory browsing. (This is not needed or advised, this is lab laziness)

1. Then. open the Certificate Authority manager.
2. Right click on “Revoked Certificates” and choose to issue a new Certificate Revocation List.
3. Copy your shiny new CRL from C:\Windows\System32\CertSrv\CertEnroll to c:\inetpub\wwwroot\certenroll.
4. Then, open a browser and confirm for yourself that you can access the CRL.
5. Try it from your client outside of the IaaS environment.

If all that works, you should now find that you can access the domain controller via LDAPS.

Before I get rocks thrown at me, i realize this entire post is truly horrible from a security perspective. Domain controllers don’t go on the Internet. CA’s don’t go on domain controllers and web servers don’t go on either on them. I’m completely on board. The aim of this was simply to describe how to make this weird scenario work. I needed to do on an internal network today (The AWS example was used because it illustrates the same issue).