Extension:LDAP Authentication/FAQ

Where do I download the extension?
See the download section of the infobox on any of the pages of this documentation.

Problem
If your server happens to use Solaris LDAP client instead of OpenLDAP (determiend through phpinfo) then you will be unable to connect to LDAP servers. The cause is the expected Host name passed to ldap_connect. The example below illustrates the issue.

Example
Works on OpenLDAP, bombs on Solaris CLient 

The cause is the ldap:// portion

Works with Solaris Client 

The code within LDAAuthenticationPlugin.php adds ldap://, ldapi://, or ldaps:// for server names. This will cause it to fail.

Remedy
Remove the $serverpre value for the block below; $servers = ""; $tmpservers = $wgLDAPServerNames[$_SESSION['wsDomain']]; $tok = strtok( $tmpservers, " " ); while ( $tok ) { $servers = $servers. " " . $serverpre. $tok; $tok = strtok( " " ); }		$servers = rtrim($servers);

LdapAuthentication.php up to 1.1c (>=1.1d can skip this)
I've added a bug into MediaWiki's bugzilla to get part of this fixed. One part of the workaround is in my code (which will be fixed and released soon), and the other is in MediaWiki's code. So, to make it work, please change the following in LdapAuthentication.php in the initUser function (if using 1.1c or below):

$user->setPassword( '' );

to:

$user->mPassword = '' ;

and add the following function to LdapAuthentication.php:

/**        * Can the wiki change passwords in LDAP? * Return true if yes. *        * @return bool * @access public */           function allowPasswordChange { global $wgLDAPUpdateLDAP, $wgLDAPMailPassword;

if ( isset($wgLDAPUpdateLDAP[$_SESSION['wsDomain']]) ) { $updateLDAP = $wgLDAPUpdateLDAP[$_SESSION['wsDomain']]; }               if ( isset($wgLDAPMailPassword[$_SESSION['wsDomain']]) ) { $mailPassword = $wgLDAPMailPassword[$_SESSION['wsDomain']]; }               if ( $updateLDAP || $mailPassword ) { return true; } else { return false; }              }

SpecialUserlogin.php (all Versions MediaWiki 1.9.x)
And in includes/SpecialUserlogin.php you can use the following patch (you probably want to patch by hand since this patch is against SVN):

--- SpecialUserlogin.php       (revision 19677) +++ SpecialUserlogin.php       (working copy) @@ -307,13 +307,18 @@        * @private */       function initUser( $u ) { +              global $wgAuth; +               $u->addToDatabase; -              $u->setPassword( $this->mPassword ); + +              if ( $wgAuth->allowPasswordChange ) { +                      $u->setPassword( $this->mPassword ); +              } +                $u->setEmail( $this->mEmail ); $u->setRealName( $this->mRealName ); $u->setToken; -              global $wgAuth; $wgAuth->initUser( $u ); $u->setOption( 'rememberpassword', $this->mRemember ? 1 : 0 );

How do I install the extension?
See the install section of the about page.

How do I configure the extension?
See the configuration pages.

How do I configure PHP with LDAP on Windows?
You need to:


 * 1) Add the PHP directory to the PATH system variable
 * 2) * Ensure libeay32.dll and ssleay32.dll are in this path
 * 3) Edit the php.ini file, and change:
 * ;extension=php_ldap.dll
 * to:
 * extension=php_ldap.dll
 * 1) Restart your web server
 * extension=php_ldap.dll
 * 1) Restart your web server

How do I fix certificate trust issues with LDAPS or LDAP with StartTLS on Windows?
If you are having trust issues with LDAPS or LDAP with StartTLS, you'll need to modify your ldap.conf file. This file seems to be hardcoded in PHP on Windows. Put your openldap options into the following file (create the directories and file):

C:\openldap\sysconf\ldap.conf

My LDAP server requires SSL/TLS client authentication, where do I configure this?
PHP has no method to set a client certificate and key, and as such, this isn't configurable in the LDAP extension. You can, however, define this at the Apache level. Set the HOME and LDAPRC variables to point to a custom .ldaprc file (see 'man 5 ldap.conf') in /etc/apache2/envvars (on Debian/Ubuntu), or via SetEnv directives (Red Hat). In this file you should point to your client certificate and key.

Authentication fails for usernames with underscores; how do I fix this?
This is currently unsupported in the extension. MediaWiki replaces underscores with spaces in usernames, and the extension therefore, gets the username with the underscores replaced.

Here is a user submitted hack for getting this to work:

I added a line at the beginning of the function "getSearchString":

This replaces the space with an underscore when it creates the user username that is sent to the LDAP server. As far as MediaWiki is concerned it will still use the space in the name. --JoeD July 7th 2007


 * You might also have to do the same str_replace in the function "authenticate".--80.179.206.193 16:47, 23 April 2009 (UTC)

Can I use one attribute to authenticate users, but use another as the username?
You can do this using the 'SetUsernameAttributeFromLDAP' hook. For instance, in the following configuration, authentication is done with the "cn" attribute, but the username is being set with the "uid" attribute:

I installed the extension, but now I don't have a Sysop user; how do I give myself Sysop rights?
There are a few ways of doing this; however, the easiest method is:


 * 1) Log in with your regular account (to ensure your account is created)
 * 2) Disable the extension
 * 3) Log in as WikiSysop
 * 4) Go to Special:Userrights and add the sysop group to your regular account
 * 5) Re-enable the extension

How do I remove the domain list from Special:Userlogin?
You can hide this with CSS; edit MediaWiki:Common.css, and add the following:

display: none !important; }
 * 1) mw-user-domain-section {

How do I integrate LDAP authentication with Confirm Account creation extension ?

 * See Extension:ConfirmAccount/Integration with LDAP Authentication extension

Authentication is working for some users, but not others
There are a number of things you should check:


 * 1) Is the user's password shorter than the configurable minimum ($wgMinimalPasswordLength)? MediaWiki forbids this.
 * 2) Is the user's password the same as their user name? MediaWiki forbids this.
 * 3) If you are doing group restrictions, is that user a member of that group?
 * 4) Is the user a member of that group due to group nesting? If so, do you have nested group searching enabled?
 * 5) Is that group the user's primary group? If so, the extension most likely won't find it.
 * 6) Does the username contain an underscore? MediaWiki converts underscores in usernames to spaces. This is currently an open bug in the LDAP extension.