We've been getting to grips with Joomla! lately.
Joomla! is a very popular open source content management system (CMS) with some great strengths. However, whilst an enormous amount of effort is being made to include enterprise-class features (like an ACL model that isn't insane), there is an increasing tendency for businesses and other professional organisations to go for Drupal.
The latter is certainly more elegant in its architecture but also has some draw backs. Drupal was conceived as a CMS for community building not for more run-of-the-mill 'brochureware' sites. In order to convert it from one to the other you need to get to grips with its complex templating engine. Our theory is that Drupal's additional complexity presents a significant barrier to entry for web designers as opposed to developers. There are numerous third-party Joomla! template providers whose good works can be built upon to rapidly produce a beautiful site. Drupal takes a little more work.
Perhaps one of the most unpleasant things about the Joomla! project is the increasing commercialisation of some third-party developers around it. If you visit extensions.joomla.org you'll find as many paid-for components these days as those licensed under the GPL. Tread extremely carefully.
Another annoyance is the absence or opaque nature of Joomla!'s documentation. In an attempt to address this the following shows you how to set-up a Joomla! 1.5 site to authenticate with an LDAP server (in our case OpenLDAP). Please note that it is not supposed to be a step-by-step howto for a newbie but to give a moderately competent web developer some clues as to how it all works.
First things first. The PHP LDAP libraries and the Apache mod_ldap modules need to be installed and configured correctly. Failure to do this leads to an unhelpful blank screen on attempting to login. Installing and configuring these packages will differ from distro to distro.
We used only the "Authentication - LDAP" plugin, and not "User Source - LDAP" or "Authentication - Advanced LDAP" available at sammoffatt.com.au. The configuration for the plugin is actually quite simple but if you make a mistake there's very little by way of helpful debugging output.
It helps to have a basic working setup first of all before tweaking it to make it more complex. The following settings worked against a simple, non-SSL OpenLDAP installation with users in the people OU, with a DN keyed by uid, e.g. uid=bloggsj,ou=people,dc=yourdomain,dc=com
LDAP V3: Yes
Negotiate TLS: No
Follow Referrals: No
Authorisation Method: Bind Directly as User
Base DN: ou=people,dc=yourdomain,dc=com
Search String: uid=[search]
User's DN: uid=[username],ou=people,dc=yourdomain,dc=com
Map: Full Name: displayName
Map: E-mail: mail
Map: User ID: uid
The search string and user's DN are critical, of course, and a gotcha to keep an eye on is that search uses [search] as its placeholder for username substitution but User's DN: uses [username].
If you're getting "unknown user id/password" errors, you're probably failing to get the LDAP connection, User DN right (or password, of course).
If you're getting complaints about Email address being invalid, you've got past that and you might have a failing Base DN/Search String combination or you might have invalid or unpopulated attributes specified in the "Map: *" fields.