Extension talk:LDAP Authentication/LQT Archive 1

= Archive =

Due to limitations of MediaWiki structures and unidentified editor's limited patience, someone archived an earlier version of this discussion/talk page, as "it was getting way too long" - accuracy, continuity, and helpfulness be damned! Some archive contents of this discussion/talk page from ~2007-05-12 and earlier can be found (and contributed to!) here:

Archive 1 -- Peter Blaise peterblaise 10:02, 23 May 2007 (UTC)


 * Note that I archived it, and kept issues that were still open on this discussion page. It is very hard to keep track of things when a page is as long as the old one was. I understand that it breaks continuity some, but quickly finding things in what is essentially a support forum is a good thing. I'm probably going to make an FAQ from answers on the old discussion page, and this discussion page. --Ryan lane 19:32, 6 August 2007 (UTC)

= Requirements =

Php
Could the statement "PHP must be compiled with LDAP support for any functionality at all" be explained further? I'm not a developer and simply downloaded php5 from php.net and followed config instructions to get mediawiki running. I never compiled php. According to php.net I would need some development tools to compile php? What is needed to change the default version of php5.1.2 windows package to be 'compiled' for LDAP? Can I just configure some extension from php.ini? my specific situation is Windows2003/IIS/php/mysql.


 * There is quite a bit of documentation on how to get LDAP working with PHP, and specifically with windows. I believe someone even posted some info on the content page of this article. I believe this is probably beyond the scope of this documentation. --Ryan Lane

= I can't find the code! =

See the download section of the infobox at Extension:LDAP_Authentication.

= Compatibility =

Problem with autocreated users
Dangerous code snipped


 * You need to figure out what your real problem is. If there is some incompatibility between 1.10 and the plugin, I'll be happy to track down the problem and fix it (either in the core code, or the plugin). --Ryan lane 19:49, 6 August 2007 (UTC)


 * Exactly same issue as above! $wgLDAPUpdateLDAP, $wgLDAPMailPassword and $wgEmailAuthentication == false.
 * -- 22:11, 15 August 2007 (UTC)


 * ... I need more information than "it isn't working." Please post your configuration, and your debug info, with sensitive stuff snipped out. I've heard multiple reports of this working fine with 1.10. --Ryan lane 01:05, 16 August 2007 (UTC)


 * Oh, btw, all three of those are false by default, and use domain (array) style configuration. I'm betting it is pretty likely your configuration is messed up. --Ryan lane 01:07, 16 August 2007 (UTC)


 * I too was having difficulties with LDAPAuthentication for new AD users. You can view the history of this article for all my configuration settings and debugging output, but the crux of it was a "external authentication database error or you are not allowed to update your external account" error when trying to use LDAPAuthentication 1.0h on new Active Directory users and a "Login incorrect" error for all users when trying to upgrade to LDAPAuthentication 1.1g.


 * In the end I suspect it was because LDAPAuthentication 1.0h used plain LDAP binding to authenticate by default whereas the newer 1.1g uses TLS by default. By setting $wgLDAPDebug = 3 I was able to see both TLS and SSL options failing suggesting that I first need to learn about these protocols and why my server doesn't seem to support them. Setting $wgLDAPEncryptionType = array("DOMAIN"=>"clear") in conjunction with using LDAPAuthentication 1.1g allowed login via straight LDAP binding, but it would be good to get some info about the security issues of using clear binding on a semi-private wiki (internal server, accessible to outside world, logins required).
 * -- 210.23.133.248 00:14, 4 December 2007 (UTC)

Verified to work with 1.10
I've tested this pretty throughly, and I have yet to have issues with MediaWiki 1.10; if anyone has problems that can be linked to 1.10, let me know. --Ryan lane 13:25, 20 August 2007 (UTC)

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 );

Please let me know if this fixes the problem
I don't currently have the ability to test MediaWiki 1.9 w/ LDAP authentication, please let me know if this fixes your problem. --Ryan Lane 18:16, 13 February 2007 (UTC)

With a config very similar to Robert, above, and applying you fixes everything seems to be working fine for me. -- sterling 144.92.220.30 20:30, 15 February 2007 (UTC)

The above config changes together with LDAPAuthentication 1.1d fixing the problem with MediaWiki 1.9.2 and LDAP authentication against Novell eDirectory. Thanx a lot! -- Günther Rasch 07:35, 22 February 2007 (UTC)

Shit yeah! I've been trying to make this work for 2 days straight and I missed this last step. Works like a charm. :) -- Jonathan Puddle

This is exactly what i was searching for. Now every LDAP-user ist automaticaly registered while logging in at the first time, and authenticates with LDAP-password. Thanx a lot! -- Jens Vieler, 21 March 2007

This worked for me. Against both AD and Linux LDAP. Thanks much! -- John Harris, 23 March 2007 (Virginia Tech, ECE)

This fix stopped me to sweat over the ldap issue I have been having. Thanks!!!! - Mutuk March 27 2007.

PHP errors in allowPasswordChange
This fix produces PHP errors because your local variables $updateLDAP and $mailPassword are not properly scoped. (Enable onscreen PHP errors to see them.) You have defined these variables inside the IF statements, but your final test is outside. So these error messages are produced for the if ( $updateLDAP || $mailPassword ) test:

Notice: Undefined variable: updateLDAP in ....\extensions\LdapAuthentication.php on line 596

Notice: Undefined variable: mailPassword in ....\extensions\LdapAuthentication.php on line 596

To fix, just set both variables to the empty string just below the "global" line. Maiden taiwan 02:29, 1 March 2007 (UTC)


 * Well, they aren't errors, just warnings. Another user has pointed this out (I'm too lazy to find it now), and it'll be fixed in the next release. Ryan Lane 14:30, 1 March 2007 (UTC)

allowPasswordChange doesn't check for $wgLDAPUseLocal
This fix causes another bug. If $wgLDAPUseLocal is set to true and no LDAP user with write permission is specified, then when someone tries to create a new account and the wiki attempts to add the user's password to the database, it first checks with $wgAuth->allowPasswordChange which returns false. This causes the user to be added to the database fine but with no password. The user is logged in, but once they log out their account has no password so they can never get back in. --Christian 15:57, 17 April 2007 (UTC)

if ( 'local' == $_SESSION['wsDomain'] ) { return true; }


 * You can fix this by adding the above to the beginning of the function allowPasswordChange --Christian 16:13, 17 April 2007 (UTC)


 * Thanks for the report and fix; this will be in the next release. Ryan lane 02:45, 18 April 2007 (UTC)


 * This is fixed in svn right now if it is causing you any issues. Ryan lane 02:45, 18 April 2007 (UTC)


 * After overwriting 1.1d with 1.1e on 1.9.3, my password is no longer accepted. I'm using AD 2003.  Are there any additional tweaks that need to be done?  163.252.39.78 14:56, 18 April 2007 (UTC)


 * 1.1d to 1.1e was essentially just bug fixes. It shouldn't have broken anything. I'll need debugging info from you, and your configuration with anything sensitive snipped out. --Ryan lane 15:04, 18 April 2007 (UTC)


 * I just tried to apply this fix to the top of allowPasswordChange but it had no effect. I had to simply put "return true;" at the top of the function for my logins to work.  This was with $wgLDAPUseLocal set to 'true'.  (Setting it to 'false' caused the same password-change-forbidden error before I applied my hack, though).  This is on mw 1.9.3 and plugin 1.1e.  --138.26.64.50 15:35, 24 April 2007 (UTC)


 * I just checked this using the SVN version. It seems to be working for me. I'm working on the plugin right now, so don't use HEAD, try revision 24891 (or you can wait for the release of 1.1f) --Ryan lane 01:39, 18 August 2007 (UTC)


 * I installed this and am getting the same error message "password-change-forbidden". I get the same error regardless of what $wgLDAPUseLocal is set equal to.  Is it trying to set the password in Active Directory, or in the MySQL Database?  I am using the 1.1g version.  Thanks, Shane.


 * Are you using MediaWiki 1.9? If so, upgrade MediaWiki, or follow the instructions posted on how to fix the problem. I won't actively support issues with versions of MediaWiki that are out of support (with the exception of 1.6, until PHP5 is readily available most places). --Ryan lane 14:11, 5 November 2007 (UTC)


 * Thank you, I was using 1.9, I upgraded to 1.11 and it logged in without any issues.

= How do I install this thing? =

Drop the LdapAuthentication.php into the includes or extensions directory and follow the configuration information.

= How do I configure it? =

Configuration examples are here:

Configuration Examples

Explanation of the plugin is in the content page.

= Support =

Please ask support questions here, posting new questions at the bottom.

password min length limit curiosity
It's over my head, but the authors may be interested in this user's findings:


 * http://mail.wikipedia.org/pipermail/mediawiki-l/2005-September/006985.html
 * http://mail.wikipedia.org/pipermail/mediawiki-l/2005-September/006997.html

-- Sy / (talk) 12:30, 15 September 2005 (UTC)


 * Ah, good to know. I'm probably not checking the password limit when creating users. This will have to be an outstanding bug for a while. I'm currently evacuated from new orleans, and have no ability to work on the patch. -- Ryan Lane


 * This bug is unfortunately in the core code, and not in my plugin. I have submitted a bug (and a patch correcting the problem) into the bugzilla at: http://bugzilla.wikipedia.org/show_bug.cgi?id=4081
 * --Ryan Lane

Nested Groups option not working
Hello All,

I know this isn't a default plugin for MediaWiki, but I am sure that others are using LDAP authentication.

I am using the Ldap plugin on the mediawiki site and I am unable to get nested groups working. I can authenticate when a user is part of a specific group, but when a group is added to the required group it does not work.

Below is my nested groups array in my Localsettings.php file.

$wgLDAPGroupSearchNestedGroups = array( "domain.com"=>true );

I am running mediawiki 1.9.3, php 5.2.0, apache 2.2.3 and Version 1.1c 12/04/2006 of this module.

Can anyone help me out with this?

What can I do to fix this or get further assistance?

Thanks :)

DEBUG: Entering validDomain User is using a valid domain. Setting domain as: domain.com Entering getCanonicalName Username isn't empty. Munged username: User Entering authenticate Entering Connect Using TLS or not using encryption. Using servers: ldap://dc2.domain.com ldap://dc4.domain.com Using TLS Connected successfully Entering getSearchString Doing a proxy or anonymous bind Entering getUserDN Doing a proxy bind Created a regular filter: (sAMAccountName=User) Using base: dc=domain,dc=com Fetched username is not a string (check your hook code...). userdn is: CN=User,OU=Operations&NOC,OU=Domain Staff,DC=domain,DC=com Binding as the user Binded successfully Checking for (new style) group membership Entering isMemberOfRequiredLdapGroup Required groups:cn=nca se wiki users,ou=groups,dc=domain,dc=com Entering getUserGroups Entering getGroups Search string: (&(member=CN=User,OU=Operations&NOC,OU=Domain Staff,DC=domain,DC=com)(objectclass=group)) Binding as the proxyagentDN Returned groups:cn=operations,ou=groups,dc=domain,dc=com,cn=nca all,ou=groups,dc=domain,dc=com,cn=nca vpn users,ou=groups,dc=domain,dc=com,cn=nca altiris,ou=groups,dc=domain,dc=com,cn=systems engineering,ou=groups,dc=domain,dc=com,cn=nca   outage,ou=groups,dc=domain,dc=com,cn=altiris helpdesk workers,ou=groups,dc=domain,dc=com,cn=nc tripwire,ou=groups,dc=domain,dc=com,cn=linuxadmins,ou=groups,dc=domain,dc=com,cn=linuxdns,ou=groups,dc=domain,dc=com,cn=nca gw wiki users,ou=groups,dc=domain,dc=com,cn=nca wiki core users,ou=groups,dc=domain,dc=com Returned groups:,,,,,,,,,,, Entering searchNestedGroups Checking groups:cn=operations,ou=groups,dc=domain,dc=com,cn=nca all,ou=groups,dc=domain,dc=com,cn=nca vpn users,ou=groups,dc=domain,dc=com,cn=nca altiris,ou=groups,dc=domain,dc=com,cn=systems engineering,ou=groups,dc=domain,dc=com,cn=nca   outage,ou=groups,dc=domain,dc=com,cn=altiris helpdesk workers,ou=groups,dc=domain,dc=com,cn=nc tripwire,ou=groups,dc=domain,dc=com,cn=linuxadmins,ou=groups,dc=domain,dc=com,cn=linuxdns,ou=groups,dc=domain,dc=com,cn=nca gw wiki users,ou=groups,dc=domain,dc=com,cn=nca wiki core users,ou=groups,dc=domain,dc=com

Entering getUserGroups Checking membership for: cn=operations,ou=groups,dc=domain,dc=com Checking membership for: cn=nca all,ou=groups,dc=domain,dc=com Checking membership for: cn=nca vpn users,ou=groups,dc=domain,dc=com Checking membership for: cn=nca altiris,ou=groups,dc=domain,dc=com Checking membership for: cn=systems engineering,ou=groups,dc=domain,dc=com Checking membership for: cn=nca   outage,ou=groups,dc=domain,dc=com Checking membership for: cn=altiris helpdesk workers,ou=groups,dc=domain,dc=com Checking membership for: cn=nc tripwire,ou=groups,dc=domain,dc=com Checking membership for: cn=linuxadmins,ou=groups,dc=domain,dc=com Checking membership for: cn=linuxdns,ou=groups,dc=domain,dc=com Checking membership for: cn=nca gw wiki users,ou=groups,dc=domain,dc=com Checking membership for: cn=nca wiki core users,ou=groups,dc=domain,dc=com (Loops about 5 times or so)

Entering searchNestedGroups Checking groups:cn=operations,ou=groups,dc=domain,dc=com,cn=nca all,ou=groups,dc=domain,dc=com,cn=nca vpn users,ou=groups,dc=domain,dc=com,cn=nca altiris,ou=groups,dc=domain,dc=com,cn=systems engineering,ou=groups,dc=domain,dc=com,cn=nca   outage,ou=groups,dc=domain,dc=com,cn=altiris helpdesk workers,ou=groups,dc=domain,dc=com,cn=nc tripwire,ou=groups,dc=domain,dc=com,cn=linuxadmins,ou=groups,dc=domain,dc=com,cn=linuxdns,ou=groups,dc=domain,dc=com,cn=nca gw wiki users,ou=groups,dc=domain,dc=com,cn=nca wiki core users,ou=groups,dc=domain,dc=com (Repeats about 10 times or so)

