Core Services Engineering and Operations (CSEO) | Digital Security and Risk Engineering (DSRE)

LDAP to LDAPS Migration Scenarios Guide

Purpose
The main objective of the document is to guide users through common scenarios where
insecure LDAP (LDAP over port 389) is used to communicate with Active Directory (AD), how it
could be migrated to secure LDAP (LDAP over SSL or LDAPS), as well as implementing LDAPS
Channel Binding.

Certificate Installation Common Scenarios:

Certificate Verification SQL stored procedure

Channel Binding Tomcat

Printer

Linux with Jenkins

Linux only

MAC Device

Page 1 of 11
 Core Services Engineering and Operations (CSEO) | Digital Security and Risk Engineering (DSRE)

Primer on Lightweight Directory Access Protocol (LDAP)

Lightweight Directory Access Protocol (LDAP) is a client-server protocol for accessing
directory services. The AD domain controllers (DC) are configured to listen on both the LDAP
ports 389 and 636. When LDAP over port 389 is used, the network traffic transmits in cleartext
between the client machine and the DC. Such traffic is susceptible to Man-in-the-Middle
(MITM) attacks and hence the need to migrate this traffic to an encrypted channel using
LDAPS.

In some scenarios, migrating the insecure LDAP traffic to use LDAPS instead is simple, like
updating the port to 636, using LDAPS in the connection string, or perhaps updating an
application configuration.

Instructions for Certificate Installation

As we talk about SSL, there is a requirement to ensure the Microsoft (MS) trusted certificates
are all available in the appropriate certificate stores for LDAPS to function properly. All of the
DCs are already configured with the required certificates for LDAPS.

For any client machines which are domain joined to any of the Corp domains (Africa, Europe,
Fareast, MiddleEast, NorthAmerica, Redmond, SouthAmerica, and SouthPacific), the
certificates are automatically populated in the appropriate certificate stores on the client
machine through a group policy.

If the client machine is not domain joined to any of the Corp domains, the following
certificates may need to be downloaded and imported into the Intermediate Certificate
Authority and Trusted Root Authority certificate stores.

Follow the steps below to download and install the certificates on a Windows device:

1. Click on the links below to download the MS trusted certificates for preparing for
import on the client machine(s).
• Microsoft Internal Corporate Root CA certificate:
http://corppki/aia/msintcrca.crt
• Microsoft Internal Intermediate Certificate Authority Certificates:
http://corppki/aia/MSIT%20CA%20Z1(1).crt
http://corppki/aia/MSIT%20CA%20Z2(1).crt
http://corppki/aia/MSIT%20CA%20Z3(1).crt
http://corppki/aia/MSIT%20CA%20Z4(1).crt

Page 2 of 11
 Core Services Engineering and Operations (CSEO) | Digital Security and Risk Engineering (DSRE)

2. When you click on the above links, a popup will show to save the certificate to a
location on the client machine, like below.

Page 3 of 11
 Core Services Engineering and Operations (CSEO) | Digital Security and Risk Engineering (DSRE)

3. Once the certificate is saved to a location, right-click on the certificate file and select on
Install Certificate on the client machine(s).

4. On the next screen, select “Local Machine” and select “Next”.

5. If you receive a User Account Control prompt, select “Yes”. If not, continue to next step.

Page 4 of 11
 Core Services Engineering and Operations (CSEO) | Digital Security and Risk Engineering (DSRE)

6. On the next screen, leave the default selection “Automatically select the certificate store
based on the type of the certificate” and select “Next”.

7. Select “Finish”.

Page 5 of 11
 Core Services Engineering and Operations (CSEO) | Digital Security and Risk Engineering (DSRE)

The above snapshots for installing the certificates are only valid for Windows client machines.
In some cases, these certificates may need to be imported to an application, printer, network
device, etc., and the steps may be different in such cases. For non-Windows devices, please
refer to guidance from the vendor or manufacturer to enable LDAPS.

Instructions for Certificate Verification

These are the root/intermediate certificates with thumbprints which need to be on the
Trusted/Intermediate stores on the client machines. You may find more than 1 certificate with
the same thumbprint in the certificate store, which is fine

Certificate Subject Name Thumbprint

Microsoft Internal Corporate
Root CA d17697cc206ed26e1a51f5bb96e9356d6d610b74
MSIT CA Z1 d83305599aecdf05aab04b83766f013ed649a1ea
MSIT CA Z2 37ab15eda35664448c00fb30f00a76d87fe9a855
MSIT CA Z3 b08e3ab62e8f020d5005fa32651fe50465af2248
MSIT CA Z4 2f4e6911814ec1bfdaa505686f5623cea47ed693

Please go through the following steps to verify if the Trusted and Intermediate certificates are
in the appropriate stores

1. On a windows desktop, right-click on Windows and click “Run”

• Type certlm.msc and hit enter
• Click on “Yes” on the dialog box
• This will open Certificates snap-in for local computer

Page 6 of 11
 Core Services Engineering and Operations (CSEO) | Digital Security and Risk Engineering (DSRE)

2. Right click on ‘Certificates – Local Computer’ and select Find Certificates

Page 7 of 11
 Core Services Engineering and Operations (CSEO) | Digital Security and Risk Engineering (DSRE)

3. Select “SHA1 Hash” from the “Look in Field” drop-down and copy/paste the thumbprint
of the root certificate and click on “Find Now”. Root certificate needs to be in “Trusted
Root Certification Authorities” store

4. Similarly, copy/paste the thumbprints for all the intermediate certificates from the
above table and click on “Find Now”. This will help verify if the certificates are in
“Intermediate Certification Authorities” store

