Extension:LDAP Authentication

Bugzilla enhancement feature
This enhancement feature is listed as http://bugzilla.wikipedia.org/show_bug.cgi?id=814 --Tom Gries mail 18:43, 4 Nov 2004 (UTC)

Current version
For the time being this patch is intended mostly for smaller or internal sites that wish to manage their user accounts solely through LDAP. In this current patch version, users cannot add themselves, change their own password, or get a new password mailed to them.

Future version
In a future version, larger sites, or a group of larger sites that wish to share one pool of users could use an LDAP server (or multimaster/consumer servers) to create a single sign on solution; in this future version, the wiki could operate in the same way it does using the local database, except using LDAP as a backend for storing authentication information.

Summary of patch
I've added 6 options to DefaultSettings.php and LocalSettings.php which are the following when used by an admin:

DefaultSettings.php:

$wgUseLDAP = false; $wgLDAPDomainNames = array(""); $wgLDAPServerNames = array(""); $wgLDAPSearchStrings = array(""); $wgLDAPUseSSL = true; $wgLDAPUseLocal = false;

LocalSettings.php (example):

$wgUseLDAP = true; $wgLDAPDomainNames = array( "testADdomain","testLDAPdomain"  ); $wgLDAPServerNames = array( "testADdomain"=>"testADserver.example.com",  "testLDAPdomain"=>"testLDAPserver.example.com testLDAPserver2.example.com"  ); $wgLDAPSearchStrings = array( "testADdomain"=>"TDOMAIN\\USER-NAME",  "testLDAPdomain"=>"cn=USER-NAME,ou=people,dc=example,dc=com"  ); $wgLDAPUseSSL = true; $wgLDAPUseLocal = true;

In this example, there are three different domains, one is local, one is an Active Directory domain, and the other is a normal LDAP domain (Sun directory server, openLDAP, etc). The user must provide the search string for a user's distinguished name (USER-NAME is substituted in SpecialUserLogin.php with the actual user's loginname). Using SSL is optional (although it is the default) and so is using the local domain (which is the wiki itself, and is not on by default). Of course, using LDAP is off by default.

When using LDAP, passwords are not stored in the database (unless users create accounts on the local domain). Blank passwords are no longer allowed since we wouldn't want people using the local domain logging in as domain users.

The interface for logging in is slightly different when using LDAP as well. Since the LDAP directory will be managing user accounts and passwords, I have removed the "mail me a new password" button, and the validate password field (unless $wgLDAPUseLocal is true). I have added a selection box that will allow users to choose which domain they wish to authenticate against (in the above example, the options would be "testADdomain", "testLDAPdomain", and "local").

A few problems i have are not how I have it currently implemented, but with features that could be added later. For instance, large sites (wikipedia, and the like) i'm sure do not want to handle user accounts manually; small sites, and organizations that use it internally probably do. A feature that could be added to the basic LDAP authentication is the ability for the wiki to add user accounts and manage passwords like it does currently (locally). The problem with this is that most LDAP directories cannot work in this fashion. For instance, if the wiki was to mail a new password to a user, it would need to change the password on the LDAP directory which would cause the user's old password to no longer work. Obviously this is a huge DoS situation. Adding user accounts is less of a problem, but because of time considerations, I cannot implement it.

Additions/changes for later versions

 * Allowing users to add themselves to LDAP using the wiki ($wgLDAPselfAdd)
 * Allowing users to change LDAP passwords through the wiki ($wgLDAPselfModify)
 * Reenabling "Mail me a new password" This is a problem because allowing this with any normal LDAP directory could lead to a DoS attack (since there is no way to store an additional password in LDAP). One possible way to allow this would be to use both the local database, and the LDAP directory in conjunction with each other, holding the temporary password in the local database.