Monday, December 27, 2010

LDAP web administration with phpLDAPadmin

As part of my OpenLDAP under Ubuntu Linux project, I wanted to find a good web administration tool for the directory. The best option I found was phpLDAPadmin (Wikipedia), a.k.a. PLA.

I meant to complete several other LDAP-related posts since I started this project in April, but other priorities took precedence. However, a side benefit is that my previous configurations have now been successfully repeated and tested under Ubuntu Linux's latest release, 10.10 ("Maverick Meerkat").

Apache Configuration

As phpLDAPadmin is a web application, it depends on a web server that can serve PHPs. My choice is the Apache HTTPD Server (Wikipedia) version 2.2, which will simply be referred to as "Apache" for the remainder of this post.

phpLDAPadmin is available in the Ubuntu package repositories. However, the default configuration (as packaged for Ubuntu) could use some improvement, so I'd recommend against installing it from the repository. I already have an Apache instance running for some other uses, which uses Apache's default worker MPM. However, Ubuntu's packaged version depends on libapache2-mod-php5, which depends on apache2-mpm-prefork, which reconfigures Apache to use the prefork MPM. The differences between these Multi-Processing Modules is documented by Apache in Apache Performance Tuning, and a few other references that I stumbled upon:

Now granted, my uses of Apache and/or LDAP aren't currently anywhere near demanding enough for a significant difference in performance between the MPMs. However, this is a good exercise, and I can be confident that this setup will be able to scale with fewer issues in the future.

My existing Apache installation consisted of the "apache2" Ubuntu (meta)package. To support PLA, the "php5-cgi" and "php5-ldap" packages also need to be installed. (Do not install the base "php5" package, as this also has the same dependencies listed above, and will reconfigure Apache to use the prefork MPM.)

The primary reason for libapache2-mod-php5 depending on the prefork MPM is due to thread-safety issues. As such, a suitable way is necessary to run PHP under Apache in a thread-safe fashion. Standard CGI would be one option, but is terribly inefficient. FastCGI is an option that provides for isolation between PHP (and/or other modules and languages) and Apache, while avoiding the inefficiencies of CGI. Support for FastCGI in Apache was originally available through mod_fastcgi, but is discouraged due to various stability and license compatibility issues. mod_fcgid is the preferred alternative, provides binary compatibility, is reportedly faster, and is available as the libapache2-mod-fcgid package in Ubuntu.

To summarize the above paragraph, also install libapache2-mod-fcgid. The module should be automatically enabled. If not, use "sudo a2enmod fcgid", or manually create the symbolic links in "/etc/apache2/mods-enabled". (a2enmod is a Debian-specific script shared with Ubuntu.)

Download the latest "phpldapadmin-php5" package from http://sourceforge.net/projects/phpldapadmin/files/phpldapadmin-php5/. As of this post, I am using version 1.2.0.5. I extracted the download into "/var/www/phpldapadmin" (the default DocumentRoot). Then add a <Location> directive into the Apache configuration, utilizing fcgid:

  <Location "/phpldapadmin">
    Options +ExecCGI
    AddHandler fcgid-script .php
    FCGIWrapper /usr/lib/cgi-bin/php5 .php
  </Location>

As phpLDAPadmin deals with credentials (including passwords for both administrative login, as well as user accounts), proper measures should be taken to secure this site. It should only be accessible over SSL/TLS (HTTPS). I've also configured Apache to require authorization to access PLA at all - including its login page (detailed later).

phpLDAPadmin Configuration

phpLDAPadmin provides an example configuration in config/config.php.example. Copy it to config/config.php, then customize it from there. If you are running the LDAP server (e.g. OpenLDAP) on the same host, no changes should be required, but setting the server "friendly" name is probably desired at a minimum. Details are available at Installation, Config, Config.php, and LDAP server definitions in the PLA Wiki.

At this point, phpLDAPadmin should be mostly usable. However, as of version 1.2.0.5 of PLA, there are a few quirks that I found and addressed:

  1. One unloadable DN causes others to not expand in the tree, due to a buggy early return from the draw function in lib/HTMLTree.php that skips over draw_javascript() from being called, and ajax_tree.js and layersmenu-browser_detection.js not being loaded into the browser. I reported this in bug # 2997938, and also provided a patch (attached to the bug report). As of 2010-12-27, there has been no acknowledgement or other activity taken by the PLA developers on this bug, so anyone also affected will need to manually apply the patch.

  2. When using phpLDAPadmin over HTTPS (as recommended above), all page resources are properly loaded over HTTPS except the SourceForge logo in the page footer. This causes security warnings in the browser due to "partial encryption". I reported this in bug # 2997703, along with a work-around of using the "remoteurls" option that is mentioned but otherwise undocumented at http://phpldapadmin.sourceforge.net/wiki/index.php/Config.php, as well as a code fix to properly use proper relative URLs. As of 2010-11-06, a fix has been committed for the next (but not yet available) PLA release.
  3. With every attempt to edit an entry, there is a nuisance "Select a template to edit the entry" page, that prompts for a template to use (either "Default", "Generic: Address Book Entry", or "Generic: Posix Group"). This prompt is repeated for repeat edits, with no visible option to save a default template. After reading this forum post on gentoo.org, and extending upon some of the suggestions offered for other issues in the PLA FAQ, I renamed each of the 2 .xml files under "templates/modification" to add a non-.xml suffix, essentially disabling the modification templates. (Simply renaming or removing the directory seemed like it should be a better option, but causes other errors.)
  4. Similar to the above, and more closely covered by the FAQ, even after removing the "modification" templates, there are still "Automatically removed objectClass from template" warnings displayed when first editing an entry in a PLA session. Renaming "mozillaOrgPerson.xml", "courierMailAccount.xml", and "courierMailAlias.xml" under the "templates/creation" folder seems to have removed all of these warnings, at least for my configured LDAP schema. (I'm not sure why the "creation" templates are even being referenced during modification.)

Alternatives

I had looked through a few alternatives before choosing phpLDAPadmin. At least while limiting the search to free and open-source solutions, I really didn't find anything that I think can compare to PLA. However, one cool, but non-web-based alternative I did find is shelldap, which allows for browsing and manipulating an LDAP directory using familiar shell commands like cat, cd, cp, ls, touch, mkdir, move, and vi.

4 comments:

Anonymous said...

you have to change your config file :

/* Just show your custom templates. */
$config->custom->appearance['custom_templates_only'] = true;

/* Disable the default template. */
$config->custom->appearance['disable_default_template'] = false;


writed by : mehdi kashfi

Anonymous said...

"mehdi kashfi" solution works only if you didn't add your own templates, but if you did then

$config->custom->appearance['custom_templates_only'] = true;

doesn't help unfortunately.

Anonymous said...

Hello, regarding the HTMLTree.php bug, is it possible to post the patch, since the links are broken. Thank you

Mark A. Ziesemer said...

Michalis - this was 4.5 years ago, but way to go Sourceforge...

I can't immediately find what I had uploaded here. However, I checked my running install - which is 1.2.3 (and having run 1.2.1.1 previously). When compared to the associated download bundle, I have no patches applied against HTMLTree.php - so I'm assuming this has been fixed since the 1.2.0.5 release on which I posted regarding this.