This is the first in a two-article series on how to enable secure LDAP (Lightweight Directory Access Protocol) communications between client and server applications on Windows Server 2008 and 2012 domain controllers. First, we need to remember that by default, regular LDAP communications between server and client applications are not protected with encryption. Without encryption, it would be possible for an attacker to use networking monitoring or packet sniffing tools to capture packets and examine the data being transmitted between the servers and the LDAP client. In an LDAP bind, the password and username information is passed over the connection in unencrypted packets. Obviously the big concern here is that this could lead to administrative credentials could be stolen. This first article will go over how to enable secure LDAP on Windows Server 2008 and 2012 domain controllers, specifically your options and the prerequisites needed.
Enabling LDAP on Windows-Based Domain Controllers
One of the questions I’ve been asked on various forums is how to enable LDAP over Secure Sockets Layer (SSL) / Transport Layer Security (TLS) (aka LDAPS) on Windows-based Domain Controllers (DCs). I will use this opportunity to describe exactly how.
This first thing you must understand is that LDAPS is primarily used for non-Microsoft clients. LDAPS is best used to protect credentials during a simple LDAP bind. This is when a user name and password could be exposed.
There is no real need or use for LDAPS in any other scenario, but using non-Microsoft clients, and some third-party applications that do not have their own secure method of communicating with DCs, and that do not rely on the built-in Microsoft APIs.
Most Microsoft-based clients don’t need to use LDAPS. For example, MMC snap-ins use sign and seal, which means that they use integrated authentication that is encrypted; for many apps, the LDAP traffic itself is sealed via kerberos or NTLM.
The Active Directory Domain Service administration tools still use port 389, but they are protected by the sign and seal binding.
There is no way to make clients prefer LDAPS because the type of connection depends on the application that is running on the client computer. Nothing would stop you from typing 389 or trying any other port for that matter.
You cannot force all non-Microsoft LDAP clients to use LDAPS, other than blocking access to the domain Controller on TCP port 389. Whatever application you’re using must support LDAPS. While you can block the Domain Controllers from using TCP port 389, you don’t really want to do this on the actual DCs. Blocking port 389 is a typical thing to do on an external firewall, but is not something you would do on a domain controller.
How can I tell if any of my applications need LDAPS? Well that’s quite easy. An AD domain warning event ID 1220 will be registered on a DC when client PCs attempt an LDAPS connection if SSL connections aren’t allowed on that directory. So look this event up on your DCs; if you find any, that’s a clear indication that LDAPS is needed.
Finally, remember that LDAPS uses TCP port 636. Now that we have that covered, let’s move on.
Enabling LDAP on a DC: Options
Basically, there are two methods of enabling LDAPS on a DC.
The first method is the easiest: LDAPS is automatically enabled when you install an Enterprise Root CA on a Domain Controller. If you install the AD-CS role and specify the type of setup as “Enterprise” on a DC, all DCs in the forest will be automatically be configured to accept LDAPS.
However, while in general, having a CA in your organization may be a good thing to do, but overall (because it has many other benefits), I clearly admit that having that CA on a DC is not the best idea. In addition, creating or extending a public key infrastructure (PKI) just for the purpose of enabling LDAPS is kind of like killing a fly with a sledgehammer.
In most cases you should use a certificate from a CA that is not installed on a DC. The second method is to simply add a Digital Certificate on each DC. Without the imported CA certificate, the application cannot detect a man-in-the-middle attack between itself and the LDAP/SSL server(s) (the DCs).
Important: Remember that no matter whate CA you decide to use for obtaining this Digital Certificate, it must be trusted by both your DCs and by the computers running the LDAP client application.
Note: If you are preparing a Windows Server 2008/R2/2012 DC to accept LDAPS connections, you should import the certificate into the AD DS personal store. If you are working on a Windows Server 2003/R2 computer, you should import the certificate into the computer’s personal store. In this article, I will assume you’re using windows Server 2008 R2.
In any case, installing a CA is out of the scope of this article, so please consult with the appropriate Microsoft KBs if you do not yet have a CA accessible in your organization.
Enabling LDAPS on a DC: Prerequisites
Before continuing let’s cover the prerequisites. There are three simple prerequisites for using LDAPS on a DC:
1. Digital Certificate must be valid for the purpose of “Server Authentication.” This means that they must contain the Server Authentication object identifier (OID). OIDs are like the Internet domain name space. They are series of numbers separated by dots, each with a specific meaning. For this purpose, the relevant OID we’re looking for is 220.127.116.11.18.104.22.168.1.
You can trust me on this: Windows CAs have this already set up properly. However, if you want to verify this and if you want to know what OIDs it can handle, perform the following steps:
- Open the Certificate Authority snap-in from Administrative Tools and connect to your CA.
- Right-click Certificate Templates and then click Manage.
- In the Certificate Template Console, click on Action > View Object Identifiers.
- Note the Server Authentication OID: 22.214.171.124.126.96.36.199.1
- Close all opened windows.
2. The Subject name or the first name in the Subject Alternative Name (SAN) must match the Fully Qualified Domain Name (FQDN) of the host machine, such as Subject:CN=server.domain.com.
3. The host machine account needs to have access to the private key. This is done when the digital certificate request is issued from that machine, or when the private key was exported and imported to a different machine.
Here are some other good articles about this subject: