After having a server running fine for a while (about a year) a simply upgrade of ldap, and apache brought one of my “cheap hack” pages to a halt. That “cheap hack” page was developed to save account managers having to rummage their way through the company configuration screens of our app. I basically have a php app that talks directly to the DB, and allows them to update the account manage information quickly for a bunch of stores. This was protected by a login prompt that was generated by mod_auth_ldap. This hits our domain controllers, and makes management very nice. Here is the catch. We recently added a new domain controller, and I also upgraded apache and openldap on this particular server (security updates). All of a sudden, things came to a halt, the logs hinted at the issue…
auth_ldap authenticate: user *user* authentication failed; \
URI */somepage.php* [ldap_search_ext_s() for user failed][Operations error]
Mildly baffled, I jumped on google, suspecting that the upgrade for OpenLDAP had broken something, or mod_auth_ldap (packaged with Apache2) had altered their syntax. I stumbled across a post or two that hinted at group names, but I wasn’t specifying any. I then finally stumbled across this. Now I am a complete airhead sometimes, and forgot that only a week before I did all these upgrades, I started re-arranging the domain into organizational units for improved security. It appears Apache’s mod_auth_ldap module gets itself in a tizzy when the results from the search are in OUs. A suggestion was to hit the global catalog instead. This was just a case of changing the port number from 389, to 3268. Another quick test, and it appears to all be working rather nicely again.