Entering getUserGroups Checking membership for: cn=operations,ou=groups,dc=domain,dc=com Checking membership for: cn=nca all,ou=groups,dc=domain,dc=com Checking membership for: cn=nca vpn users,ou=groups,dc=domain,dc=com Checking membership for: cn=nca altiris,ou=groups,dc=domain,dc=com Checking membership for: cn=systems engineering,ou=groups,dc=domain,dc=com Checking membership for: cn=nca   outage,ou=groups,dc=domain,dc=com Checking membership for: cn=altiris helpdesk workers,ou=groups,dc=domain,dc=com Checking membership for: cn=nc tripwire,ou=groups,dc=domain,dc=com Checking membership for: cn=linuxadmins,ou=groups,dc=domain,dc=com Checking membership for: cn=linuxdns,ou=groups,dc=domain,dc=com Checking membership for: cn=nca gw wiki users,ou=groups,dc=domain,dc=com Checking membership for: cn=nca wiki core users,ou=groups,dc=domain,dc=com wiki users,ou=groups,dc=domain,dc=com Checking membership for: cn=nca wiki core users,ou=groups,dc=domain,dc=com (Loops 137 times)

Entering searchNestedGroups Couldn't find user in any nested groups. Couldn't find the user in any groups (2). Entering strict. Returning true in strict. Entering modifyUITemplate

Configuration require_once( 'LdapAuthentication.php' ); $wgAuth = new LdapAuthenticationPlugin; $wgLDAPProxyAgent = array( "domain.com"=>"CN=ldapuser,CN=Users,DC=domain,DC=com" ); $wgLDAPSearchAttributes = array( "domain.com"=>"sAMAccountName" ); $wgLDAPProxyAgentPassword = array( "domain.com"=>"password" ); $wgLDAPDomainNames = array( "domain.com" ); $wgLDAPServerNames = array( "domain.com"=>"dc2.domain.com dc3.domain.com" ); $wgLDAPUseLocal = false; $wgLDAPAddLDAPUsers = false; $wgLDAPUpdateLDAP = false; $wgLDAPMailPassword = false; $wgLDAPRetrievePrefs = true; $wgMinimalPasswordLength = 1; $wgLDAPGroupLowerCaseUsername = false; $wgLDAPRequiredGroups = array( "domain.com"=>array("cn=nca se wiki users,ou=groups,dc=domain,dc=com") ); $wgLDAPGroupUseFullDN = array( "domain.com"=>true ); $wgLDAPGroupObjectclass = array( "domain.com"=>"group" ); $wgLDAPGroupAttribute = array( "domain.com"=>"member" ); $wgLDAPGroupSearchNestedGroups = array( "domain.com"=>true ); $wgLDAPBaseDNs = array( "ncaustin.com"=>"dc=domain,dc=com" ); $wgLDAPDebug = 4; //for debugging LDAP $wgShowExceptionDetails = true; //for debugging MediaWiki $wgLDAPEncryptionType = array("domain.com"=>"tls");

The group "systems engineering" is a member of nca se wiki users. But I still can't login... I hope this is enough information.


 * This looks like it may be a bug. The part about "Returned groups" looks completely wrong. It shows the same group a bunch of times. All the looping is pretty strange too. Can you post your configuration with sensitive stuff snipped out? --Ryan lane 13:30, 27 March 2007 (UTC)

Was this issue ever resolved? I am having the same problem. The only difference is I am doing a straight bind. Any ideas? Thanks.


 * I just noticed that "$wgLDAPGroupNameAttribute" isn't defined here... it should be defined as $wgLDAPGroupNameAttribute = array ("domain.com"=>"cn"); --Ryan lane 22:48, 30 June 2007 (UTC)

I still can't get it to work. Same errors. Just to clarify, should that be $wgLDAPGroupNameAttribute = array ("domain.com"=>"cn"); or should I substitute cn for my master group name that contains the nested groups that need to be searched? I tried it both ways, but I wanted to make sure my syntax was right. MIS is the master group that contains a bunch of other nested groups. So here is what I used with all the sensitive information removed.

require_once( 'LdapAuthentication.php' ); $wgAuth = new LdapAuthenticationPlugin; $wgLDAPDomainNames = array( "domain.com" ); $wgLDAPServerNames = array( "domain.com"=>"server1.domain.com server2.domain.com" ); $wgLDAPSearchStrings = array( "domain.com"=>"USER-NAME@domain.com" ); $wgLDAPEncryptionType = array( "domain.com"=>"clear" ); $wgLDAPUseLocal = true; $wgMinimalPasswordLength = 1;

$wgGroupPermissions['*']['edit'] = false;
 * 1) Disable anonymous editing

$wgGroupPermissions['*']['createpage'] = false;
 * 1) Anonymous users can't create pages

$wgGroupPermissions['*']['read'] = false;
 * 1) Disable reading by anonymous users

$wgStrictFileExtensions = false; $wgCheckFileExtensions = false; $wgMimeDetectorCommand= "file -bi"; require_once("extensions/SpecialPdf.php");

$wgLDAPRequiredGroups = array( "domain.com"=>array("cn=mis,ou=groups,ou=site1,ou=sites,dc=domain,dc=com") ); $wgLDAPGroupUseFullDN = array( "domain.com"=>true ); $wgLDAPGroupObjectclass = array( "domain.com"=>"group" ); $wgLDAPGroupAttribute = array( "domain.com"=>"member" ); $wgLDAPGroupSearchNestedGroups = array( "domain.com"=>true ); $wgLDAPBaseDNs = array( "domain.com"=>"ou=administrators,dc=domain,dc=com" ); $wgLDAPSearchAttributes = array( "domain.com"=>"sAMAccountName" ); $wgLDAPGroupNameAttribute = array( "domain.com"=>"mis" );
 * 1) DNs in $wgLDAPRequiredGroups must be lowercase, as search result attribute values are...
 * 2) $wgLDAPRequiredGroups = array( "domain.com"=>array("cn=mis-tech-2,ou=groups,ou=administrators,dc=domain,dc=com", "cn=mis-tech-1,ou=groups,ou=administrators,dc=domain,dc=com") );
 * 1) $wgLDAPGroupSearchNestedGroups = array( "domain.com"=>false );
 * 1) $wgLDAPBaseDNs = array( "domain.com"=>"ou=groups,ou=administrators,dc=domain,dc=com" );

$wgLDAPDebug = 3;

It should be this exactly (copy, paste): $wgLDAPGroupNameAttribute = array( "domain.com"=>"cn" );

Once you make this change and authenticate, you should notice this line Returned groups:,,,,,,,,,,, Change to Returned groups:mis-tech-2,mis-tech-1,etc Basically, it will return the actual groups instead of ,,,,,,,,,. Once it returns the groups, does the Nested Groups work? It's still not working for me. I'm going to make a post to the mailing list. 2007-07-02

I made the change and it did return the proper groups instead of just the commas, but the login still isn't working.

In my case, I can log in if the user is in one of the $wgLDAPRequiredGroups, however, I CANNOT log in when my user is in a group, that is in one of the $wgLDAPRequiredGroups (ie, Nested). In the case of a nested group, I get what you are getting, my debug log shows massive looping when "Entering searchNestedGroups" and "Entering getUserGroups". I'm assuming this has something to do with our GroupNameAttribute, but my PHP is limited. Here is my post to the mailing list. I haven't received a reply yet: http://lists.wikimedia.org/pipermail/mediawiki-l/2007-July/021463.html


 * Ignore the last thing I wrote (now erased). I'm reading my own function very poorly :) (stupid recursion). $wgLDAPGroupNameAttribute should definately be set as "cn", as that seems to be the naming attribute of your group. The massive looping may be a bug, as I've noticed it happening to a few people. It also may just be poor debug logging on my part. I'm going to change around the logging some to be less spammy, and more informative. Hopefully it'll help us track this problem down. --Ryan lane 19:55, 6 July 2007 (UTC)

Ryan, If you need help recreating the error, or testing, I'm available M-F 9-6 PST. You can get my email from the post http://lists.wikimedia.org/pipermail/mediawiki-l/2007-July/021463.html

Same here. I can help test too. This is a big issue for me in getting this implemented. GT4NE1 at gmail dot com Thanks

Nested groups works fine for me, but...

I use LDAP auth extension to authenticate against AD with quite complicated structure with global groups consisting local groups. Users are members of "departmental" groups, that belong to local level, only. So effectively there is 3 level structure, with users in bottom level groups. When I specify "top level" groups as required ($wgLDAPRequiredGroups) then authentication process takes up to 1min, sometimes even longer. (BTW it is possible to have more then one group in $wgLDAPRequiredGroups array).

So my point is - would it be possible to have some caching for LDAP queries, as vast number of queries performed in authentication process are for groups resolving.

Thanks, Pawel

Fixed in SVN (1.1f)
I believe I've fixed the problem. I had some caching issues on searches, that speed up group searching/syncing, but completely clobbered nested group searching. I modified the caching stuff to take into account nested group searching; everything should be working now. Please test this out, and let me know. --Ryan lane 13:21, 20 August 2007 (UTC)
 * Tested in a 3-level nested group, works perfectly. Thanks a lot! --Guillaume Moutier 19:32, 30 August 2007 (UTC)
 * Confirmed working in 1.1g (alpha). Great work Ryan!  Thanks!

initUser bug is fixed in current mediawiki svn
I setup MediaWiki 1.9.3 and LdapAuthentication.php but got errors about "password-change-forbidden" when logging in as a user in LDAP but not yet in the MW DB. I found that this bug is already fixed in mediawiki svn, just not yet in a released version. If you encounter this, apply this small change:

http://svn.wikimedia.org/viewvc/mediawiki/trunk/phase3/includes/SpecialUserlogin.php?r1=20158&r2=20300

--Mindless 15:58, 30 March 2007 (UTC)

Problems with underlines in username (AD)
Hi I've got the Problem that users with underlines in their usernames can't login. Read in another article that I have to change $this->mTextform = str_replace( '_', ' ', $dbkey ); to $this->mTextform = str_replace( '_', '_', $dbkey ); int the Title.php. But this didn't make any difference. The Login still doesn't work with users withe underlines in their loginnames. Is there anybody who can help me? ..Thanks...


 * I honestly don't know how to fix this. The username is passed to the plugin after it is munged by MediaWiki. I'm sure there is somewhere I can hack the core code to fix this, but I haven't looked around for it yet. --Ryan lane 22:50, 30 June 2007 (UTC)

I had the same problem and fixed it with a small edit in the plugin. I added a line at the beginning of the function "getSearchString" $username = str_replace(' ','_',$username); 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

Internal server error on login
Ok, so i've setup the wiki before the weekend, and it was working all just fine with LDAP-authentication. Now on monday, when logging in with a user that already exists in the database it comes up with the following Internal server error: Database error A database query syntax error has occurred. This may indicate a bug in the software. The last attempted database query was: (SQL query hidden) from within function "User::addToDatabase". MySQL returned error "1062: Duplicate entry 'ldap-username' for key 2 (localhost)". Where ldap-username is ofcourse the ldap-user. When I delete the ldap-user from the database, logging in works just fine, but after logging out and in again it comes up with the same error message. It's strange because nothing has changed on the server over the weekend as logging on and off was just working fine last week. With debugging on the authentication has passed. Somehow it is trying to add the user again, while instead it has to update it if I am correct? Anybody got any ideas? -Martin
 * BTW, I am using the following setup: MediaWiki: 1.9.3, PHP: 5.2.1, MySQL: 5.0.37, LDAP plugin 1.1d. -Martin
 * Ok, so I fixed the problem, by making a dump and dropping the database. After this importing the database fixed the problem. Somehow there is some caching issue here, but I cannot seem to know which. Also I didn't use database caching upon installation. Maybe this helps somebody out or maybe Ryan can take a look at it in furter development. -Martin


 * Did you mess around with your database manually? I don't remember any entry called ldap-username... The plugin doesn't ever touch the database directly. --Ryan lane 21:34, 1 May 2007 (UTC)

Making work with Pywikipediabot
Has anyone had any experience getting pywikipediabot to work with LDAP? I tried it and it seems to not work because it can't successfully select the domain name. Any thoughts?

HotMonkeyAC 18:25, 27 April 2007 (UTC)


 * See: Extension talk:LDAP Authentication. This is a similar issue. the domain stuff is a valid part of the software, and bot frameworks should be providing that info on login. The pywikipediabot developer needs to fix that. --Ryan lane 20:10, 27 April 2007 (UTC)


 * one possible fix is to add the line
 * "wpDomain": self.domain,


 * to the predata array under def getCookie in login.py


 * you'll have to set self.domain somewhere else. mine is hardcoded in login.py as
 * self.domain = 'mydomain'
 * but this is very nasty. it should be set somewhere else like mywiki_family.py
 * let me know if this works for you
 * Jono Brooker 13:27, 20 June 2007 (UTC)


 * Jono, that worked perfectly.  Thank you!!!   -HotMonkeyAC 14:48, 26 June 2007 (UTC)

Import LDAP user data to wiki
Hi! I've got a strange problem. I've read a lot, but couldn't find anything, that was helping me. The LDAP-Authentication works well (after some starting troubles) ... when a user logs in, then the user is created in the wiki-database as well, that's good.

1. But is there a way, to import ALL LDAP users to the wiki? Thus, I can see on the userlist site in the wiki all LDAP users, which are able to log in, even those who haven't been logged in yet? Maybe there is a way in combination with another extension?

2. And is there a way, to automatically import the basic LDAP data of a user to his usersite, like Realname and email? Therefore the usersites of the users, who haven't logged in yet, wouldn't be that empty.

I already thought about writing a php script, which inserts the users in die usertable in the wiki DB ... but I'm afraid of destroying the consistency of the DB.

I hope you can give me some hints to achieve that.

thanks -- widi


 * Unfortunately, that is probably the only way to do it. If you really want to do this, I'd right a php script that uses MediaWiki to add the users, don't manually mess with the database. The SSL auto-authentication hook is probably a good starting ground for figuring out how to do it; you can ignore everything except for the part that actually creates the users. --Ryan lane 22:44, 30 June 2007 (UTC)

Please archive this page
Too long. 202.54.176.51 10:14, 7 May 2007 (UTC)


 * Is this better? Enjoy --Ryan lane 03:55, 13 May 2007 (UTC)