Note: The above steps are valid for certificates verification on a windows client machine. For
non-windows client machines, the certificates need to be downloaded and configured on the
client machine

Commonly Found LDAP Traffic Scenarios

The following are common scenarios of insecure LDAP traffic (LDAP over port 389), which
could be migrated to use LDAPS (LDAP over SSL) by making very minimal configuration
changes on the client machines.

Scenario 1: A SQL stored procedure using LDAP connection string

In this scenario, a service account is running a stored procedure on a SQL server, which
connects to AD to enumerate group membership using a LDAP connection string. For
example, “LDAP://<domainFQDN>:389” is embedded in the stored procedure.
Page 8 of 11
 Core Services Engineering and Operations (CSEO) | Digital Security and Risk Engineering (DSRE)

To migrate this over to LDAP over SSL, update the LDAP connection string to be LDAPS
instead, which makes the connection string look like “LDAPS://<domainFQDN>” or
LDAP://<domainFQDN>:636.

If the stored procedure is using a connection string such as GC://<domainFQDN>, it

needs to be updated to GC://<domainFQDN>:3269

Once the changes are made, validate the execution of the stored procedure. If there are
any errors identified for missing certificates, please go through the section for
certificate installation and make sure that the intermediate and root certificates are all
available in the appropriate certificate stores and try the execution again.

Scenario 2: An application Tomcat Apache server using LDAP connection string

In this scenario, an application server which is running Tomcat is configured to use

LDAP connection string for checking whether a user account is valid or not. For
example, the connection string may look like “LDAP://<domainFQDN>:389”

To migrate this over to LDAPS, update the connection string look like
“LDAPS://<domainFQDN>:636”.

Make sure that the intermediate and root certificate authority certificates are
downloaded by going through section for certificate installation and place them in the
Java key store on the client machines. For additional information on importing
certificates to a Java key store, refer to this article.

Scenario 3: A printer is using a LDAP connection string

In this scenario, a printer is configured with LDAP to authenticate a user by connecting

to AD using a LDAP connection string “LDAP://<domainFQDN>:389”.

To use LDAPS instead, update the printer configuration to LDAPS.

Make sure that the intermediate and root certificate authority certificates are
downloaded by going through section for certificate installation and configure them on
the printer.

Page 9 of 11
 Core Services Engineering and Operations (CSEO) | Digital Security and Risk Engineering (DSRE)

Scenario 4: A Linux machine (Jenkins) configured with LDAP

In this scenario, a Linux machine running Ubuntu 18.04.2 is configured with LDAP to
authenticate a user by connecting to AD

To use LDAPS instead, please go through the following steps

• Install the certificates in to the cacerts (TrustStore)

• Run Jenkins with proper startup parameters (Java arguments). This would be
specific to Jenkins Ubuntu 18.04.2 version.
• Setup AD plugin in Jenkins in secure mode

Some useful references, which might help.

The link below describes how to preform those steps. Please follow steps 3,4,5
described in the link below.

https://support.cloudbees.com/hc/en-us/articles/235472808-Active-Directory-AD-
Plugin-secure-AD-integration

How to install the certificates to the Jenkins TrustStore:

https://support.cloudbees.com/hc/en-us/articles/203821254-How-to-install-a-new-SSL-
certificate

How to add Java arguments to Jenkins:

https://support.cloudbees.com/hc/en-us/articles/209715698-How-to-add-Java-
arguments-to-JenkinsonAndCustomization

Note: While the above scenario lists the steps for Ubuntu 18.04.2, the same steps might
work for other versions of Linux as well.

Scenario 5: A Linux machine configured with LDAP

The general steps, after installing openldap-clients(latest) and cyrus-sasl-gssapi(latest),

would be joining the system to the domain to get a system keytab(/etc/krb5.keytab).

To use LDAPS, you need to change the port and the flags to ldapsearch, as well as
putting this in the client ldap config file:

TLS_CACERT /etc/openldap/cacerts/msitcacert.cer

Page 10 of 11
 Core Services Engineering and Operations (CSEO) | Digital Security and Risk Engineering (DSRE)

SASL_SECPROPS minssf=0,maxssf=0

And the ldap url should be configured to use LDAPS as below

ldaps://<domainFQDN>:636

Note: You may need to import “Microsoft Internal Corporate Root CA certificate” -
http://corppki/aia/msintcrca.crt in your Windows system and then export it as base64

Scenario 6: Configure a MAC device to use LDAPS

Please follow the steps below on a MAC device to configure LDAPS:

1. Open Terminal and run the following command:

dsconfigad -packetencrypt ssl

2. When prompted, enter the password for the logged in account to save the
configuration.
3. Verify if the certificate “Microsoft Internal Corporate Root” is under System in Key
Chain. If the certificate is not available under System in Key Chain, please use this
link to download the certificate and drag/drop it under System and trust the
certificate.
4. To trust the certificate, double-click the certificate, Expand Trust and then select
“Always Trust” for “When using this certificate”

LDAP Channel Binding

LDAP Channel Binding adds an additional layer of security for all LDAP/SSL traffic by binding
the secure channel at the network layer to authentication at the higher layer. More
information on LDAP Channel Binding can be found at this article.

LDAPEnforceChannelBinding is a registry setting on the DCs, and it is set to “Enabled”. This

will enable the DCs to support any clients which provide Channel Binding Token information.

In the above support article, there is guidance for Windows client machines to install a specific
KB to provide ChannelBindingToken (CBT) information to the domain controllers. For non-
Windows clients, please refer to guidance from the vendor or manufacturer to enable LDAP
Channel Binding.

Page 11 of 11