So, let\u2019s see where we are. We have a master server you will be doing all administration work on. This master server replicates to two hosts in the environment that serve LDAP queries to your clients. These servers are replicants and are load-balanced under a VIP that is pointed to by the name you choose. (in our case, ldap.bob.com). You can change passwords at the client level, and have it pushed back up to master and replicated out to the environment immediately.<\/p>\n\n\n\n
Finally, we need to talk about security. There\u2019s a number of ways to do security, but RedHat has done a lot of the footwork for you. Unfortunately, it\u2019s very poorly documented, and they really Really REALLY want you to use RedHat Directory Server for everything, so I don\u2019t guess it\u2019s a priority.<\/p>\n\n\n\n
Essentially, we want to secure all queries floating around the network with TLS. In a RedHat world, you simply need to make a couple changes at the server, restart LDAP, and then connect from TLS-enabled clients and all works just as it did before, except now it runs over an encrypted channel.<\/p>\n\n\n\n
First Steps<\/strong><\/p>\n\n\n\n RedHat has tried to ease the pain of generating certificates by placing all you need in a Makefile on-box. navigate to \/etc\/pki\/tls\/certs <\/strong>and see that there is a makefile there. Next, run:<\/p>\n\n\n\n make slapd.pem<\/strong><\/p>\n\n\n\n to generate the needed files. If it has already been done for you by the system, you will get the answer:<\/p>\n\n\n\n make: `slapd.pem’ is up to date.<\/strong><\/p>\n\n\n\n If you get this message, you\u2019re halfway there.<\/p>\n\n\n\n Next, edit the \/etc\/openldap\/slapd.<\/em>conf<\/strong> file. You will need to refer to the appropriate files to allow for secure operation. Insert the following lines into that file:<\/p>\n\n\n\n # TLS Security <\/strong> Next, edit the file \/etc\/sysconfig\/ldap<\/strong><\/em>. Make the following lines:<\/p>\n\n\n\n SLAPD_LDAP=yes <\/strong> look like:<\/p>\n\n\n\n SLAPD_LDAP=no <\/strong> Then, restart LDAP: \/sbin\/service ldap restart. <\/strong><\/em>This does two things. First, it tells the client where to look for the certificates, and then tells the system to only serve from the secure port 636. (recall that we are on the replicants which are, in turn, servers themselves. We have handled connecting to the master as well as setting the replicant up to receive queries)<\/p>\n\n\n\n Finally, we connect a client.<\/p>\n\n\n\n Connecting the Client<\/strong><\/p>\n\n\n\n To allow a client to connect, you need the appropriate key on the client (public server key) to be able to exchange identities with the server, and establish the secure session. To do this, you have to distribute this key you just made out to each client you wish to connect back to the server.<\/p>\n\n\n\n The key you will be distributing lives in \/etc\/pki\/tls\/certs<\/strong> and is named ca-bundle.crt<\/strong>. Simply move this cert to your client (I use scp<\/strong> for such an operation) and place it into your openldap cacerts directory like so:<\/p>\n\n\n\n scp -rp ca-bundle.crt host.bob.com:\/etc\/openldap\/cacerts<\/strong><\/em><\/p>\n\n\n\n If you don\u2019t have rights to copy straight into the destination, send it to your home directory, then just move the cert there using \u201csudo\u201d.<\/p>\n\n\n\n Finally, you need to tell the system about the cert. This is done in \/etc\/openldap\/ldap.conf <\/strong>via three lines that tell the system how to connect, and where the cert lives:<\/p>\n\n\n\n TLS_CACERTDIR \/etc\/openldap\/cacerts <\/strong> In the left column, select \u201cUse LDAP\u201d and in the right column \u201cUse LDAP Authentication\u201d. Tab down to the \u201cNext\u201d button and press \u201cEnter\u201d.<\/p>\n\n\n\n As misleading as \u201cUse TLS\u201d may be, do not select it. \ud83d\ude42 Instead, go down to your server line, and modify it like so:<\/p>\n\n\n\n ldaps:\/\/ldap.bob.com:636<\/strong><\/p>\n\n\n\n Your base DN should already be filled out (in our case: dc=bob,dc=com). Navigate to the \u201cOK\u201d button, and press \u201cEnter\u201d.<\/p>\n\n\n\n This should conclude your client configuration. Now, you should be able to run a query against LDAP, and the whole path be secure:<\/p>\n\n\n\n id bob uid=123(bob) gid=123(users) groups=123(users),456(bob)<\/strong><\/p>\n\n\n\n Conclusion<\/strong><\/p>\n\n\n\n I\u2019m sure I\u2019ve missed or glossed over something highly important. I am in the process of discovery on this particular topic, and this article is serving as my documentation store until I can get the whole thing cleaned up & finalized to push back into my work environment as official documentation. I\u2019ll correct here as I find mistakes and omissions.<\/p>\n","protected":false},"excerpt":{"rendered":" _This article goes hand in hand with \u201cLDAP Administration – Part I\u201d in regards to configuring the client. _ So, let\u2019s see where we are. We have a master server you will be doing all administration work on. This master server replicates to two hosts in the environment that serve LDAP queries to your clients. […]<\/p>\n","protected":false},"author":1,"featured_media":0,"comment_status":"closed","ping_status":"closed","sticky":false,"template":"","format":"standard","meta":{"advanced_seo_description":"","jetpack_seo_html_title":"","jetpack_seo_noindex":false,"_jetpack_memberships_contains_paid_content":false,"footnotes":"","jetpack_publicize_message":"","jetpack_publicize_feature_enabled":true,"jetpack_social_post_already_shared":false,"jetpack_social_options":{"image_generator_settings":{"template":"highway","enabled":false},"version":2}},"categories":[8,1],"tags":[],"class_list":["post-295","post","type-post","status-publish","format-standard","hentry","category-open-source","category-uncategorized"],"jetpack_publicize_connections":[],"jetpack_featured_media_url":"","jetpack_likes_enabled":true,"jetpack_sharing_enabled":true,"_links":{"self":[{"href":"https:\/\/questy.org\/index.php\/wp-json\/wp\/v2\/posts\/295","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/questy.org\/index.php\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/questy.org\/index.php\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/questy.org\/index.php\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/questy.org\/index.php\/wp-json\/wp\/v2\/comments?post=295"}],"version-history":[{"count":1,"href":"https:\/\/questy.org\/index.php\/wp-json\/wp\/v2\/posts\/295\/revisions"}],"predecessor-version":[{"id":296,"href":"https:\/\/questy.org\/index.php\/wp-json\/wp\/v2\/posts\/295\/revisions\/296"}],"wp:attachment":[{"href":"https:\/\/questy.org\/index.php\/wp-json\/wp\/v2\/media?parent=295"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/questy.org\/index.php\/wp-json\/wp\/v2\/categories?post=295"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/questy.org\/index.php\/wp-json\/wp\/v2\/tags?post=295"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}
TLSCACertificateFile \/etc\/pki\/tls\/certs\/ca-bundle.crt <\/strong>
TLSCertificateFile \/etc\/pki\/tls\/certs\/slapd.pem <\/strong>
TLSCertificateKeyFile \/etc\/pki\/tls\/certs\/slapd.pem<\/strong><\/p>\n\n\n\n
SLAPD_LDAPS=no <\/strong>
SLAPD_LDAPI=no<\/strong><\/p>\n\n\n\n
SLAPD_LDAPS=yes <\/strong>
SLAPD_LDAPI=no<\/strong><\/p>\n\n\n\n
TLS_CACERT \/etc\/openldap\/cacerts\/ca-bundle.crt <\/strong>
TLS_REQCERT allow<\/strong><\/p>\n\n\n\nNext, we run the RedHat authentication gui tool (curses) called authconfig-tui. _**(Note: last time I had you hand-edit the \/etc\/openldap\/ldap.conf file, and this is entirely still possible.\u00a0 I am endeavoring to show you that there is a tool to do this work, should you desire to use it.\u00a0 If not, simply add the above lines and change the URI to the one below, making sure \/etc\/nsswitch.conf is configured correctly, and you should be good to go.)<\/em><\/h5>\n\n\n\n