Another preferences problem
Everything works great for me except the preference pulling, i think (via the $wgLDAPdebug option) i have narrowed it down to it doesn't pull preferences. i have the following line at the end of the LDAP options in localsettings.php: $wgLDAPRetrievePrefs = true; but for some reason this is still returning false: $this->printDebug("Retrieving preferences",1); $entry = @ldap_read($ldapconn, $userdn, "objectclass=*"); $info = @ldap_get_entries($ldapconn, $entry); $this->email = $info[0]["mail"][0]; $this->lang = $info[0]["preferredlanguage"][0]; $this->nickname = $info[0]["displayname"][0]; $this->realname = $info[0]["cn"][0]; $this->printDebug("Retrieved: $this->email, $this->lang, $this->nickname, $this->realname",2); #} I'm not very patient so after posting this i continued to try to fix it. i found that this was also returning false: #if ( isset($wgLDAPRetrievePrefs[$_SESSION['wsDomain']]) && $wgLDAPRetrievePrefs[$_SESSION['wsDomain']] ) { $this->printDebug("Setting user preferences.",1); if ('' != $this->lang) { $user->setOption('language',$this->lang); } 		if ('' != $this->nickname) { $user->setOption('nickname',$this->nickname); } 		if ('' != $this->realname) { $user->setRealName($this->realname); } 		if ('' != $this->email) { $user->setEmail($this->email); } 		$saveSettings = true; #} i commented out the check blocks and preferences are reported as pulled and after my second edit, they are being populated in wiki, tho preferred language is coming back empty as such: Retrieved: eberlec@ .com,, Christopher Eberle, Christopher Eberle Setup is mediawiki 1.9.3, IIS6, mysql 4.1, PHP 5.2.2, windows 2003 standard I have changed the specialuserlogin.php as suggested and here are the settigns from my localsettings.php (incase you need them):
 * 1) if ( isset($wgLDAPRetrievePrefs[$_SESSION['wsDomain']]) && $wgLDAPRetrievePrefs[$_SESSION['wsDomain']] ) {

$wgGroupPermissions['ITUser']['read'] = true; $wgGroupPermissions['ITUser']['edit'] = true; $wgGroupPermissions['ITUser']['createpage'] = true; $wgGroupPermissions['ITUser']['createtalk'] = true; $wgGroupPermissions['ITUser']['upload'] = true; $wgGroupPermissions['*']['edit'] = false; $wgGroupPermissions['user']['edit'] = false; $wgGroupPermissions['*']['createaccount'] = false; $wgWhitelistRead = array( "Main Page", "Special:Userlogin", "Special:Userlogout", "-", "MediaWiki:Monobook.css" ); $wgGroupPermissions['*']['read']= false; $wgGroupPermissions['user']['read']=false; $wgShowIPinHeader = false; require_once( 'LdapAuthentication.php' ); $wgAuth = new LdapAuthenticationPlugin; $wgLDAPDomainNames = array(" "," "); $wgLDAPServerNames = array(" "=>"naddc1. .com"); $wgLDAPSearchStrings = array(" "=>" \\USER-NAME"); $wgLDAPEncryptionType = array(" "=>"clear"); $wgLDAPUseLocal = false; $wgMinimalPasswordLength = 7; $wgLDAPRetrievePrefs = true; $wgLDAPDebug=4; $wgLDAPBaseDNs = array( " "=>"dc= ,dc=com" ); $wgLDAPSearchAttributes = array( " "=>"sAMAccountName" ); $wgShowExceptionDetails = true; $wgLogo = "http://mercury/ITWiki/images/c/c9/Logo.png"
 * 1) Create IT User group
 * 1) Only logged in ITUsers can edit
 * 1) Nobody is allowed to create accounts
 * 1) Define pages people not logged in can see
 * 1) LDAP Auth Integration info##
 * 2) These lines should work in conjunction with ldapauthentication.php in the includes dir.
 * 1) These lines should work in conjunction with ldapauthentication.php in the includes dir.
 * 1) These lines should work in conjunction with ldapauthentication.php in the includes dir.
 * 1) Setup for LDAP Auth

And here is my output:

Entering validDomain User is using a valid domain. Setting domain as: Entering getCanonicalName Username isn't empty. Munged username: Eberlec Entering authenticate Entering Connect Using TLS or not using encryption. Using servers: ldap://naddc1. .com Connected successfully Entering getSearchString Doing a straight bind userdn is: \Eberlec Binding as the user Binded successfully Entering getUserDN Created a regular filter: (sAMAccountName=Eberlec) Using base: dc= ,dc=com Fetched username is not a string (check your hook code...). Pulled the user's DN: CN=Christopher Eberle,OU=Local Admins,OU=Groups,OU=NAA,DC= ,DC=com Retrieving preferences Retrieved: eberlec@ .com,, Christopher Eberle, Christopher Eberle Authentication passed Entering updateUser

(What is the deal with the "Fetched username is not a string"? Seems to be in everyones debug...)

Any help would be appreciated (after the second edit, apparently its just the checks for the variable $wgLDAPRetrievePrefs isn't being read or stored properly. Commenting out the "if" checks makes the whole thing work perfect. Any idea why the if checks aren't working?). eberlec at nicholsal (ignore this parented part) dot com


 * /me pokes you in the - you are using the wrong syntax for this option, and the option is documented at Extension:LDAP_Authentication. This option, like most options, are defined on a per domain basis. A good way to ensure your options are correct is to never use external documentation for how to configure this plugin. External documentation almost always seems to be completely incorrect. Usually the external docs were written for an older version of the plugin. Options have changed since then.


 * BTW, the "Fetched username is not a string" part is something most people don't configure. It isn't a bug; I guess I should make the message a little clearer. --Ryan lane 03:35, 13 May 2007 (UTC)

Username / Real Name question
I'm tackling LDAP authentication for the first time. I've managed to connect and authenticate, logging in with my LDAP username. Ideally, I'd like to login to an account named after LDAP real name, eg. having authenticated with username "johns", the registered account name is "John Smith" instead of "johns". Is this possible? I'm using the following configuration fragment (version 1.1d).

require_once( 'LdapAuthentication.php' ); $wgAuth = new LdapAuthenticationPlugin; $wgLDAPDomainNames = array( " " ); $wgLDAPServerNames = array( " "=>" "  ); $wgLDAPSearchAttributes = array( " "=>"uid" ); $wgLDAPBaseDNs = array( " "=>"o=Gla" ); $wgLDAPEncryptionType = array( " "=>"false" ); $wgLDAPDebug = 7; $wgMinimalPasswordLength = 1;


 * Well, if you have an attribute in LDAP that is the same as the real name, then yes, it is possible. For instance, if the entry's cn value is "John Smith", you can change:


 * $wgLDAPSearchAttributes = array( " "=>"uid" );


 * to:


 * $wgLDAPSearchAttributes = array( " "=>"cn" );


 * This way, the user can log in with "John Smith" instead of "johns". Also, btw, if you don't want to use encryption, set:


 * $wgLDAPEncryptionType = array( " "=>"false" );


 * to:


 * $wgLDAPEncryptionType = array( " "=>"clear" );


 * The plugin defaults to TLS encryption if the setting isn't defined, or if it is set to an incorrect value (for protection purposes). However, if this is working for you, set that to "tls", or remove the entry, since TLS is much better than clear. --Ryan lane 22:41, 30 June 2007 (UTC)

LDAPAuth for 1.10?
I try to use LDAPAuth for MediaWiki 1.10... it works with

$wgLDAPEncryptionType = array("D Name"=>"clear");

but not with

$wgLDAPEncryptionType = array("D Name"=>"ssl");

I get Failed to bind as xxusernamexx when I use ssl... - any idea?


 * Ok - it works fine ;) I forgot the LDAP-Cert :-/ -- 07:57, 24 May 2007


 * I am using LDAPAuth and MediaWiki 1.10 and am still having issues when I have $wgLDAPEncryptionType = array("D Name"=>"ssl");

I have the LDAP-cert imported and working as far as I see. Here is an example of my config

require_once( 'LdapAuthentication.php' ); $wgAuth = new LdapAuthenticationPlugin; $wgLDAPDomainNames = array( "test" ); $wgLDAPServerNames = array( "test"=>"ad.test.lan" ); $wgLDAPEncryptionType = array ( "test"=>"ssl" ); $wgLDAPSearchAttributes = array ("test"=>"sAMAccountName" ); $wgLDAPBaseDNs = array ("test"=>"dc=test,dc=lan" ); $wgLDAPSearchStrings = array ("test"=>"TEST\\USER-NAME" ); $wgLDAPProxyAgent = array ("test"=>"cn=user,ou=test,dc=asynchrony,dc=lan" ); $wgLDAPProxyAgentPassword = array ("test"=>"password" ); $wgLDAPRetrievePrefs = array( "test"=>"true" ); $wgMinimalPasswordLength = 1; $wgLDAPDebug = 3;

I get Binding as the user and than Failed to bind as username. If I don't use ssl everything works fine......HELP! -- 27 Aug 2007


 * Are you sure SSL is enabled on your AD server? Does your web server trust the AD server's CA? Does the fully qualified hostname of the AD server match the CN on the certificate? Try using TLS instead of SSL, it should die in the connect method instead of the authenticate method. To see the error messages coming from the LDAP calls, remove the "@" character from before the function calls; the errors should show up in your web server or php error logs.


 * I recommend testing using a command like:
 * ldapsearch -Z -x -D "username@DOMAIN" -W -b "dc=YOUR,dc=DOMAIN" -H ldap://ad.test.lan (sAMAccountname=*)
 * (notice that -Z tells the command to use startTLS, if you want to try it using ldaps, remove the -Z, and change ldap://ad.test.lan to ldaps://ad.test.lan) --Ryan lane 00:33, 28 August 2007 (UTC)

PHP warnings
With the latest version on MW 1.10 getting the following PHP warnings: [Mon May 28 21:59:59 2007] [error] [client ...] PHP Notice: Undefined index:  wsDomain in ..../extensions/LdapAuthentication/LdapAuthentication.php on line 669, referer: http://.../w/Special:Preferences [Mon May 28 21:59:59 2007] [error] [client ...] PHP Notice: Undefined index:  wsDomain in .../extensions/LdapAuthentication/LdapAuthentication.php on line 673, referer: http://.../w/Special:Preferences [Mon May 28 21:59:59 2007] [error] [client ...] PHP Notice: Undefined index:  wsDomain in .../extensions/LdapAuthentication/LdapAuthentication.php on line 677, referer: http://.../w/Special:Preferences This comes from a failure to check for isset($_SESSION['wsdomain']) in the relevant code (3 spots I've found).

I just finished setting up LdapAuthentication.php version 1.1e with MediaWiki 1.93. After getting the login to work with TLS & SSL to work and the debug info turned on, I see these warnings after successful login:

... Notice: Undefined index: mail in /var/www/wiki/mediawiki-1.9.3/extensions/LdapAuthentication.php on line 354 Notice: Undefined index: preferredlanguage in /var/www/wiki/mediawiki-1.9.3/extensions/LdapAuthentication.php on line 355 Notice: Undefined index: displayname in /var/www/wiki/mediawiki-1.9.3/extensions/LdapAuthentication.php on line 356 Notice: Undefined index: cn in /var/www/wiki/mediawiki-1.9.3/extensions/LdapAuthentication.php on line 357 Retrieved:, , , ...

Lines 354-357 contain: $this->email = $info[0]["mail"][0]; $this->lang = $info[0]["preferredlanguage"][0]; $this->nickname = $info[0]["displayname"][0]; $this->realname = $info[0]["cn"][0];

The warnings go away if I remove the setting for $wgLDAPRetrievePrefs.


 * This should be fixed in 1.1f (currently in SVN, but stable) --Ryan lane 13:18, 20 August 2007 (UTC)

Real AD Group Synch
I needed a real Group Sync to get the LDAP Extension work with the "Group_Based_Access_Control" Extension. I wrote this method and add it to the Class. I call in in the "authenticate" method. It does a real syncronize between AD Group Membership and the Wiki UserGroups. (Note: The Group Name size is limited by wiki database)

04.06.07 by Punisher: [mailto:punisher@e-workstation.de E-Mail]

function syncGroups($username){ $aLDAPGroups = $this->userLDAPGroups; $userID = User::idFromName($username);

if(($userID == 0)||(count($aLDAPGroups)== 0)) return; $u = User::newFromName($username); $aOldGroups = $u->getGroups;

// Adding new Groups for($i=0;$iaddGroup($aLDAPGroups[$i]); }           // Remove old Groups for($i=0;$iremoveGroup($aOldGroups[$i]); }           }	    $u->saveSettings; return; }


 * Huh? I've tested the plugin against active directory, and it seems to sync groups just fine. Is there something specific not working in the plugin? --Ryan lane 22:32, 30 June 2007 (UTC)


 * I actually found a bug in group sync, thanks to bug reports from other users. You may want to try this again. --Ryan lane 13:17, 20 August 2007 (UTC)

Creating a sysop user after configuring LDAP
My WikiSysop user account seems to be locked out now that I've set up MediaWiki to use LDAP authentication and I can't create a WikiSysop user in our LDAP directory. Can I make my own LDAP username a sysop user somehow? The instructions under Adding WikiSysop seem to be for doing so before setting up LDAP; however, I've already gotten LDAP configured.


 * Nevermind, I found the instructions on the Help:Setting user rights in MediaWiki page and that helped me figure it out.

HTTP Basic Authentication
I modified the extension to use HTTP Basic Authentication, if available. I tried to make it be an AutoAuth plugin, like SSL Auth is in this extension now, but I'm willing to bet it's not 100% right. You'll find a diff against SVN trunk below.

Index: LdapAuthentication.php

=
====================================================== --- LdapAuthentication.php     (revision 22916) +++ LdapAuthentication.php     (working copy) @@ -56,7 +56,7 @@

function LdapAuthenticationPlugin { } - +       /**         * Check whether there exists a user account with the given name. * The name will be normalized to MediaWiki's requirements, so @@ -1587,6 +1587,11 @@ $wgHooks['PersonalUrls'][] = 'NoLogout'; /* Disallow logout link */ }                       break; +              case "http": +                      $wgAuth->printDebug( "Allowing http basic authentication.", 1 ); +                       $wgHooks['AutoAuthenticate'][] = 'HttpAuth'; /* Hook for magical authN */ +                       $wgHooks['PersonalUrls'][] = 'NoLogout'; /* Disallow logout link */ +                      break; default: $wgAuth->printDebug( "Not using any AutoAuthentication methods.", 1 ); } @@ -1597,6 +1602,98 @@       $personal_urls['logout'] = null; }

