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 (through ldap, they can locally).

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 Extension
I've added options LocalSettings.php which are the following when used by an admin:

LocalSettings.php:

require_once( 'LdapAuthentication.php' ); $wgAuth = new LdapAuthenticationPlugin; $wgLDAPDomainNames = array(""); $wgLDAPServerNames = array(""); $wgLDAPSearchStrings = array(""); $wgLDAPUseSSL = true;

LocalSettings.php (example):

require_once( 'LdapAuthentication.php' ); $wgAuth = new LdapAuthenticationPlugin; $wgLDAPDomainNames = array( "testADdomain","testLDAPdomain"  ); $wgLDAPServerNames = array( "testADdomain"=>"testADserver.example.com",  "testLDAPdomain"=>"testLDAPserver.example.com testLDAPserver2.example.com"  ); $wgLDAPSearchStrings = array( "testADdomain"=>"TDOMAIN\\USER-NAME",  "testLDAPdomain"=>"uid=USER-NAME,ou=people,dc=example,dc=com"  ); $wgLDAPUseSSL = 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 and so is using the local domain.

Since this is coded as an extension, some changes must be done in the extension itself. If you wish to use a local domain, you must change the "strict" function in includes/LdapAuthentication.php to return false.

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. 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 yet.

The next major revision will fix this by allowing a temporary password to be stored in the local database. This single use password will allow the user to login and change his password on the LDAP directory. (I have no planned release date on the next major revision)

Modification of Current Core Code Required
This extension does modify the core code slightly. The core code allows people to create accounts with blank passwords, and allows people to login with blank passwords. As this would be a serious security flaw when using external and internal authentication methods, it was necessary.

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.

Suggestions
--Dack 20:55, 19 Jan 2005 (UTC)
 * The mail password problem could be solved by emailing a link to a temporary URL that allows a password change. Not sure if this would be easier or harder to impliment than the temporary local password idea (though maybe a tiny bit less hackish).