NukeDap Module v2.2

This package synchronizes the PHP-Nuke user database with an LDAP database so names and passwords can be maintained in the LDAP database. It can coexist with other LDAP support such as POSIX and SAMBA allowing LDAP to act as a central repository for user authentication and information. This version of NukeLDAP does not support synchronization of fields other than the password field.

NukeLDAP is installed as an administration module in admin/modules. It provides a management interface accessible only to PHPNuke Super Users. It has a support module that is loaded via the database support and changes have been made to the Your_Account module to facilitate the interaction between the LDAP server and the PHPNuke database.

In addition, changes may be required to the system if script support is used and if the nuke.schema is used with your LDAP server. The system has been tested with OpenLDAP and the sample files provided are for this server running on Linux. It is suitable for other LDAP environments as well but instructions and examples are not provided here. Anyone knowledgable about the operation of their LDAP server should be able to take the OpenLDAP examples and adapt them to their own server.

Settings are stored in the nuke_ldap table in the PHPNuke database. These settings are changed using the NukeLDAP administration page that is accessible via an LDAP icon on the main administration page. The settings control the operation of the NukeLDAP support and the access methods and structures used with the LDAP server. Typical settings include the URI or IP address of the LDAP server, the port used and the root name and password. For an OpenLDAP server, these values are found in /etc/openldap/slapd.conf.

NukeLDAP hooks into Your_Account in the administration and user index.php files. There are minimal changes and the function names used are all prefixed with ldap_fn_ making them easy to find. They are located in four major areas: user creation, user deletion, password changing and authentication. Less than half a dozen lines of code are added to these files. Make sure the changes have been made appropriately to these files if the version of PHPNuke you are using differs from the one used to supply the changes as part of this package.

The NukeLDAP functions are called before or after PHPNuke performs the matching function such as deleting a user. The functions perform a similar operation but using the LDAP server. The main interaction is via authentication. In this case, the user supplies their user name and password. This is checked against the LDAP database. If it is valid then the PHPNuke database entry for the user is modified since the password may be different. This allows users to make changes to their LDAP password using other means. If the user name is correct but the password does not match then a random PHPNuke password is set preventing the user from logging on.

This approach allows the PHPNuke system to utilize the password in its native form independent of the LDAP support. The downside it that any module with PHPNuke that changes the password will need to be modified with NukeLDAP support. At this point, only Your_Account makes these kind of changes.

The interaction between the LDAP server and NukeLDAP is primarily done using the user name and password. This typically match the LDAP uid and userPassword fields. However, LDAP is very configurable and there are different versions so the names of these fields may differ. The NukeLDAP administration interface makes changing these an easy task.

LDAP Basics: You should be somewhat familiar with LDAP and objectclass'es. Essentially each type of LDAP entry is defined by a set of fields that are required or optional as specified by an objectclass definition found in an LDAP schema file. A particular entry normally has a few objectclass definitions associated with it.

The two fields (uid and userPassword) can be specified by one or more objectclass definitions that define a user LDAP record. One of these objectclass'es may be NukeAccount.

The NukeAccount objectclass is provided in the nuke.schema file. The OID number used is registered and should not conflict with any LDAP definitions. The NukeAccount can be used and the standalone samples utilize it to provide a simple LDAP structure.

It is possible to use a different set of objectclass'es and not use the NukeAccount objectclass to allow a user entry to include the two required fields. This approach is often more desirable for systems that already have an LDAP server in place.

If you are just using LDAP for NukeLDAP then the samples provided will be sufficient. If you are including other objectclass definitions for services such as Samba then you will have to examine them a little more closely to see if you need to include the NukeAccount definition for user entries or if you can get by without using NukeAccount.

NukeAccount can interact with the system when creating user entries in two ways. One is for NukeLDAP to create a user entry directly using parameters, including a list of objectclass'es, from the NukeLDAP administration page or using scripts. The latter are run outside of the web server process, whereas NukeLDAP works as part of this process. The scripts are command line actions that can invoke any program allowing you to customize the action for your system. For example, the add script could create an LDAP Samba user by calling the Samba LDAP support programs that perform this function. The script can also provide logging information. The level of complexity or simplicity is up to you and your requirements as well as your script programming talents. In general, simple operations can be done in a line or two of text. The samples provided with NukeLDAP log actions such as creating a user in the operating system message log.

The internal and scripting support can be used alone or together. If you are not logging any information and you are using a basic LDAP configuration like the one provided as an example then you can get away with just using the internal support and never writing a script. The option is there if you need it.

NukeLDAP is transparent to users. If they change their password using PHPNuke then the change is reflected in the LDAP database. If this database is used for other services such as Samba then the LDAP server can provide single sign on support or at least consistent passwords for different services.