+function HttpAuth(&$user){ +      global $wgUser; +      global $wgAuth; +      global $wgLDAPHttpDomain; +      $wgAuth->printDebug( "Entering HttpAuth.", 1 ); +      $wgAuth->printDebug( "PHP_AUTH_USER = " . $_SERVER['PHP_AUTH_USER'], 1 ); +      $wgAuth->printDebug( "PHP_AUTH_PW = " . $_SERVER['PHP_AUTH_PW'], 1 ); +      $wgAuth->printDebug( "wgLDAPHttpDomain = " . $wgLDAPHttpDomain ,1 ); +      $wgAuth->setDomain($wgLDAPHttpDomain); + +      //Give us a user, see if we're around +      $tmpuser = User::newFromSession; + +      //They already with us? If so, quit this function. +      if( $tmpuser->isLoggedIn ) { +              $wgAuth->printDebug( "User is already logged in.", 1 ); +              return; +      } + +        //Let regular authentication plugins configure themselves for auto +       //authentication chaining +       //$wgAuth->autoAuthSetup; + +      $authenticated = $wgAuth->authenticate( $_SERVER['PHP_AUTH_USER' ], $_SERVER['PHP_AUTH_PW'] ); +      if ( !$authenticated ) { +                      //If the user doesn't exist in LDAP, there isn't much reason to +                       //go any further. +                      $wgAuth->printDebug("User wasn't found in LDAP, exiting.", 1 ); +                      return; +              } +       if ( $tmpuser == null ) { +              $wgAuth->printDebug( "Username is not a valid MediaWiki username.", 1 ); +              return; +      } + +       //We need the username that MediaWiki will always use, *not* the one we +       //get from LDAP. +      $mungedUsername = $wgAuth->getCanonicalName( $_SERVER['PHP_AUTH_USER' ] ); + +      $wgAuth->printDebug( "User exists in LDAP; finding the user by name in MediaWiki.", 1 ); + +      //Is the user already in the database? +      $tmpuser = User::newFromName( $mungedUsername ); + +      if ( $tmpuser == null ) { +              $wgAuth->printDebug( "Username is not a valid MediaWiki username.", 1 ); +              return; +      } + +       //If exists, log them in +       if( $tmpuser->getID != 0 ) { +              $wgAuth->printDebug( "User exists in local database, logging in.", 1 ); +              $wgUser = &$tmpuser; +              $wgAuth->updateUser( $wgUser ); +              $wgUser->setCookies; +              $wgUser->setupSession; +              return; +      } +       $wgAuth->printDebug( "User does not exist in local database; creating.", 1 ); + +      //Require SpecialUserlogin so that we can get a loginForm +      require_once( 'SpecialUserlogin.php' ); + +      //This section contains a silly hack for MW +       global $wgLang; +      global $wgContLang; +      global $wgRequest; +      if( !isset( $wgLang ) ) +      { +               $wgLang = $wgContLang; +              $wgLangUnset = true; +      } + +       $wgAuth->printDebug( "Creating LoginForm.", 1 ); + +      //This creates our form that'll let us create a new user in the database +      $lf = new LoginForm( $wgRequest ); + +      //The user we'll be creating... +      $wgUser = &$tmpuser; +      $wgUser->setName( $wgContLang->ucfirst( $mungedUsername ) ); + +      $wgAuth->printDebug( "Creating User.", 1 ); + + +      //Create the user +      $lf->initUser( $wgUser ); + +      //Initialize the user +      $wgUser->setupSession; +      $wgUser->setCookies; +} + /** * Does the SSL authentication piece of the LDAP plugin. *


 * This, or something very similar, will be added to 1.1g (or 1.2a if I think the changes made are large enough for a major number release). Thanks for the patch! --Ryan lane 13:15, 20 August 2007 (UTC)
 * Thanks. I'm looking forward to that new version.

Problems authenticating usernames with underscore character(s)
I installed the LDAP Auth extension and have it working in MediaWiki 1.7.1 and Windows 2003 Server. The problem I have is that authentication does not work with usernames that include an underscore ("_"). After googling around, it looks like it is normal for MediaWiki to convert underscores ("_") to spaces (" "). Is there any workaround for this? Or, will I have to make sure any AD user that needs Wiki access has a username without any underscores? :( Please see my included debug output below... Anyone else have this issue :)? Your help is appreciated! Entering validDomain User is using a valid domain. Setting domain as: exampledomain Entering getCanonicalName Username isn't empty. Munged username: Wiki user Entering authenticate Entering Connect Using TLS or not using encryption. Using servers: ldap://ad0.exampledomain.org Connected successfully Entering getSearchString Doing a straight bind userdn is: exampledomain\Wiki user Binding as the user Failed to bind as exampledomain\Wiki user Entering strict. Returning true in strict. Entering modifyUITemplate

Reeboblue 20:32, 13 June 2007 (UTC) [mailto:reeboblue@yahoo.com E-Mail]


 * Well, the plugin doesn't currently support this. You may be able to add support for this into the authentication method, similar to how the plugin allows users to lowercase the username. Thing is, no matter what, you can either have users that have underscores, or spaces, not a mix of the two, because the wiki is always going to change underscores to spaces. The plugin unfortunately has no way of changing that. Sorry I couldn't be more help. --Ryan lane 22:30, 30 June 2007 (UTC)

Returned Groups not returning my Returned groups :)
I'm having a similar problem as the "Nested Groups option not working" guy. Ldapauthentication.php works fine prior to adding group based restrictions. When I add the "#group based auth" section to my config, AD users in the allowed group can no longer authenticate. However, the users that logged in prior to group based restriction were added to the users mySQL table and they can still successfully authenticate although they are no longer in the allowed group.

cat LdapAuthentication.php | grep "'version'" 'version' => '1.1f (alpha)',

Here is my conf: require_once( "includes/LdapAuthentication.php" ); $wgAuth = new LdapAuthenticationPlugin; $wgLDAPDomainNames = array( "DOMAIN" ); $wgLDAPServerNames = array( "DOMAIN"=>"frodo.domain.com legolas.domain.com" ); //this place is run by true geeks $wgLDAPSearchStrings = array( "DOMAIN"=>"DOMAIN\\USER-NAME" ); $wgLDAPUseSSL = false; //not recommended but OK for testing $wgLDAPEncryptionType = array( "DOMAIN"=>'clear' ); // this is needed in >= 1.1c $wgLDAPUseLocal = true; //allows mysql db driven auth (default Root user) $wgMinimalPasswordLength = 1; $wgLDAPRetrievePrefs = true; $wgLDAPUpdateLDAP = array( "DOMAIN"=>"false" ); //disables mediawiki from updating LDAP $wgLDAPDebug = 3; //debugging $wgLDAPBaseDNs = array( "DOMAIN"=>"dc=domain,dc=com" ); $wgLDAPRequiredGroups = array( "DOMAIN"=>array("cn=wiki-sysops,dc=group,dc=domain,dc=com") ); $wgLDAPGroupUseFullDN = array( "DOMAIN"=>true ); $wgLDAPGroupObjectclass = array( "DOMAIN"=>"group" ); $wgLDAPGroupAttribute = array( "DOMAIN"=>"member" ); $wgLDAPGroupSearchNestedGroups = array( "DOMAIN"=>false ); $wgLDAPSearchAttributes = array( "DOMAIN"=>"sAMAccountName" );
 * 1) LDAP FUN!!!
 * 1) $wgLDAPRetrievePrefs = array( "DOMAIN"=>false ); // this is needed in >= 1.1c
 * 1) group based auth

Here is the debug log:

Entering validDomain User is using a valid domain. Setting domain as: SMP-INC Entering getCanonicalName Username isn't empty. Munged username: Wiki-user Entering userExists Entering authenticate Entering Connect Using TLS or not using encryption. Using servers: ldap://frodo.smp-inc.com ldap://legolas.smp-inc.com Connected successfully Entering getSearchString Doing a straight bind userdn is: SMP-INC\Wiki-user Binding as the user Binded successfully Entering getUserDN Created a regular filter: (sAMAccountName=Wiki-user) Using base: dc=smp-inc,dc=com Fetched username is not a string (check your hook code...). Pulled the user's DN: CN=wiki-user,CN=Users,DC=smp-inc,DC=com Checking for (new style) group membership Entering isMemberOfRequiredLdapGroup Required groups:cn=wiki-sysops,dc=group,dc=smp-inc,dc=com Entering getUserGroups Entering getGroups Search string: (&(member=CN=wiki-user,CN=Users,DC=smp-inc,DC=com)(objectclass=group)) Returned groups:cn=wiki-sysops,cn=users,dc=smp-inc,dc=com Returned groups: Couldn't find the user in any groups (2). Entering modifyUITemplate Allowing the local domain, adding it to the list.

Look at my 2 lines that start with "Returned groups:". It appears that the search string is returning results, however it's not listing the groups. When there are multiple groups, the second Returned Groups: line has a bunch of commas, ie:

Returned group:,,,,,,,,

When I turn on nested groups, it also cycles the same groups multiple times. I've read this has happened to other users as well. 6/26/07 15:45 PST

EDIT-i had the wrong OU defined. this has been resolved.

Allow certain department numbers
How would I do a search for department number ("departmentnumber") or a group of them in LDAP and restrict the login using those numbers? Thanks


 * If you want to limit login by an attribute like department number, you can use search based options, like so:

$wgLDAPRequireAuthAttribute = array( "mydomain"=>true ); $wgLDAPAuthAttribute = array( "mydomain"=>"departmentnumber=331" );


 * Say for instance, you wanted to have multiple department numbers, you could use the following syntax:

$wgLDAPRequireAuthAttribute = array( "mydomain"=>true ); $wgLDAPAuthAttribute = array( "mydomain"=>"|(departmentnumber=331)(departmentnumber=332)(departmentnumber=333)" );


 * Pretty much any valid LDAP filter works; notice however, that the plugin wraps around the filter (I'll try to fix this in the future in a backwards-compatible way), so make sure you take that into account.


 * As for groups, you can define groups however you like in LDAP, and then use group based login restrictions to limit users by group.


 * Btw, I didn't notice your post earlier because you stuck the question at the top. Please stick all new support requests at the bottom of the page. --Ryan lane 20:42, 9 July 2007 (UTC)

Passwords using §
Any user who uses a § in his password cannot login. Mediwiki is claiming that the password is wrong or has not been entered. Can I change that? Thanks


 * Does this work with LDAP Authentication turned off? I need to know if it is MediaWiki causing the problem, or the plugin. --Ryan lane 13:27, 30 July 2007 (UTC)

Local Username Munging and Local User Creation
Two issues:

Local Usernames are Munged
If you enable local authentication in addition to the LDAP auth, all usernames are still munged, which causes previously created local MW user accounts with upper-case letters in the middle of them to be unusable (i.e. StatBot). Moving the strtolower call in to the if {} block that runs only for DOMAIN logins resolves this issue.


 * Hmm, I never thought of this... (I haven't used local accounts since I transitioned to LDAP). I'm putting this on the todo list. --Ryan lane 13:30, 30 July 2007 (UTC)


 * I ran into the same problem today. Here's the fix:

Index: LdapAuthentication.php

=
====================================================== --- LdapAuthentication.php     (revision 23725) +++ LdapAuthentication.php     (working copy) @@ -964,15 +964,15 @@                       if ( $this->LDAPUsername != '' ) { $this->printDebug( "Using LDAPUsername.", self::NONSENSITIVE ); $username = $this->LDAPUsername; + +                              //Change username to lowercase so that multiple user accounts +                              //won't be created for the same user. +                              $username = strtolower( $username ); + +                              //The wiki considers an all lowercase name to be invalid; need to +                               //uppercase the first letter +                              $username[0] = strtoupper( $username[0] ); } - -                      //Change username to lowercase so that multiple user accounts -                      //won't be created for the same user. -                      $username = strtolower( $username ); - -                      //The wiki considers an all lowercase name to be invalid; need to -                       //uppercase the first letter -                      $username[0] = strtoupper( $username[0] ); }

$this->printDebug( "Munged username: $username", self::NONSENSITIVE );
 * Almost - The line
 * $username[0] = strtoupper( $username[0] );
 * needs to be outside the IF loop - local Wiki accounts still need to have the first character capitalized - otherwise users who enter their uname all lowercase in Special:Userlogin will not be able to login locally. Only the strtolower call should be inside the if LDAP block.

Local Users are created with a blank "user_password" field
Only Domain user accounts should have a blank user_password field - Local users need to have the standard MW password hash. As-is, any local accounts created are unusable.


 * This bug must have creeped in recently. I know for sure that at some point in the past this was working properly. It sounds like I need to make some unit tests... I'm adding this to the todo list. --Ryan lane 13:30, 30 July 2007 (UTC)
 * ty. btw, great extension.  We use it on our Internal HelpDesk wiki against a W2k3 AD at St. Cloud State University.  (btw, haven't updated the works on area yet - we're runing MediaWiki 1.10.1 / PHP 5.2.0-8+etch7 apache2handler / MySQL 5.0.32-Debian_7etch1-log --Tim Laqua 14:55, 30 July 2007 (UTC)


 * Unless I'm mistaken, this bug duplicates the allowPasswordChange doesn't check for $wgLDAPUseLocal bug which is described (and patched) elsewhere on this page. I applied the Christian's suggested patch under that heading, and it appears to have more-or-less solved the problem with missing passwords for locally-created users. (As an aside, however, I'll note that it would be nice if the Domain dropdown list on the create account page didn't show the LDAP domain if remote password creation isn't enabled for LDAP.) --Dmdwiggi 20:46, 14 August 2007 (UTC)

Fixed in SVN
I've fixed both of these in SVN. Can you test it out to see if the fixes did in fact fix your problem?

getCanonicalName fix for Local and AD users
I downloaded the latest version from SVN and I noticed this addition in getCanonicalName :

if ( !isset( $wgLDAPUseLocal ) || !$wgLDAPUseLocal ) { //Change username to lowercase so that multiple user accounts //won't be created for the same user. $username = strtolower( $username ); }

I believe that is a clever step ahead in the solution of this issue.

The condition tested, thou, tests a "constant" for what concerns LdapAuthentication.php, since $wgLDAPUseLocal never changes its value given in LocalSettings.php

This test doesn't help those wikis that use both local (SysOps and Bots with a capital letter in the middle) and AD accounts (case insensitive).

I thought to modify the test condition this way:

if ( isset($_SESSION['wsDomain']) && 'local' != $_SESSION['wsDomain']) { //Change username to lowercase so that multiple user accounts //won't be created for the same user. $username = strtolower( $username ); }

This way I can have $wgLDAPUseLocal == True.

When I select the Local domain, I skip this test and capitalize the first letter without changing the rest. (done in the rest of the code not re-written here)

When I select one AD domain, I lowercase the user name, that for some reason arrives in getCanonicalName still with mixed lowers and caps.

I was curious to know why $this->LDAPUsername doesn't get set in my wiki configuration... that's why I made this change.

Giovanni 02:50, 22 August 2007 (UTC)


 * Ah, good catch. That most likely is the best logic. Its in SVN now. --Ryan lane 04:01, 23 August 2007 (UTC)

AD Group usage help
Hi, I need some help on how to set up this extension in the following way: we have two AD groups, for example "WikiUsers" and "WikiAdmins". I want to restrict the the usage of the Wiki for these groups, i.e.
 * If a user is in neither group, he cannot access the Wiki at all (well, except the main page and the login page)
 * If a user is in WikiUsers, he should get read access to all wiki pages (and, if possible, r/w access to his own userpage and to all talk pages)
 * If a user is in the WikiAdmin group, he has "full" rights to view/edit the wiki (obviously still restricted by "blocked" pages or the like)

Anyone care to give me a quick howto on how to set up the wiki like that? I'm an LDAP newbie, so any help would be much appreciated. I guess I need to create the respective groups in the wiki and map the two AD group to them, then set $wgGroupPermissions accordingly?


 * Yep, that would be it. I'm not sure if it possible to restrict edit access like you would like to do with WikiUsers, but I could be wrong. That is more of a MediaWiki permissions thing. --Ryan lane 19:02, 6 August 2007 (UTC)

AD/LDAP and wgGroupPermissions and Group Name length
I've created a group in my AD called "Wiki Administrators", and given that group sysop permisions with this line: $wgGroupPermissions['Wiki Administrators'] = $wgGroupPermissions['sysop'];

This doesn't work, because the DB schema allows only 16 chars in the Group name. I am added to the "Wiki Administ" group, which doesn't match, so I am not a sysop.

A work around for this was to shorten the name to Wiki Admins, but the DB schema should allow longer names or the LDAP Auth module should match in a different way.


 * I don't disagree, but this is a MediaWiki core thing. I've asked the developers before, but didn't get much of a positive response (schema changes are somewhat of a big thing). --Ryan lane 19:04, 6 August 2007 (UTC)


 * I'll take a look into making it match a different way (or I'll talk to the developers again). --Ryan lane 19:28, 6 August 2007 (UTC)

User gets added to groups, but is never removed
I am using the $wgLDAPUseLDAPGroups feature. At first, everything works fine... Users are being added to the MW Database, MW Groups are created, and users are put into groups, all according to LDAP. Now: When i Remove a user from a group in LDAP, it stays in all the groups in MW. I found that this is a bug in the code: $this->printDebug("Checking to see if we need to remove user from: $cGroup",1);                                if ((!$this->hasLDAPGroup($cGroup)) && ($this->isLDAPGroup($cGroup))) { $this->printDebug("Removing user from: $cGroup",1);

The Fixed line would be:                                if ((!$this->hasLDAPGroup($cGroup)) && (!$this->isLDAPGroup($cGroup))) {

I Am using the Version 1.1e right now, but found that the bug is still existent in 1.1f alpha. Keep the good work up, this Extension is GREAT!

Cheers: Thomas Gruber --17:52, 7 August 2007 (UTC)


 * Hmm, actually I'm not sure that is a bug. The logic looks correct; well, I actually do see a problem, but not what you are describing. Turn on debugging, and make sure that the "getAllGroups" function is returning your groups. If it isn't then the plugin can't remove the user from the group, because it leaves non-ldap mediawiki groups alone.


 * Which of course causes a bug I just noticed. If you delete a group from LDAP, that group still exists in mediawiki, and the plugin can't sync it (and hence, can't remove the user from the group). --Ryan lane 21:50, 7 August 2007 (UTC)


 * Hi there, i got the following from the Debug output:

Available groups are: bot,sysop,bureaucrat,global-it
 * When i remove a user from a group, it IS displayed correctly when returning the groups for LDAP, but the user is not removed from the Group in MW - oh and BTW: This is a AD I am trying to use. Thomas Gruber - 13:49, 8 August 2007 (UTC)


 * Well, thats the available mediawiki groups. Look for this string "Returned groups:", after seeing "Entering getAllGroups". Btw, can you post your configuration with all sensitive stuff snipped out? --Ryan lane 02:04, 9 August 2007 (UTC)


 * Hi again, sorry, that i did not answer a long time. Had Holidays :-). I pasted the Config and the complete Debug output (debug 3) into a file on my server. I think this would definately be too big (and this article is long enough already) -> http://tuxpower.org/~virusmaster/mediawiki-ldap-bug - at the moment i have the problem, that i cannot recheck the problem now, since i do not have access to the AD Server atm. But in the debug output i see no "Entering getAllGroups" which would indicate, that the function is never called in the first place.
 * --ThomasGruber 13:11, 10 September 2007 (UTC)


 * Actually, it looks like it isn't finding the user in any groups. If it doesn't find your user in a required group, it won't synchronize groups at all. You need to get group restriction working before you worry about group synchronization. Please upgrade to the newest plugin release; there is a bug in the version you are using that may be causing the issue. --Ryan lane 16:56, 10 September 2007 (UTC)

--ThomasGruber 13:16, 8 January 2008 (UTC)
 * Hi, yes i am still alive ;-) I just wanted to tell you, that with the version 1.1g of AuthLDAP it works flawlessly... but i got another thingie... for this i'll open up another 'call'

Any DLL Files needed?
I am using Mediawiki 1.9 running it on an XAMPP server on Windows XP. My LDAP is not working at all even after pasting the code from the configuration link from mediawiki help. Do i need to copy any ".dll" into the system32 folder in order to make it working?

Also, including LdapAuthication.php and making changes in the LocalSettings.php is all i need to make to LDAP running right ?

I need simple Authentication from my LDAP server as to confirming username and password. What all codes do i need to paste in the respective .php files Please help me on this .. thanks.

Also,When i click on Login button,nothing happens and a blank screen come up. Frustration creeping in.

--220.225.64.6 07:30, 9 August 2007 (UTC)


 * I don't use XAMPP (and never have before). I also never use apache/php/mysql on Windows. Unless the current documentation on the content page can help, there is nothing I can do for you. Honestly, a little googling on your side is probably a good idea. I know there have got to be other people who have had to have ldap and ssl working with php on windows before.


 * Maybe someone else here can help you out? --Ryan lane 14:05, 9 August 2007 (UTC)


 * Thanks Ryan.. i have reached to the final step now .. things working now .. the error now coming is "start-tls]: Unable to start TLS: Server is unavailable in C:\xampp\htdocs\mediawiki\includes\LdapAuthentication.php on line 165" Though i am able to ping my LDAP normaly through the command prompt.


 * Also, how to get this contents block on the top of every page ? --Ankit.madan 07:21, 10 August 2007 (UTC)


 * Can you post your configuration, with sensitive stuff snipped out? --Ryan lane 14:03, 13 August 2007 (UTC)


 * Thanks for helping me on this Ryan

The LocalSetting.php is as follows: $wgGroupPermissions['*']['edit'] = false; $wgGroupPermissions['user']['edit'] = true;


 * 1) Prevent new registrations from anonymous users (Sysops can still create new account)

$wgGroupPermissions['*']['createaccount'] = false;


 * 1) Define the pages un-authenticate users can see. This is crucial.
 * 2) Otherwise, there's no way for people to login.

