Openldap migrate to TLS/SSL communication

Q. My ldap server currently configured to accept only non-encrypted connections. The server listens to port 389. I want to make my server to accept only TLS/SSL encrypted connections. How to migrate to TLS/SSL communication with very minimal downtime window? Most important is current LDAP directory data should not be disturbed.

Benefits

By upgrading to TLS/SSL encrypted communication we ensure data transferred between LDAP client and server will be encrypted. This is most important when the data travel through untrusted or public network. The normal LDAP communication over TLS/SSL channel specified as “ldaps” (same like https) in URI.

LDAP – Connect to server through non-encrypted channel via 389 port

LDAPS – LDAP connection over TLS/SSL encryption channel via port 636

Step1 – Generate self-signed SSL certificate

The SSL/TLS protocol uses signed certificates to authorize client and server. We can get the signed certificate from CA such as Verizon, Entrust, etc. But it involves charges. The alternate is self-signed certificate. Here we use self-signed certificates for client and server authorization.

Use this command to generate self-signed public certificate and private key. The public certificate must be copied to every client. The private key should be placed only in server. It should not be world readable.

#openssl req -x509 -nodes -days 3650 -newkey rsa:2048 -keyout /etc/openldap/cacerts/serverkey.pem -out /etc/openldap/cacerts/servercert.pem
#chown -R ldap:ldap /etc/openldap/cacerts
#chmod 600 /etc/openldap/cacerts/serverkey.pem

Step2 – Add SSL certificate to Openldap

Enforce Openldap to use the certificate and privatekey generated from step1. This can be configured online through LDIF files. Create the LDIF file with content as below and update using ldapmodify command.

#cat ssl.ldif
dn: cn=config
add: olctlscertificatefile
olctlscertificatefile: /etc/openldap/cacerts/ldapscert.pem
-
add: olctlscertificatekeyfile
olctlscertificatekeyfile: /etc/openldap/cacerts/keys/ldapskey.pem
# ldapmodify -xw $CROOTPW –D $CROOTDN -f ssl.ldif

Note: Replace CROOTPW and CROOTDN with config database ROOTPW and ROOTDN respectively.

Note: Till this stage there will not be interruption to client connections.

Step3 – Start accepting TLS/SSL connection

Configure slapd daemon to start listening both 389 (ldap) and 636 (ldaps). Edit /etc/sysconfig/ldap and update like shown.

#vi /etc/sysconfig/ldap
SLAPD_LDAP=yes
SLAPD_LDAPI=yes
SLAPD_LDAPS=yes

#service slapd restart

#netstat –alnp |grep slapd
tcp        0      0 0.0.0.0:636                 0.0.0.0:*                   LISTEN      7122/slapd     
tcp        0      0 0.0.0.0:389                 0.0.0.0:*                   LISTEN      7122/slapd     
unix  2      [ ACC ]     STREAM     LISTENING     50718  7122/slapd          /var/run/ldapi

During slapd restart, existing ldap client connection will be dropped.

Note: Server now listen on both ldap and ldaps port. The existing clients can continue to connect server through non-encrypted communication (port 389).

Step4 – LDAP Client side configuration

Copy the certificate from server to /etc/openldap/cacerts or preferred location. Update the ldap.conf as shown below. This enforce LDAP client to use this certificate for SSL/TLS communication.

#scp root@rhel4:/etc/openldap/cacerts/ldapcert.pem /etc/openldap/cacerts/
#chmod 600 /etc/openldap/cacerts/ldapcert.pem
#echo “TLS_CACERT /etc/openldap/cacerts/ldapscert.pem” >> /etc/openldap/ldap.conf

At last /etc/openldap/ldap.conf file will look like this.

TLS_CACERTDIR /etc/openldap/cacerts
URI ldaps://rhel4.sunt.com/  ldaps://rhel6.sunt.com
BASE dc=sunt,dc=com
TLS_CACERT /etc/openldap/cacerts/ldapscert.pem

configure client using authconfig command.

#authconfig --enableshadow --enableldap --enableldapauth --enableshadow --enablecache --disablekrb5 --enableforcelegacy --ldapbasedn "dc=sunt,dc=com" --ldapserver "ldaps://rhel4.sunt.com/, ldaps://rhel6.sunt.com" --enableldaptls  --update

Note: From here we insisting client machine to use ldaps URI. Ensure firewall configured to allow port 636 between clients and server.

This how to document provides in-depth details about configuring RHEL 6 server as LDAP client.

Step5 – Testing

Validate the client server connection using “ldapsearch” command.

#ldapsearch -w $ROOTPW -D cn=manager,dc=sunt,dc=com -H ldaps://rhel4.sunt.com -LLL “(ou=people)” dn

Note: URI ldaps is used.

Now the client is able to communicate with server through secure SSL/TLS channel. The same way unencrypted channel also should work. It can be verified using this command.

#ldapsearch -w $ROOTPW -D cn=manager,dc=sunt,dc=com -H ldap://rhel4.sunt.com -LLL “(ou=people)” dn

Note: URI ldap is used instead of “ldaps”.

If you face trouble in establishing TLS/SSL communication, it should be fixed before proceeding with next step. Does TLS negotiation failure error reported at server end? This article helps you then.

Step6 – Migrate all clients

Repeat the step 4 and 5 on all existing clients. So that every client started using secure channel to communicate with LDAP server. Once this is achieved proceed with next stage.

Step7 – Completely migrate to TLS/SSL connection

Now we are good to stop supporting unencrypted channel from server. In other words stop listening to ldap (389) port. Edit /etc/sysconfig/ldap and do below changes.

#vi /etc/sysconfig/ldap
SLAPD_LDAP=no
SLAPD_LDAPI=no
SLAPD_LDAPS=yes

#service slapd restart

#netstat –alnp |grep slapd

tcp        0      0 0.0.0.0:636                 0.0.0.0:*                   LISTEN      7437/slapd

Note: During service restart existing user connection may get dropped.

Now the server only accepts connection via secure URI ldaps. This is ldap over SSL/TLS. And it listens to port 636 alone.

Earlier the data transfer between client and server happened in plain text mode. With very minimal downtime (less than 2 mins) the client and server communication upgraded to TLS/SSL encrypted channel. Users will be able to access LDAP server as usual with their existing settings. This solution has been tested in Redhar 6.

Does this post help you ? Yes/No.

Leave a Reply

Your email address will not be published. Required fields are marked *