First the good news: Microsoft planned to release a patch in January 2020 to disable insecure LDAP channel binding and LDAP signing to more secure configurations. As a result of businesses asking for more time due to the holiday season, Microsoft pushed this off to March 2020.
Now the bad news: You may be already passing the credentials for the domain admin account in cleartext in your network.
The Light Weight Directory Access Protocol (LDAP) is used to read from and write to Active Directory, in the Microsoft Server environment.
By default, LDAP traffic is transmitted unsecured. Due to this network-monitoring software is able to view the LDAP traffic between clients and the Domain Controllers (DC). So, user name and password data are sent and received in a clear text and they can be easily stolen. This security problem also applies to the LDAP subprotocols, such as LDAP bind, that applications, services, or users use to transport credentials and authenticate against a Windows DC.
Organizational security policies typically require that all client/server communication is encrypted. In addition, applications that integrate with AD might require encrypted LDAP communication.
To make LDAP traffic secure, one can use the SSL/TLS protocols; this combination is referred to as LDAP over SSL — or LDAPS. SSL/TLS establishes an encrypted tunnel between an LDAP client and a Windows DC to ensure that no one else can read the traffic.
You can enable LDAP over SSL (LDAPS) by installing a properly formatted certificate from either a Microsoft Certification Authority (CA) or a Private CA.
There’s no user interface for configuring LDAPS. Installing a valid certificate on a domain controller permits the LDAP service to listen for, and automatically accept, SSL connections for both LDAP and global catalog traffic.
Are you already passing the admin and user credentials in cleartext?
Start by looking for event ID 2886 and 2887 in your directory service log. If event ID 2886 is present, it indicates that LDAP signing is not being enforced by your domain controller. What’s so bad about this? Plenty. It means that it’s possible to perform a cleartext LDAP bind over a non-encrypted connection.
If you see event 2886, you need to take immediate action to remedy the situation. Review your Group Policy or registry settings on your domain controllers. If you’ve never configured the option “Domain controller: LDAP server signing requirements” and still have them set as none, chances are this LDAP configuration is opening you up to risky configurations.
Review your group policy setting located at GPO_name\Computer Configuration\Windows Settings\Security Settings\Local Policies\Security Options.
Especially if you are running a domain based on older servers and participating in the extended support patch process and will obtain Server 2008 R2 patches, review this Group Policy setting and change it to “Require signing”.
Requirements for an LDAPS certificate
To enable LDAPS, you must install a certificate that meets the following requirements:
- The LDAPS certificate is located in the Local Computer’s Personal certificate store (programmatically known as the computer’s MY certificate store).
- A private key that matches the certificate is present in the Local Computer’s store and is correctly associated with the certificate. The private key must not have strong private key protection enabled.
- The Enhanced Key Usage extension includes the Server Authentication (1.3.6.1.5.5.7.3.1) object identifier (also known as OID).
- The Active Directory fully qualified domain name of the domain controller (for example, dc01.contoso.com) must appear in one of the following places:
-
- The Common Name (CN) in the Subject field
- DNS entry in the Subject Alternative Name extension.
- The certificate was issued by a CA that the domain controller and the LDAPS clients trust. Trust is established by configuring the clients and the server to trust the root CA to which the issuing CA chains.
- Use the Schannel cryptographic service provider (CSP) to generate the key.
Create the certificate request
(applies to Windows Server 2012 R2)
Any utility or application that creates a valid PKCS #10 request can be used to form the SSL certificate request. Use Certreq to form the request.
Certreq.exe requires a text instruction file to generate an appropriate X.509 certificate request for a domain controller. You can create this file by using your preferred ASCII text editor. Save the file as a .inf file to any folder on your hard drive.
To request a Server Authentication certificate that is suitable for LDAPS, follow these steps:
1. Create the .inf file. Following is an example .inf file that can be used to create the certificate request.
;—————– request.inf —————–
[Version]
Signature=”$Windows NT$
[NewRequest]
Subject = “CN=<DC fqdn>” ; replace with the FQDN of the DC
KeySpec = 1
KeyLength = 1024
; Can be 1024, 2048, 4096, 8192, or 16384.
; Larger key sizes are more secure, but have
; a greater impact on performance.
Exportable = TRUE
MachineKeySet = TRUE
SMIME = False
PrivateKeyArchive = FALSE
UserProtected = FALSE
UseExistingKeySet = FALSE
ProviderName = “Microsoft RSA SChannel Cryptographic Provider”
ProviderType = 12
RequestType = PKCS10
KeyUsage = 0xa0[EnhancedKeyUsageExtension]
OID=1.3.6.1.5.5.7.3.1 ; this is for Server Authentication
;———————————————–
Cut and paste the sample file into a new text file named Request.inf. Provide the fully qualified DNS name of the domain controller in the request.
Some third-party certification authorities like SecureNT may require additional information in the Subject parameter. Such information includes an e-mail address (E), organizational unit (OU), organization (O), locality, or city (L), state or province (S), and country or region (C). You can append this information to the Subject name (CN) in the Request.inf file. For example:
Subject=”E=admin@contoso.com, CN=<DC fqdn>, OU=Servers, O=Contoso, L=Redmond, S=Washington, C=US.”
2. Create the request file by running the following command at the command prompt:
Console
certreq -new request.inf request.req
A new file called Request.req is created. It’s the base64-encoded request file.
3. Submit the request to a CA. You can submit the request to a Microsoft CA or to a third-party CA like SeccureNT.
4. Retrieve the certificate that’s issued, and then save the certificate as Certnew.cer in the same folder as the request file by following these steps:
a. Create a new file called Certnew.cer.
b. Open the file in Notepad, paste the encoded certificate into the file, and then save the file.
Note
The saved certificate must be encoded as base64 (PEM format). Some third-party CAs return the issued certificate to the requestor as base64-encoded text in an e-mail message.
5. Accept the issued certificate by running the following command at the command prompt:
Console
certreq -accept certnew.cer
6. Verify that the certificate is installed in the computer’s Personal store by following these steps:
a. Start Microsoft Management Console (MMC).
b. Add the Certificates snap-in that manages certificates on the local computer.
c. Expand Certificates (Local Computer), expand Personal, and then expand Certificates. A new certificate should exist in the Personal store. In the Certificate Properties dialog box, the intended purpose displayed is Server Authentication. This certificate is issued to the computer’s fully qualified host name.
7. Restart the domain controller.
Note: As for any SSL certificate, the LDAPS certificate must have been issued by a Certification Authority (CA) that the DC and the LDAPS clients trust. Trust is established by configuring the clients and the server to trust the issuing CA’s certificate (in a one-tier CA setup) or the certificate of the root CA to which the issuing CA of the LDAPS certificate chains (in a multi-tier CA setup).
In the case of SecureNT Intranet SSL, you will have to import the root certificate chain using the Import option. Details are given below.
You can find a list of all trusted CA certificates in the Trusted Root Certification Authorities container of a machine’s certificate store. This store contains the certificates of CAs that you or your domain administrator consider trustworthy and that Windows can use as a trust anchor for validating other certificates. The CA certificates of CAs installed on machines that are part of your AD infrastructure are automatically added to client machines’ certificate stores through the Group Policy Object (GPO) update mechanism. If the CA certificate of the CA that issued the LDAPS certificate isn’t present in the Trusted Root CA Certification Authorities container, you can manually import it using the Import option that’s available from this container’s context menu.
Verify an LDAPS connection
After a certificate is installed, follow these steps to verify that LDAPS is enabled:
- Start the Active Directory Administration Tool (Ldp.exe).
- On the Connection menu, click Connect.
- Type the name of the domain controller to which you want to connect.
- Type 636 as the port number.
- Click OK.
RootDSE information should print in the right pane, indicating a successful connection.
For Possible issues and Improvements see the article mentioned at 1 below. For Troubleshooting Problems read the article mentioned at 4 below.
Source:
1. Enable Lightweight Directory Access Protocol (LDAP) over Secure Sockets Layer (SSL) – Windows Server
2. How to fix insecure LDAP binds to prevent exposed Windows admin credentials | CSO Online
3. How-To: Use LDAP Over SSL to Lock Down AD Traffic (itprotoday.com)
4. Troubleshoot LDAP over SSL connection problems – Windows Server