$wgWhitelistRead = array( "Main Page","Special:Userlogin","-","MediaWiki:Monobook.css"); $wgGroupPermissions['*']['read'] = false;


 * 1) Authenticate users from an Active Directory.

require_once('LdapAuthentication.php'); $wgAuth = new LdapAuthenticationPlugin; $wgLDAPDomainNames = array( "ASDF" ); $wgLDAPServerNames = array( "ASDF"=>"10.76.122.2"); $wgLDAPUseSSL = false; $wgLDAPUseLocal = false; $wgLDAPAddLDAPUsers = false; $wgLDAPUpdateLDAP = false; $wgLDAPMailPassword = false; $wgLDAPRetrievePrefs = true; $wgMinimalPasswordLength = 1; $wgLDAPSearchStrings = array( "ASDF"=>"ASDF\\USER-NAME" );

I have pasted the .dll files and made changes to the php.ini in the apache/bin folder as that is the path shown in http://localhost/xampp/phpinfo.php under Loaded Configuration File. The Line 165 in LdapAuthentication.php is 		//TLS needs to be started after the connection is made if ( $encryptionType == "tls" ) { $this->printDebug("Using TLS",2); //165-->	ldap_start_tls($ldapconn); }

return $ldapconn;


 * Please take a look at the official documentation... Most of your configuration settings are invalid. I swear. I have no clue where these old configuration settings are at, but when I find them, all of them are getting deleted, or I'm going to bitch at the person hosting them. This is a pretty common problem...


 * Notice that since you are not using the correct config setting for encryption that TLS is going to be used. Also, you should use the AD server's fully qualified domain name, not its IP address. If you ever plan on using TLS/SSL, the server's certificate name needs to match the server name used, and the client must trust the CA that signed the certificate. Encryption is generally a good idea if you can get it working. --Ryan lane 01:02, 16 August 2007 (UTC)


 * Oops.. i just got it after searching for LDAP+Mediawiki+Windows :)

To be frank documentation is pretty confusing.Which part of it should i use ?There are so many Code Snippets here that i dont know which one to use ! I'm running it on Windows XP,PHP 5.2.3(XAMPP Server),Mediawiki 1.9.3,LdapAuthentication v 1.1d There is no specific documentation for Windows XP. --Ankit.madan 03:57, 16 August 2007 (UTC)


 * The documentation isn't OS dependent. It is LDAP server dependent for the most part. Look at the configuration examples, and use the one that fits your environment. If you are using AD, and only have a single domain, use Extension:LDAP Authentication/Configuration Examples.


 * Notice that the main documentation page's explanation of options should be used to ensure that the options you are using have the correct syntax, and do what you expect them to do.


 * Also notice that there is user provided information about how to configure windows Extension:LDAP Authentication. I don't use Windows as a web server (Linux is free after all, and I use OSX as my main desktop...), so it is hard for me to provide documentation on how to configure Apache/PHP/MySQL/OpenLDAP/MediaWiki on that platform; honestly, it is a little out of the scope of this documentation. If a user is kind enough to provide precise documentation after doing it, I wouldn't mind having an entire section devoted to it in the documentation, I'm just not likely to ever write it. Ryan lane 13:40, 17 August 2007 (UTC)

Yet another preferences problem
It seems I can authenticate as a domain user, but on Special:Preferences, email and real name are empty. I'm running Apache2, PHP5, MediaWiki 1.7, LdapAuthentication 1.1d.

LocalSettings.php:

require_once( 'LdapAuthentication.php' ); $wgAuth = new LdapAuthenticationPlugin; $wgLDAPRetrievePrefs = true; $wgLDAPDebug = 4; $wgLDAPDomainNames = array( "DOMAIN" ); $wgLDAPServerNames = array( "DOMAIN"=>"pdc.domain.edu" ); $wgLDAPSearchStrings = array( "DOMAIN"=>"DOMAIN\\USER-NAME" ); $wgLDAPEncryptionType = array( "DOMAIN"=>"false" ); $wgLDAPUseLocal = false; $wgMinimalPasswordLength = 1; $wgLDAPBaseDNs = array( "DOMAIN"=>"dc=domain,dc=edu" ); $wgLDAPSearchAttributes = array( "DOMAIN"=>"sAMAccountName" ); $wgLDAPAddLDAPUsers = false; $wgLDAPUpdateLDAP = false; $wgLDAPMailPassword = false;

And the debug output:

Entering validDomain User is using a valid domain. Setting domain as: Domain Entering getCanonicalName Username isn't empty. Munged username: Jscott Entering authenticate Entering Connect Using TLS or not using encryption. Using servers: ldap://pdc.domain.edu Connected successfully Entering getSearchString Doing a straight bind userdn is: DOMAIN\Jscott Binding as the user Binded successfully Entering getUserDN Created a regular filter: (sAMAccountName=Jscott) Using base: dc=domain,dc=edu Fetched username is not a string (check your hook code...). Pulled the user's DN: CN=Jason Scott,OU=Techs,DC=domain,DC=edu Authentication passed Entering updateUser


 * Please read the documentation. Most of your configuration options are wrong. Almost every configuration option is specified with the domain in question. Specifically, you do not have "$wgLDAPRetrievePrefs" set correctly, and the plug-in considers this to be set to false. BTW, options are set to false by default, so explicitly setting options to false isn't necessary. --Ryan lane 13:56, 13 August 2007 (UTC)

MS LDAP Authentication from LAMP setup
is MS Active Directory domain authentication possible using LAMP? Specifically can i use Linux/Apache to authenticate users on MS active directory? I dont have the possibility to install wiki on IIS/windows however i am using MS Active Directory. I tried some configs but logging always fails.


 * Yep. This is supported. I'd imagine a decent amount of people are doing this. Notice that AD will not allow unencrypted binds by default. AD requires the use of some type of encryption (which is kerberos by default -- unfortunately the plugin doesn't currently support kerberos authentication). If your AD server does not have an SSL certificate installed, TLS/SSL binding is not possible, and will cause logins to fail. Turn on debugging to see if encryption is the issue. Also notice that openldap by default will require the AD server's certificate to be trusted, and the server name to match the certificate name. Please see the appropriate PHP/openldap documentation to enable this correctly; if you don't care about the trust, and only care about the encryption, you can turn off the trust setting in openldap. Notice that information on how to do this is in the user provided information section of this article. --Ryan lane 14:01, 13 August 2007 (UTC)

Connecting to Global Catalog
I have gotten the extension working and authenticating using AD, but I wonder how to connect to the global catalog to authenticate. I would assume from the debug log that the connections use the standard ldap (389) and ldaps (636) ports. I saw a reference to the GC in the documentation but never how to actually connect (if I missed it, my apologies). When I add the :3269 (port for secure GC connections) to the server name it no longer allows me to bind. We have a main domain, and then several sub-domains. For instance, sub1.domain.com, sub2.domain.com... Also each subdomain then has several DC's. My problem is that only the GC can authenticate people from sub1, sub2, sub3, etc...  I can't list the servers from the other subdomains because I don't have the privileges to connect. Is there a way to choose the port to connect to or am I going about this wrong?? --Ctbarber 16:05, 14 August 2007 (UTC)


 * The global catalog is the AD server that hosts it. You will still use either port 389 or 636. AD should take care of the rest for you. --Ryan lane 00:56, 16 August 2007 (UTC)

Restricting groups from AD
Is it possible to restrict the groups the are pulled into mediawiki from an AD other that by using the GroupBaseDN?

The problem is that we have a large AD that contains many groups which have the same CN and the sAMAccountNames of these groups is not unique within the first 16 characters.

What I would like to be able to do is name a group in the AD that contains the groups that I would like mediawiki to pull in. Preferably it would pull all the sub groups as well. I have modified the code so getAllGroups just returns the groups I want but I still need to restrict the groups the user is in to those returned by getAllGroups based on the long name (DN).


 * You'll have to come up with some method of doing this. If your group names aren't unique within the first 16 characters, mediawiki won't be able to tell the difference. As I mentioned elsewhere on this page, I'll take a look into trying to get the character limit increased.--Ryan lane 13:13, 21 August 2007 (UTC)


 * I've talked with the core code developers, and there is now a bug in bugzilla regarding it. I'm hoping it'll be put in place for 1.12. --Ryan lane 16:51, 4 October 2007 (UTC)

Updated to MediaWiki 1.10, cant create new users
I updated from MediaWiki 1.7.1 to 1.10.1. When a new user tries to login, the following error appears: .. .. Authentication passed Entering setPassword Wiki is set to not allow updates

Internal error There was either an external authentication database error or you are not allowed to update your external account. ..

Now with the update, I assume localsettings.php and LDAPauthentication.php should not have been changed. That is those files remain the same. Should something have been changed here? Should something in SpecialUserLogin.php be changed?

Thank you very much Polo 08:42, 23 August 2007 (UTC)

OK, fixed it!!

Edit the LDAAuthentication.php script

change $user->setPassword; to $user->mPassword; (round about line 695) change return false; to return true; in the else if path in the setPassword function. (round about line 367)

Polo 12:24, 23 August 2007 (UTC)


 * What version of the LDAP plugin are you using? This was fixed quite a while ago. You probably need to upgrade. --Ryan lane 16:53, 23 August 2007 (UTC)

