# LDAP Authentication

## Get "hand"-delivered posts.

via GIPHY

One of the things I’m constantly frustrated with is the unnecessary complexity of Lightweight Directory Access Provider (LDAP) integration into your applications. Not only with LDAP, but also implementing Okta into your tools can be cumbersome, annoying, and tricky.

For a brief primer on LDAP, which is basically a database that manages users and logins, I recommend this article here, or of course Wikipedia, for something more a little more in-depth. LDAP is an open industry standard developed as a lightweight response to X.500 networking standards, helping organizations to manage user access to multiple things – files, servers, databases – without necessarily knowing where in the hierarchical structure that user is located.

LDAP is mistakenly used interchangeably with Active Directory (AD), even by me. The key difference between the two is that LDAP is a protocol, and AD is an implementation of that protocol. (As usual, there’s a StackOverflow question about this.)

This also should not be confused with SSO services like SAML, which again can (or cannot) leverage the LDAP protocol. Okta or OneLogin are further removed, as SAML/AD implementations.

Lately, we’ve been dealing with all kinds of LDAP integration issues. Part of those problems have been caused by the data center migration. But some have also been caused by changing our root cert on our domain controllers. I have been battling for several weeks with ever changing requirements for one of our applications that integrates LDAP through Apache due to our changing landscape. Plus, the problem is exacerbated by having several different LDAP vips – all which leverage different domain controllers, and have different configurations on them.

LDAP integration through apache is… interesting. I’ve been working with automating our Icinga2 monitoring system for teams that are being onboarded onto pipeline. Our pipeline teams are going to be automating the entire workflow from soup to nuts, and also will receive a separate Icinga2/Thruk instance that pulls data just for servers/applications relevant to them. Today I spent some time trying to understand why LDAP with the exact same configuration worked on one server, and not on another.

In case you were curious, the solution was apparently a 4th restart of apache solved the problem.

via GIPHY

It requires use of the mod_auth, mod_authz, and mod_ldap modules within your standard httpd.conf. There’s also mod_auth_ldap, so I’m sure there’s multiple ways it can be implemented within apache itself. I highly recommend implementing your configuration within a separate conf.d directory for your application. You can put references to your certs in your *.conf file itself, or rely on your ldap installation (we use openldap, so /etc/openldap/ldap.conf) to manage your root CA. If your certs are self-signed, you need to account for that as well, potentially by adding

LDAPVerifyServerCert Off