If you’ve read this far, Your site config isn’t complete and we’re still working inside the <location> directive. My last post ended with the Kerberos configs. Get through this post and there is one to go to test. Two to go to use Apache’s Require directive to tighten things up.
LDAP Module Settings
Start a new file.
This configures default caching and the very important path to the certificate authority (CA) cert. Getting the CA cert out might be possible from the web GUI. I’ll fill this detail in later.
LDAPSharedCacheSize 500000 LDAPCacheEntries 1024 LDAPCacheTTL 600 LDAPOpCacheEntries 1024 LDAPOpCacheTTL 600 LDAPTrustedGlobalCert CA_BASE64 /etc/httpd/certs/ca.crt myPassword?
I’m not 100% sure what’s going on with those default settings until you get to the last one. The last one is Certificate Authority path. You must have this in order to initiate SSL LDAP connections. If your certificate is encrypted with a password, the password goes on the end.
Apache supports two formats for keys, pem and der. CA_BASE64 is “pem” format. FreeIPA exports the PEM format.
Be sure Apache and only Apache can read the file.
Before you continue.
It’s going to be very helpful to be able to tail the 389DS logs in the freeIPA server. Apache’s LDAP and Kerberos auth error logs are cryptic. If you can check the 389DS logs, you can get an idea where the issue lies.
If you don’t have an LDAP browser, you should probably get one. It’s very helpful in being sure your paths are set up right. I like jxplorer. The SSL setup is pretty straightforward, especially if you have previous experience in Java’s encryption norms.
For me, in August 2017, the handy AuthBasicProvider directives did not work as advertised. It is probably me. If you can get it to work, it’s a very handy way to trim and reuse directives.
Here’s the LDAP portion of the subversion site.
# AuthBasicProvider ldap1 ldap2 does not work AuthLDAPBindDN uid=ldapsearcher,cn=users,cn=accounts,dc=mydomain,dc=la AuthLDAPBindPassword Preposterous!! AuthLDAPURL ldaps://idserver.kwiklinux.la/cn=users,cn=accounts,dc=mydomain,dc=la?krbPrincipalName?sub LDAPTrustedClientCert CERT_BASE64 /etc/httpd/certs/apache-host.crt
Notice that I set up a normal user without host login rights that can search. 389DS has some anonymous searching permissions set, but, certainly not enough to do group searches and little logging of the permission denial. There are a couple of different blog posts describing another way to add an unprivileged user to the 389DS config instance on the Internet. But, the config method didn’t work for me in 2017.
Pay careful attention to the construction of the user that connects to the 389DS instance in freeIPA. If you are new to LDAP, this might trip you up. The UID field worked for me.
Here’s the second most important stanza in the LDAP setup. The construction of the stanza with spaces added for clarity is ldaps:// Fully Qualified Host Name / Search Base? / Search field ?sub.
A fully qualified domain name works with SSL. The “search base” is where the client begins the search for the user. The “search field” is the attribute used to find the user name passed into Apache from the login form. The “sub” directive means to search every branch below the search base. The question marks matter.
If you don’t get this stanza set up right, LDAP just won’t work and it won’t be obvious why if you are just checking Apache’s logs. Here is where you need to tail the 389DS logs looking for Apache’s client search activity. The 389DS log is busy. You’ll need good grep-fu to pick the Apache activity out.
The host certificate needs to be stored inside a directory Apache can read. You can get the certificate from the freeIPA website GUI under the host info. Copy/paste and set correct permissions so only Apache can read it.
Advanced Config Wish List
I haven’t worked through the method of using the user logging into the repository Kerberos credentials to do the search. Apparently, this is possible.