I also had the exact same problem with mediawiki 1.11 and thankfully your suggested code changes resolved the issue. I tried the latest 3 versions of the plugin and all gave a 'password incorrect' error. Debugging showed the error 'unable to start tls'. reverting back to an old version of the plugin and making the suggested code changes suggested by polo resolved my issue. - Anna


 * Reverting back worked because the older versions didn't throw an error if tls failed, which is a very bad thing. Now you think you are using encryption, and you really aren't. You need to figure out why TLS failed. You can try SSL, and see if that works for you. Either way, reverting back isn't really a fix. --Ryan lane 16:45, 4 October 2007 (UTC)

Problem with ProxyAgent and LDAPWriter using encrypted passwords
The documentation shows storing the passwords for the Proxy Agent and LDAP Writer in the LocalSettings.php using SHA encryption. When I try to specify the passwords this way, I get errors on binding inside the  function (called from  ) and the   function. If I change the configuration to plain-text passwords, everything works properly.

I am using MediaWiki 1.10.0 on PHP 5.1.6, with LDAP Authentication Plugin 1.1e. Is there some configuration setting or step that I am missing to make SHA-encrypted passwords work?

Thanks... Pcorreia 19:18, 23 August 2007 (UTC)


 * I can't remember the last time I did this. I usually just use a user who has very few privileges. --Ryan lane 03:32, 24 August 2007 (UTC)

WikiSysop user
I've added a WikiSysop user to the LDAP server as directed, but when I log in as WikiSysop I don't have sysop privileges. As it turns out, when I log in as WikiSysop the first time after turning on LDAP authentication, a new user is created in the MediaWiki database named Wikisysop (note the lowercase 's'). This user does not have sysop privileges. I have tried it with  set to both true and false, and I get the same result both times. Here's my LDAP WikiSysop user:

dn: uid=WikiSysop,ou=ServiceAccounts,dc=mydomain,dc=net objectClass: account objectClass: simpleSecurityObject uid: WikiSysop description: Wiki administrator account userPassword: (withheld)

Am I missing something? Does anyone have this (a WikiSysop user in LDAP that automatically gets sysop privileges) working with MediaWiki 1.10.0 and LDAP Authentication Plugin 1.1e?

Pcorreia 20:10, 23 August 2007 (UTC)


 * Well, actually, I don't recommend putting WikiSysop in LDAP. I recommend creating a regular user with the LDAP plugin disabled, and giving it sysop and bureaucrat rights, then enabling the LDAP plugin. You can also turn on $wgLDAPUseLocal temporarily, and log in with WikiSysop and do the same. Essentially, once the plugin is enabled, WikiSysop is never used again. --Ryan lane 03:35, 24 August 2007 (UTC)

Scoping down LDAP search for (&(member=*)(objectclass=group))
Well, doing this search on our AD is suicide - we would NEVER want a list of all our LDAP groups - we have over 3000. So how about this patch that scopes the search down to all the user's LDAP groups (which will definately hit) and all existing MW local groups, pulled from $wgUser->getAllGroups - which should yield all groups that we could ever want to compare anything to for this particular session:


 * This is a good solution to the problem (...actually, it is far better than the solution I was thinking of). Thanks for the patch, I'll be including this in the next release. --Ryan lane 17:00, 10 September 2007 (UTC)


 * I believe I've fixed this problem in 1.1g. I actually didn't include the patch, but I've added $wgLDAPLocallyManagedGroups, which allows the plugin to not have to check to see if a group is an LDAP group or not. So, now getAllGroups is simply not called unless $wgLDAPGroupsPrevail is enabled, which doesn't need to be unless you are using one of those (insecure) access control plugins.


 * Notice that the default behavior of the group synch stuff slightly changed. bot, sysop, and bureaucrat (which are always considered to be part of $wgLDAPLocallyManagedGroups) will sync normally, but never have members removed (unless you remove them manually). All other groups that are not part of $wgLDAPLocallyManagedGroups will have members added/removed normally. --Ryan lane 21:19, 21 September 2007 (UTC)

Protest vote about lack of "auth" category?
Fair enough - and much appreciated. I don't really think LDAP (or any of the other security related extensions) belongs as an "interface" type either, but for now it was the only one that even maybe fit (no access --> no interface), and of course, that alone proves the point that we need some new categories. There is an on-going discussion at Template_Talk:Extension. Please feel free to add your ideas. Egfrank 14:21, 11 September 2007 (UTC)


 * It looks like there is a category called User identity, which contains all of the auth plugins. I think this is probably fine. --Ryan lane 18:54, 21 September 2007 (UTC)

Problem after update to 1.11
Hello,

I just updated MediaWiki to 1.11 and am having some problems with the LDAP extension. I just updated the extension to 1.1f. Here is a sample of my configuration (that worked on 1.10):


 * 1) BEGIN ALL LDAP CRAP

// Active Directory LDAP Authentication require_once( 'LdapAuthentication.php' ); $wgAuth = new LdapAuthenticationPlugin;

$wgLDAPDomainNames = array( "MYDOMAIN" ); $wgLDAPServerNames = array( "MYDOMAIN"=>"mydomaincontroller.mydomain.edu" ); $wgLDAPUseLocal = false; $wgLDAPEncryptionType = array( "MYDOMAIN"=>"clear" ); $wgLDAPRetrievePrefs = array( "MYDOMAIN"=>true ); //<- this is how to do it $wgMinimalPasswordLength = 8; $wgLDAPSearchStrings = array( "MYDOMAIN"=>"MYDOMAIN\\USER-NAME" ); //BINDING


 * 1) GROUP CRAP

$wgLDAPRequiredGroups = array( "MYDOMAIN"=>array("cn=wikiusers,ou=ntfs groups,ou=enterprise,dc=mydomain,dc=edu") ); $wgLDAPGroupUseFullDN = array( "MYDOMAIN"=>true ); $wgLDAPGroupObjectclass = array( "MYDOMAIN"=>"group" ); $wgLDAPGroupAttribute = array( "MYDOMAIN"=>"member" ); $wgLDAPGroupSearchNestedGroups = array( "MYDOMAIN"=>false ); $wgLDAPBaseDNs = array( "MYDOMAIN"=>"dc=mydomain,dc=edu" ); $wgLDAPSearchAttributes = array( "MYDOMAIN"=>"sAMAccountName" );
 * 1) DNs in $wgLDAPRequiredGroups must be lowercase, as search result attribute values are...

/** $wgLDAPUseSSL = true;   //Commented out because these options use syntax $wgLDAPUseLocal = false;    //for 1.0 and below (and are hence incorrect) $wgLDAPAddLDAPUsers = false; $wgLDAPUpdateLDAP = false; $wgLDAPMailPassword = false; $wgLDAPRetrievePrefs = true; */

//FOR DEBUGGING ONLY $wgLDAPDebug = 1; //for debugging $wgShowExceptionDetails = true; //for debugging MediaWiki

Now keep in mind the above worked fine in 1.10. After updating I get the error:

Incorrect password entered. Please try again.

I have had several people try their passwords and everyone gets the same message. When enabling debugging I get the following:

Entering validDomain User is using a valid domain. Setting domain as: MYDOMAIN Entering getCanonicalName Username isn't empty. Munged username: Acook001 Entering authenticate Entering Connect Missing LDAP support; please ensure you have either compiled LDAP support in, or have enabled the module. Failed to connect Entering strict. Returning true in strict. Entering modifyUITemplate

I'm not sure why it's saying: Missing LDAP support; please ensure you have either compiled LDAP support in, or have enabled the module. Any ideas?? Thanks!

HotMonkeyAC 16:36, 11 September 2007 (UTC)


 * Anyone still around in here?? HotMonkeyAC 16:13, 20 September 2007 (UTC)


 * I'm probably doing the check for the ldap module improperly... This is an issue with the plugin. You can comment out the return statement after the check in the code for now. In the next release I'll give a warning and won't cause the plugin to die (I'll try to figure out the proper way to detect the module too). --Ryan lane 19:00, 21 September 2007 (UTC)


 * Thanks for the reply Ryan. Do you happen to know where in the code I'd need to comment out?  Maybe you can provide a line number?  I'll let you know if it works.
 * -HotMonkeyAC 14:13, 25 September 2007 (UTC)


 * I changed this in 1.1g. If you upgrade, it should work for you. --Ryan lane 16:43, 4 October 2007 (UTC)

$domain Variable Empty?
I've been struggling to get this to move past the very first stage on my intranet wiki. I'm continuing to get these errors:

Entering validDomain User is not using a valid domain. Setting domain as: invaliddomain Entering modifyUITemplate

I added a "strlen($domain)" into the debugging code and it returned 0! I guess this means my $domain variable is empty. What does this mean? How do I fix this?


 * Does the login page have a selectable domain? If not, the plugin probably isn't configured properly. Post your config with sensitive stuff snipped out. --Ryan lane 19:02, 21 September 2007 (UTC)

Queries in Group Authentication
Hi Ryan,

I could do simple user authentication using LDAP.

But my aim was to authenticate and allow only a group of users to access the site. But i am unable to authenticate the user. Can you please tell me where am i going wrong.

The following is my code and the debug output.

$wgLDAPRequiredGroups = array( "domain"=>array("cn=group_admins,ou=groups,ou=abc,ou=bom,oc=ind,dc=ad,dc=abc,dc=com") ); $wgLDAPGroupUseFullDN = array( "ad.abc.com"=>true ); $wgLDAPGroupObjectclass = array( "ad.abc.com"=>"group" ); $wgLDAPGroupAttribute = array( "ad.abc.com"=>"member" ); $wgLDAPGroupSearchNestedGroups = array( "ad.abc.com"=>true ); $wgLDAPGroupNameAttribute = array( "ad.abc.com"=>"cn" )

Entering validDomain User is not using a valid domain. Setting domain as: invaliddomain Entering modifyUITemplate Username Received: Harshal m Username isn't empty. Munged username: Harshal m Entering authenticate Entering Connect Using TLS or not using encryption. Using servers: ldap://ad.abc.com Connected successfully Entering getSearchString Doing a straight bind Username is : Harshal_m Password is : userdn is: abc\Harshal_m Binding as the user Binded successfully Entering getUserDN Created a regular filter: (sAMAccountName=Harshal m) Using base: dc=ad,dc=abc,dc=com Fetched username is not a string (check your hook code...). Pulled the user's DN: Checking for (new style) group membership Entering isMemberOfRequiredLdapGroup Required groups:cn=group_admins,ou=groups,ou=abc,ou=bom,oc=ind,dc=ad,dc=abc,dc=com Entering getUserGroups Entering getGroups Search string: (&(member=)(objectclass=group)) Returned groups: Returned groups: Couldn't find the user in any groups (1). Entering strict. Returning true in strict. Entering modifyUITemplate


 * Do you have underscores in your username? Underscores cause problems because MediaWiki turns them into spaces. Essentially, the wiki is searching for a user with the samaccountname of "Harshal m", and can't find the user (and therefore can't use the DN in the search for the group). --Ryan lane 19:09, 21 September 2007 (UTC)


 * Thanks Ryan.Yes. I do have underscores as a part of the username. Can you suggest a workaround for the same. --Harshalm 11:13, 24 September 2007 (UTC)


 * I think someone else on this page has a workaround for this posted. This seems to be a pretty common problem. I'm going to see if there is a core-code way of fixing this... --Ryan lane 16:42, 4 October 2007 (UTC)


 * Btw, here is the workaround someone else posted: Extension_talk:LDAP_Authentication --Ryan lane 16:55, 4 October 2007 (UTC)

Setting DisplayName via AD
We have the LDAP connectivity to AD working well - except that it looks like the wiki real_name is being populated by our AD cn - which for us, is a login code (we are numbers not names in AD).

Ideally I'd like it to be a friendly givenName but am not sure what to change or set. I've tried changing the following code, but to no avail.

any help greatly appreciated


 * Changing:


 * to:


 * Should work properly. This is the only spot these are used when retrieving preferences... --Ryan lane 19:15, 21 September 2007 (UTC)
 * thanks, Callum Wilson 08:41, 25 September 2007 (UTC)

An additional note for those that have number based AD cn's, it is worth changing the Special:Listusers to include the user_real_name. This change is unlikely to affect non-LDAP auth sites with self-chosen usernames because they won't care about the users' real name. To do this:


 * open the file {wikidir}/includes/SpecialListuser.php
 * then change these bits of code
 * firstly, in GetQueryInfo, add user_real_name to the fields paramater
 * then in formatRow add in the realname display:


 * --Callum Wilson 09:42, 28 September 2007 (UTC)

Doesn't work with 1.11?
I have a fresh install of Mediawiki 1.11. Two problems:

First: require_once( 'LdapAuthentication.php' ); doesn't work. I have to use require_once( './includes/LdapAuthentication.php' );. Without the ./includes/, I get this error:

Second: no matter what options I put in LocalSettings.php, I cannot get the LDAP authentication to do anything. Here is a sanitized version of my settings:

If I alter the code in /includes/LdapAuthentication.php to add some bad PHP, then I do get a runtime error. But it seems that no matter what I use with the above code, I never get anything on my wiki remotely resembling LDAP authentication.

If I replace wgLDAPServerNames with a bogus server name, I get no error.

Note well that despite setting the debug level to 3, I get nothing that would even slightly suggest any LDAP activities are going on.

Aren Cambre 17:39, 24 September 2007 (UTC)


 * By the way, I am using 1.1g. Aren Cambre 18:17, 24 September 2007 (UTC)


 * Aha, the documentation is bad. You have to put these commands at the end of your LdapSettings.php file, not at the beginning. Aren Cambre 16:00, 27 September 2007 (UTC)

Is 1.1g really the latest?
http://www.mediawiki.org/wiki/Extension:LDAP_Authentication#Current_version says that 1.1f is the latest version, but the box on the top right of http://www.mediawiki.org/wiki/Extension:LDAP_Authentication says 1.1g is the latest. Which one should I use?

Aren Cambre 18:26, 24 September 2007 (UTC)


 * Sorry, 1.1g is the latest. I've fixed this in the documentation. --Ryan lane 16:24, 4 October 2007 (UTC)

Problem after moving to SUSE!!
I recently moved my Wiki from a Fedora box to a Suse 9 Enterprise Server box. I installed openLDAP, and compiled PHP --with-LDAP...everything went fine. HOWEVER, now when logging in I am getting an error that says "Incorrect Password". I debugged and this is what it's showing:

Entering validDomain User is using a valid domain. Setting domain as: MYDOMAIN Entering getCanonicalName Username isn't empty. Munged username: Acook001 Entering authenticate Entering Connect Using TLS or not using encryption. Using servers: ldap://mydomaincontroller-dc-003.mydomain.edu Connected successfully Entering getSearchString Doing a straight bind userdn is: MYDOMAIN\Acook001 Binding as the user Failed to bind as MYDOMAIN\Acook001 Entering strict. Returning true in strict. Entering modifyUITemplate

