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
