FreeIPA, Kerberos, LDAP, Subversion Stack Part 3: LDAP Setup

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.

nano /etc/httpd/conf.d/ldap.conf.

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.

AuthLDAPURL

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.

LDAPTrustedClientCert

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.

 

FreeIPA Replication and the Invalid Credentials

I had replication go down between two freeIPA hosts with the following message in the logs.

Error (49) Problem connecting to replica - LDAP error: Invalid credentials (connection error)

If you are used to a world of passwords and keys, then the assumption is something is wrong with “the password.”

Since this is Kerberos authentication, time matters.  If the clocks between the two hosts aren’t very closely synced, then replication fails.

The short answer is:

stop service ntpd.

ntpdate pool.us.ntpd.org

start service ntpd.

The long answer is:

Your NTPD configuration isn’t working.  It seems like the freeIPA installer does not check for a good ntpd setup.   I’ll have another post on a functional /etc/ntp.conf soon as I get the config details confirmed.