All of the configuration was copied from a working install. Everything is the same (Mediawiki version, database, etc). Is there a reason why I'm getting the error Failed to bind as MYDOMAIN\Acook001? Please help!


 * Resolved HotMonkeyAC 16:59, 28 September 2007 (UTC)

wgHook broken in 1.11 and 1.1g
I'm trying to get the wgHooks['SetUsernameAttributeFromLDAP'][] = 'SetUsernameAttribute'; to work but doesn't seem to work. First of all I got an error, stating that function SetUsernameAttribute in the LocalSettings.php file was suppose to return true. Added that code but it still doesn't work. Any ideas would be most appreciated.

Code: $wgHooks['SetUsernameAttributeFromLDAP'][] = 'SetUsernameAttribute';

function SetUsernameAttribute(&$LDAPUsername, $info) { $LDAPUsername = $info[0]['givenname'][0]. $info[0]['sn'][0]; return 1; }

I've also tried to analyze the output with $wgLDAPDebug = 7. It gave no indication that the hook were doing anything. Returning $LDAPUsername instead of 1 or 'true' doesn't work either. Other then that quirk I can't seem to get nestedgroups to work but you can easily work around that, tediuos, but it works.


 * Hmm. This should be working fine if you end with "return true;". Let me test this and get back to you. --Ryan lane 16:25, 4 October 2007 (UTC)

SSL has to be capitalized?
works, but  doesn't. Does SSL have to be capitalized? Should this be in the documentation?

Aren Cambre 16:21, 27 September 2007 (UTC)


 * No. It is definitely "ssl". If you put "SSL" it will use "tls" because "SSL" isn't a valid type (I don't do a tolower...). Most likely, if you change from using "ssl" to "tls", or don't define the encryption type (which will cause it to default to tls), it'll work for you. --Ryan lane 16:29, 4 October 2007 (UTC)

No need for email confirmation...
There is no need for email confirmation if the email address comes from a known-good source like an LDAP directory. Therefore, I'd like to propose: Aren Cambre 18:30, 27 September 2007 (UTC)
 * Autocreated users with email pulled from LDAP should have appropriate values in the user_email_authenticated field of the user table indicating the email is pre-confirmed. Suggested value is the timestamp of the most recent LDAP query where the user's personal info was last checked.
 * The user's personal info is checked on each LDAP authentication.
 * The real name, e-mail, and nickname fields are not editable by the user.
 * Looks like $wgEmailAuthentication may satisfy the first bullet point. Aren Cambre 18:57, 27 September 2007 (UTC)
 * I'd prefer the realname to stay editable because many corporate directories do odd things such as surname, firstname. just my 2p. --Callum Wilson 09:45, 28 September 2007 (UTC)
 * It would be nice if we had an option to choose that behavior. Aren Cambre 13:10, 28 September 2007 (UTC)


 * If these changes don't require manual database modification, I'll try to work it into the next version. --Ryan lane 16:31, 4 October 2007 (UTC)

Performance issues with 1.1g and MW 1.11.0
Hi,

I updated from MW 1.10.0 to 1.11.0 and LDAPAuth 1.0a to 1.1g today. Of course, I had to redo my LDAP config strings, but once that was working and I was able to login to the wiki, I immediately noticed a significant performance degradation.

I have a parallel wiki running on the same hardware that is at 1.10.0/1.0a and every page load takes literally three times longer on 1.11.0/1.1g! Most pages on 1.10 take 1 second to load, while it takes 3 seconds on 1.11.

After doing some digging, I realized that if I allow unauthenticated access to all pages, the performance is what I would expect: 1 second page loads. When I require authentication, the main and auth pages come up in 1 second, but once I actually authenticate via LDAP, I am back to 3 seconds per page.

I have done the routine steps of disabling all other extensions, and played with some of the LDAP settings, but haven't made a dent in the problem. Anyone have a thought as to what might cause this behavior?

-- Jonathan King


 * I can't imagine why this would happen, the plugin should only be called on login (unless you are using auto-authentication, like SSL Auth). I'll see if I can replicate this. --Ryan lane 16:38, 4 October 2007 (UTC)


 * Ryan and all, sorry for the false alarm. It turns out that the problem only occurred for IE7 users with WikEd enabled. Once disabled, performance returned to normal levels. --jonathan king

I'm still confused
I'm still getting to grips with LDAP itself, and this is also my first MediaWiki extension, so I'd appreciate some walkthrough for installing this.

I'm using Fedora DS (but that ought not to matter, as the protocol should be the same), MW 1.11.0 and LdapAuthentication 1.1g

Please feel free to ask questions about my set up to work out how to get this installed and working correctly.

Thanks &mdash; Timotab 17:30, 17 October 2007 (UTC)


 * Take a look at the documentation; if you have any specific problems, feel free to ask. --Ryan lane 13:44, 18 October 2007 (UTC)


 * OK, I did some reading and have a better understanding of our LDAP configuration, and armed with that knowledge, got it working just fine. Does this have the option to have the change password page hook into LDAP and change the LDAP password?  Also, can I (and if so how do I) control groups (such as Bureaucrat and Sysop) in the LDAP db? &mdash; Timotab 16:40, 22 October 2007 (UTC)


 * Glad to hear you got it working.


 * Yes, the password field in MediaWiki can change LDAP passwords, but you'll have to configure the plugin to have a user that is allowed to change passwords in LDAP (a little insecure); See Options for using LDAP as a user backend for more information. You can also control groups through LDAP; See Group options and Group synchronization. --Ryan lane 22:40, 24 October 2007 (UTC)

$wgLDAPDisableAutoCreate set to false has no effect
I want to authenticate against an LDAP server and have local accounts also. Auto creating users does not work for me. I'm using MediaWiki 1.9.3 en plugin version 1.11g. Are there other option in LocalSettings I have to set to make this work? This is the error I recieve:

Login error: There is no user by the name "xxxxxx". Check your spelling, or create a new account.

Here's (part of) my config:

--Tkuipers 10:45, 26 October 2007 (UTC)


 * I noticed I made a typo; 'false' is not a string so I changed it to


 * This gave me the following error, which is discussed earlier.

&lt;password-change-forbidden&gt;

Backtrace:


 * 1) 0 /usr/share/mediawiki/includes/SpecialUserlogin.php(311): User->setPassword('xxxxxx')
 * 2) 1 /usr/share/mediawiki/includes/SpecialUserlogin.php(352): LoginForm->initUser(Object(User))
 * 3) 2 /usr/share/mediawiki/includes/SpecialUserlogin.php(407): LoginForm->authenticateUserData
 * 4) 3 /usr/share/mediawiki/includes/SpecialUserlogin.php(103): LoginForm->processLogin
 * 5) 4 /usr/share/mediawiki/includes/SpecialUserlogin.php(19): LoginForm->execute
 * 6) 5 /usr/share/mediawiki/includes/SpecialPage.php(625): wfSpecialUserlogin(NULL, Object(SpecialPage))
 * 7) 6 /usr/share/mediawiki/includes/SpecialPage.php(431): SpecialPage->execute(NULL)
 * 8) 7 /usr/share/mediawiki/includes/Wiki.php(182): SpecialPage::executePath(Object(Title))
 * 9) 8 /usr/share/mediawiki/includes/Wiki.php(47): MediaWiki->initializeSpecialCases(Object(Title), Object(OutputPage), Object(WebRequest))
 * 10) 9 /usr/share/mediawiki/index.php(48): MediaWiki->initialize(Object(Title), Object(OutputPage), Object(User), Object(WebRequest))
 * 11) 10 {main}
 * --Tkuipers 10:51, 26 October 2007 (UTC)


 * I upgraded to MediaWiki version 1.10.2 (in combination with LDAPAuthetication 1.11.g) because I didn't want to do all the patching by hand and got confused about the different solutions. Everything is working fine with stock versions.
 * --Tkuipers 10:56, 26 October 2007 (UTC)

error in creation of dn for new user
in most recent version (1.1g), there seems to be a bug creating the new userdn. Since the userdn seems to get prepended to the wgLDAPWriteLocation isn't a field separator (comma) necessary. I got an error from my ldap server without it, but when I added it, it seemed to work.

