Linux by Trial and Error

A repository of the things I learn about Linux

LDAP Directory Server on CentOS 6.3 Using TLS

This is essentially a continuation of my last post because I needed to set up a CA to sign certs in order to configure my Directory Server to use TLS. As before, I’m using a CentOS 6.3 VM which was built using the minimal installation .iso and all responses to prompts are exactly as I used them on my system in order to keep an exact record of how I built this server.

If  you do not currently have a CA to sign certificate requests and are willing to use your own self-created, self-signed CA, follow the steps of my last post and you’ll be right as rain. In fact, as I’m writing, I’m bouncing back and forth between writing this one and the last one because I haven’t generated the certificate request that I documented in the other post yet.

And now, onto my continuation of my LDAP server installation & configuration.

  1. The first thing you’ll need is to set up the EPEL repository so that you can get the full Directory Service package and to do that, you’ll need a way to download the rpm.
    # yum install wget
  2. Now, download the epel repository installation rpm from one of the Fedora mirrors
    # wget
  3. Install the EPEL rpm package
    # rpm -ivh epel-release-6-8.noarch.rpm
  4. Use yum to install the 389-ds package
    # yum install 389-ds
  5. If you are not on a network with a DNS server which has your servers hostname/IP address, you’ll need an entry in your /etc/hosts file. I added the following entry into my /etc/hosts:       ds1
  6. Run the setup program
    Continue: yes
    Continue: yes
    Setup Type: 2
    Computer Name:
    Proceed with host name: yes
    System user: nobody
    System group: nobody
    Register with existing Dir Server: no
    DirSrv Admin: admin
    DirSrv password: DirServerPwd
    Confirm password: DirServerPwd
    Admin Domain:
    Dir Srv Port: 389
    Dir Srv ID: ds1
    Suffix: dc=example,dc=com
    Dir Manager DN: cn=Directory Manager
    Dir Manager Password: DirMgrPwd
    Confirm Password: DirMgrPwd
    Admin port: 9830
    Set up servers: yes
  7. For the next steps, you’ll need X-Windows access. This is probably overkill, but just to get things up and running, I ran:
    # yum install xorg-x11-xerver-Xorg xorg-x11-xauth xorg-x11-fonts*
  8. Next, since you’ve only got the root user, you’ll need to modify /etc/ssh/sshd_config using vi (or other editor of choice)
    PermitRootLogin Yes
  9. Connect to  your new server with ssh:
    # ssh root@
  10. Start the Directory Server Console
    # 389-console &
  11. When prompted to sign into the console, enter the login information:
    User ID: cn=Directory Manager
    Password: DirMgrPwd
    Admin URL: http://localhost:9830
  12. Expand the entry for
  13. Expand the entry for Server Group
  14. Double-click on Directory Server (ds1)
  15. Select Manage Certificates
  16. When prompted, set up a new password for the private key:
    New Password: DirSrvKeyPwd
    New Password (again): DirSrvKeyPwd
  17. Change to the CA Certs tab
  18. From your shell, get the text for  your CA cert:
    # cat /etc/pki/CA/certs/ca-cert.crt
  19. Copy the contents of the ca-cert.crt to your clipboard
  20. From your Manage Certificates, CA tab, select Install…
  21. Select Paste from Clipboard and then select Next
  22. At the Certificate Information screen, select Next
  23. At the Certificate Type screen, select Next
  24. At the Intended Purpose screen, select Done
  25. Back on the Server Certs tab, select Request…
  26. At the Introduction screen, select Next
  27. Enter Requestor Information and select Next
    Server name: ds1
    Organization: Example
    Organizational Unit: Example
    City: Topeka
    State: Kansas
    Country: US United States
  28. Enter the private key password from Step 16 above and select Next:
  29. At the Request Submission screen, select Save to file
    File Name: ds1.csr
  30. Select Done
  31. Now, you can follow the steps from the post on setting up your CA. The latter part of that post details how to use this certificate request that we just generated to create a new, signed cert for our Directory Server.
  32. Get the contents of your signed cert
    # cat ds1.pem
  33. From your Manage Certificates screen, on the Server Certs tab, select Install…
  34. From the Certificate Location screen, select Paste from Clipboard and then select Next
  35. From the Certificate Information screen, verify that the information is correct and select Next
  36. From the Certificate Type screen, select Next
  37. From the Token Password screen, enter your private key password and select Done
  38. From the Manage Certificates screen, select Close
  39. Now, close the Directory Server window and go back to the Console
  40. Double-click the Administration Server
  41. From the Admin Server, select Manage Certificates
  42. Create a new password for the admin server:
    New Password: DirAdminSrvPwd
    New Password (again): DirAdminSrvPwd
  43. From the CA Certs tab, select Install…
  44. From a shell, get the contents of the CA cert and copy the contents to the clipboard
  45. From the Certificate Location screen, select Past from Clipboard and select Next
  46. From the Certificate Information screen, verify the information and select Next
  47. From the Certificate Type screen, select Next
  48. From the Intended Purpose screen, select Done
  49. Back on the Server Certs tab, select Request…
  50. From the Introduction screen, select Next
  51. From the Requestor Information screen, fill out the information and select Next
    Server Name: ds1-admin
    Organization: Example
    Organizational Unit: Example
    City: Topeka
    State: Kansas
    Country: US United States
  52. Enter the private key password and select Next
  53. At the Request Submission screen, select Save to File and then select Done
    File Name: ds1-admin.csr
  54. Once again, refer to the steps to sign your certificate request
  55. Repeat Steps 33-39, remembering to use the correct password in Step 37
  56. Create a new text file /etc/dirsrv/slapd-ds1/pin.txt with the following contents:
    Internal (Software) Token:DirSrvKeyPwd
  57. From the Console, double-click to open the Directory Server
  58. From the Directory Server, on the Configuration tab, select the Encryption tab to the right
  59. From the Encryption tab, check the “Enable SSL for this server” checkbox
  60. Next, check the “Use this cipher family: RSA” checkbox, leave the rest of the fields at their defaults and select Save.
  61. From the Directory Server, back on the Tasks tab, select Restart Directory Server
  62. From the Configuration tab, select Data and check the “Enable fine-grained password policy” and any other options you wish to ensure that people use good, solid, secure passwords.
  63. Lastly, we want to make sure our Directory Server is set to start when the system is started:
    # chkconfig dirsrv on
    # chkconfig dirsrv-admin on

At this point, you have now installed and configured Directory Server and set it up to use TLS in order to encrypt your logins. Now, this does not mean it is finished, however. Rather than make this post several thousand words long, we are going to leave this as it is today and I will do a separate post later regarding how to make creating users so that you can actually use your new Directory Server.


June 22, 2013 Posted by | authentication, ldap | , , | 2 Comments

It’s the Little Things

So, I recently deployed the latest errata via our Red Hat Satellite server to a handful of RHEL boxes. The updates included a minor OS revision, so we went from RHEL 5.7 to RHEL 5.8. This was my first deployment of errata onto production servers, so I was a bit nervous.

Because of the kernel update, a reboot was required. So, I scheduled the errata to deploy at 7:00pm in order to give the time to install before I started bouncing servers at 9:00pm. Before I got to 9:00, however, I started getting alert e-mails from system monitors about systems not responding.

Most of the restarts went fine. However, several of them were in our DMZ, so instead of authenticating to our Active Directory server, we have a directory server in the DMZ.

Five of the servers being restarted were in the DMZ, including DNS and Directory Servers. After the application of the errata, I found that I could not log in using LDAP user accounts. Good thing they were VMs and I had access to the console so I could log in as root!

After fighting with this for about 2 1/2 hours in the middle of the night, I decided that since the mission critical applications running in the DMZ did not seem to be adversely affected, I’d get some rest and tackle this first thing in the morning.

Another couple hours of sifting through logs and working with one of my senior server admins (who actually knows how to use tools like strace and such), we found that LDAP was throwing an error regarding “Unauthorized connections” to the directory server. That led us to take a look at the /etc/ldap.secret file.

One thing we have noticed about RHEL is that a lot of files, for some reason, require a blank line at the end of the file in order to be recognized. Our /etc/ldap.secret file did not have a carriage-return at the end of the first line…so there was one and only one line in the file and the EOF was at the end of the first line.

# vi /etc/ldap.secret
<ldap password>


# vi /etc/ldap.secret
<ldap password>


[Note the lack of the ‘~’ character on the second line.]


# getent passwd johndoe

In less than 15 seconds, we fixed a problem that I had spent several hours working on.

Don’t you hate when that happens?

March 29, 2012 Posted by | ldap | , , | 2 Comments