--- LdapAuthentication.php     Mon Oct 29 10:55:48 2007 if ( isset( $wgLDAPWriteLocation[$_SESSION['wsDomain']] ) ) { $this->printDebug( "wgLDAPWriteLocation is set, using that", NONSENSITIVE ); $userdn = $wgLDAPSearchAttributes[$_SESSION['wsDomain']]. "=" . !                                              $username. $wgLDAPWriteLocation[$_SESSION['wsDomain']]; } else { $this->printDebug( "wgLDAPWriteLocation is not set, failing", NONSENSITIVE ); //getSearchString will bind, but will not unbind --- 799,805                                if ( isset( $wgLDAPWriteLocation[$_SESSION['wsDomain']] ) ) { $this->printDebug( "wgLDAPWriteLocation is set, using that", NONSENSITIVE ); $userdn = $wgLDAPSearchAttributes[$_SESSION['wsDomain']]. "=" . !                                              $username. "," . $wgLDAPWriteLocation[$_SESSION['wsDomain']]; } else { $this->printDebug( "wgLDAPWriteLocation is not set, failing", NONSENSITIVE ); //getSearchString will bind, but will not unbind
 * LdapAuthentication.php.save Mon Oct 29 10:55:38 2007
 * 799,805 ****
 * 799,805 ****


 * Thanks for the bug report. I'll have this fixed in the next version. --Ryan lane 21:40, 29 October 2007 (UTC)

$wgLDAPDomainNames - Remove from login screen
I have set the $wgLDAPDomainNames for a single domain with local set to false. I would like to remove this drop down from the login screen, is there a setting that I can use to remove the drop down, or would I have to modify the code for that page? Thank you.

mediawiki-1.11.0 LdapAuthentication.php ver. 1.1g openLDAP2-2.3.37-7 Login error: Incorrect password entered. Please try again.
I had everything working fine in mediawiki-1.9.4 (after following workaround). Installed from scratch 1.11 and it doesn't work anymore. The first time I login with the user I get following messages: Entering validDomain User is using a valid domain. Setting domain as: exampleNonADDomain Entering getCanonicalName Username isn't empty. Munged username: Sow Entering userExists Entering authenticate Entering Connect Using TLS or not using encryption. Using servers: ldap://mydomain.com Connected successfully Entering getSearchString Doing a straight bind userdn is: uid=Sow,ou=People,dc=mydomain,dc=com Binding as the user Bound successfully Authentication passed Entering initUser Entering updateUser Entering modifyUITemplate

The second time I login there are such messages: Entering validDomain User is using a valid domain. Setting domain as: exampleNonADDomain Entering getCanonicalName Username isn't empty. Munged username: Sow Entering modifyUITemplate

I know I use correct password. My LocalSettings.php (only end of it): $wgLogo = ''; require_once 'LdapAuthentication.php'; $wgAuth = new LdapAuthenticationPlugin; $wgLDAPDomainNames = array(   'exampleNonADDomain',  ); $wgLDAPServerNames = array(   'exampleNonADDomain' => 'mydomain.com',  ); $wgLDAPUseLocal = false; $wgLDAPAddLDAPUsers = false; $wgLDAPUpdateLDAP = false; $wgLDAPMailPassword = false; $wgLDAPSearchStrings = array(   'exampleNonADDomain' => 'uid=USER-NAME,ou=People,dc=mydomain,dc=com',  ); $wgLDAPEncryptionType = array(   'exampleNonADDomain' => 'clear',  ); $wgLDAPRetrievePrefs = true; $wgMinimalPasswordLength = 1; //FOR DEBUGGING ONLY $wgLDAPDebug = 8; //for debugging $wgShowExceptionDetails = true; //for debugging MediaWiki

Is there anything I am missing??


 * What version of the plugin are you using? --Ryan lane 17:51, 7 November 2007 (UTC)


 * LdapAuthentication.php ver. 1.1g (seems to be the last one. --mbronczyk 23:43, 8 November 2007 (UTC)


 * First let's start by using the options correctly (obviously you've been reading other people's configuration options, against my advice):


 * Remove:

$wgLDAPUseLocal = false; $wgLDAPAddLDAPUsers = false; $wgLDAPUpdateLDAP = false; $wgLDAPMailPassword = false;


 * As all of those are not even defined correctly, and if they were, false is generally the default for everything... Now, change:

$wgLDAPRetrievePrefs = true;


 * to:

$wgLDAPRetrievePrefs = array(   'exampleNonADDomain' => true    );


 * In fact, you should also try using false for that one, just in case, at first. --Ryan lane 15:36, 9 November 2007 (UTC)


 * Thanks for your help. The cause of the problem was using the same username and password. I am only testing in closed environment so didn't bother with real passwords. Should read all the comments more carefully before. Thanks for the plugin. --mbronczyk 23:40, 12 November 2007 (UTC)

Access-Restiction to certain Pages or Categories
I like to restict read/write support to certain pages or categories based on LDAP group members. Which Patch/Extension is supposed to work with this Extension? --TimHaegele 15:33, 11 November 2007 (UTC)

I am trying to do the same thing, and what I've got set up is at login it queries the AD for all groups the user is a member of and stores them in the session variable. Then, I use one of the Page Security plugins and change the part where it looks for if the user is a member of a group to check the array of LDAP groups. I store it in the session variable because it takes a long time to search the whole LDAP structure every time it's used. Also, it doesn't create a billion Wiki groups that map to AD groups. If anyone has any critiques of this method, please let me know. --Danielha 14:42, 12 November 2007 (UTC)


 * Apparently Extension:Group Based Access Control may. I added a patch in for them, so I'd imagine it works. Of course, I don't recommend any of these (for reasons why, read the top of that page, or the page of any of the access control plugins). Use a CMS, or a wiki that is designed for it. --Ryan lane 19:41, 15 November 2007 (UTC)

LDAP was working before Groups
I am trying to setup my wiki to work with LDAP and only allow certain users access based on the group they are in. I have it so that it is authenticating against AD and binding successfully for users. When I put in the code to try and restrict it to specific groups, it will not authenticate anymore. The debug statements contain: User is using a valid domain. Setting domain as: LDAPNAME Entering getCanonicalName Username isn't empty. Munged username: Sjordan Entering authenticate Entering Connect Using TLS or not using encryption. Using servers: ldap://ldap.server.com:3268 Connected successfully Entering getSearchString Doing a straight bind userdn is: sjordan@students.server.com Binding as the user Failed to bind as sjordan@students.server.com <-- if this fails, I try it again with sjordan@server.com which then binds successfully Bound successfully Entering getUserDN Created a regular filter: (sAMAccountName=Sjordan) Entering getBaseDN basedn is not set for this type of entry, trying to get the default basedn. Entering getBaseDN basedn is DC=server,DC=com Using base: DC=server,DC=com Fetched username is not a string (check your hook code...). This message can be safely ignored if you do not have the SetUsernameAttributeFromLDAP hook defined. Pulled the user's DN: CN=sjordan,OU=Employees,DC=server,DC=com Checking for (new style) group membership Entering isMemberOfRequiredLdapGroup Required groups:cn=* dept - information technology,ou=exchange distribution groups,dc=server,dc=com Entering getUserGroups Entering getGroups Entering getBaseDN basedn is not set for this type of entry, trying to get the default basedn. Entering getBaseDN basedn is DC=server,DC=com Search string: (&(sAMAccountName=Sjordan)(objectclass=user)) Returned groups:cn=sjordan,ou=employees,dc=server,dc=com Returned groups: Couldn't find the user in any groups (2). Entering strict. Returning true in strict. allowPasswordChange - Line 1 Entering modifyUITemplate

My local settings file contains:

require_once( "$IP/extensions/LdapAuthentication.php" ); $wgAuth = new LdapAuthenticationPlugin; $wgLDAPDebug = 3; $wgLDAPDomainNames = array("LDAPNAME"); $wgLDAPServerNames = array("LDAPNAME"=>"ldap.server.com:3268"); $wgLDAPUseLocal = false; $wgLDAPEncryptionType = array("LDAPNAME"=>"clear"); $wgLDAPSearchStrings = array("LDAPNAME"=>"USER-NAME@students.server.com"); $wgLDAPSearchAttributes = array("LDAPNAME"=>"sAMAccountName"); $wgLDAPBaseDNs = array("LDAPNAME"=>"DC=server,DC=com"); $wgLDAPRequiredGroups = array("LDAPNAME"=>array("CN=* Dept - Information Technology,OU=Exchange Distribution Groups,DC=server,DC=com")); $wgLDAPGroupAttribute = array("LDAPNAME"=>"sAMAccountName"); $wgLDAPGroupObjectclass = array("LDAPNAME"=>"user"); $wgLDAPGroupNameAttribute = array( "LDAPNAME"=>"group" ); $wgLDAPRetrievePrefs = array("LDAPNAME"=>true); $wgShowExceptionDetails = true

i'm not sure why it is only showing that one group, when I look at memberOf using dsquery with the same filter, i'm receiving a lot more information. Thanks, Shane.


 * You are searching for users instead of groups. Try this:

$wgLDAPGroupAttribute = array("LDAPNAME"=>"member"); $wgLDAPGroupObjectclass = array("LDAPNAME"=>"group"); $wgLDAPGroupNameAttribute = array( "LDAPNAME"=>"cn" );


 * That should return groups instead of users. --Ryan lane 16:10, 13 December 2007 (UTC)


 * I made those changes, and it is still not returning any groups. Thanks, Shane

Proposition for wgLDAPRetrievePrefs
Recently i've successfully managed to implement LDAP authentification with local LDAP server, problem is that LDAP directory, for instance, doesn't have attribute displayName, but it has some other attribute to use instead of displayname. In the end i've hacked LdapAuthentication.php to suit my needs.

My proposition is to use an array to map predefined user prefrences variables (mail, preferredlanguage, ..) to their corresponding values in a LDAP directory, if that array is not defined then default mappings should be used. Is this doable? --Dodobas 14:37, 29 November 2007 (UTC)


 * I've been wanting to add this for a while, and never got to it; I've added it to the todo list. --Ryan lane 16:20, 13 December 2007 (UTC)

SSL CA Issue
Hi. We have an SSL LDAP server which uses a non-standard CA. Is there a way to turn off certificate checking? Failing that, where is the CA registry kept?

Thanks.

Simsong 05:54, 4 December 2007 (UTC)


 * It depends on what type of OS your web server is on. If you are on a Linux system, you can define it in your /etc/openldap/ldap.conf file. If you want to turn off checking, you can set "TLS_REQCERT    never". If you want to add your CA, you can add it to the same file via "TLS_CACERT " and/or "TLS_CACERTDIR ". --Ryan lane 16:25, 13 December 2007 (UTC)

"Undefined offset" error
I get this error with 1.1g: PHP Notice: Undefined offset:  0 in /var/www/html/itwiki/includes/LdapAuthentication.php on line 1149 It shows up in the browser at login. Once the login page redirects to the Main page, the error is gone and everything functions normally. I don't know if it's something in my config causing the trouble or not so i'll post it just in case (sanitized): // Prevent users from creating accounts $wgGroupPermissions['*']['createaccount'] = false; // Block access to all pages except Login and Logout pages for users who are not logged in. $wgWhitelistRead = array( "Special:Userlogin", "Special:Userlogout", "-", "MediaWiki:Monobook.css" ); $wgGroupPermissions['*']['read']= false; // * This breaks access to other pages // $wgGroupPermissions['user']['read']=false; $wgShowIPinHeader = false; // * Doesn't work as expected // $wgGroupPermissions['MY-GROUP'] = $wgGroupPermissions['sysop']; // Load the LDAP module require_once( 'LdapAuthentication.php' ); //Turn on debugging, 0-3 $wgLDAPDebug = 0; // // LDAP Settings $wgAuth = new LdapAuthenticationPlugin; $wgLDAPDomainNames = array( "DOMAIN" ); $wgLDAPServerNames = array( "DOMAIN"=>"SERVER01.foo.com" ); $wgLDAPSearchStrings = array( "DOMAIN"=>"DOMAIN\USER-NAME" ); $wgLDAPEncryptionType = array( "DOMAIN"=>'clear' ); // this is needed in >= 1.1c $wgMinimalPasswordLength = 1; $wgLDAPRetrievePrefs = array( "DOMAIN"=>true,  ); // this is needed in >= 1.1c $wgLDAPGroupUseFullDN = array( "DOMAIN"=>true ); $wgLDAPGroupObjectclass = array( "DOMAIN"=>"group" ); $wgLDAPGroupAttribute = array( "DOMAIN"=>"member" ); $wgLDAPGroupSearchNestedGroups = array( "DOMAIN"=>false ); $wgLDAPBaseDNs = array( "DOMAIN"=>"cn=MY-GROUP,ou=groups,dc=foo,dc=com" ); $wgLDAPSearchAttributes = array( "DOMAIN"=>"sAMAccountName" ); $wgShowExceptionDetails = true; // Disallow the use of the local database (MySQL) $wgLDAPUseLocal = false; If anyone can tell me how to get rid of it, that would be great!

Interacting with Novell's eDirectory and usage on NetWare
To those who thought NetWare was dead, fear not! It took quite a bit of yelling at my company's 6.5 SP7 box, but I finally got it to run MediaWiki, and then to auth against eDirectory. But some changes to the LDAP Plugin are needed to drop the use of ldaps:// and actually pass a port number to the ldap_connect call (This patch is a HACK!): --- LdapAuthentication.orig.php	2007-12-08 22:30:08.000000000 -0500 +++ LdapAuthentication.php	2007-12-08 22:11:00.000000000 -0500 @@ -158,10 +158,12 @@ class LdapAuthenticationPlugin extends A 			case "ssl": $this->printDebug( "Using SSL", SENSITIVE ); $serverpre = "ldaps://"; +				$serverport = 636; break; default: $this->printDebug( "Using TLS or not using encryption.", SENSITIVE ); $serverpre = "ldap://"; +				$serverport = 389; } 		//Make a space seperated list of server strings with the ldap:// or ldaps:// @@ -169,16 +171,16 @@ class LdapAuthenticationPlugin extends A 		$servers = ""; $tmpservers = $wgLDAPServerNames[$_SESSION['wsDomain']]; $tok = strtok( $tmpservers, " " ); -		while ( $tok ) { -			$servers = $servers. " " . $serverpre. $tok; -			$tok = strtok( " " ); -		} +		//while ( $tok ) { +		//	$servers = $servers. " " . $serverpre. $tok; +		//	$tok = strtok( " " ); +		//} 		$servers = rtrim($servers); $this->printDebug( "Using servers: $servers", SENSITIVE ); //Connect and set options -		$ldapconn = @ldap_connect( $servers ); +		$ldapconn = @ldap_connect( $servers, $serverport ); ldap_set_option( $ldapconn, LDAP_OPT_PROTOCOL_VERSION, 3); ldap_set_option( $ldapconn, LDAP_OPT_REFERRALS, 0);


 * Sorry to hear you are stuck using netware ;). --Ryan lane 16:47, 13 December 2007 (UTC)
 * Hah, actually, I chose to stick with NetWare because I wasn't impressed with NSS support on Novell's OES1 iteration. The kernel module would randomly unload itself from memory, among other things, so I stayed with NetWare for this generation.  Next upgrade we do will probably be all Linux.  Besides, I kind of like NetWare....It's quirky and quite unique :) --Kumba 01:48, 17 December 2007 (UTC)

And I state this is a hack because I did this at 3am in the morning, and haven't touched PHP code really in-depth since 3.x, so doing anything more would probably be tricky. That stated, however, I think it'd be a nice addition to use the above as a template, and design a ports variable, say $wgLDAPServerPorts, which would take an array as an assignment wherein each array member represents an LDAP domain (or Novell Tree), and each domain is itself an array taking exactly two args: unencrypted server port and encrypted server port. That way, if $wgLDAPEncryptionType references ssl, then the secure port (def. 636) is used; else, unsecure (def. 389).
 * 389 is default for tls or clear, 636 is default for SSL. PHP should be doing this for you. You should only have to specifically define the ports if you use something non-standard, which makes this patch a little redundant. --Ryan lane 16:47, 13 December 2007 (UTC)
 * Should, but wasn't. I don't know what the core problem was, but even with the plugin's debugging turned on, I wasn't getting anywhere until I made the modifications highlighted in the patch.  Whether it's a NetWare-specific oddity or not, I'm unsure.  The funny thing is, Apache using ldaps:// forms works fine.  Of course, I also found that I wasn't granting browse rights for the CN attribute to the [Public] user at the root of my tree, which was breaking contextless logins as well.  I may have to try again now that I got that fixed.  As I saw this and the use of a proxy user as two different ways to get anonymous ldap browsing to work. --Kumba 01:48, 17 December 2007 (UTC)

Some interesting side-effects and other notes:


 * WikiSysop doesn't need to exist in eDirectory. Even though the bind against ldap fails, I guess if WikiSysop is in the local database, it somehow gets a non-zero result (or whatever result is being checked) returned and lets it log in.  Cancel that, it was something weird in my config causing that.  I wound up adding the Wikisysop user to my eDirectory tree in a top-level OU of its own, and creating a second "admin" domain specifically for the sysop login (I may put other wiki-specific users here, like bureaucrats and such), as my regular users are isolated in another top-level OU and need to stay separate.
 * You don't really need to add the wiki-specific users. I don't use any of those users personally, just create a regular user, turn off the plugin, promote the user, and turn the plugin back on. After that point, you won't need the default users ever again. You could also configure the plugin to pull groups from LDAP, and assign the proper permissions to certain groups. If you do that, you don't even have to do the more annoying stuff I mentioned previously. --Ryan lane 16:47, 13 December 2007 (UTC)
 * Yeah, all I have for now is just the wikisysop user in eDirectory. I may do what you suggest down the road and create a admin-level group in eDir and have my -admin domain auth against that to determine what users get what rights.  For a first run at setting up Wiki software, I'll probably stay with this until me and our DBA can get some content added, then start playing with it some more. --Kumba 01:48, 17 December 2007 (UTC)
 * Users don't have much of an ability to update stuff. Granted, I'm being pretty strict on allowing any change to flow back up into eDirectory, but I'd think it'd be possible for Wiki to be a little more flexible in this area.  Like say, adding the user to the local database if not already present BUT not using the database as an authenticator (I don't think $wgLDAPUseLocal and $wgLDAPAddLDAPUsers control it like this; it's either one or the other, not the mix I suggest), only to store preferences.  Not sure if this capability is present, as I only started playing with this yesterday, but I'd prefer this over a schema update and storing all the data in eDirectory itself.
 * This is what the plugin does by default. If a user doesn't exist in the database, it gets added automatically when they first login. Any preference they change is saved in the database. Any preferences pulled from LDAP automatically overwrite any locally set preferences. --Ryan lane 16:47, 13 December 2007 (UTC)
 * Well, when I tried updating someone's user profile data, I get an error back stating that I'm authing against an external database and preference saving isn't allowed. Either I have a variable disabled that shouldn't be, or it's because I'm communicating with eDirectory instead of a more normal LDAP implementation, like AD. --Kumba 01:48, 17 December 2007 (UTC)
 * If someone's up to it, writing an Identity Manager driver for MediaWiki would completely work around this.
 * If you're a touch old-fashioned, and like using all lowercase names in eDirectory, then make sure to use $wgLDAPLowerCaseUsername. It'll save some headaches, as eDirectory seems to be rather case sensitive on the DNs.
 * Novell actually has a wiki entry on their site for auth'ing MW against eDirectory, using this very plugin. But I suspect it's a bit dated: http://wiki.novell.com/index.php/Using_eDirectory_to_control_access_to_MediaWiki
 * I'm sure it probably is outdated. I'm not a big fan of people writing documentation in other places for this plugin, but I don't complain about that documentation since I'm able to update it myself. (if you look through the history, you'll notice I've updated it on occasion) --Ryan lane 16:47, 13 December 2007 (UTC)
 * On NetWare, you'll need to export your server's self-signed certificate via ConsoleOne (iManager may do this too) and place it into SYS:\PHP5\CERT (or wherever you have PHP), then restart Apache2 (AP2WEBDN, AP2WEBUP) so that PHP re-scans the cert folder and notes the new cert. Export it in DER format, and do NOT include the private key.  The cert is in the Security container at the top of the tree, in the CA object (if my memory is correct).
 * Updated Apache, PHP, and MySQL binaries can be found at http://www.gknw.net/. I advise visiting the forums too -- Günter is very helpful and knows lots about running this wacky setup on NetWare.
 * MySQL 5.0.45 has a bug in mysql_install_db, btw, so get 5.0.27 and copy the two *.sql scripts from the bin folder to 5.0.45's bin folder before running it.

Anyways, that's all I can think of for now. I'll add more if I discover something.

--Kumba 22:15, 9 December 2007 (UTC)

Nested groups not usable for $wgGroupPermissions
Hi there... I bet this is a known 'issue', but i am reporting it anyways since that feature would be VERY useful in our environment here...

The Problem: we use nested groups here, for example: (((qa-north + qa-south) = qa ) + prog-dept = tech) ...

Now we want to let all people of tech edit the wiki. At the moment we have to add ALL users of all the other groups to another virtual wiki access group (or tech directly) and then allow tech with $wgGroupPermissions to access various functions. Would it be possible (and clean to implement) to add a feature to add a wiki user to all the nested groups a user is in? (namely in this example tech, qa, and qa-north if a user is in qa-north)

This feature would be VERY appreciated.

--ThomasGruber 13:32, 8 January 2008 (UTC)


 * Yeah, this is a known issue. The reason this doesn't work is because my nested group code was written for group restriction, and for performance sake, the code stops searching ldap for higher nestings when it finds a required group. I'll need to rework the code for this to work. I'll put it on my todo list, but lately I've been very busy with other projects. --Ryan lane 16:19, 9 January 2008 (UTC)