Extension talk:LDAP Authentication/Archive 2

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;

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

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

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

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

#DNs in $wgLDAPRequiredGroups must be lowercase, as search result attribute values are...
#$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") );
$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"=>false );
$wgLDAPGroupSearchNestedGroups = array( "domain.com"=>true );
$wgLDAPBaseDNs = array( "domain.com"=>"ou=administrators,dc=domain,dc=com" );
#$wgLDAPBaseDNs = array( "domain.com"=>"ou=groups,ou=administrators,dc=domain,dc=com" );
$wgLDAPSearchAttributes = array( "domain.com"=>"sAMAccountName" );
$wgLDAPGroupNameAttribute = array( "domain.com"=>"mis" );

$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:mailarchive: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 postmailarchive: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)

Multiple domains leads to username clash?

We're running a multi-domain AD environment, and I'm hoping this LDAP extension will make mediawiki "intergratable" into our environment.

So I've set up the ability for our users to login from the different domains, including myself as "dom1/user1". However, now I've logged in, I notice my mediawiki "account" is actually "user1" - ie the "dom1" has disappeared.

Well, we definitely have many instances of username "clashes" - eg there's a "dom3/user1". Won't that mean "dom3/user1" logging in will end up in my mediawiki profile?

Owch :-(

Update: I just had a thought. As slashes of all description are bad as username chars, perhaps getting the AD-retrieved email address to become the mediawiki account name would be the best workaround? e.g. dom1/user1 logs in, and finds themselves in a mediawiki account profile named "user@email.address" instead of the non-unique "user1"?

Email addresses likely won't work as the @ symbol is illegal in user names. Maybe I'll try to work some domain conflict resolution stuff into the next version.
--Ryan lane 14:22, 28 October 2008 (UTC)

How about just DOM "-" USERNAME (eg dom-jhaar). Your "conflict resolution" comment implies you think it should remain "username" unless a clash occurs? I think that would be unwise - specifically as it leads to inconsistancy. What about defaulting to "dom-username", and having (new variable) "$wgLDAPIgnoreDomainInAccountName=1" as the default. That would then allow a new release to by default act like old releases, but would enable users like me to set to zero and enable the multi-domain account support?
--Jason Haar 10:30, 30 October 2008 (NZDT)

When I said conflict resolution, I meant adding something like user@domain or DOMAIN\user. I can't promise anything soon. I'm not really a big fan of dom-user; something more common would be nice. I'll take patches to fix this, but it would probably be a good idea to run the ideas through me before coding them up.
--Ryan lane 22:38, 3 November 2008 (UTC)

I've already looked at user@domain - but the interwiki code appears to misinterpret that? It sort of works - but if you try to change wiki group membership using such accounts, it fails. The backslash would be most "Windows-like" - but as an escape char, it might be misinterpreted by all sorts of things? The forward slash is likewise not a usable choice - which is why I was suggesting lame things like hyphens
--Jason Haar 19:44, 6 November 2008 (NZDT)

I have the same problem right now and I was wondering why the Hook "SetUsernameAttributeFromLDAP" is only used for Auto login. You could use this to build your own unique usernames. --02:22, 22 June 2009 (UTC)

That hook isn't just used for auto-login; it just happens to be documented under that section. You can use it for regular log-in too. See my blog post that uses it to make semi-anonymous user names.
--Ryan lane 21:07, 25 June 2009 (UTC)

In fact, I just moved that into its own section, to clarify that.
--Ryan lane 21:12, 25 June 2009 (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

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

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#CMS::MediaWiki Breaks. 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)

I logged a pywikipedia ticket about this. -maiden_taiwan, 09 May 2008

The problem is now fixed in the pywikipedia software. Maiden taiwan 14:25, 29 May 2008 (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)

Hi, is there a way to create an account for each user in the ldap annuary now ? Maybe a solution has been designed since june 2007... Thanks --Teriblus 11:10, 13 May 2008 (UTC)

I don't think I understand your question...
--Ryan lane 21:20, 13 May 2008 (UTC)

Oops sorry, I'm french. I would like to create a MediaWiki account for all registered users in LDAP including those wich have never been logged in on the wiki. Is it better now ?.. Thanks --Teriblus 10:30, 14 May 2008 (UTC)

I don't plan on supporting this any time soon. This would require things like scheduled tasks (cron, windows task scheduler, etc), as you'd have to keep it up to date. Also, it would require the deletion (or renaming) of accounts, and the renaming of accounts when they have been modified in LDAP. This isn't exactly an easy feat, and it doesn't really add much as far as I can tell.
--Ryan lane 21:49, 19 May 2008 (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:

#if ( isset($wgLDAPRetrievePrefs[$_SESSION['wsDomain']]) && $wgLDAPRetrievePrefs[$_SESSION['wsDomain']] ) {
	$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@<domain>.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):

###Create IT User group
$wgGroupPermissions['ITUser']['read'] = true;
$wgGroupPermissions['ITUser']['edit'] = true;
$wgGroupPermissions['ITUser']['createpage'] = true;
$wgGroupPermissions['ITUser']['createtalk'] = true;
$wgGroupPermissions['ITUser']['upload'] = true;

###Only logged in ITUsers can edit
$wgGroupPermissions['*']['edit'] = false;
$wgGroupPermissions['user']['edit'] = false;

###Nobody is allowed to create accounts
$wgGroupPermissions['*']['createaccount'] = false;

###Define pages people not logged in can see
$wgWhitelistRead = array( "Main Page", "Special:Userlogin", "Special:Userlogout", "-", "MediaWiki:Monobook.css" );
$wgGroupPermissions['*']['read']= false;
$wgGroupPermissions['user']['read']=false;
$wgShowIPinHeader = false;

##############################
##LDAP Auth Integration info##
##############################
##These lines should work in conjunction with ldapauthentication.php in the includes dir.

###Setup for LDAP Auth
require_once( 'LdapAuthentication.php' );
$wgAuth = new LdapAuthenticationPlugin();
$wgLDAPDomainNames = array("<domain>","<domain>");
$wgLDAPServerNames = array("<domain>"=>"naddc1.<domain>.com");
$wgLDAPSearchStrings = array("<domain>"=>"<domain>\\USER-NAME");
$wgLDAPEncryptionType = array("<domain>"=>"clear");
$wgLDAPUseLocal = false;
$wgMinimalPasswordLength = 7;
$wgLDAPRetrievePrefs = true;
$wgLDAPDebug=4;

$wgLDAPBaseDNs = array( "<domain>"=>"dc=<domain>,dc=com" );
$wgLDAPSearchAttributes = array( "<domain>"=>"sAMAccountName" ); 

$wgShowExceptionDetails = true;
$wgLogo = "http://mercury/ITWiki/images/c/c9/Logo.png" 

And here is my output:

Entering validDomain
User is using a valid domain.
Setting domain as: <domain>
Entering getCanonicalName
Username isn't empty.
Munged username: Eberlec
Entering authenticate
Entering Connect
Using TLS or not using encryption.
Using servers: ldap://naddc1.<domain>.com
Connected successfully
Entering getSearchString
Doing a straight bind
userdn is: <domain>\Eberlec
Binding as the user
Binded successfully
Entering getUserDN
Created a regular filter: (sAMAccountName=Eberlec)
Using base: dc=<domain>,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=<domain>,DC=com
Retrieving preferences
Retrieved: eberlec@<domain>.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#Options_for_using_LDAP_as_a_user_backend. 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( "<domain>" );
$wgLDAPServerNames = array( "<domain>"=>"<domain1> <domain2>"  );
$wgLDAPSearchAttributes = array( "<domain>"=>"uid" );
$wgLDAPBaseDNs = array( "<domain>"=>"o=Gla" );
$wgLDAPEncryptionType = array( "<domain>"=>"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( "<domain>"=>"uid" );

to:

$wgLDAPSearchAttributes = array( "<domain>"=>"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( "<domain>"=>"false" );

to:

$wgLDAPEncryptionType = array( "<domain>"=>"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)

But in this case, username will look like "John smith" instead of "John Smith" which is not correct. And the main idea was to let users use their login name everywhere, and in a wiki too. There is a hook that calls for a function that extracts user name. Why can't extracted name be used as wiki user? That would be perfect.

81.211.109.234 09:57, 4 November 2008 (UTC)

You should be able to use that hook for this purpose. Take smartcard authentication for instance. I may get "RYAN.LANE.098080980980" as the CN from the card, but the plugin does a lookup on this user, and via the hooks sets the username as "rlane". My username in the wiki at that point in time is "rlane". I think the hook could be used for your purpose too. Don't forget though, that usernames in the wiki need to be unique. By changing a unique name into a non-unique name, you could cause yourself some serious issues.
--Ryan lane 22:08, 18 February 2009 (UTC)

Enterprise LDAP Solution

So the basic concept of this plugin is tops! The only issue is that I am using it in an enterprise environment. Users have IDs like 986438, not jsmith.

Seeing attributions like '986438' are useless. I needed to see real names, while allowing login under usernames.

In addition we needed to restrict edit rights to certain groups within the enterprise, and allow sysops and bureaucrat roles to be pulled form LDAP.

My solution was two fold. First off I pull memberOf details from LDAP to determine rights, secondly I pull tons of more info like department, real name, title, phone extension and mailstop. I use all this additional info to populate the user info page on login. This means we can click 986438 and see

John Smith
Title: Software Engineer
Department: ID Services
Email: j.smith@company.com
Phone: 1-555-555-5555
Mailstop: 3n-a

which makes the sysop's role a lot easier to determine if deletes or edits should be respected.

Anyway I was wondering how many people would be interested in this solution. It requires a good deal of edits in the LDAPAuthentication.php file as well as some additional fields in LocalSettings.php

If there is a demand I'll share.

You may want to look at Extension_talk:LDAP_Authentication#ldapinfo. It violates the GPL; however, it pulls information from LDAP using the hcard microformat. You may want to put that into your user's page instead. I may modify this plugin, and add it to MediaWiki's SVN (and make it GPL compliant while I'm at it).
--Ryan lane 22:18, 18 February 2009 (UTC)

Could you share this enterprise solution? I am being asked to do this exact thing and don't really know where to start, I can't seem to get that ldapinfo plugin to work, it just says "LDAP user "*****" not found" --62.172.72.131 10:58, 12 March 2009 (UTC)

LDAP info isn't my plugin, so I can't help you with it.
--Ryan lane 14:54, 20 May 2009 (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: 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;$i<count($aLDAPGroups);$i++){
                if(!in_array($aLDAPGroups[$i],$aOldGroups))
		    $u->addGroup($aLDAPGroups[$i]);
            }
	    
            // Remove old Groups
	    for($i=0;$i<count($aOldGroups);$i++){
	       if(($aOldGroups[$i] != 'bot')&&($aOldGroups[$i] != 'bureaucrat')&&($aOldGroups[$i] != 'sysop')){
	           if(!in_array($aOldGroups[$i],$aLDAPGroups))
		      $u->removeGroup($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)

Thanks for this code, works great! I simply added it at the start after the variable initializations, and then called it with:

// LDAP Group Synchronization
	$this->syncGroups($username);

just before the "//Retrieve preferences" line. Syncs our LDAP<->Wiki groups perfectly.
--Andrew Hodder 17:28, 19 February 2008 (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.

Hi, is this on the 1.2a release? I don't see any documentation for enabling this option. I also don't see any "PHP_AUTH_USER" or "SERVER" text in the 1.2a release. :(

Yes, this has been added in 1.2a. You won't see SERVER in the plugin, because I allow the admin to choose whatever that want for the auto-auth username. See Extension:LDAP Authentication/Smartcard Configuration Examples and Extension:LDAP Authentication/Kerberos Configuration Examples. If you notice, the kerberos example has the following in LocalSettings.php:

$wgLDAPAutoAuthUsername = preg_replace( '/@.*/', '', $_SERVER["REMOTE_USER"] );

This allows the same code base to be used for kerberos, SSL, radius, SASL, or whatever else you happen to chose on your webserver.
--Ryan lane 23:10, 2 December 2008 (UTC)

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!

<!--The valid AD username is "wiki_user"-->
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) 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:

#LDAP FUN!!!
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;
#$wgLDAPRetrievePrefs = array( "DOMAIN"=>false ); // this is needed in >= 1.1c
$wgLDAPUpdateLDAP = array( "DOMAIN"=>"false" ); //disables mediawiki from updating LDAP
$wgLDAPDebug = 3; //debugging

#group based auth
$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" );

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)

Needless search (IMHO)

I tried this, but it does not work as I expected.

1. The $wgLDAPAuthAttribute does not not effect the initial user search - getUserDn -.
2. It only works for the first (of n) result entries of getUserDN searches.
3. The effect is another search after the binding. This is redundant!

Please patch the getUserDN in a way it uses $wgLDAPAuthAttribute. With this you save a needless search.

I have three cn="jane doe"s in my LDAP, each with different mail addresses. I want only one mail domain to be allowed to log in mail=*@example.org. Jane Doe cannot log in, because getUserDN finds three jane doe, tries the first, fails, error, end. If getUserDN would work as I mentioned above, there would be only one search result: filter=(&(cn=jane doe)(mail=*@example.com)).

I now hardcoded the filter in my getUserDN to get it work quickly. I'm not a experienced PHP coder, otherwise I would send you a patch. :(

212.144.255.11 16:54, 11 November 2008 (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.

→Tim Laqua^{Talk | contribs}_{@13:08, 31 July 2007 (UTC)}

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)

I had the same problem at work. For the authentication of our wikis we have groups with long names. What I have done to solve it is increase the maximum size of the field 'ug_group' of the table 'wik_user_groups' to 255 (the tables of my database have 'wik_' comme prefix). It works! The SQL command would be ...

   ALTER TABLE `wik_user_groups` MODIFY COLUMN `ug_group` varbinary(255)  NOT NULL;

--José Manuel Ciges Regueiro 13:20, 25 November 2009 (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)

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'
--ThomasGruber 13:16, 8 January 2008 (UTC)

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;

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

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

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

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


###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#Single Domain Requiring Straight Binding Only.

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#Windows configuration. 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 bindAs() function (called from getSearchString()) and the setPassword() 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 $wgLDAPLowerCaseUsername 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:

Index: LdapAuthentication.php
===================================================================
--- LdapAuthentication.php	(revision 25407)
+++ LdapAuthentication.php	(working copy)
@@ -1361,7 +1361,8 @@
 	function getGroups( $ldapconn, $dn ) {
 		global $wgLDAPGroupObjectclass, $wgLDAPGroupAttribute, $wgLDAPGroupNameAttribute;
 		global $wgLDAPProxyAgent, $wgLDAPProxyAgentPassword;
-
+		global $wgUser;
+		
 		$this->printDebug( "Entering getGroups", self::NONSENSITIVE );
 
 		$base = $this->getBaseDN( self::GROUPDN );
@@ -1370,11 +1371,39 @@
 		$attribute = $wgLDAPGroupAttribute[$_SESSION['wsDomain']];
 		$nameattribute = $wgLDAPGroupNameAttribute[$_SESSION['wsDomain']];
 
-                // We actually want to search for * not \2a
-                $value = $dn;
-                if ( $value != "*" )
-                        $value = $this->getLdapEscapedString( $value );
-		$filter = "(&($attribute=$value)(objectclass=$objectclass))";
+		// We actually want to search for * not \2a
+		$value = $dn;
+		if ( $value != "*" )
+				$value = $this->getLdapEscapedString( $value );
+		
+		# Check to see if the search is scoped or not
+ 		if ( $value == "*" ) {
+			# HOLY CRAP!  All is too many - lets just get everything that
+			# we MIGHT need to compare to - filter on ALL MW groupnames and
+			# all user groupsnames
+			$localAvailGrps = $wgUser->getAllGroups();
+			
+			# We're going to scope down to existing MW groups
+			$attribute = $wgLDAPGroupNameAttribute[$_SESSION['wsDomain']];
+			
+			$filter = "(&(objectclass=$objectclass)(|";
+			
+			# Build filter for MW groups
+			foreach($localAvailGrps as $value) {
+				$filter .= "($attribute=$value)";
+			}
+			
+			# If the user has LDAP groups, build the filter for those too
+			if ( $this->foundUserLDAPGroups ) {
+				foreach($this->userLDAPGroups as $value) {
+					$filter .= "($attribute=$value)";
+				}
+			}
+			$filter .= "))";
+		} else {
+			# Scoped search, filter on the $dn provided
+			$filter = "(&($attribute=$value)(objectclass=$objectclass))";
+		}
 
 		$this->printDebug( "Search string: $filter", self::SENSITIVE );

→Tim Laqua^{Talk | contribs}_{@16:25, 2 September 2007 (UTC)}

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#Type_taxonomy. 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):

# 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

### GROUP CRAP

#DNs in $wgLDAPRequiredGroups must be lowercase, as search result attribute values are...
$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" );

/** $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#Problems_with_underlines_in_username_.28AD.29
--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.

// in retrieve preferences
if (isset($info[0]["cn"])) {
        $this->realname = $info[0]["cn"][0];
}

any help greatly appreciated

# pull back display name, email etc
$wgLDAPRetrievePrefs = array("production.local" => true);

Changing:

// in retrieve preferences
if (isset($info[0]["cn"])) {
        $this->realname = $info[0]["cn"][0];
}

to:

// in retrieve preferences
if (isset($info[0]["givenname"])) {
        $this->realname = $info[0]["givenname"][0];
}

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

'fields' => array('user_real_name','user_name',
                        'MAX(user_id) AS user_id',
                        'COUNT(ug_group) AS numgroups',
                        'MAX(ug_group) AS singlegroup'),
                        'options' => array('GROUP BY' => 'user_name'),
                        'conds' => $conds

• then in formatRow() add in the realname display:

        function formatRow( $row ) {
                $userPage = Title::makeTitle( NS_USER, $row->user_name );

                $name = $this->getSkin()->makeLinkObj( $userPage, htmlspecialchars( $userPage->getText() ) );
                $realname = ': <i>' .  $row->user_real_name . '</i>';

                if( $row->numgroups > 1 || ( $this->requestedGroup && $row->numgroups == 1 ) ) {
                        $list = array();
                        foreach( self::getGroups( $row->user_id ) as $group )
                                $list[] = self::buildGroupLink( $group );
                        $groups = implode( ', ', $list );
                } elseif( $row->numgroups == 1 ) {
                        $groups = self::buildGroupLink( $row->singlegroup );
                } else {
                        $groups = '';
                }

                return '<li>' . wfSpecialList( $name . $realname, $groups ) . '</li>';
        }

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

Thanks. How do I change the "special:Recentchanges" list, to include the user_real_name? --David, 18:58, 31 January 2008 (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:

Warning: require_once(LdapAuthentication.php) [function.require-once]: failed to open stream: No such file or directory in /var/www/html/wiki/LocalSettings.php on line 4

Fatal error: require_once() [function.require]: Failed opening required 'LdapAuthentication.php' (include_path='.:/usr/share/pear') in /var/www/html/wiki/LocalSettings.php on line 4

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:

require_once( './includes/LdapAuthentication.php' );
$wgAuth = new LdapAuthenticationPlugin();
$wgLDAPDomainNames = array( "ADDomain" );
$wgLDAPServerNames = array( "ADDomain"=>"XXXXX.XXXXX.XXX"  );
$wgLDAPSearchStrings = array( "ADDomain"=>"XXXXX\\USER-NAME"  );
$wgLDAPEncryptionType = array( "ADDomain"=>"ssl" );
$wgLDAPUseLocal = false;
$wgMinimalPasswordLength = 1;
$wgLDAPBaseDNs = array( "ADDomain"=>"OU=XXXXXX,DC=XXXXX,DC=XXXXX" );
$wgLDAPSearchAttributes = array( "ADDomain"=>"sAMAccountName" );
$wgLDAPDebug = 3;
$wgLDAPRetrievePrefs = array( "ADDomain"=>true );
$wgShowExceptionDetails = true;

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)

Hi,

I've all up-to-date versions of mediawiki and the ldap plugin. Still I have the The Same exact problem as Aren. I put all things in but the login page didn't change a bit... No errors, logs, anything!

Rodrigo.-

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?

$wgLDAPEncryptionType = array( "domain"=>"SSL" );

works, but

$wgLDAPEncryptionType = array( "domain"=>"ssl" );

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:

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

Aren Cambre 18:30, 27 September 2007 (UTC)

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)

It looks like the only one that needs anything done is #3. This will probably require core code changes. Notice that with this one, even if the user edits the field, the next time they log in, the field will be overwritten. I'll look into the core code changes, and I'll make a new config option to allow for preferences to be customized.
--Ryan lane 19:20, 16 August 2008 (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 — 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? — 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:

$wgLDAPUseLocal = true;
$wgLDAPDisableAutoCreate = array("MyDomain"=>"false");
$wgMinimalPasswordLength = 1;
...

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

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

$wgLDAPDisableAutoCreate = array("MyDomain"=>false);

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

<password-change-forbidden>

Backtrace:

#0 /usr/share/mediawiki/includes/SpecialUserlogin.php(311): User->setPassword('xxxxxx')
#1 /usr/share/mediawiki/includes/SpecialUserlogin.php(352): LoginForm->initUser(Object(User))
#2 /usr/share/mediawiki/includes/SpecialUserlogin.php(407): LoginForm->authenticateUserData()
#3 /usr/share/mediawiki/includes/SpecialUserlogin.php(103): LoginForm->processLogin()
#4 /usr/share/mediawiki/includes/SpecialUserlogin.php(19): LoginForm->execute()
#5 /usr/share/mediawiki/includes/SpecialPage.php(625): wfSpecialUserlogin(NULL, Object(SpecialPage))
#6 /usr/share/mediawiki/includes/SpecialPage.php(431): SpecialPage->execute(NULL)
#7 /usr/share/mediawiki/includes/Wiki.php(182): SpecialPage::executePath(Object(Title))
#8 /usr/share/mediawiki/includes/Wiki.php(47): MediaWiki->initializeSpecialCases(Object(Title), Object(OutputPage), Object(WebRequest))
#9 /usr/share/mediawiki/index.php(48): MediaWiki->initialize(Object(Title), Object(OutputPage), Object(User), Object(WebRequest))
#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.save Mon Oct 29 10:55:38 2007
--- LdapAuthentication.php      Mon Oct 29 10:55:48 2007
***************
*** 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
--- 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

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.

You can hide this with CSS; edit MediaWiki:Common.css, and add the following:

#mw-user-domain-section {
    display: none !important;
}

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 <path to base64 encoded cert>" and/or "TLS_CACERTDIR <path to a directory of hash linked cert files>".
--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!

Your php configuration may have "display_errors = on" set. Set this to off (notice this is the secure thing to do anyway).

I do wonder about your configuration though... Why are you setting group options, if you aren't doing group syncronization, or group restriction? Also, notice that you should define "$wgLDAPSearchStrings" like this:

$wgLDAPSearchStrings = array( "DOMAIN"=>"DOMAIN\\USER-NAME" );

Notice the extra backslash. It is important. That may also fix your problem.

--Ryan lane 23:15, 22 January 2008 (UTC)

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)

Just had the same problem. Quick (and dirty) patching (against latest version) was to do the following:

• add " var $nested_group_found; " in the global variables declaration,
• add " global $nested_group_found; " at the beginning of the "authenticate" function,
• in the same function as above, right after fetching User's groups (that makes line 394), add this line:

array_push($this->userLDAPGroups,substr($nested_group_found,3,strpos($nested_group_found,",")-3));

(here I use 3 because group name starts with "cn=..."

• and finally, in the function that searches for the nested group, when it is found (line 1256), add:

$nested_group_found = $checkme;

As I said quite dirty. This works if the User is in only one of the groups you are looking for because as Ryan said, the code stops after finding the first one. But at least you can use this nested group for access control...
Guimou

Cann't get LDAP group working

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:

 Entering validDomain
 User is using a valid domain.
 Setting domain as: ABC
 Entering getCanonicalName
 Username isn't empty.
 Munged username: Mohanc
 Entering authenticate
 Entering Connect
 Using TLS or not using encryption.
 Using servers: ldap://ad.abc.com
 Connected successfully
 Entering getSearchString
 Doing a straight bind
 userdn is: ARRK\Mohanc
 Binding as the user
 Bound successfully
 Entering getUserDN
 Created a regular filter: (sAMAccountName=Mohanc)
 Entering getBaseDN
 basedn is not set for this type of entry, trying to get the default basedn.
 Entering getBaseDN
 basedn is DC=abc, DC=com
 Using base: DC=abc, 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=MohanC,OU=LVL,OU=Users,OU=AIN,DC=abc,DC=com
 Checking for (new style) group membership
 Entering isMemberOfRequiredLdapGroup
 Warning: implode() [function.implode]: Bad arguments. in C:\wamp\www\wiki\extensions\LdapAuthentication.php on line 1185
 Required groups:
 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=abc, DC=com
 Search string: (&(member=CN=MohanC,OU=LVL,OU=Users,OU=AIN,DC=abc,DC=com)(objectclass=group))
 Returned groups:cn=developers,cn=users,dc=abc,dc=com,cn=rac group,cn=users,dc=abc,dc=com
 Returned groups:developers,rac group
 Warning: in_array() [function.in-array]: Wrong datatype for second argument in C:\wamp\www\wiki\extensions\LdapAuthentication.php on line 1200
 Warning: in_array() [function.in-array]: Wrong datatype for second argument in C:\wamp\www\wiki\extensions\LdapAuthentication.php on line 1200
 Couldn't find the user in any groups (2).
 Entering strict.
 Returning true in strict().
 Entering modifyUITemplate

However, If you see above it do return the groups for the user but still it won't authenticate the user. Also, when I enable the group based restriction there are some PHP related warnings.

My local settings file contains:

 #LDAP Auth Start
 require_once 'extensions/LdapAuthentication.php';
 $wgAuth = new LdapAuthenticationPlugin();
 $wgLDAPDomainNames = array('abc');
 $wgLDAPServerNames = array('abc' => 'ad.abc.com');
 $wgLDAPSearchStrings = array( 'abc' => 'ABC\\USER-NAME');
 $wgLDAPEncryptionType = array( 'abc' => 'clear');
 $wgLDAPUseLocal = false;
 $wgMinimalPasswordLength = 8;
 $wgLDAPBaseDNs = array( 'abc' => 'DC=abc, DC=com');
 $wgLDAPSearchAttributes = array( 'abc' => 'sAMAccountName');
 #GROUPS
 $wgLDAPRequiredGroups = array('abc' => 'ou=groups, dc=abc, dc=com');
 $wgLDAPGroupUseFullDN = array( 'abc'=> true);
 $wgLDAPGroupObjectclass = array('abc' => 'group');
 $wgLDAPGroupAttribute = array('abc' => 'member');
 $wgLDAPGroupSearchNestedGroups = array('abc' => false);
 $wgLDAPGroupNameAttribute = array( 'abc'=>'cn' );
 #Debug Purpose only
 $wgLDAPDebug = 99;
 #LDAP Auth Ends

I am using MediaWiki 1.6.10 and LdapAuthentication 1.1g.

Please advice.

Regards,

Mohan

Notice that:

$wgLDAPRequiredGroups = array('abc' => 'ou=groups, dc=abc, dc=com');

should be an array of arrays, and it should list specific groups, not an ou. An example would be:

$wgLDAPRequiredGroups = array('abc' => array( 'cn=wikiadmins, ou=groups, dc=abc, dc=com', 'cn=wikiusers, ou=groups, dc=abc, dc=com' ) );

--Ryan lane 23:09, 22 January 2008 (UTC)

undefined variables: $mailpassword and $updateLDAP

function allowPasswordChange() (line 586 of LDAPAuthentication.php) doesn't predefine these variables to a base case so depending on flow of execution through the function they are either undefined or set when tested. They should be set to something say "false" at the top of the function.

I'm assuming this is fixed? I'm checking to see if they are set or not. They don't need a base case. If they aren't defined, then it is the same as if they are turned off.
--Ryan lane 21:51, 16 August 2008 (UTC)

AD Required Groups

I'm using MediaWiki 1.9.3 and Ldapauthentication 1.1g

My LocalSettings.php

// LDAP Add
require_once( "includes/LdapAuthentication.php" );
$wgAuth = new LdapAuthenticationPlugin();
$wgLDAPDomainNames      = array( "MI" );
$wgLDAPServerNames      = array( "MI"=>"ql1dc5.mi.corp.rockfin.com" );
$wgLDAPUseLocal         = false;
$wgLDAPEncryptionType = array( "MI"=>"tls" );
$wgLDAPSearchStrings = array( "MI"=>"MI\\USER-NAME" );
$wgMinimalPasswordLength= 1;
$wgLDAPRetrievePrefs    = true;
$wgLDAPUpdateLDAP       = false;
$wgLDAPAddLDAPUsers     = false;
$wgLDAPDebug=3;
$wgLDAPLowerCaseUsername = array("MI"=>true);
$wgLDAPGroupUseRetrievedUsername = array("MI"=>false);
$wgLDAPGroupBaseDNs = array("MI"=>"dc=mi,dc=corp,dc=rockfin,dc=com");
$wgLDAPUserBaseDNs = array("MI"=>"dc=mi,dc=corp,dc=rockfin,dc=com");
# AD Group Stuff
$wgLDAPRequiredGroups = array( "MI"=>array("cn=it team wmd,ou=restricted,ou=distribution groups,ou=groups,dc=mi,dc=corp,dc=rockfin,dc=com") );
$wgLDAPGroupUseFullDN = array( "MI"=>true );
$wgLDAPGroupObjectclass = array( "MI"=>"group" );
$wgLDAPGroupAttribute = array( "MI"=>"member");
$wgLDAPGroupSearchNestedGroups = array( "MI"=>true );
$wgLDAPGroupNameAttribute = array( "MI"=>"cn" );
$wgLDAPBaseDNs = array("MI"=>"dc=mi,dc=corp,dc=rockfin,dc=com");
$wgLDAPSearchAttributes = array("MI"=>"samaccountname");
// End LDAP

It authenticates the user correctly but craps out on the groups.

Entering validDomain
User is using a valid domain
Entering getCanonicalName
Munged username: Jmcdonald
Entering Connect
Entering Connect
Using servers: ldap://ql1dc5.mi.corp.rockfin.com
Connected successfully
Entering getSearchString
Doing a straight bind
userdn is: MI\Jmcdonald
Binding as the user
Binded successfully
Checking for (new style) group membership
Entering isMemberOfRequiredLdapGroup
Required groups:cn=it team wmd,ou=restricted,ou=distribution groups,ou=groups,dc=mi,dc=corp,dc=rockfin,dc=com
Entering getGroups
Search string: (&(member=MI\Jmcdonald)(objectclass=group))
Warning: ldap_get_entries(): supplied argument is not a valid ldap result resource in /var/www/wikitest.mi.corp.rockfin.com/htdocs/includes/LdapAuthentication.php on line 857
Warning: array_shift() [function.array-shift]: The argument should be an array in /var/www/wikitest.mi.corp.rockfin.com/htdocs/includes/LdapAuthentication.php on line 860
Warning: Invalid argument supplied for foreach() in  /var/www/wikitest.mi.corp.rockfin.com/htdocs/includes/LdapAuthentication.php on line 863
Returned groups:
Couldn't find the user in any groups (1).

The search string should be McDonald\, Joe, etc... (distinguishedName)

Remove the following:

$wgLDAPUpdateLDAP       = false;
$wgLDAPAddLDAPUsers     = false;
$wgLDAPLowerCaseUsername = array("MI"=>true);
$wgLDAPGroupBaseDNs = array("MI"=>"dc=mi,dc=corp,dc=rockfin,dc=com");
$wgLDAPUserBaseDNs = array("MI"=>"dc=mi,dc=corp,dc=rockfin,dc=com");

And set these options:

$wgLDAPRetrievePrefs    = array("MI"=>true); # nearly all options use the array syntax
$wgLDAPGroupUseRetrievedUsername = array("MI"=>true);

Notice that you are using AD-style straight binding. To search for a user in a group, you can't use the AD-style syntax, and instead have to use the user's full DN. When the plugin binds as the user, it will only get the user's full DN if you set "$wgLDAPGroupUseRetrievedUsername". Also, there shouldn't be a reason to lowercase the user's login. AD generally doesn't care so much about case. If you are still having issues, you can try adding that back in.

--Ryan lane 15:44, 7 February 2008 (UTC)

Thanks for the help. I made the corrections but it still didn't work. I modified the $wgLDAPEncryptionType to clear and everything worked (I tried both ssl and tls.)

--jmcdonald 10:43, 8 February 2008

You likely have an issue with your SSL trust; or, you may not have an SSL certificate installed on your AD server.
--Ryan lane 17:05, 19 February 2008 (UTC)

I have done like this and got it working. I also took a look at how to add new admin-user. But where should I add that user? To ldap-server or to Localsettings.php?

--ThaFox 15:46, 18 November 2008

Not able to add Group based access control - Please help..

Hi, Like a few other I am also trying to set up group based permissions for my wiki. I started with adding LDAP authentication for n entire domain and that worked just fine.

Now I am trying to restrict access to only a group and am not bale to do it right.

these are my settings...

require_once( 'LdapAuthentication.php' );
$wgAuth = new LdapAuthenticationPlugin();
$wgLDAPDomainNames = array("abc");
$wgLDAPServerNames = array("abc"=>"abc.xyz.com");
$wgLDAPEncryptionType = array("abc"=>"clear");
$wgLDAPSearchAttributes = array("abc"=>"sAMAccountName");
$wgLDAPBaseDNs = array("abc"=>"dc=abc,dc=xyz,dc=com");
$wgLDAPSearchStrings = array("abc"=>"abc\\USER-NAME");
$wgLDAPRetrievePrefs = array("abc"=>true);
$wgMinimalPasswordLength = 1;
$wgGroupPermissions['*']['edit'] = false;
$wgGroupPermissions['user']['edit'] = true;
$wgGroupPermissions['*']['createaccount'] = false;
It does not work even if these 2 are commented
$wgLDAPAddLDAPUsers = false;
$wgLDAPUpdateLDAP = false;

Group Permissions

$wgLDAPGroupUseFullDN = array("abc"=>true );

$wgLDAPGroupUseRetrievedUsername = array("abc"=>true );

$wgLDAPGroupObjectclass = array("abc"=>"group");

$wgLDAPGroupAttribute = array("abc"=>"member");

$wgLDAPGroupNameAttribute = array("abc"=>"sAMAccountName");

$wgLDAPRequiredGroups = array(
   "abc"=>array(
     "cn=gp_developers,cn=gp_groups,ou=Groups,ou=Lins,dc=abc,dc=xyz,dc=com",
        
     )
 );  (The normal domain based authentication works when this part is commented out..so I ma assuming there's a problem here..but I do not know what)

$wgLDAPGroupSearchNestedGroups = array("abc"=>false);

I have the LDAPAuth...php version 1.1g, PHP version 5.2 and apache 2.2. Do I need any other extension for Group based restriction to work?

Any help will be highly appreciated.

Thanks

cn=...,cn=.. doesn't look like a valid name to me. Is gp_groups an OU? --213.182.148.34 11:49, 27 February 2008 (UTC)

Text file white list

Hi all... I'm in a situation where I can authenticate users via LDAP, but there are no appropriate LDAP groups which match the subset of users that I want to authorise for access to the wiki. What I need is for users to be authenticated by the LDAP extension, and then the logon should be rejected if their username does not appear in the white-list file. Does this sound possible? I'd be happy to jump in and make PHP changes myself, if someone could point me in the right direction. - Borofkin 04:27, 18 February 2008 (UTC)

Don't worry -- this has turned out to be a dead-easy modification. - Borofkin 05:58, 18 February 2008 (UTC)

You may be able to do this without modifying the code if you are using a search based configuration, by doing the following:

//Require the following additional search string.
$wgLDAPAuthAttribute = array(
  "yourDomain"=>"!(|(uid=user1)(uid=user2)(uid=user3)(uid=...))"
  );

--Ryan lane 17:03, 19 February 2008 (UTC)

Authenticating against AD and Local

Hello, I have my wiki setup to authenticate against AD. I would also like to set it up to check and see if the username is in a local list before allowing them access. I am willing to place all the names in an array and then check against the array. Or, place the users in the table and then only allow the user to authenticate if they are in the table. Any help would be great. Thanks, Shane

I have created an array of usernames and then a loop to check the user against that array, I placed this the getCanonicalName function. This is placed directly after the if statement to see if the username is not blank:

 $LDAPallowedUsers = array("sjordan", "ebock", "ereger", "djoseph2", "ntennant", "jfarley1", "jraisovich", "araisovich"); 
 $num_users = 0;
 foreach($LDAPallowedUsers as $num=>$users){ 
   $matches = strcmp(strtolower($users), strtolower($username)); 
   if($matches == 0){ 
     $num_users++;
   }
 } 
 if($num_users == 0){
   return 'XXYYXX';
 } 

This probably isn't the best way, since it still goes and does a check for XXYYXX user in the domain, but it is working. I wanted to define my array in the LocalSetting.php file, but when I try to do this, it causes the wiki to generate blank pages. Anyone know what I have to do to create the array in LocalSettings? - Shane

I recommend restricting by AD groups instead. Notice, however, this is the same question that was asked above. Also, in response to the code posted as a solution: it'll work, but it probably a better idea to put this in the authenticate() function, somewhere close to the top.
--Ryan lane 18:28, 3 March 2008 (UTC)

I have tried a slight change which seems to accomplish what you are mentioning. I put a global variable $wgLDAPAllowedUsers in the authenticate function and added a statement just below the debug statement also in the authenticate function

global $wgLDAPAllowedUsers
.
.
.
if (!in_array(strtolower($username), $wgLDAPAllowedUsers)) {
   return false;
}

Then in LocalSettings.php I can put in the array of users I want.

$LDAPallowedUsers = array("sjordan", "ebock", "ereger", "djoseph2", "ntennant", "jfarley1", "jraisovich", "araisovich"); 

[[Rbarton 15:26, 23 September 2008 (UTC)]]

Several Wiki Authentication (Something like SSO)

We have a Mediawiki 1.11 with the "LDAP Authentication Extension" installed. It works with an AD server flawlessly.

As we have several Wikis working in a Wiki family it would be great to authenticate once for all the wikis in the family. Otherwise one has to authenticate for each Wiki individually. The entire Wiki Family is running under the same domain.

Is there a way to tweak, hack or extend the environment so one can login once for several Wikis? I guess one has to fiddle with the user_token cookie. But I couldn't really find information about the process. Any help is highly appreciated. Thank you.

I haven't looked into this much. You may want to look at how they plan on doing this with SSO for wikipedia. I believe this is the extension in question.
--Ryan lane 18:25, 3 March 2008 (UTC)

Thank you for the hint. CentralAuth is a SUL (Single User Login) effort. Dealing with the problem of people having accounts with different user names for different wikis. Thus it is about merging users. Single Sign On among Wikis may happen at a later point in time, is stated on the project pages.

The OpenID Extension is doing a Single Sign On though it doesn't make sense when you've got AD or LDAP...

Now that you point that out, it looks like you are completely right. No SSO, just merging as of now. OpenID/Shibboleth/WebSSO/Federation, and other approaches do SSO by authenticating in one spot, and passing an authentication token to all sites. This isn't the kind of thing that can be done with regular web authentication. You may want to look at using Federation (aka Shibboleth aka WebSSO). Federated authentication works along side LDAP authentication, and in many cases is simply an add-on to another product you are already using. You may want to take a look at Sun's suite of products (Sun Directory Server, Sun Access Manager), as they are free for use unless you want support. Access manager does SSO. You may also want to look at Atlassian's crowd authentication. There is already a MediaWiki plugin available for crowd auth.
--Ryan lane 19:33, 14 March 2008 (UTC)

Copy E-Mail-Adress to wiki database when user logs in for the first time

Is there any configuration option that when a user logs in for the first time, the E-Mail-Adress is automatically copied to the wiki database?

$wgLDAPRetrievePrefs = array( "domainname"=>true );

This will pull the "mail", "preferredLanguage", "displayName", and "cn" attributes from the user's LDAP entry, if available, and populate the wiki database with those values. If you need to change the attributes, you'll have to do it manually in the code for now. A more customizable way of doing this is on the todo list for the next release.
--Ryan lane 18:23, 3 March 2008 (UTC)

Added Group Based Permission and wiki stopped authenticating the user

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 LDAP 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:

 Entering validDomain
 Entering validDomain
 User is using a valid domain.
 Setting domain as: ARRK
 Entering getCanonicalName
 Username isn't empty.
 Munged username: Rajeshmr
 Entering authenticate
 Entering Connect
 Using TLS or not using encryption.
 Using servers:  ldap://127.0.0.1
 Connected successfully
 Entering getSearchString
 Doing an anonymous bind
 Entering getUserDN
 Created a regular filter: (uid=Rajeshmr)
 Entering getBaseDN
 basedn is not set for this type of entry, trying to get the default basedn.
 Entering getBaseDN
 basedn is DC=arrkgroup, DC=com
 Using base: DC=arrkgroup, 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.
 userdn is: uid=rajeshmr,ou=People,dc=example,dc=com
 Binding as the user
 Bound successfully
 Checking for (new style) group membership
 Entering isMemberOfRequiredLdapGroup
 Required groups:cn=arrk, ou=group,  dc=example, 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=example, DC=com
 Search string: (&(memberuid=Rajeshmr)(objectclass=posixgroup))
 Returned groups:cn=arrk,ou=group,dc=example,dc=com
 Returned groups:arrk
 Couldn't find the user in any groups (2).
 Entering strict.
 Returning true in strict().
 Entering modifyUITemplate

However, If you see above it do return the groups for the user but still it won't authenticate the user.

My local settings file contains:

 #LDAP Auth Start
 require_once 'extensions/LdapAuthentication.php';
 $wgAuth = new LdapAuthenticationPlugin();
 $wgLDAPDomainNames = array('ARRK');
 $wgLDAPServerNames = array('ARRK' => '127.0.0.1');
 #$wgLDAPSearchStrings = array( 'ARRK' => 'uid=USER-NAME,ou=people,dc=example,dc=com');
 $wgLDAPSearchAttributes = array( 'ARRK' => 'uid');
 $wgLDAPBaseDNs = array( 'ARRK' => 'DC=example, DC=com');
 $wgLDAPEncryptionType = array( 'ARRK' => 'clear');
 $wgLDAPUseLocal = false;
 $wgMinimalPasswordLength = 1;
 $wgLDAPRequiredGroups = array('ARRK'=>array('cn=arrk, ou=group,  dc=example, dc=com'));
 $wgLDAPGroupUseFullDN = array( 'ARRK'=>false);
 $wgLDAPGroupLowerCaseUsername = true;
 $wgLDAPGroupObjectclass = array('ARRK' => 'posixgroup');
 $wgLDAPGroupAttribute = array('ARRK' => 'memberuid');
 $wgLDAPGroupSearchNestedGroups = array('ARRK' => false);
 $wgLDAPGroupNameAttribute = array( 'ARRK'=>'cn' );
 $wgLDAPDebug = 9;
 #LDAP Auth Ends

I am using MediaWiki 1.6.10 and LdapAuthentication 1.1g.

Please advice.

Regards, Rajesh

You may notice that the group being returned is "cn=arrk,ou=group,dc=example,dc=com", and the group you are requiring is "cn=arrk, ou=group, dc=example, dc=com". Take the spaces out of the group you are requiring.
--Ryan lane 19:24, 14 March 2008 (UTC)

I stumbled over the same problem today. Maybe the issue should be mentioned on the main page. (Btw, you do a great job, Ryan)
--TimPe 2008-05-21

Groups from LDAP are displayed correctly in "returned group" but they don't find their way into Database

First of all thanks for the great work!

I want to authenticate with LDAP and synchronize then these Groups with my local Database. For testing i setted up a Domaincontroller with the Domain "Streichelzoo.de" and I created for example a User "Test2" who is in 2 Groups "asdf" and "Testgruppe". These Groups i get wonderfully displayed at the Debug Mode in "Returned Groups" but not in Effective Groups. Here is the Debug:

  Setting domain as: Streichelzoo
  Entering getCanonicalName
  Username isn't empty.
  Munged username: Test2
  Entering authenticate
  Entering Connect
  Using TLS or not using encryption.
  Using servers: ldap://admin.streichelzoo.de
  Connected successfully
  Lowercasing the username: Test2
  Entering getSearchString
  Doing a straight bind
  userdn is: Streichelzoo\test2
  Binding as the user
  Bound successfully
  Entering getUserDN
  Created a regular filter: (sAMAccountName=test2)
  Entering getBaseDN
  basedn is not set for this type of entry, trying to get the default basedn.
  Entering getBaseDN
  basedn is dc=streichelzoo,dc=de
  Using base: dc=streichelzoo,dc=de
  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=Test2,CN=Users,DC=streichelzoo,DC=de
  Retrieving LDAP group membership
  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=streichelzoo,dc=de
  Search string: (&(member=CN=Test2,CN=Users,DC=streichelzoo,DC=de)(objectclass=group))
  Returned groups:cn=asdf,cn=users,dc=streichelzoo,dc=de,cn=testgruppe,cn=users,dc=streichelzoo,dc=de
  Returned groups:asdf,testgruppe
  Entering getAllGroups
  Entering getGroups
  Entering getBaseDN
  basedn is not set for this type of entry, trying to get the default basedn.
  Entering getBaseDN
  basedn is dc=streichelzoo,dc=de
  Search string: (&(member=*)(objectclass=group))
  Returned groups:cn=hilfedienstgruppe,cn=users,dc=streichelzoo,dc=de,cn=administratoren,cn=builtin,dc=streichelzoo,dc=de,cn=   benutzer,cn=builtin,dc=streichelzoo,dc=de,cn=g㤳te,cn=builtin,dc=streichelzoo,dc=de,cn=leistungsprotokollbenutzer,cn=builtin,dc=   streichelzoo,dc=de,cn=schema-admins,cn=users,dc=streichelzoo,dc=de,cn=organisations-admins,cn=users,dc=streichelzoo,dc=de,cn=dom㤮en   -admins,cn=users,dc=streichelzoo,dc=de,cn=richtlinien-ersteller-besitzer,cn=users,dc=streichelzoo,dc=de,cn=pr㤭windows 2000    kompatibler    zugriff,cn=builtin,dc=streichelzoo,dc=de,cn=windows-autorisierungszugriffsgruppe,cn=builtin,dc=streichelzoo,dc=de,cn=wikiuser,cn=users,dc=streichelzoo,dc=de,cn=wikiadmins,cn=users,dc=streichelzoo,dc=de,cn=asdf,cn=users,dc=streichelzoo,dc=de,cn=haus,cn=users,dc=streichelzoo,dc=de,cn=testgruppe,cn=users,dc=streichelzoo,dc=de
  Returned groups:hilfedienstgruppe,administratoren,benutzer,g㤳te,leistungsprotokollbenutzer,schema-admins,organisations-admins,dom㤮en-admins,richtlinien-ersteller-besitzer,pr㤭windows 2000 kompatibler zugriff,windows-autorisierungszugriffsgruppe,wikiuser,wikiadmins,asdf,haus,testgruppe
  Authentication passed
  Entering updateUser
  Setting user groups.
  Entering setGroups.
  Locally managed groups: bot,sysop,bureaucrat,
  Adding all groups to wgGroupPermissions: hilfedienstgruppe,administratoren,benutzer,g㤳te,leistungsprotokollbenutzer,schema-admins,      organisations-admins,dom㤮en-admins,richtlinien-ersteller-besitzer,pr㤭windows 2000 kompatibler    zugriff,windows-autorisierungszugriffsgruppe,wikiuser,wikiadmins,asdf,haus,testgruppe
  Available groups are: Administrator,bot,sysop,bureaucrat,WikiAdmins
  Effective groups are: dom㤮en-benutze,*,user,autoconfirmed
  Checking to see if user is in: Administrator
  Entering hasLDAPGroup
  Checking to see if user is in: bot
  Entering hasLDAPGroup
  Checking to see if user is in: sysop
  Entering hasLDAPGroup
  Checking to see if user is in: bureaucrat
  Entering hasLDAPGroup
  Checking to see if user is in: WikiAdmins
  Entering hasLDAPGroup
  Saving user settings.

Here are my Settings in the LocalSettings.php

  require_once 'extensions/LdapAuthentication.php';
  $wgAuth = new LdapAuthenticationPlugin();
  #$wgLDAPBaseDNs = "streichelzoo";
  $wgLDAPBaseDNs = array('Streichelzoo'=>'dc=streichelzoo,dc=de');
  $wgLDAPDomainNames = array('Streichelzoo');
  $wgLDAPServerNames = array('Streichelzoo' => 'admin.streichelzoo.de');
  $wgLDAPSearchStrings = array('Streichelzoo' => 'Streichelzoo\\USER-NAME');
  $wgLDAPEncryptionType = array('Streichelzoo' => 'clear');
  $wgLDAPUseLocal = false;
  $wgMinimalPasswordLength = 1;
  $wgLDAPGroupUseFullDN = array("Streichelzoo"=>true);
  $wgLDAPLowerCaseUsername = array("Streichelzoo"=>true);
  $wgLDAPGroupObjectclass = array("Streichelzoo"=>"group");
  $wgLDAPGroupAttribute = array("Streichelzoo"=>"member");
  $wgLDAPGroupNameAttribute = array( "Streichelzoo"=>"cn" );
  $wgLDAPUseLDAPGroups = array("Streichelzoo"=>"true");
  $wgLDAPLocallyManagedGroups = array("Streichelzoo"=>array( "" ));
  $wgLDAPGroupsPrevail = array("Streichelzoo"=>true);
  $wgLDAPGroupSearchNestedGroups = array("streichelzoo"=>true);
  $wgLDAPSearchAttributes = array( "Streichelzoo"=>"sAMAccountName" );

Is something wrong here? I have no more idea what i could do...

Greets Franz

Groups only get modified if they are set in $wgGroupPermissions in LocalSettings.php; this is a MediaWiki-ism. Once you assign the groups rights, they'll show up.
--Ryan lane 14:23, 28 March 2008 (UTC)

Handling empty searches

When LdapAuthenticationPlugin::getSearchString() returns an empty string and smartcard auth is not used, the search is performed, but returns a result on my setup:

$entry = Array
(
    [count] => 1
    [0] => Array
        (
            [objectclass] => Array
                (
                    [count] => 2
                    [0] => top
                    [1] => OpenLDAProotDSE
                )
            [0] => objectclass
            [count] => 1
            [dn] => 
        )
)

My quick and dirty solution is to change: (LdapAuthenticationPlugin.php@112)

//Search for the entry.
	$entry = @ldap_read( $ldapconn, $searchstring, "objectclass=*" );

to:

//Search for the entry.
if ( $searchstring != '' )
	$entry = @ldap_read( $ldapconn, $searchstring, "objectclass=*" );

This gives me the correct behaviour.

...and just for completeness, I'm using version 1.1g on Debian and not using the smartcard stuff, if that helps.

83.67.10.100

Thanks for the patch, I'll add this in the next version.
--Ryan lane 22:26, 24 April 2008 (UTC)

Database updates not transactional on LDAP failures

When you have LDAP issues (be they configuration or otherwise,) the user accounts are written into the database regardless of whether they were written into the LDAP directory successfully. Ideally, this should be transactional. When developing my configuration I had to keep hacking out the wiki users from the MySQL tables.

83.67.10.100

I'll put this on my (ever increasing, hasn't decreased in a while) todo list; thanks for the report!
--Ryan lane 22:25, 24 April 2008 (UTC)

I just looked into this, and I can't replicate this problem. Can you please provide me a more detailed problem report? Please provide MediaWiki version, Ldap plugim version, in what circumstance users are being added to the local database, and not in LDAP, how the LDAP configuration was incorrect in this situation, and anything else that may be applicable. I also looked at the code and can't see a situation in which this would be possible.
--Ryan lane 18:23, 2 January 2009 (UTC)

AD authentication failure

Hello -

For about an hour, I had the LDAP Authentication working successfully.

Now I have an issue with authentication. After all was working, I reset the machine address for a static address for this linux server,and rebooted. I tried to authenticate, and now receive this debug error:

Entering validDomain
User is using a valid domain.
Setting domain as: abc.local
Entering getCanonicalName
Username isn't empty.
Munged username: Hessond
Entering authenticate
Entering Connect
Using TLS or not using encryption.
Using servers: ldap://servername.abc.local
Connected successfully
Entering getSearchString
Doing a straight bind
userdn is: ABC.LOCAL\Hessond
Binding as the user
Failed to bind as ABC.LOCAL\Hessond
Entering strict.
Returning true in strict().
Entering modifyUITemplate

Please can you assist? I've been hacking at this way too long. Best, D

Please post your configuration with any sensitive info snipped out.
--Ryan lane 22:26, 24 April 2008 (UTC)

Did not see: Entering authenticatie. Entering Connect

I have mediawiki 1.10, and LdapAuthentication.php 1.1g.

I have this settings in LocalSettings.php:

require_once( "$IP/extensions/LdapAuthentication.php" );

$wgAuth = new LdapAuthenticationPlugin();

$wgLDAPDomainNames = array("wikiLDAPdomain");

$wgLDAPServerNames = array("wikiLDAPdomain"=>"myserver.mycompany.com");

$wgLDAPUseLocal = true;

$wgLDAPEncryptionType = array("wikiLDAPdomain"=>"SSL");

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

$wgLDAPBaseDNs = array("wikiLDAPdomain"=>"dc=myserver,dc=mycompany.com");

$wgLDAPDisableAutoCreate = array("wikiLDAPdomain"=>true);

$wgLDAPDebug = 3;

When I tried to login, I got the following debug info:

Entering validDomain

User is using a valid domain

Setting domain as: wikiLDAPdomain

Entering getCanonicalName

Username isn't empty

Munged username: myname@mycompany.com

Entering modifyUITemplate

Allowing the local domain, adding it to the list

That is, I didnot see "Entering authenticate" and "Entering Connect" that most people will see.

Can someone tell me what link is broken? Thanks.

You likely do not have LDAP support in PHP. Check to ensure that you do using "php -i".
--Ryan lane 22:23, 24 April 2008 (UTC)

Signature with Real Name

Hi, is it possible do save the Realname instead of Username if a user makes his sign on a Side? In our Ldap we log in with a Number, for the Login thats ok but I want wo see who has written an article. Thanks in Advance --87.154.138.194 20:18, 10 April 2008 (UTC)

You may be able to do this in the getCanonicalName() function. I'll look into it and hopefully give you a better/more in depth answer.
--Ryan lane 22:28, 24 April 2008 (UTC)

That would be pefect if you could help me :-) Thanks a lot Ryan --62.159.112.104 09:58, 30 April 2008 (UTC)

You may be interested in my #Enterprise LDAP Solution to show real name and much more as the User page. Also allows roles to be dependent on LDAP (sysop and bureaucrats)

Any update on this or the next stable version of the extension?

I've been so busy lately that I'm not expecting another release for a while. I'm sure it is probably doable, though. I mean, I do it in the SSL authentication portion of the code. You may want to look at how I'm doing it there, and see if you can replicate it. In fact, here is how I set the username to something other than what the user's smartcard has (in LocalSettings.php):

// This hook is called by the LdapAuthentication plugin. It is a configuration hook. Here we
// are specifying what attibute we want to use for a username in the wiki.
// The hook calls the function defined below.
$wgHooks['SetUsernameAttributeFromLDAP'][] = 'SetUsernameAttribute';

// This function allows you to get the username from LDAP however you need to do it.
function SetUsernameAttribute(&$LDAPUsername, $info) {
        $LDAPUsername = $info[0]['cn'][0];
        // All hooks have to return a boolean in MediaWiki
        return true;
}

Notice that this won't work if you are doing straight binds, unless you are doing AD-style binding (ie: DOMAIN\\USER-NAME) and are doing extra configuration.
--Ryan lane 22:11, 26 June 2008 (UTC)

Problem Whit RSS Feed after implenting LDAP

Hi there,

Been new user of LDAP Auth wich is working fine, but my rss feed are not working anymore, do we have a fix or workaround for that ?

Thanks a lot in advance.

you can get me per email at flamontagne@no_spam.noxent.com (need to remove the no_spam)

I'm not sure what to tell you, this plugin shouldn't affect that at all (and my RSS feeds are working just fine). Disable the LDAP plugin and see if your RSS feeds start working again; if so, check your configuration for something very wrong; if not, then the LDAP plugin isn't your problem.
--Ryan lane 22:30, 24 April 2008 (UTC)

Images don't have any security

Hi, I'm not sure if I did something wrong with the set-up, but my images directory doesn't have any security on it, so you don't need to authenticate to view them. If you remove read permission from public users, this solves the problem, but then even authenticated users can't view the images. Obviously the issue is that the images are being viewed as flat files.

Thanks in advance for any help!

You need to use img_auth.php, otherwise Apache is handing out the images, and Apache isn't asking for authentication.
--Ryan lane 22:20, 24 April 2008 (UTC)

Using Apache for image security

Hello, Is there a way to have apache handle the LDAP authentication but then have this extension grab the user name and log them into mediawiki after they have authenticated through apache? Much thanks in advance for your help!

Yes, but this extension is overkill if that is all you need. You might want to look at Extension:HttpAuth or one of the other extensions like it. This extension is useful if you want to do more than what Apache's module can do, and/or want to deliver a friendlier login screen.
--Ryan lane 17:12, 28 October 2008 (UTC)

Problem with Underscores in User Names

Hiya All,

My users all have account names with an underscore in them e.g. Name_Surname.

When entering NAME_SURNAME I get this with debugging turned on:

Connected successfully
Entering getSearchString
Doing a straight bind
userdn is: ENTERPRISE\Wayne humphrey
Binding as the user
Failed to bind as ENTERPRISE\Wayne humphrey
Entering modifyUITemplate

However if I hard code my user name in LocalSettings.php e.g. Replace

 "ENTERPRISE"=>"ENTERPRISE\\USER-NAME",

With

 "ENTERPRISE"=>"ENTERPRISE\\MyName_Surname", 

I get a sucsefful login:

Connected successfully
Entering getSearchString
Doing a straight bind
userdn is: DOMAIN\MyName_Surname
Binding as the user
Bound successfully
Entering getUserDN
Created a regular filter: (=MyName surname)
Entering getBaseDN
basedn is not set for this type of entry, trying to get the default basedn.
Entering getBaseDN
basedn is not set.
Using base:
Couldn't find an entry
Pulled the user's DN:
Authentication passed
Entering updateUser

so mediwiki stripping the underscore.

I have worked around this problem by adding the following to this extension:

In function getSearchString

add

$username =  str_replace(' ','_',$username);

below

$tmpuserdn = $wgLDAPSearchStrings[$_SESSION['wsDomain']];

I know this is a dirty hack, so does anyone have any better ways in doing this?

Thanks,

--wayne

This has come up in the past, and is somewhere around here on this page, or possible in the archive. I have no graceful way to solve this.
--Ryan lane 22:01, 26 June 2008 (UTC)

MediaWiki API with LDAP

Is there any way to use the MediaWiki API with LDAP authentication? Logins via the API all fail because the API does not know about the "wpDomain" value. --Maiden taiwan 17:02, 20 May 2008 (UTC)

Never mind, looking at MW source code, it looks like it's aware of domains. Just have to figure out how to use it. --Maiden taiwan 17:05, 20 May 2008 (UTC)

MediaWiki on WIMP server, SSL Auth to AD

Hi I have MediaWiki 1.11 running on Windows 2003/IIS/PHP/My SQL with the ldap 1.1g extension installed

I am able to authenticate when the $wgLDAPEncryptionType is set to clear but not when set to ssl.

• All DC's have ssl certs installed for LDAPs
• The trusting CA certificate has been added to the trusted root certificate authorities using the mmc certificates snap-in on the server running WIMP/MediaWiki
• From the WIMP/MediaWiki server I have validated 636/3289 ldaps access to AD is working by using ldp.exe and binding to AD over ssl without issue
• php.ini has been updated to enable the php ldap extension
• LocalSettings.php has been updated as follows (sensitive information removed

# S Coney Installed Extension LDAP Authentication 1.1g

require_once $IP . "/extensions/LdapAuthentication/LdapAuthentication.php";
$wgAuth= new LdapAuthenticationPlugin(); 

$wgLDAPDomainNames = array( "domain1" ); 
$wgLDAPServerNames = array( "domain1"=>"dc1.msp.domain1.net dc2.msp.domain1.net dc3.msp.domain1.net" ); 
$wgLDAPSearchStrings = array("domain1"=>"domain1\\USER-NAME");
$wgLDAPEncryptionType = array("domain1"=>"ssl");
$wgMinimalPasswordLength = 1; 

$wgLDAPSearchAttributes = array("domain1"=>"sAMAccountName");
$wgLDAPBaseDNs = array("domain1"=>"dc=msp,dc=domain1,dc=net");

$wgLDAPDebug = 3;

When trying to logon to MediaWiki with these settings I get

Entering validDomain
User is using a valid domain.
Setting domain as: domain1
Entering getCanonicalName
Username isn't empty.
Munged username: User05
Entering userExists
Entering authenticate
Entering Connect
Using SSL
Using servers: ldaps://dc1.msp.domain1.net ldaps://dc2.msp.domain1.net ldaps://dc3.msp.domain1.net
Connected successfully
Entering getSearchString
Doing a straight bind
userdn is: domain1\User05
Binding as the user
Failed to bind as domain1\User05
Entering modifyUITemplate

If I set the $wgLDAPEncryptionType to a value of "clear" I get authenticated, the first time as follows (creating the mediawiki account. Subsequent logons create less debug due to the account already existing but work successfully.

Entering validDomain
User is using a valid domain.
Setting domain as: domain1
Entering getCanonicalName
Username isn't empty.
Munged username: User05
Entering userExists
Entering authenticate
Entering Connect
Using TLS or not using encryption.
Using servers: ldap://dc1.msp.domain1.net ldap://dc2.msp.domain1.net ldap://dc3.msp.domain1.net
Connected successfully
Entering getSearchString
Doing a straight bind
userdn is: domain1\User05
Binding as the user
Bound successfully
Entering getUserDN
Created a regular filter: (sAMAccountName=User05)
Entering getBaseDN
basedn is not set for this type of entry, trying to get the default basedn.
Entering getBaseDN
basedn is dc=msp,dc=domain1,dc=net
Using base: dc=msp,dc=domain1,dc=net
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=User05,OU=admins,OU=dsUsers,DC=msp,DC=domain1,DC=net
Authentication passed
Entering initUser
Entering updateUser
Entering authenticate
Entering Connect
Using TLS or not using encryption.
Using servers: ldap://dc1.msp.domain1.net ldap://dc2.msp.domain1.net ldap://dc3.msp.domain1.net
Connected successfully
Entering getSearchString
Doing a straight bind
userdn is: domain1\User05
Binding as the user
Bound successfully
Entering getUserDN
Created a regular filter: (sAMAccountName=User05)
Entering getBaseDN
basedn is not set for this type of entry, trying to get the default basedn.
Entering getBaseDN
basedn is dc=msp,dc=domain1,dc=net
Using base: dc=msp,dc=domain1,dc=net
Pulled the user's DN: CN=User05,OU=admins,OU=dsUsers,DC=msp,DC=domain1,DC=net
Authentication passed
Entering updateUser

Any feedback on this much appreciated!

Openssl/PHP don't use Microsoft's system trust. See someone's documentation on how to configure it for Windows. Notice that I don't necessarily support using "TLS_REQCERT never", but instead you should use "TLS_CACERTFILE <some path to your CA file>". Note that "TLS_REQCERT never" is better than authenticating without encryption.
--Ryan lane 22:21, 26 June 2008 (UTC)

MediaWiki LDAP configuration problem - Error, Setup.php must be included from the file scope, after DefaultSettings.php

Hi Guys,

I have install media wiki and everything is working perfectly. when i tried to configure LDAP i'm getting this error: "Error, Setup.php must be included from the file scope, after DefaultSettings.php PHP Notice: Undefined variable: wgCommandLineMode in E:\MediaWiki\LocalSettings.php on line 33 PHP Notice: Undefined variable: wgCacheEpoch in E:\MediaWiki\LocalSettings.php on line 132 "

i've looked in many sites on google to solve this problem but with no success. the problem start when i use this line in the LocalSettings.php:

require_once( "$IP/extensions/LdapAuthentication.php" );

Someone got any idea?

help is appreciated.

thanks, ofer.

Are you putting this into the bottom of the file?
--Ryan lane 22:17, 26 June 2008 (UTC)

Is objectclass test necessary?

In debugging, I kept seeing the getGroups function searching with the filter "(&(memberUid=NAME)(objectclass=))", even though I had set the $wgLDAPGroupObjectClass variable to an appropriate value ("posixGroup"). getGroups was then unable to find any groups, and the LDAP user was therefore unable to log in. I changed line 1408 of LdapAuthentication.php from this:

$filter = "(&($attribute=$value)(objectclass=$objectclass))";

to this:

$filter = "$attribute=$value";

and now it works. getGroups finds the user's groups, and LDAP users in the required group can log onto the wiki without a problem.

My question here: do I really need the objectclass test? I can put it back if I need it, but it doesn't look like I really need it. - Jredmond 16:23, 4 June 2008 (UTC)

You don't need the objectclass if the attribute you are searching for only exists in groups.
--Ryan lane 21:59, 26 June 2008 (UTC)

Patch to avoid crash when many groups

My organization has zillions of groups so that a call to @ldap_search crashed php (1.8Mb response when running the query in ldapsearch). Here is a patch that fixes it by only returning useful fields. BTW Thanks a lot for the great extension!

Index: LdapAuthentication.php
===================================================================
--- LdapAuthentication.php      (revision 36340)
+++ LdapAuthentication.php      (working copy)
@@ -1418,7 +1418,7 @@
                        $bind = $this->bindAs( $ldapconn, $wgLDAPProxyAgent[$_SESSION['wsDomain']], $wgLDAPProxyAgentPassword[$_SESSION['wsDomain']] );
                }

-               $info = @ldap_search( $ldapconn, $base, $filter );
+               $info = @ldap_search( $ldapconn, $base, $filter, array( "dn", $nameattribute) );
                if ( !$info ) {
                        $this->printDebug( "No entries returned from search.", SENSITIVE );

Changing username when creating local users

Hi, I'm having some trouble with the extension : the dn retrieved from LDAP is an email address, and it is used as the user name for local users. The problem is I can't use the built-in user right management with these users because when you type a name with '@' in it, the page thinks you're trying to edit a user from another wiki. Is there a way to use for instance the cn instead of the dn? (with users still logging using their dn). Thanks!

See this discussion for an idea of how you might be able to do this.
--Ryan lane 22:12, 26 June 2008 (UTC)

Bugs when adding user

It seems to me there is two bugs in the function addUser since (at least) v1.1g. The first is near the lines 800-801 where a comma may be omitted

if ( isset( $wgLDAPWriteLocation[$_SESSION['wsDomain']] ) ) {
    $this->printDebug( "wgLDAPWriteLocation is set, using that", NONSENSITIVE );
    $userdn = $wgLDAPSearchAttributes[$_SESSION['wsDomain']] . "=" .
        $username . "," . $wgLDAPWriteLocation[$_SESSION['wsDomain']];
} else {

and the second near the line 828 where it is considered the entire table

if ( $wgLDAPRequireAuthAttribute[$_SESSION['wsDomain']] ) {
    $values[$wgLDAPAuthAttribute[$_SESSION['wsDomain']]] = "true";
}

Moreover, I don't see what should make these 3 last lines:

• must LDAPRequireAuthAttribute really be set to "true"/"false" (and not true/false - string vs boolean, see doc) ?
• LDAPAuthAttribute is not a LDAP attribute in view of the doc but is an expression, I'm wrong ?

~ Seb35 13:08, 1 July 2008 (UTC)

This code is probably the least used, which would probably be why it still has bugs; you are the first to report them, and this part of the code isn't part of my normal tests (I guess I'll start testing this as well now). All of the above looks correct, and as a matter of fact, the second part isn't even needed. You also pointed out an error in my documentation ($wgLDAPRequireAuthAttribute should take a boolean, not a string), which is now fixed. I'll fix all of this in the next release.
--Ryan lane 14:07, 1 July 2008 (UTC)

Fatal error: Call to private method User::loadfromsession()

Hi,

I'm trying to use smartcard authentication... I seem to be missing something pretty obvious, since the extension doesn't even get to the the stage of searching my directory... but what? The output in the browser looks like this:

Entering AutoAuthSetup.
Allowing smartcard authentication.
wgLDAPSSLUsername = Heinrich Opgenoorth
wgLDAPSSLUsername is not null, adding hooks.
Entering SSLAuth.

Fatal error: Call to private method User::loadfromsession() from context '' in /var/www/mw/extensions/LdapAuthentication.php on line 1768

My LocalSettings.php contains the following lines:

require_once( "$IP/extensions/LdapAuthentication.php" );
$wgLDAPDomainNames = array("testLDAPdomain");
$wgLDAPServerNames = array("testLDAPdomain"=>"directory.fraunhofer.de");
$wgLDAPEncryptionType = array("testLDAPdomain"=>"clear");
$wgLDAPSearchAttributes = array("testLDAPdomain"=>"cn");
$wgLDAPBaseDNs = array("testLDAPdomain"=>"ou=".$_SERVER['SSL_CLIENT_S_DN_OU'].",o=fraunhofer,c=de");
$wgLDAPDebug = 5;
$wgLDAPAutoAuthMethod = "smartcard";
$wgLDAPSmartcardDomain = "testLDAPdomain";
if (isset($_SERVER['SSL_CLIENT_S_DN_CN'])) {
    $wgLDAPSSLUsername = $_SERVER['SSL_CLIENT_S_DN_CN'];
}

$wgHooks['SetUsernameAttributeFromLDAP'][] = 'SetUsernameAttribute';
function SetUsernameAttribute(&$LDAPUsername, $info) {
        $LDAPUsername = $info[0]['cn'][0] . " " . $info[0]['ou'][0];
        return true;
}

AutoAuthSetup();

The extension version is 1.1g, MediaWiki 1.12 (I also tried 1.10, same effect).

Any ideas welcome...

Heinrich opgenoorth, 04 Jul 2008

I think some things changed in later versions of MediaWiki. It looks like I've updated the local version of the LDAP plugin I'm using to work with newer versions of MediaWiki and didn't commit the changes. Please try changing the line:

$tmpuser = User::LoadFromSession();

to:

$tmpuser = User::newFromSession();

If that doesn't solve your problem, I'll need to commit my changes (which I can't do at work, so it'll be a day or two before I can get to it).
--Ryan lane 13:18, 7 July 2008 (UTC)

Changing the line, the above error message is gone, but instead I get a MediaWiki internal error:

Original exception: exception 'MWException' with message 'Unstub loop detected on call of $wgUser->getOption from StubUserLang::_newObject
' in /var/www/mw/includes/StubObject.php:54
Stack trace:

...I omit the Stack trace; best I just wait until you have committed the changes from your most recent version... Thanks, Heinrich

Problem With LDAP

Hello,

I'm trying to connect Mediawiki with LDAP and always appears a blank page, the code I use is this:

// Validación LDAP
require_once( "$IP/extensions/LdapAuthentication.php" );

$wgAuth = new LdapAuthenticationPlugin(); //Nombres de los dominios que utilizarás.
$wgLDAPDomainNames = array("Alumnes","Professors");

//Asociación entre nombre de dominio y nombre DNS de la máquina donde se va a validar.
$wgLDAPServerNames = array("Alumnes"=>"*********", "Professors"=>"**********");

//Podemos permitir la convivencia de autenticación local del wiki con LDAP.
$wgLDAPUseLocal = true; //Encriptación en las solicitudes LDAP.
$wgLDAPEncryptionType = array("Alumnes"=>"clear", "Professors"=>"clear");

//Le decimos cual es la base de la consulta
$wgLDAPBaseDNS = array("Alumnes"=>"dc=Udl,dc=es", "Professors"=>"ou=People, dc=Udl, dc=es");
$wgLDAPSearchAttributes = array("Alumnes"=>"uid", "Professors"=>"uid");

//Utilizamos los grupos LDAP para las directivas de grupo:
$wgLDAPGroupsPrevail = array("Alumnes"=>true, "Professors"=>true);
$wgLDAPGroupNameAttribute = array("Alumnes"=>"cn", "Professors"=>"cn");

$wgLDAPDebug = 3;

With the Debugg it give me this messages:

Entering validDomain
User is using a valid domain.
Setting domain as: Alumnes
Entering getCanonicalName
Username isn't empty.
Munged username: C4768695
Entering userExists
Entering authenticate
Entering Connect
It looks like you are issing LDAP support; please ensure you have either compiled LDAP support in, or have enabled the module. If the authentication is working for you, the plugin isn't properly detecting the LDAP module, and you can safely ignore this message.
Using TLS or not using encryption.
Using servers: ldap://************

What's the matter? Thanks for all.

Your PHP doesn't have LDAP support (as the debug output mentions - although it mentions it with a typo ;) ). You need to either compile PHP with LDAP support, or you need to install the LDAP module for PHP, and include it in your php.ini file. If you are using a flavor of Red Hat, you can just install the php-ldap package.
--Ryan lane 13:50, 21 July 2008 (UTC)

User is not using a valid domain

Error

Entering validDomain
User is not using a valid domain.
Setting domain as: invaliddomain
Entering modifyUITemplate
Allowing the local domain, adding it to the list.

LocalSettings.php:

$wgLDAPDomainNames = array(
  "university_edu"
  );

$wgLDAPServerNames = array(
  "university_edu"=>"ldap.its.university.edu",
  );

$wgLDAPUseLocal = true;

$wgLDAPEncryptionType = array(
  "university_edu"=>"clear",
  );

$wgLDAPSearchStrings = array(
  "university_edu"=>"uid=[search],ou=Accounts,dc=its,dc=university,dc=edu"
  );

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

$wgLDAPBaseDNs = array(
  "university_edu"=>"dc=its,dc=university,dc=edu"
  );
#$wgLDAPGroupBaseDNs = array(
#  "university_edu"=>"ou=group,dc=its,dc=university,dc=edu"
#  );
$wgLDAPUserBaseDNs = array(
  "university_edu"=>"ou=people,dc=its,dc=university,dc=edu"
  );

wgLDAPDebug = 2;

require_once( 'LdapAuthentication.php' ); //or the appropriate lines for putting it in the extensions directory
$wgAuth = new LdapAuthenticationPlugin(); //or the appropriate lines for putting it in the extensions directory

• $domain appears to be empty.
• I have tried installing the extension in includes and extensions. Same result.
• ExtensionFunctions.php is installed.
• LDAP support is enabled in php.
• I have a joomla install that uses ldap fine.
• I can also telnet to the ldap server.

Thoughts? -- niels

Move these to the top (I've never tested with these after the options):

require_once( 'LdapAuthentication.php' ); //or the appropriate lines for putting it in the extensions directory
$wgAuth = new LdapAuthenticationPlugin(); //or the appropriate lines for putting it in the extensions directory

Also, please provide the full debug output.
--Ryan lane 14:06, 24 July 2008 (UTC)

Oh. and this:

$wgLDAPServerNames = array(
  "university_edu"=>"ldap.its.university.edu",
  );

should look like this (notice the missing comma):

$wgLDAPServerNames = array(
  "university_edu"=>"ldap.its.university.edu"
  );

--Ryan lane 14:07, 24 July 2008 (UTC)

Is there other debug output somewhere? This is all that comes up in my browser, even in debug level 3.

Debug info

Entering validDomain
User is not using a valid domain.
Setting domain as: invaliddomain
Entering modifyUITemplate
Allowing the local domain, adding it to the list.

LocalSettings.php (everything is at the end)

require_once( "$IP/extensions/LdapAuthentication.php" );
$wgAuth = new LdapAuthenticationPlugin();

$wgLDAPDomainNames = array(
  "university_edu"
  );

$wgLDAPServerNames = array(
  "university_edu"=>"ldap.its.university.edu"
  );

$wgLDAPUseLocal = true;

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

$wgLDAPSearchStrings = array(
  "university_edu"=>"uid=[search],ou=people,dc=its,dc=university,dc=edu"
  );

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

$wgLDAPBaseDNs = array(
  "university_edu"=>"dc=its,dc=university,dc=edu"
  );

#$wgLDAPGroupBaseDNs = array(
#  "university_edu"=>"ou=group,dc=its,dc=university,dc=edu"
#  );

$wgLDAPUserBaseDNs = array(
  "university_edu"=>"ou=people,dc=its,dc=university,dc=edu"
  );

$wgLDAPDebug = 3;

-- niels

Are you getting a white screen? Does anything of interest show up in your web server error log, or your php log? If you get a white screen, you don't have LDAP support in PHP. You either need to compile support in, or add the appropriate package for your distro (recommended).
--Ryan lane 20:31, 24 July 2008 (UTC)

the apache doesn't log any errors related to this (trust me, it logs a lot of other errors for other installed web apps!). I looked for a php log, haven't found one yet (any suggestions on that while you're here?) I do not get a white screen, mediawiki renders fine, and I can login using the local mediawiki user database. PHP LDAP support is installed. Has been. I have a Joomla install that authenticates against the same ldap server. Here are the settings in Joomla:

Host: ldap.its.university.edu
Port: 389
LDAP V3: Yes
Negotiate TLS: No
Follow referrals: No
Authorization Method: Bind and Search 	
Base DN: ou=people,dc=its,dc=university,dc=edu
Search String: uid=[search]
Users DN: <blank>
Connect username: blank 	
Connect password: blank
Map: Full Name: fullName
Map: E-mail: mail
Map: User ID: uid

-- niels

Auto Authentication (get rid of the login form)

Hi everyone

I would like to modify the login procedure. I want to get the username with something like the AUTH_USER variable of PHP, and bind to the AD with another account (having read/browse rights). Then I could retrieve info about the real user logging in and continue the normal flow of the LdapAuthentication extension. I think I will have to go deep in the PHP code ... anyone can help ?

Thanks

Michael      14 / 08 / 2008

I just added support for this in 1.2a; download the newest version of the plugin from svn, and be sure to also download LdapAutoAuthentication.php. Hopefully I'll have some documentation soon for various types of web authentication (Kerberos, NTLM, htpasswd, smartcard, etc.).
--Ryan lane 22:21, 16 August 2008 (UTC)

Auto-auth (kerberos) examples?

Ryan, can you run through some real quick basics of setting up the kerberos (IIS integrated authentication, correct?) settings with the autoauth piece? I know that others have been chomping at the bit for this functionality, and I think I'm close, but I've not been able to make it work quite yet. Thanks a ton for this; it's been pretty fantastic! --Lane 04:19, 19 September 2008 (UTC)

I've been hoping to get to this for a while, but haven't had the time. Hopefully I'll get a chance to do it this week or next week.
--Ryan lane 17:13, 28 October 2008 (UTC)

Unable to use encrypted login

Hi, I'm trying to use this plugin on a Windows 2003 system running IIS, with PHP 5.2.3 and Mediawiki 1.12.0, and I cannot for the life of me get a TLS-encrypted login to work. Using clear, it works, but whenever I enable TLS, I get:

Entering validDomain
User is using a valid domain.
Setting domain as: ****
Entering getCanonicalName
Username isn't empty.
Munged username: ****
Entering authenticate
Entering Connect
Using TLS or not using encryption.
Using servers: *****
Using TLS
Failed to start TLS.
Failed to connect
Entering strict.
Returning false in strict().
Entering modifyUITemplate
Allowing the local domain, adding it to the list.

The "Failed to start TLS" bit there caught my eye. Is there some add-on I have to install to support TLS? I couldn't find anything that I'm missing either on this page or on php.net, so I'm hoping somebody can point me in the right direction here. --155.72.100.4 16:59, 30 July 2008 (UTC)

Are you using Active Directory (AD)? If so, it may not support TLS, or you may not have a certificate installed on the AD server. Try using "ssl" instead of "tls". Some AD servers will have ldaps enabled, but not tls over ldap. If that doesn't work, you need to ensure the AD server has a cert installed. If you do have a cert installed, you need to ensure that your client trusts the CA that signed the certificate. Some directions have been given by users for doing stuff like this.
--Ryan lane 22:25, 16 August 2008 (UTC)

Removing domain selection from login screen

I'd like to remove the domain selection from the login screen because we only have one domain so select. Somebody knows how this can be achieved in the current version (MW 1.13.0, LDAP_Authentication 1.2a)? I don't see an Id on the select so I could hide it via CSS directly. If there's know option currently, can this be added in a future version please? Thanks. - Jan

I'll add the id; it'll be the same as the name. If you want to backport the change to your version of MediaWiki, you'll be safe. I'll add this to the todo list.
--Ryan lane 18:25, 11 September 2008 (UTC)

Valid paramaters for $wgLDAPBaseDNs?

I have been working on getting mediawiki to auth against a w2k3 domain. used an above fix to restore the _'s that are present in all domain acounts, and also tested the php->ldap login outside of mediawiki with a script I found on http://www.gossamer-threads.com/lists/wiki/mediawiki/43821

The linked script works, as long as I set $ldaprdn = ''; (this is the equivlanet of $wgLDAPBaseDNs I used ldp from the windows 2000 admin kit and know it should be dc=mycompany,dc=local but I dont know of any other options.

what would be a way to set this variable to nothing if the plugin does not require it, and to find out correct values for other required fields if it is?

I also notice that I am still getting a capital letter for the first part of my username. I see that caused problems in the past, and have tried posted solutions with no change. What is the current/correct fix?

What would really be helpful is getting more error info than simply "Failed to bind as mydomain\myuser"

If all you want to do is basic AD authentication, you don't need to know the basedn. All you need to know is the hostname of the AD server, and the domain name. See the simple configuration example for active directory.
--Ryan lane 22:43, 3 November 2008 (UTC)

How about wgLDAPDeniedGroups?

Along with $wgLDAPRequiredGroups, would it be possible for you to create a complementary variable, $wgLDAPDeniedGroups, that excludes members of certain NT groups? It would be very handy to be able to express: "Everybody in group X, but not in group Y, can authenticate." Maiden taiwan 11:01, 18 September 2008 (UTC)

I'll think about adding this to the next release.
--Ryan lane 22:45, 3 November 2008 (UTC)

Windows Integrated Authentication

Ryan, can you give a starting point to configuring this for Windows Integrated authentication? I'm assuming this will use a variation on the way it's set up to use smartcard auth, but I've not been able to get it to work as of yet.

Thanks! --Laduncan 21:17, 3 October 2008 (UTC)

I'll try to get some documentation out for this ASAP. I know a lot of people are really wanting this... Sorry for the wait!
--Ryan lane 22:46, 3 November 2008 (UTC)

usedomain, useemail, getCanonicalName(), and email confirmation

We successfully rolled out the LDAP extension to four MediaWiki sites, one of which is using auto authentication with the Apache server's mod_authnz_ldap. Thank you for this great extension!

We did run into three issues, two of which I fixed with small edits to LdapAuthentication.php, and one which is outstanding.

We want users who already have LDAP accounts to be able to login without creating additional wiki accounts (the LDAP extension does this nicely) and we want users who do not already have LDAP accounts to be able to create new wiki accounts (the LDAP extension lets us do this also), but all of our wikis require email confirmation to be able to edit.

This is a problem for users who create new wiki accounts, because the LDAP extension removes the email address input from the create account page. Consequently users cannot provide an email address (and therefore cannot edit) unless they subsequently go to their preferences page.

Relatedly, we only have only one domain. We do use $wgLDAPUseLocal, for users who do not already have accounts in LDAP, but we _always_ want to try LDAP first, and fallback to wiki accounts. Again, the LDAP extension does this nicely. We just do not want users to see the domain selection input. We want the wiki to appear to the user exactly as it would if we were not using the LDAP extension, but their LDAP passwords work : )

To solve these problems, I commented out the "usedomain" and "useemail" lines in LdapAuthentication.php:

@@ -552,8 +552,8 @@
 			$template->set( 'create', false );
 		}
 
-		$template->set( 'usedomain', true );
-		$template->set( 'useemail', false );
+		#$template->set( 'usedomain', true );
+		#$template->set( 'useemail', false );
 
 		$tempDomArr = $wgLDAPDomainNames;
 		if ( $wgLDAPUseLocal ) {

Then, because the domain form parameter is no longer submitted when users login, I had to set in manually in LdapAuthentication.php:

@@ -891,7 +891,7 @@
 	 */
 	function setDomain( $domain ) {
 		$this->printDebug( "Setting domain as: $domain", NONSENSITIVE );
-		$_SESSION['wsDomain'] = $domain;
+		$_SESSION['wsDomain'] = 'default';
 	}
 
 	/**

This works, but I would prefer that there were configuration options to have the same effect, without editing the LdapAuthenitcation.php source. For example, I wish there were configuration options to show the email input on the create account page, and hide the domain select input. I wish there were a configuration option to explicitly set which domain will always be used - like $wgLDAPAutoAuthDomain for non-automatic login : )

I'll add this to my TODO list.
--Ryan lane 22:54, 3 November 2008 (UTC)

Or, I wish if there is only one domain configured, the LDAP extension would hide the domain select input and always use that one domain?

I think this was a wishlist of someone else, and I'm hoping to allow users to fix this by modifying their CSS. This is a fix that will require a core code change.
--Ryan lane 22:54, 3 November 2008 (UTC)

MediaWiki is case sensitive about usernames - it allows two usernames with the same letters but different case: e.g. Petervg and PeterVG. Consequently some of our existing MediaWiki accounts use mixed case: e.g. PeterVG

The LDAP extension's getCanonicalName() makes usernames case insensitive by lowercasing them, and uppercasing the first letter. This means that when we want to fallback to local MediaWiki accounts, users with mixed case usernames, like PeterVG, cannot login.

I got around this be commenting out the strtolower() call in getCanonicalName():

@@ -1068,7 +1068,7 @@
 				//Change username to lowercase so that multiple user accounts
 				//won't be created for the same user.
 				//But don't do it for the local domain!
-				$username = strtolower( $username );
+				#$username = strtolower( $username );
 			}
 
 			//The wiki considers an all lowercase name to be invalid; need to

Again, I wish there were a configuration option to disable getCanonicalName(), instead of having to edit LdapAuthentication.php

I'd recommend renaming users with mix characters to all lowercase. Unless this was fixed and I'm not aware of it, if a user logs in via ldap with UsErname, and Username, and UsernamE, three different accounts will be created. LDAP isn't checking case, but MediaWiki is; MediaWiki sees the users as three separate users.
--Ryan lane 22:54, 3 November 2008 (UTC)

Finally! I mentioned that we require email confirmation to edit the wiki. We do not want to disable email confirmation, but all of the email addresses in out LDAP database are already confirmed. So we do not want users with LDAP accounts, where their email address is retrieved by the LDAP extension from their LDAP account, to have to confirm their email. In other words, when the LDAP extension retrieves an email address from LDAP, we want it to mark that address as confirmed.

I have not got around to fixing this, so we currently have to tell all our users with LDAP accounts that they can use their LDAP password to login, but that they must then go to the preferences page and send themselves a confirmation email.

I wish there were a configuration option to mark email address retrieved from LDAP as confirmed : )

This should be on the TODO list; if it isn't I'll add it.
--Ryan lane 22:54, 3 November 2008 (UTC)

After updating via rpm ldap auth failed when i press eidit

Hi All I have upgraded to mediawiki mediawiki-1.13.2-40.99 via rpm ,All thing are working fine before upgradation but after upgrading there seems to be a problem when i press edit.we use ldap authentication for wiki. This is debug log please give sugestion debug result is

Entering validDomain
User is not using a valid domain.
Setting domain as: invaliddomain
Entering getCanonicalName
Username isn't empty.
Munged username: ******
Entering authenticate
Entering Connect
Using TLS or not using encryption.
Using servers: 
Using TLS
Failed to start TLS.
Failed to connect
<Entering strict.
<br>Returning true in strict().
<br>Entering modifyUITemplatedtd">



This error occured 
[error] [client ****************] PHP Notice:  Undefined index:  invaliddomain in /var/www/wiki/sysadmin/LdapAuthentication.php on line 148, referer: *************************************************



error] [client *************] PHP Warning:  ldap_start_tls() [<a href='function.ldap-start-tls'>function.ldap-start-tls</a>]: Unable to start TLS: Can't contact LDAP server in /var/www/wiki/sysadmin/LdapAuthentication.php on line 166, referer: ************************************************************************************
<nowiki><nowiki>Insert non-formatted text here</nowiki></nowiki>

What distro is this? I'm not sure how they package the software, and have no clue what could have happened. It'll be really hard for me to debug this. I recommend always downloading the module manually. There isn't a guarantee the distro is taking version compatibility into consideration.
--Ryan lane 22:57, 3 November 2008 (UTC)

Automatic authorization using Windows AD to access MediaWiki

Hi everyone, I have been trying to get MediaWiki running on IIS, Windows Server 2003 with a mysql DB for a few weeks now. I have incorporated LDAP so users can manually login with their domain credentials. However i desperatly need to automate this process. Is there any current method to achieve this?? I have been browsing the web for ages now, and although people discuss the idea, there seems no be no notes on successes or failures! Is this totally unachievable at the moment??

Everyone seems to be asking this right now. I did add code to do this recently, but I don't have documentation written yet. I'll try to get some out soon.
--Ryan lane 22:58, 3 November 2008 (UTC)

Ryan, I'm also trying to get this to work, so even some brief notes would be helpful. Of more concern is that I'm currently using LdapAuthentication.php version 1.1g with MediaWiki 11.1.0 for manual authentication, and it works fine; but LdapAuthentication.php version 1.2a results in a white screen (which I understand is a PHP issue, but I don't have access to the PHP logs).
Snuck 01:10, 3 February 2009 (UTC)

Authenticating automatically using REMOTE_USER

I just got it to work with php REMOTE_USER (after the web server authenticated the user using LDAP). I used the 1.2a version with Mediawiki 1.13.2; some bugs and notes:

1. Don't forget to download (and include) LdapAutoAutentication.php as well ( http://svn.wikimedia.org/viewvc/mediawiki/trunk/extensions/LdapAuthentication/ )

2. In LdapAuthentication.php: function AutoAuthSetup has a check on the mediawiki version, this however results in the wrong hook being set, this was the one that worked for me:

 $wgHooks['UserLoadFromSession'][] = 'LdapAutoAuthentication::Authenticate';

3. In LdapAuthentication.php (about line 564): it says wgLDAPAutoAutoDomain, with should be wgLDAPAutoAuthDomain

4.In LocalSettings, make sure you have (amongst the other needed LDAP settings):

 $wgLDAPAutoAuthDomain = "<my domain>";
 $wgLDAPAutoAuthUsername = $_SERVER['PHP_AUTH_USER'];
 $wgHooks['SetUsernameAttributeFromLDAP'][] = 'SetUsernameAttribute';
 //This function allows you to get the username from LDAP however you need to do it.
 //This is the username MediaWiki will use. (>> for me this should be 'uid')
 function SetUsernameAttribute(&$LDAPUsername, $info) {
   $LDAPUsername = $info[0]['uid'][0];
   return true;
 }
 AutoAuthSetup();

Regards, Gyuri

I'm marking these fixes as TODOs; thanks!
--Ryan lane 22:59, 3 November 2008 (UTC)

Fixed the above fixes in SVN
--Ryan lane 17:26, 11 November 2008 (UTC)

ldap_search for groups fails / AD

I have some problems to sync groups from AD. Login with AD account works fine, but it wont pull group names from AD. After I removed the @ from ldap_search at line 1420 I became an error Search: Can't contact LDAP server. But how it comes? Authentification on LDAP works so how he cant contact ldap server???

Thanks for advice..

debug output at login:

Entering validDomain
User is using a valid domain.
Setting domain as: DOMAIN
Entering getCanonicalName
Username isn't empty.
Munged username: Username
Entering authenticate
Entering Connect
Using TLS or not using encryption.
Using servers: ldap://dc.domain.intern
Connected successfully
Lowercasing the username: Username
Entering getSearchString
Doing a straight bind
userdn is: DOMAIN\username
Binding as the user
Bound successfully
Entering getUserDN
Created a regular filter: (sAMAccountName=username)
Entering getBaseDN
basedn is not set for this type of entry, trying to get the default basedn.
Entering getBaseDN
basedn is dc=domain,dc=intern
Using base: dc=domain,dc=intern
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=Username,OU=sampleou,DC=domain,DC=intern
Retrieving LDAP group membership
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=domain,dc=intern
Search string: (&(member=CN=Username,OU=sampleou,DC=domain,DC=intern)(objectclass=group))

Warning: ldap_search() [function.ldap-search]: Search: Can't contact LDAP server in wiki\extensions\LdapAuthentication.php on line 1420
No entries returned from search.
Authentication passed
Entering updateUser
Setting user groups.
Entering setGroups.
Locally managed groups is unset, using defaults: bot,sysop,bureaucrat
Available groups are: bot,sysop,bureaucrat,groupa,groupb,groupc
Effective groups are: *,user,autoconfirmed
Checking to see if user is in: groupa
Entering hasLDAPGroup
Checking... [stripped]
Saving user settings.

settings:

 require_once( 'extensions/LdapAuthentication.php' );
 $wgAuth = new LdapAuthenticationPlugin();
 $wgLDAPDomainNames = array('DOMAIN');
 $wgLDAPServerNames = array('DOMAIN'=>'dc.domain.intern',);
 $wgLDAPEncryptionType = array('DOMAIN'=>'clear');
 $wgMinimalPasswordLength = 1;
 $wgLDAPUseLocal = false;
 #$wgLDAPRetrievePrefs = array("DOMAIN"=>true);
 $wgLDAPLowerCaseUsername = array("DOMAIN"=>true);
 $wgLDAPDebug = 5;
 $wgLDAPSearchStrings = array('DOMAIN'=>'DOMAIN\\USER-NAME');
 $wgLDAPSearchAttributes = array('DOMAIN'=>'sAMAccountName');
 $wgLDAPBaseDNs  = array('DOMAIN'=>'dc=domain,dc=intern');
 $wgLDAPGroupUseFullDN = array('DOMAIN'=>true);
 $wgLDAPGroupObjectclass = array('DOMAIN'=>'group');
 $wgLDAPGroupAttribute = array('DOMAIN'=>'member');
 $wgLDAPGroupSearchNestedGroups = array('DOMAIN'=>true);
 $wgLDAPGroupNameAttribute = array('DOMAIN'=>'cn');
 $wgLDAPUseLDAPGroups = array('DOMAIN'=>true);
 $wgLDAPGroupUseRetrievedUsername = array('DOMAIN'=>true);

 $wgGroupPermissions['groupa']['createpage']	= true;
 $wgGroupPermissions['groupb']['createpage']	= true;
 $wgGroupPermissions['groupc']['createpage']	= true;

What version of the plugin and MediaWiki are you using?
--Ryan lane 23:19, 5 November 2008 (UTC)

patch for UserLoadAfterLoadFromSession

Looking at the version in HEAD for MW 1.14:

 if ( version_compare( $wgVersion, '1.14.0', '<' ) ) {
   $wgHooks['UserLoadAfterLoadFromSession'][] = 'LdapAutoAuthentication::Authenticate';
 } else {
   $wgHooks['UserLoadFromSession'][] = 'LdapAutoAuthentication::Authenticate';
 }

Don't you want that the other way around? If current code version is < 1.14, use UserLoadFromSession and fake the isLoggedIn()?

(By the way, thanks many times for resolving that recursive load() issue, and for having great sample code to look at in LDAP_Authenticate for other Auth developers.)

Thinkling 00:12, 4 November 2008 (UTC)

Yeah, looks like I have that backwards. I'll fix this ASAP. Going into the TODO. Thanks!
--Ryan lane 23:14, 5 November 2008 (UTC)

Fixed! Thanks for the bug report.
--Ryan lane 17:18, 11 November 2008 (UTC)

Problem when there are many groups in the Active Directory

It looks like a bug - all of the sudden no user were able to log in to wiki.

After a little investigation we found: In the function getGroups, there is a code that bring all the groups from LDAP (why?). In the end of the function, before printing all the groups it calls "implode":

$this->printDebug( "Returned groups:" . implode( ",", $groups ) . "", SENSITIVE );
$this->printDebug( "Returned groups:" . implode( ",", $shortnamegroups ) . "", SENSITIVE );

While there are too many groups in the LDAP, the function implode doesn't return, and the Wiki doesn't work. After removing the printDebug, the Wiki worked again. --D 09:00, 5 November 2008 (UTC)

Oops. Didn't think about that. I'll refactor the printDebug method to handle arrays so that I don't do this kind of thing unless debug is turned on. This is going on my TODO. Thanks for the bug report!
--Ryan lane 23:16, 5 November 2008 (UTC)

setting up group-based login (AD) for idiots?

So far I have set up LDAP authentication to use AD usernames and passwords for logging in to the wiki. My settings file looks like this

$wgLDAPDomainNames = array(
  "cc3-sbhs.internal"
  );

$wgLDAPServerNames = array(
  "cc3-sbhs.internal"=>"sow-sr-001.cc3-sbhs.internal",
    );

$wgLDAPUseLocal = true;

$wgLDAPEncryptionType = array(
  "cc3-sbhs.internal"=>"clear",
  );
$wgLDAPBaseDNs = array("cc3-sbhs.internal"=>"DC=sow-sr-001");

$wgLDAPSearchStrings = array(
  "cc3-sbhs.internal"=>"USER-NAME@cc3-sbhs.internal",
  );
lse
$wgLDAPGroupUseFullDN = array(
  "cc3-sbhs.internal"=>true
  );
 
$wgLDAPDebug = 3;

This works fine so far, but I want to be able to restrict it to particular groups within AD. Unfortunately, most of the syntax for these configuration settings is baffling to me. Can anyone explain in fairly simple terms how to set this up? I can provide domain names, server names, group names etc. as required.

Thanks in advance --Carelesshx 15:07, 6 November 2008 (UTC)

Slight modification

Hey Ryan thank you so much for this extension. I've used with two employers. I had to make the following modification to get logins by group to work though. It's probably the way that AD is configured at my company, but only the first group was getting checked. The groups were all at the same level (attribute was memberOf) of the same search result (so only one entry, but multiple groups in it). In case anyone else runs into the issue here's what I did to make it work (code probably not greatest as I was just monkeying the PHP code, haven't really used PHP in a long time):

Code diff -u

$ diff -u LdapAuthentication.php.orig LdapAuthentication.php.altered
--- LdapAuthentication.php.orig      2008-11-06 15:29:43.000000000 -0600
+++ LdapAuthentication.php.altered    2008-11-06 15:51:56.000000000 -0600
@@ -1440,6 +1440,11 @@

                       array_push( $groups, $mem );
                       array_push( $shortnamegroups, $shortnamemem );
+
+         array_shift( $entry[$nameattribute] );
+         foreach ( $entry[$nameattribute] as $othergroups ) {
+            array_push( $groups, strtolower( $othergroups ) );
+         }
               }

               $both_groups = array();

LocalSettings.php config

#LDAP login
$wgLDAPDebug = 3;
require_once 'extensions/LdapAuthentication/LdapAuthentication.php';
$wgAuth = new LdapAuthenticationPlugin();
$wgLDAPDomainNames = array( 'mydomain' );
$wgLDAPServerNames = array( 'mydomain' => 'ldap-server' );
$wgLDAPSearchStrings = array( 'mydomain' => 'USER-NAME@mydomain.mysite.com' );
$wgLDAPBaseDNs = array( 'mydomain' => 'dc=mydomain,dc=mysite,dc=com' );
$wgLDAPEncryptionType = array( 'mydomain' => 'clear' );
$wgLDAPLowerCaseUsername = array( 'mydomain' => true );
$wgLDAPRetrievePrefs = array( 'mydomain' => true );
$wgLDAPRequiredGroups = array( 'mydomain' => array( strtolower('CN=Super Duper Group,OU=Clever Corporation,DC=mydomain,DC=mysite,DC=com') ) );
$wgLDAPGroupUseFullDN = array( 'mydomain' => false );
$wgLDAPGroupObjectclass = array( 'mydomain' => 'user' );
$wgLDAPGroupAttribute = array( 'mydomain' => 'sAMAccountName' );
$wgLDAPGroupSearchNestedGroups = array( 'mydomain' => false );
$wgLDAPGroupNameAttribute = array( 'mydomain' => 'memberof' );
$wgLDAPBaseDNs = array( 'mydomain' => 'dc=mydomain,dc=mysite,dc=com' );
$wgLDAPSearchAttributes = array( 'mydomain' => 'sAMAccountName' );
$wgLDAPUseLocal = true;
$wgMinimalPasswordLength = 1;

Dori 00:12, 7 November 2008 (UTC)

At some point in time I'm going to add memberOf support so that no one will have to do hacky stuff. I have to rework my group code some before doing so though. Hopefully it'll be soon and I'll fix your problem in a nice way ;).
--Ryan lane 17:22, 11 November 2008 (UTC)

Group based restriction for users having different base DNs than group

Hello Ryan,

Some of my users’ base DNs do not match the required group’s base DN. Because of this, no matching groups are returned for the user since the plug-in sees the user as a non-member of the required group’s base DN. Is there something I can reconfigure in the plug-in settings or is this feature not included? Below, jpn\Jdoe is a member of the usa\group1 universal group.

Using servers: ldap://jpn.company.com
Using TLS
Connected successfully
Entering getSearchString
Doing a straight bind
userdn is: jpn\Jdoe
Binding as the user
Bound successfully
Entering getUserDN
Created a regular filter: (sAMAccountName=Jdoe)
Entering getBaseDN
basedn is ou=workers,dc=jpn,dc=company,dc=com
Using base: ou=workers,dc=jpn,dc=company,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=Doe\, John,OU=Workers,DC=jpn,DC=company,DC=com
Checking for (new style) group membership
Entering isMemberOfRequiredLdapGroup
Required groups:cn=group1,ou=groups,dc=usa,dc=company,dc=com,cn=group2,ou=groups,dc=usa,dc=company,dc=com
Entering getUserGroups
Entering getGroups
Entering getBaseDN
basedn is ou=groups,dc=usa,dc=company,dc=com
Search string: (&(member=CN=Doe\5c, John,OU=Workers,DC=jpn,DC=company,DC=com)(objectclass=group))
Returned groups:
Returned groups:
Couldn't find the user in any groups (1).
Entering strict.
Returning true in strict().
Entering modifyUITemplate

Below are my settings:

$wgLDAPDomainNames = array(
 "usa",
 "jpn"
$wgLDAPServerNames = array(
 "usa"=>"usa.company.com",
 "jpn"=>"jpn.company.com"
 );
$wgLDAPUseLocal = false;
$wgLDAPEncryptionType = array(
 "usa"=>"clear",
 "jpn"=>"clear"
 );
$wgLDAPSearchStrings = array(
 "usa"=>"usa\\USER-NAME",
 "jpn"=>"jpn\\USER-NAME"
 );
$wgLDAPSearchAttributes = array(
 "usa"=>"sAMAccountName",
 "jpn"=>"sAMAccountName"
 );
$wgLDAPBaseDNs = array(
 "usa"=>"dc=usa,dc=company,dc=com",
 "jpn"=>"dc=jpn,dc=company,dc=com"
 );
$wgLDAPGroupBaseDNs = array(
 "usa"=>"ou=groups,dc=usa,dc=company,dc=com",
 "jpn"=>"ou=groups,dc=usa,dc=company,dc=com"
 );
$wgLDAPUserBaseDNs = array(
 "usa"=>"ou=workers,dc=usa,dc=company,dc=com",
 "jpn"=>"ou=workers,dc=jpn,dc=company,dc=com"
 );
$wgLDAPGroupUseFullDN = array(
 "usa"=>true,
 "jpn"=>true
 );
$wgLDAPLowerCaseUsername = array(
 "usa"=>false,
 "jpn"=>false
 );
$wgLDAPGroupObjectclass = array(
 "usa"=>"group",
 "jpn"=>"group"
 );
$wgLDAPGroupAttribute = array(
 "usa"=>"member",
 "jpn"=>"member"
 );
$wgLDAPGroupNameAttribute = array(
 "usa"=>"cn",
 "jpn"=>"cn"
 );
$wgLDAPUseLDAPGroups = array(
 "usa"=>true,
 "jpn"=>true
 );
$wgLDAPRequiredGroups = array(
 "usa"=>array(
   "cn=group1,ou=groups,dc=usa,dc=company,dc=com",
   "cn=group2,ou=groups,dc=usa,dc=company,dc=com"
   ), 
 "jpn"=>array(
   "cn=group1,ou=groups,dc=usa,dc=company,dc=com",
   "cn=group2,ou=groups,dc=usa,dc=company,dc=com"
   )
 );
$wgLDAPGroupSearchNestedGroups = array(
 "usa"=>true,
 "jpn"=>true
 );

thx, --MadX 09:27, 21 November 2008 (UTC)

I believe for this to work, you need to point the plugin to whichever server is the active directory global catalog for both domains.
--Ryan lane 20:40, 10 December 2008 (UTC)

ldapinfo

A useful extension that builds on this extension is ldapinfo. http://webdesignessence.com/os/ldapinfo/#Description

But I can not find the meta wiki talk page about that extension.

I adapted the extension to use the hcard microformat. The output of the ldapinfoAdapted is then a call to a hcard template { {hcard| with the needed parameters } }

debugging

I'm having an issue installing this extension. It seems that whenever I attempt to login with a domain account it tells me "Login error:Incorrect password entered. Please try again." I decided to try debugging but I see no output on the login screen. Where does the debug information display or write to?

I do see the domain dropdown menu at the login screen so the extension is obviously being used.

My setup: Windows 2003 server, IIS 6, MediaWiki 1.13.3, PHP 5.2.8, (PHP installed) OpenLDAP ($Id: ldap.c,v 1.161.2.3.2.13 2008/05/04 21:19:17 colder Exp $) 2004 API, OpenSSL (OpenSSL 0.9.8i 15 Sep 2008). Domain controller's base OU is 'DC=testdomain,DC=net', all the group OU's are under that.

Just for reference, here is the config I'm using:

require_once 'extensions/LdapAuthentication.php';
$wgAuth = new LdapAuthenticationPlugin();
$wgLDAPDebug = 4;
$wgLDAPDomainNames = array(  'testdomain'  );
$wgLDAPServerNames = array(  'testdomain' => 'dc.testdomain.net'  );
$wgLDAPSearchAttributes = array(  'testdomain' => 'sAMAccountName'  );
$wgLDAPBaseDNs = array(  'testdomain' => 'DC=testdomain,DC=net'  );
$wgLDAPEncryptionType = array(  'testdomain' => 'ssl'  );
$wgMinimalPasswordLength = 1;
$wgLDAPUseLocal = false;

-- Michael

What version of the plugin are you using? The version of the plugin in SVN doesn't log to the screen anymore, it logs to a file; see the svn commit message (it isn't a production ready version of the plugin). Btw, if all you are doing is basic AD authentication, and don't need any of the other stuff (like group searching, preference pulling, etc.), you can use the following line:

$wgLDAPSearchStrings = array( 'testdomain' => 'TESTDOMAIN\\USER-NAME' ) );

and remove:

$wgLDAPSearchAttributes = array( 'testdomain' => 'sAMAccountName' );

$wgLDAPBaseDNs = array( 'testdomain' => 'DC=testdomain,DC=net' );

--Ryan lane 16:41, 15 December 2008 (UTC)

Hi Ryan, thanks for your response.

I was using v1.2b. I've updated to the version in subversion and I get the following with my original configuration:

2008-12-15 17:23:10 wikidb-itops_: Entering validDomain

2008-12-15 17:23:10 wikidb-itops_: User is using a valid domain.

2008-12-15 17:23:10 wikidb-itops_: Setting domain as: testdomain

2008-12-15 17:23:10 wikidb-itops_: Entering getCanonicalName

2008-12-15 17:23:10 wikidb-itops_: Username isn't empty.

2008-12-15 17:23:10 wikidb-itops_: Munged username: ***username***

2008-12-15 17:23:10 wikidb-itops_: Entering userExists

2008-12-15 17:23:10 wikidb-itops_:

2008-12-15 17:23:10 wikidb-itops_: Entering authenticate

2008-12-15 17:23:10 wikidb-itops_:

2008-12-15 17:23:10 wikidb-itops_: Entering Connect

2008-12-15 17:23:10 wikidb-itops_: Using SSL

2008-12-15 17:23:10 wikidb-itops_: Using servers: ldaps://dc.testdomain.net

2008-12-15 17:23:10 wikidb-itops_: Connected successfully

2008-12-15 17:23:10 wikidb-itops_: Entering getSearchString

2008-12-15 17:23:10 wikidb-itops_: Doing an anonymous bind

2008-12-15 17:23:10 wikidb-itops_: Failed to bind as

2008-12-15 17:23:10 wikidb-itops_: with password:

2008-12-15 17:23:10 wikidb-itops_: Failed to bind

2008-12-15 17:23:10 wikidb-itops_: User DN is blank

2008-12-15 17:23:10 wikidb-itops_: Entering allowPasswordChange

2008-12-15 17:23:10 wikidb-itops_: Entering modifyUITemplate

It does not appear to be using the domain\name I put in to bind as?

With your suggested configuration modification, I get the following:

2008-12-15 17:27:55 wikidb-itops_: Entering validDomain

2008-12-15 17:27:55 wikidb-itops_: User is using a valid domain.

2008-12-15 17:27:55 wikidb-itops_: Setting domain as: testdomain

2008-12-15 17:27:55 wikidb-itops_: Entering getCanonicalName

2008-12-15 17:27:55 wikidb-itops_: Username isn't empty.

2008-12-15 17:27:55 wikidb-itops_: Munged username: ***username A***

2008-12-15 17:27:55 wikidb-itops_: Entering userExists

2008-12-15 17:27:55 wikidb-itops_:

2008-12-15 17:27:55 wikidb-itops_: Entering authenticate

2008-12-15 17:27:55 wikidb-itops_:

2008-12-15 17:27:55 wikidb-itops_: Entering Connect

2008-12-15 17:27:55 wikidb-itops_: Using SSL

2008-12-15 17:27:55 wikidb-itops_: Using servers: ldaps://dc.testdomain.net

2008-12-15 17:27:55 wikidb-itops_: Connected successfully

2008-12-15 17:27:55 wikidb-itops_: Entering getSearchString

2008-12-15 17:27:55 wikidb-itops_: Doing a straight bind

2008-12-15 17:27:55 wikidb-itops_: userdn is: testdomain\***username B***

2008-12-15 17:27:55 wikidb-itops_:

2008-12-15 17:27:55 wikidb-itops_: Binding as the user

2008-12-15 17:27:55 wikidb-itops_: Failed to bind as testdomain\***username B***

2008-12-15 17:27:55 wikidb-itops_: with password: ***password***

2008-12-15 17:27:55 wikidb-itops_: Entering allowPasswordChange

2008-12-15 17:27:55 wikidb-itops_: Entering modifyUITemplate

With both configurations I've tried logging in as various accounts, nothing seems to be valid.

I do not think that I want to use basic authentication because it looks like it was trying to log in with 'username B' (which is what I put in the configuration) even though I may try to login with 'username A' on the login screen.

My configuration with IIS is such that they must provide domain user credentials to access mediawiki to begin with. A second login is ok though, using those same credentials. If it were possible to autolog them in based on the credentials they already gave ($_SERVER['AUTH_USER']) that would be ideal -- however in that case I would still need to be able to login as a local user to access the wiki Admin account that was created on installation.

I appreciate your work on this extension and your continuing effort with support.

-- Michael

USER-NAME is the exact string you need to put in, when the user logs in, USER-NAME will be replaced with the username the user submitted.

proxy bind problem

Hi, when i try to login i get a white page. I'm sure PHP have LDAP enabled because i made a test script and it can connect and bind without problems.

MediaWiki version: 1.13.3

Plugin version: 1.2a and SVN 45350

Config:

$wgLDAPDebug = 5;
$wgDebugLogGroups["ldap"] = 'file.log';
require_once( "$IP/extensions/LdapAuthentication.php" );
$wgAuth = new LdapAuthenticationPlugin();
$wgLDAPDomainNames = array("test.es");
$wgLDAPServerNames = array("test.es"=>"ldap.test.es");
$wgLDAPUseLocal = true;
$wgLDAPEncryptionType = array("test.es"=>"clear");
$wgLDAPSearchAttributes = array('test.es' => 'uid');
$wgLDAPBaseDNs = array('test.es' => 'dc=test,dc=es');
$wgLDAPUserBaseDNs = array('test.es' => 'ou=usuarios,dc=test,dc=es');
$wgMinimalPasswordLength = 1;
$wgLDAPProxyAgent = array('test.es'=>'cn=proxyuser,dc=test,dc=es');
$wgLDAPProxyAgentPassword = array('test.es'=>'XXXX');

Log:

2009-01-03 15:25:11 Entering validDomain

2009-01-03 15:25:11 User is not using a valid domain.

2009-01-03 15:25:11 Setting domain as: invaliddomain

2009-01-03 15:25:11 Entering allowPasswordChange

2009-01-03 15:25:11 Entering modifyUITemplate

2009-01-03 15:25:11 Allowing the local domain, adding it to the list.

2009-01-03 15:25:45 Entering validDomain

2009-01-03 15:25:45 User is using a valid domain.

2009-01-03 15:25:45 Setting domain as: test.es

2009-01-03 15:25:45 Entering getCanonicalName

2009-01-03 15:25:45 Username isn't empty.

2009-01-03 15:25:45 Munged username: user.name

2009-01-03 15:25:45 Entering userExists

2009-01-03 15:25:45

2009-01-03 15:25:45 Entering authenticate

2009-01-03 15:25:45

2009-01-03 15:25:45 Entering Connect

2009-01-03 15:25:45 Using TLS or not using encryption.

2009-01-03 15:25:45 Using servers: ldap://ldap.test.es

2009-01-03 15:25:45 Connected successfully

2009-01-03 15:25:45 Entering getSearchString

2009-01-03 15:25:45 Doing a proxy bind

2009-01-03 15:26:30 Failed to bind as cn=proxyuser,dc=test,dc=es

2009-01-03 15:26:30 with password: XXXXX

2009-01-03 15:26:30 Failed to bind

2009-01-03 15:26:30 User DN is blank

2009-01-03 15:26:30 Entering allowPasswordChange

2009-01-03 15:26:30 Entering modifyUITemplate

2009-01-03 15:26:30 Allowing the local domain, adding it to the list.

Can you try this with the stable version of the plugin (svn rev 43434), and see if it works for you? I made significant changes since then, and there is a possibility that I broke proxy binding; I haven't tested proxy bind yet since I made the changes.
--Ryan lane 15:09, 5 January 2009 (UTC)

I get the same results in that version.

-- Vicente

I just realized you mentioned you are getting a white page... That means you are getting a php crash. What is showing up in your php error logs (may show in your http error logs)?
--Ryan lane 23:29, 12 January 2009 (UTC)

$wgLDAPAuthAttribute seems to be broken in 1.2a

Maybe it's just me but it seems like $wgLDAPAuthAttribute is broken in 1.2a when not using auto authentication (on mediawiki 1.13.3 & php5). See my debug output:

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.
userdn is: cn=First Last,o=Some Company,ou=people,dc=domain,dc=com

Binding as the user
Bound successfully
Checking for auth attributes

Warning: ldap_read() [function.ldap-read]: Search: No such object in /var/www/vhosts/wiki/mediawiki/extensions/LdapAuthentication.php on line 336

Warning: ldap_get_entries(): supplied argument is not a valid ldap result resource in /var/www/vhosts/wiki/mediawiki/extensions/LdapAuthentication.php on line 337
Failed auth attribute check
Entering strict.
Returning false in strict().
Entering allowPasswordChange
Entering modifyUITemplate
Allowing the local domain, adding it to the list.

Here are my settings:

## Section for configuring LDAP authentication
require_once("extensions/LdapAuthentication.php");
$wgAuth = new LdapAuthenticationPlugin();
$wgLDAPDomainNames = array(
  "companyLDAPdomain"
  );
$wgLDAPServerNames = array(
  "companyLDAPdomain"=>"ldap.company.com"
  );
$wgLDAPUseLocal = true;
$wgLDAPEncryptionType = array(
  "companyLDAPdomain"=>"clear"
  );
$wgLDAPProxyAgent = array(
  "companyLDAPdomain"=>"cn=wiki,ou=proxy,dc=company,dc=com"
  );
$wgLDAPProxyAgentPassword = array(
  "companyLDAPdomain"=>"password"
  );
$wgLDAPSearchAttributes = array(
  "companyLDAPdomain"=>"uid"
  );
$wgLDAPBaseDNs = array(
  "companyLDAPdomain"=>"ou=people,dc=company,dc=com"
  );
$wgLDAPRequireAuthAttribute = array(
  "companyLDAPdomain"=>true
  );
$wgLDAPAuthAttribute = array(
  "companyLDAPdomain"=>"wikiAttributes=externalwiki"
  );

$wgLDAPDebug = 3;

The userdn in question does have that custom attribute (from a custom schema) 'wikiAttributes' defined and it's set to 'externalwiki'. Am I doing something wrong or is there really a bug? I tried hacking lines 336 & 337 but to no avail. This also seems to be happening on the latest from subversion as of rev 45670.

--Howard, 01/11/2009

Try setting your auth attribute to the following:

$wgLDAPAuthAttribute = array( "companyLDAPdomain"=>"(wikiAttributes=externalwiki)" );

--Ryan lane 23:23, 12 January 2009 (UTC)

Thank you for the quick response! I finally got to the bottom of this. Turns out your code is perfect (sorry); this is a permissions issue. The proxy user had access to those attributes, but once it did the bind to the user in question; it had no access to any of its own attributes! I guess reading through the debug statements carefully is something I should've done _first_. Oops!

--Howard H 14:33, 14, January 2009 (CST)

Kerberos in a Windows environment

Is it possible to set up kerberos to work in a Windows environment? If yes; How?? --Aroekene 15:26, 12 January 2009 (UTC)

Your question isn't very clear. Are you looking to use IIS+mediawiki+AD? Are you looking to use apache and mediawiki on windows with AD? Are you looking to use apache and mediawiki on linux with AD? All of the answers are likely yes. You pretty much just need to follow the directions for the kerberos part. I'd make sure that regular LDAP authentication is working before you try enabling kerberos (one step at a time is always best).
--Ryan lane 23:26, 12 January 2009 (UTC)

Windows Server 2003 - IIS6 - AD - MediaWiki - Ldap Authentication. Regular LDAP is working fine. I'll try to go trough the examples one more time. --Aroekene 08:57, 13 January 2009 (UTC)

Make sure "Integrated authentication" is enabled in IIS. Also, ensure that your client has gssapi/spengo/kerberos/integrated auth enabled. You may also want to check your server strings, and make sure it is $_SERVER["REMOTE_USER"]; it is possible this string is something different in IIS. I haven't tested this in IIS.
--Ryan lane 14:10, 13 January 2009 (UTC)

usernames containing underscore (_)

How do you set up LDAP to deal with usernames containing underscore (_). It seems like the underscore in usernames is converted to spaces ( ). --Aroekene 15:28, 12 January 2009 (UTC)

This question has been answered numerous times on this discussion page; there are workarounds, and I don't intend on fixing this right now.
--Ryan lane 23:27, 12 January 2009 (UTC)

Usernames containing parenthesis

I had some problems with a username for the LDAP Wikimedia France (fr:Utilisateur:(:Julien:)) because of its parenthesis : debug=" Created a regular filter: (sn=\5c28:Julien:\5c29)". I succeed by changing getLdapEscapedString into :

return str_replace(
                       array( "\\", "*", "(", ")", "\x00" ), //replace this
                       array( "\\5c", "\\2a", "\\28", "\\29", "\\00" ), //with this
                       $string //in this
               );

~ Seb35 11:13, 13 January 2009 (UTC)

Thanks for the bug report, I'll add this in the TODO. I'll release this with the next version.
--Ryan lane 14:11, 13 January 2009 (UTC)

AuthPlugin.php required?

I just installed LdapAuthentication and LdapAutoAuthentication from SVN, and I'm noticing now that there's an error thrown that AuthPlugin is needed. Looking back, I see that earlier versions of the plugin appear to have a require_once for AuthPlugin.php, but that has been removed. Was that intentional? I'm running MediaWiki 1.11.0, and I can't get the plugin to run without that line. --Laduncan 20:03, 13 January 2009 (UTC)

It shouldn't be required. That said, I didn't make that change, and it may only apply to 1.12 and higher. Try adding it back in and see if it works...
--Ryan lane 22:33, 13 January 2009 (UTC)

I needed to add require_once("AuthPlugin.php"); to LocalSettings.php.

Without it, I was getting this error:

Class 'AuthPlugin' not found in extensions/LdapAuthentication/LdapAuthentication.php on line 70

on Debian Lenny, Mediawiki 1.12.0, LDAP Authentication Plugin 1.2b. --Albert25 14:43, 2 January 2011 (UTC)

1. Don't edit the archives!
2. Don't use the Debian MediaWiki package. I refuse to offer support for that version of MediaWiki.

   --Ryan lane 19:00, 2 January 2011 (UTC)

Userexists method always returns true.

Hi.

I'm currently working on a Wiki project, and I'm a very beginner with wiki.

However, i'd like to be able to check if somebody is in Active Directory.

The following code is in the loginToUse() method of the Outputpage class (in OutputPage.php) (which is easier for me now)

$auth = new LdapAuthenticationPlugin();
echo $auth->userExists("firstname.lastname");

And the response of the log is :

Entering userExists

1

Moreover, the LocalSettings.php file is configured properly because I can authenticate to the wiki with LDAP.

Where is the problem ?

Thanks

In some situations, the plugin always returns true in userExists, here is the line of code that is returning true:

        //If we can't add LDAP users, we don't really need to check
        //if the user exists, the authenticate method will do this for
        //us. This will decrease hits to the LDAP server.
        //We do however, need to use this if we are using auto authentication.
        if ( ( !isset( $wgLDAPAddLDAPUsers[$_SESSION['wsDomain']] ) || !$wgLDAPAddLDAPUsers[$_SESSION['wsDomain']]) && !$this->useAutoAuth() ) {
            return true;
        }

If you aren't using auto-authentication, and you aren't allowing the wiki to add users, the plugin will always return true in this method. As the comments mention, the authenticate method will fail if the user doesn't exist, so it is redundant (and a waste of resources) to first check if the user exists unless we absolutely have to.

If you have a valid need for this kind of functionality, you can add an option to have the wiki always check for existence.
--Ryan lane 15:57, 17 February 2009 (UTC)

LdapAutoAuthentication::Authenticate failed to return a value

I've setup a Kerberos/OpenLDAP SSO solution for my group. I'm trying to get mediawiki to authenticate against the kerberos server and use LDAP to get simple user information (like their name and maybe email address). My goal is to not allow new user accounts to be created or anonymous edits and views on the wiki. I have mod_auth_kerb setup and working correctly. I'm getting an error message from mediawiki that I can't figure out. Here is the message:

Warning: call_user_func_array() [function.call-user-func-array]: First argument is expected to be a valid callback, 'LdapAutoAuthentication::Authenticate' was given in /srv/web/mediawiki-1.13.3/includes/Hooks.php on line 117
Internal error

Detected bug in an extension! Hook LdapAutoAuthentication::Authenticate failed to return a value; should return true to continue hook processing or false to abort.

Backtrace:

#0 /srv/web/mediawiki-1.13.3/includes/User.php(748): wfRunHooks('UserLoadFromSes...', Array)
#1 /srv/web/mediawiki-1.13.3/includes/User.php(221): User->loadFromSession()
#2 /srv/web/mediawiki-1.13.3/includes/User.php(1732): User->load()
#3 /srv/web/mediawiki-1.13.3/includes/User.php(1745): User->getGroups()
#4 /srv/web/mediawiki-1.13.3/includes/User.php(1718): User->getEffectiveGroups()
#5 /srv/web/mediawiki-1.13.3/includes/User.php(1864): User->getRights()
#6 [internal function]: User->isAllowed('read')
#7 /srv/web/mediawiki-1.13.3/includes/StubObject.php(58): call_user_func_array(Array, Array)
#8 /srv/web/mediawiki-1.13.3/includes/StubObject.php(184): StubObject->_call('isAllowed', Array)
#9 [internal function]: StubUser->__call('isAllowed', Array)
#10 /srv/web/mediawiki-1.13.3/includes/Title.php(1450): StubUser->isAllowed('read')
#11 /srv/web/mediawiki-1.13.3/includes/Wiki.php(149): Title->userCanRead()
#12 /srv/web/mediawiki-1.13.3/includes/Wiki.php(54): MediaWiki->preliminaryChecks(Object(Title), Object(OutputPage), Object(WebRequest))
#13 /srv/web/mediawiki-1.13.3/index.php(93): MediaWiki->initialize(Object(Title), NULL, Object(OutputPage), Object(User), Object(WebRequest))
#14 {main}

Here are all of my additions (to the bottom) of my LocalSettings.php file:

# LDAP Authentication
require_once('extensions/LdapAuthentication.php');

$wgLDAPDomainNames = array("testing");
$wgLDAPServerNames = array("testing"=>"ldaps.example.com");

$wgLDAPAutoAuthDomain = "testing";

$wgLDAPProxyAgent = array("testing"=>"cn=ldapbrowser,dc=example,dc=com");
$wgLDAPProxyAgentPassword = array("testing"=>"password");
$wgLDAPBaseDNs = array("testing" => "dc=example,dc=com");

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

$wgLDAPAutoAuthUsername = preg_replace( '/@.*/', '', $_SERVER["REMOTE_USER"] );

AutoAuthSetup();

# Prevent new user registrations
$wgGroupPermissions['*']['createaccount'] = false;
# Restrict anonymous editing
$wgGroupPermissions['*']['edit'] = false;
# Restrict anonymous reads
$wgGroupPermissions['*']['read'] = false;

$wgShowExceptionDetails = true;

$wgLDAPDebug = 3;

I'm running the latest packaged Apache2 and PHP on a Ubuntu 8.04 server. I'm using the latest mediawiki (1.13.3) and Ldap_Authentication extension 1.2a.

Let me know if I can provide any other info to help diagnose this error. I really appreciate the work you've done on the extension and the support!

Thanks, Ken

I think I may be missing an argument in a function, can you please try the following patch:

--- LdapAutoAuthentication.php.old      2009-02-03 17:20:13.460951000
-0600
+++ LdapAutoAuthentication.php  2009-02-03 17:25:08.974031000 -0600
@@ -7,7 +7,16 @@
         *
         * @access public
         */
-       static function Authenticate( $user, &$result ) {
+       static function AuthenticateAfterLoad( $user ) {
+               return LdapAutoAuthentication::Authenticate( true, $user );
+       }
+
+       /**
+        * Does the web server authentication piece of the LDAP plugin.
+        *
+        * @access public
+        */
+       static function Authenticate( &$result, $user ) {
                global $wgUser;
                global $wgAuth;
                global $wgLDAPAutoAuthUsername;

--- LdapAuthentication.php.old  2009-02-03 17:25:44.236929000 -0600
+++ LdapAuthentication.php      2009-02-03 17:26:13.602250000 -0600
@@ -1741,7 +1741,7 @@
                if ( version_compare( $wgVersion, '1.14.0', '<' ) ) {
                        $wgHooks['UserLoadFromSession'][] = 'LdapAutoAuthentication::Authenticate';
                } else {
-                       $wgHooks['UserLoadAfterLoadFromSession'][] = 'LdapAutoAuthentication::Authenticate';
+                       $wgHooks['UserLoadAfterLoadFromSession'][] = 'LdapAutoAuthentication::AuthenticateAfterLoad';
                }
                $wgHooks['PersonalUrls'][] = 'LdapAutoAuthentication::NoLogout'; /* Disallow logout link */
        }

--Ryan lane 15:48, 17 February 2009 (UTC)

LDAP Authentication just stoppped working

I'm fairly new to php, but I managed to get MWv1.12 with PHP5.2.0 up and running with little difficulty. I'm running on Windows Server 2003 with IIS6.0

I have LDAPAuthentication.php (1.1g I think) integrating with my AD .. until a few days ago. It has just stopped working. I've turned on debugging and get the following:

Entering validDomain
User is using a valid domain.
Setting domain as: development
Entering getCanonicalName
Username isn't empty.
Munged username: wikiuser
Entering authenticate
Entering Connect
It looks like you are issing LDAP support; please ensure you have either compiled LDAP support in, or have enabled the module. If the authentication is working for you, the plugin isn't properly detecting the LDAP module, and you can safely ignore this message.
Using TLS or not using encryption.
Using servers: ldap://dc1.development.com ldap://dc2.development.com

I've added some more debug output, and in LDAPAuthentication.php the page just stops on the line :

$ldapconn = @ldap_connect( $servers );

My LocalSetting.php file contains the following:

# LDAP Authentication
require_once ("extensions/LdapAuthentication.php");
$wgAuth = new LdapAuthenticationPlugin();
$wgLDAPDomainNames = array(development");
$wgLDAPServerNames = array("development" => "dc1.development.com dc2.development.com");
$wgLDAPProxyAgent  = array("development"=>"cn=wikiuser,cn=Users,dc=development,dc=com");
$wgLDAPProxyAgentPassword = array("development"=>"wikipassword");
$wgLDAPSearchAttributes = array("development"=>"sAMAccountName");
$wgLDAPBaseDNs = array("development" => "DC=development, DC=com");
$wgLDAPUseLocal = false;
$wgLDAPEncryptionType = array("development" => "clear");
$wgMinimalPasswordLength = 1;
$wgLDAPDebug = 4;

I've checked and access to my domain controllers on port 389 seems fine. The user I'm authenticating with is active and not locked out or anything similar. I tried just replacing the LDAPAuthentication.php with the 1.2a version, but that doesn't run at all, so I'm assuming that I'missing some new variables in LocalSettings or something, I'll have to look into that.

It's been working fine for months, and this week I have this problem. Does anyone know of a microsoft patch or something else that may have stopped PHP being able to query the AD?

I know it's not a lot to go on, but can anyone help?

Thanks --Jcc105 09:44, 30 January 2009 (UTC)

If nothing changed on the web server side, I'd check on the AD side. Maybe there is an issue with one of your AD servers? Did you try putting dc2 before dc1 in the ServerNames option? Does your security log on the AD server show that the proxyagent is successfully authenticating? Also, I'm sure this is probably a typo, but this line is missing a quote:

$wgLDAPDomainNames = array(development");

It should be:

$wgLDAPDomainNames = array("development");

--Ryan lane 15:45, 17 February 2009 (UTC)

White page

Hi,

i am using the LDAP Extension in one of my wikis and everything is working fine! Now í installed a new wiki and i wanted to use the LDAP Authentification, too. I used the same configuration as in my first wiki but it is not working! After the login i get a white page. The URL seems to be ok. Had anyone the same problem or has anyone an idea what the fault is?

Thanks!

Is this new wiki on a new server? If so, you may be missing ldap support in php. Or maybe you are missing ssl support? Is anything showing up in your php logs (possibly in your webserver's error_log or ssl_error_log).
--Ryan lane 15:41, 17 February 2009 (UTC)

I had the exact same issue and here is how I solved it:

I ran this command to install LDAP support in php

sudo apt-get php5-ldap

After that I rebooted the server and then this LDAP auth. extension started working. Thanks for the tip, Ryan! --65.196.104.59 18:17, 23 September 2009 (UTC)

Kerberos question

See on page: Extension:LDAP Authentication/Kerberos Configuration Examples

// After we set all configuration options, we want to setup the Auto Auth plugin. This will // create an instance of LdapAuthentication as $wgAuth

how does AutoAuthSetup() work's on localsettings.php

It finishes setting up the plug-in, and creates $wgAuth. I'm not sure if this answers your question.
--Ryan lane 20:30, 26 February 2009 (UTC)

Compatibility with 1.13 and 1.14?

Can the creator of this extension or other users confirm that this extension (1.2) is really stable MW1.6 upwards all the way to 1.14.0? --Piksi 11:38, 24 February 2009 (UTC)

It should be, but I don't have a test suite set up to test for this kind of compatibility. I also don't have good enough hardware, or licenses for things like Windows 2003 Enterprise Edition.

If someone wants to donate a Macbook Pro with a lot of RAM, and a Windows 2003 Enterprise Edition license, I'll be more than happy to set up a proper testing environment with unit tests. I'd probably be more likely to kill some of the other AD related TODO's too.
--Ryan lane 20:29, 26 February 2009 (UTC)

Working fine on MW1.14 --62.172.72.131 12:25, 12 March 2009 (UTC)

Is my Config Wrong?

Hi, I'm trying to autentifcate against an AD on Windows 2003 SBS Server. With Ldap Browser login succseed.

my config:

require_once("AuthPlugin.php");
require_once ('extensions/LdapAuthentication.php');

$wgAuth = new LdapAuthenticationPlugin();

$wgLDAPDomainNames = array(
  'Test'
);

$wgLDAPServerNames = array(
  'Test' => 'ad.Test.local'
);

$wgLDAPSearchStrings = array(
  'Test' => 'USER-NAME@Test.local'
);

$wgLDAPEncryptionType = array(
  'Test' => 'clear'
);

$wgLDAPUseLocal = false;

$wgMinimalPasswordLength = 1;

$wgLDAPBaseDNs = array(
  'Test' => 'DC=Test,DC=local'
);

$wgLDAPSearchAttributes = array(
  'Test' => 'sAMAccountName'
);

$wgLDAPUserBaseDNs = array(
  "Test"=>"CN=SBSUsers,OU=Users,OU=MyBusiness,DC=Test,DC=local"
  );

$wgLDAPDebug = 99;

After failed Login:

    Entering validDomain
    User is using a valid domain.
    Setting domain as: Test
    Entering getCanonicalName
    Username isn't empty.
    Munged username: TestUser
    Entering userExists

    Entering authenticate

    Entering Connect
    Using TLS or not using encryption.
    Using servers: ldap://ad.Test.local
    Connected successfully
    Entering getSearchString
    Doing a straight bind
    userdn is: TestUser@Test.local

    Binding as the user
    Failed to bind as TestUser@Test.local
    with password: 123
    Entering allowPasswordChange
    Entering modifyUITemplate

I don't know why Binding failed. User and Password are right.

Thank you!

Everything looks right to me. Are you sure your AD server allows binds without encryption? By default it doesn't.
--Ryan lane 14:22, 3 March 2009 (UTC)

Thank you for the fast reply

No I'm not sure. Do you know where I can check / change it in windows?

Not sure; it is going to be in the security policy on the domain controller though. Should be something like "require secure channel for authentication". I'd check for you, but I don't have a Windows 2003 system to check against.
--Ryan lane 20:56, 3 March 2009 (UTC)

strange TLS problem

When apache has been running for more than a day (approx) a TLS based connection cannot be established so people cannot log in:

Unable to start TLS: Connect error in /var/www/wiki/extensions/LdapAuthentication.php on line 213

but as soon as i restart apache it works again,

Also if i disable TLS it works again, but i want/need TLS.

Debian 5.0 on sparc.

any ideas?

I'd recommend checking your openldap configuration, and your php configuration. Your openldap configuration is likely to be in /etc/openldap/ldap.conf. I haven't seen this issue before...

Is ldap.max_links set to something other than -1 in your php configuration?

Unable to set LDAPUserName via wghooks/SetUsernameAttributeFromLDAP

Greetings,

Perhaps I'm misunderstanding what this function does, or misunderstanding how to configure it.. but I've tried for a while now, could use a little help.

I'm running 1.2alpha on MW 1.14.0 .

I'm backending to a Novell eDirectory, and using a broker account to gain access. User authentication works fine, but I don't want the Wiki user to be their 'uid'. Id rather it be their 'Givenname'. This is what I've basically defined:

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

function SetUsernameAttribute(&$LDAPUsername, $info) {
        $LDAPUsername = $info[0]['givenName'][0];
        return true;
}

It's almost like it doesn't do anything. In debug it would say "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"

So I tried changing givenName to 'cn', and the error goes away.. but it doesn't seem to do anything at that point.

I had a similar issue with setting peoples preference for Real Name, and Nickname.. "email" worked fine off the bat.. but realname and nickname I could only set to a few attributes (cn being one of them), but fullName, givenName, etc.. weren't allowed. They are certainly in the directory though. I tried putting in 'mail' (Which worked fine for email..), but wouldnt work for those.

However, with this LDAPUsername piece.. nothing seems to work.. cn, email, fullName.. At least it seems to identify that 'cn' has something in it.. but doesnt show it, and the "username" i end up with when it created the MW account is always the normal uid.

Thoughts? Thanks a lot..

To use this, you need to set the following option:

$wgLDAPGroupUseRetrievedUsername = array( "domainname" => true );

Also, if the debug message is saying a string isn't being returned, it is likely one isn't. Notice that php requires attributes to be given in all lowercase (see the php documentation for this). So, you want to do:

$LDAPUsername = $info[0]['givenname'][0];

--Ryan lane 21:41, 15 April 2009 (UTC)

I can't get this to work; I want the mediawiki username to be picked from an LDAP attribute.

However once the user is logged in the username is the one they used in the login box, mediawiki ends up creating new users rather than using the existing user id from the LDAP attribute.

$wgLDAPGroupUseRetrievedUsername is not what we want as the groups use the full DN ($wgLDAPGroupUseFullDN overrides it anyway).

I have checked the hook function; it returns a string correctly every time it's called.

If possible I'd rather not have to use the user-renaming option I see in the code.

--152.78.65.7 09:14, 29 June 2009 (UTC)

Ok I've written a patch to 1.2b with which this is now possible. It rewrites the username in getCanonicalName() BEFORE MediaWiki creates a User object.

It might need some tidying to be most efficient to the LDAP server, but you're welcome to merge the code into trunk and tidy it up

Patch is here: [1] It includes a small bugfix to a line outside that function, and a tweak to connect().

--152.78.65.7 12:17, 29 June 2009 (UTC)

This patch will break the way auto-authentication works in the plugin. It does look like the way MediaWiki does auto-authentication makes the hook useless for anything other than auto-authentication though. I'll look into a way to fix this. I personally always thought getCanonicalName was called at an inopportune time.
--Ryan lane 22:07, 29 June 2009 (UTC)

"Connected successfully" lies?

I think I might have something horribly misconfigured (using 1.2a with Mediawiki 1.9.3 and PHP 5.2.8 on IIS6), but I'm having trouble trying log in to an AD server.

First of all, this is what I get whenever I try to log in (sensitive info in parenthesis):

Entering validDomain
User is using a valid domain.
Setting domain as: (company).com
Entering getCanonicalName
Username isn't empty.
Munged username: (me)
Entering userExists

Entering authenticate

Entering Connect
Using TLS or not using encryption.
Using servers: ldap://(ldapserver1).(company).com ldap://(ldapserver2).(company).com
Connected successfully
Entering getSearchString
Doing a straight bind
userdn is: (domain)\(me)

Binding as the user
Failed to bind as (company).com\(me)
Entering allowPasswordChange
Entering modifyUITemplate

And my config (sensitive info in parenthesis, again):

require_once("AuthPlugin.php");
require_once( "$IP/extensions/LdapAuthentication.php" );
$wgAuth = new LdapAuthenticationPlugin();

$wgLDAPDomainNames = array(
  '(company).com'
);
 
$wgLDAPServerNames = array(
  '(company).com' => '(ldapserver1).(company).com (ldapserver2).(company).com'
);
 
$wgLDAPSearchStrings = array(
  '(company).com' => '(company).com\\USER-NAME'
);

$wgLDAPEncryptionType = array(
  '(company).com' => 'clear'
);
 
$wgMinimalPasswordLength = 1;
$wgLDAPDebug = 3;

After tweaking it for a few hours and having nothing work, I became suspicious that it wasn't connecting to the server at all. One thing seemed to confirm this: I can change the LDAP server name to ANYTHING and it says it worked, even to the name of a machine not on our network. I can even mash the keyboard and use the resulting text as my Active Directory server name, and it still says it connected successfully (though it won't let me log in, obviously).

Does anyone have any advice, or can point out something I have wrong? Thank you.

Yes, it does lie. In php (and likely other languages), the connection to the server doesn't actually happen until the bind occurs. When connect() is called, "...it does not actually connect but just initializes the connecting parameters" [2]. To see if you are really connecting to the AD server, you can check the AD server's logs; you can also check netstat (

netstat -tanvp | egrep '389|636'

) to see if the connection was ever established.

Your AD server may not allow binds that aren't encrypted. You should try to bind over SSL. I have a blog entry that may help you with this [3].
--Ryan lane 21:47, 15 April 2009 (UTC)

Again : Undefined index: wsDomain in /LdapAuthentication.php

Hello, When I enter in 'My preference' page, i get the following error : Undefined index: wsDomain in /LdapAuthentication.php I'm running Mediawiki 1.14 and LdapAuthentication 1.1g. I also installed 1.2a but It still doesn't work. I checked some solutions listed above but it didn't helped.

Does someone have another suggestion ?

Benoit.heurter

1. This is only a warning, not an error
2. I was unable to reproduce this, please provide information about exactly what you are doing to get this message. Including configuration information and debug information will help (remember to snip out anything sensitive!).
   --Ryan lane 21:49, 15 April 2009 (UTC)

I can`t create a user.

SOLVED

Hi, i'm using LDAPAuthentication v1.2a on a MW1.13.2. To make some test i'm running it on a Wamp server, i have no problem binding users but when creating a new user, i can't do it if the user name is not the same as the real name.

CONFIGURATION:

require_once( "extensions/LdapAuthentication.php" );
$wgAuth = new LdapAuthenticationPlugin();

$wgLDAPDomainNames = array(
  "cord"
  );

$wgLDAPServerNames = array(
  "cord"=>"www.ldap.com"
  );

################################################
### Here was the problem                       #
###                                            #
### it was:                                    #
###   "cord"=>"cn=USER-NAME,dc=CORD,dc=COM"    #
###                                            #
### should be:                                 #
###    "cord"=>"uid=USER-NAME,dc=CORD,dc=COM"  #
################################################

$wgLDAPSearchStrings = array(
  "cord"=>"uid=USER-NAME,dc=CORD,dc=COM"
  );
$wgLDAPUserBaseDNs = array(
  "cord"=>"ou=people,dc=CORD,dc=COM",
  );
$wgLDAPUseLocal = false;
$wgLDAPWriterDN = array(
  "cord"=>"cn=super,dc=CORD,dc=COM"
  );
$wgLDAPWriterPassword = array(
  "cord"=>"xxxxxxxxx"
  );
$wgLDAPWriteLocation = array(
  "cord"=>"ou=people,dc=CORD,dc=COM"
  );
$wgLDAPAddLDAPUsers = array(
  "cord"=>true  
  );
$wgLDAPUpdateLDAP = array(  
  "cord"=>true
  );
$wgLDAPPasswordHash = array(
  "cord"=>"crypt"
  );
$wgLDAPDisableAutoCreate = array(
  "cord"=>false
  );
$wgMinimalPasswordLength = 1;
$wgLDAPEncryptionType = array(
  "cord"=>"clear"
  );
$wgLDAPDebug = 1;
$wgDebugLogGroups["ldap"] = "debug.log" ;

DEBUG:

Entering validDomain
User is using a valid domain.
Setting domain as: grupoalma
Entering validDomain
User is using a valid domain.
Entering getCanonicalName
Username isn't empty.
Munged username: Prova2
Entering addUser
Entering getPasswordHash
Password is {CRYPT}$1$ZJ5.u65.$yWG.aux8eosOp/6VZXaH0/
Entering Connect
Using TLS or not using encryption.
Using servers:  ldap://www.ldap.com
Successfully connected
Entering getSearchString
Doing a straight bind
userdn is: cn=Prova2,dc=CORD,dc=COM
Binding as the writerDN
Adding user
Failed to add user
Entering allowPasswordChange
Entering modifyUITemplate

Any ideas? Thanks, Alex

Creating a New User Demands LDAP Password

Hello! I'm also using LDAPAuthentication v1.2a on a MW 1.14.0 and everything works fine, but the creation of a new user... Only SysOp can create users (that's ok) but I don't want to suply the user's LDAP password in order to create it locally in my MW database. I just want to authenticate users agains our LDAP server when they are about to login.

My configuration:

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

require_once( "$IP/extensions/LdapAuthentication.php" );
$wgAuth = new LdapAuthenticationPlugin();

$wgLDAPDomainNames = array("DOMAIN");
$wgLDAPServerNames = array("DOMAIN"=>"192.168.0.1");
$wgLDAPEncryptionType = array("DOMAIN"=>"clear");
$wgLDAPProxyAgent = array(
  "DOMAIN"=>"CN=security.api,OU=Users,OU=WEB,OU=Applications,OU=Domain,DC=domainweb,DC=com,DC=br"
);
$wgLDAPProxyAgentPassword = array("DOMAIN"=>"password");
$wgLDAPSearchAttributes = array("DOMAIN"=>"sAMAccountName");
$wgLDAPBaseDNs = array("DOMAIN"=>"OU=Domain,DC=domainweb,DC=com,DC=br");
$wgLDAPPreferences = array(
  "DOMAIN"=>array("realname"=>"displayName", "nickname"=>"sAMAccountName")
);
$wgLDAPDisableAutoCreate = array("DOMAIN"=>true);
$wgMinimalPasswordLength = 1;

I really don't recommend doing this. The plugin doesn't support what you are drying to do. If you want to limit who can log in, limit it via LDAP groups. The plugin creates user accounts when the use logs in. It expects authentication to occur for the user.
--Ryan lane 21:51, 22 May 2009 (UTC)

Also I had to change one single line of code in the LdapAuthentication.php (function getUserDN) but that was just because of our LDAP server' structure (I'm not the LDAP server's admin):

//Smartcard auth needs to check LDAP for required attributes.
if ( ( isset( $wgLDAPRequireAuthAttribute[$_SESSION['wsDomain']] ) && $wgLDAPRequireAuthAttribute[$_SESSION['wsDomain']] )
	&& $this->useAutoAuth() ) {
	$auth_filter = "(" . $wgLDAPAuthAttribute[$_SESSION['wsDomain']] . ")";
	$srch_filter = "(" . $wgLDAPSearchAttributes[$_SESSION['wsDomain']] . "=" . $this->getLdapEscapedString( $username ) . ")";
	$filter = "(&" . $srch_filter . $auth_filter . ")";
	$this->printDebug( "Created an auth attribute filter: $filter", SENSITIVE );
} else {
	// Changed line (added the restriction objectClass=user to the filter
	$filter = "(&(objectClass=user)(" . $wgLDAPSearchAttributes[$_SESSION['wsDomain']] . "=" . $this->getLdapEscapedString( $username ) . "))";
	$this->printDebug( "Created a regular filter: $filter", SENSITIVE );
}

Why did you change the line? There should rarely be a reason to change any code; the only thing I've seen that requires a code change is underscores in usernames, and thats because I don't support it yet. If you tell me what your structure looks like, I'll tell you a way to do this without changing the code.
--Ryan lane 21:51, 22 May 2009 (UTC)

Currently I need to suply the user's LDAP password in order to create locally in our wiki... :-(

Please help me! Thank you. Felix

--200.169.115.32 21:01, 22 May 2009 (UTC)

User not loaded from session in MW 1.14

When setting up a LDAP+Kerberos authentication with MediaWiki 1.14, I noticed that (with Kerberos to protect the entire wiki) the log stated User isn't logged in, calling setup every time a page was loaded. This leads to an update of the user data via LDAP on every page load, even when the user is supposed to be detected from the session data.

It turned out that in AutoAuthSetup() the variable $wgVersion is not visible and so the old hook UserLoadFromSession is set. Inside the handler LdapAutoAuthentication::Authenticate the version check is working, but due to the wrong hook the function is called before the user is loaded from the session and so a check against the LDAP database is performed every time a page is loaded (baaaad performace).

Since the new hook UserLoadAfterLoadFromSession takes only one parameter $user as opposed to the two parameters expected by UserLoadFromSession, it is necessary to introduce a proxy function (I called it AuthenticateNew) that passes a dummy parameter to the Authenticate function.

The following quick+dirty patch is working:

LdapAuthentication.php:

function AutoAuthSetup() {
   global $wgVersion;
   ...
      if ( version_compare( $wgVersion, '1.14.0', '<' ) ) {
         $wgHooks['UserLoadFromSession'][] = 'LdapAutoAuthentication::Authenticate';
      } else {
         $wgHooks['UserLoadAfterLoadFromSession'][] = 'LdapAutoAuthentication::AuthenticateNew';
      }
   ...
}

LdapAutoAuthentication.php:

   static function AuthenticateNew($user) {
      $dummyResult = null;
      return LdapAutoAuthentication::Authenticate($user, $dummyResult);
   }

LosWochos 08:48, 14 April 2009 (UTC)

I've noticed this and haven't gotten a chance to fix it yet. I'll put this on my TODO; hopefully I'll be able to fix it a cleaner way :).
--Ryan lane 21:52, 15 April 2009 (UTC)

Successful login not recognized by MediaWiki

I believe I have configured everything correctly and have successfully authenticated with LDAP extenstion. I put a die() command at line 553 which is just before the return statement in the authenticate function. I received the following debug informaton:

Entering validDomain
User is using a valid domain.
Setting domain as: *mydomain
Entering getCanonicalName
Username isn't empty.
Munged username: Tim.love
Entering authenticate

Entering Connect
Using TLS or not using encryption.
Using servers: ldap://mydomain.local
Connected successfully
Entering getSearchString
Doing a straight bind
userdn is: mydomain\Tim.love

Binding as the user
Bound successfully
Entering getUserDN
Created a regular filter: (sAMAccountName=Tim.love)
Entering getBaseDN
basedn is OU=Operations, dc=mydomain,dc=local
Using base: OU=Operations, dc=mydomain,dc=local
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=Love\, Tim,OU=Users,OU=Operations,DC=mydomain,DC=local
Authentication passed

the problem: it doesn't appear the MediaWiki sees me as logged in. After logging in I do not get an error message and it redirects me back to the page i was just on, but the the login link is still there and i am unable to edit any pages. it appears as an issue with the communication between LDAPAuthentication and MediaWiki.

Any help would be appreciated

It sounds to me like you have a cookie issue. Is this working without the LDAP plugin enabled?
--Ryan lane 21:53, 15 April 2009 (UTC)

USER CAN'T LOGIN IF LOGIN OR PASSWORD HAVE SPACES " "

Yes mi friends, if the user have one username or password with space " " he cant login at the wiki =( Thanks for any help User:LKS45

That's odd. Spaces aren't a restricted character in MediaWiki user names. This should just work. Is this working with other user names? Can you post your config and debug output with sensitive stuff snipped out?
--Ryan lane 21:47, 19 May 2009 (UTC)

TLS Not Starting with version 1.2a

I am unable to get required groups to work with 1.2a (even login for that matter). I get "Warning: ldap_start_tls() [function.ldap-start-tls]: Unable to start TLS: Server is unavailable in LdapAuthentication.php on line 213".

This is the same configuration I have been running since mediawiki 1.9.3, but for some reason it no longer works when I upgrade to 1.2a from 1.1c. If I switch from 1.2a back to 1.1c, everything works as it should.

Here is my snippet from my LocalSettings.php file.

require_once( 'LdapAuthentication.php' );
$wgAuth = new LdapAuthenticationPlugin();
$wgLDAPProxyAgent = array( "DOMAIN"=>"CN=ldapquery,CN=users,DC=DOMAIN,DC=com" );
$wgLDAPSearchAttributes = array( "DOMAIN"=>"sAMAccountName");
$wgLDAPProxyAgentPassword = array( "DOMAIN"=>"somepasswdxxx");
$wgLDAPDomainNames = array( "DOMAIN" );
$wgLDAPServerNames = array( "DOMAIN"=>"dc1.domain.com dc2.domain.com");
$wgLDAPRequiredGroups = array( "domain.com"=>array( "cn=DL,ou=someou,ou=anotherou,ou=anotherou,ou=anotherou,ou=anotherou,dc=domain,dc=com" );
$wgLDAPGroupUseFullDN = array( "DOMAIN"=>true);
$wgLDAPGroupObjectclass = array( "DOMAIN"=>"group");
$wgLDAPGroupAttribute = array( "DOMAIN"=>"member");
$wgLDAPGroupSearchNestedGroups = array( "DOMAIN"=>false);
$wgLDAPBaseDNs = array( "DOMAIN"=>"dc=domain,dc=com");
$wgLDAPEncryptionType = array("DOMAIN"=>"tls");
$wgLDAPUseLocal = false;
$wgLDAPAddLDAPUsers = false;
$wgLDAPUpdateLDAP = false;
$wgLDAPMailPassword = false;
$wgLDAPRetrievePrefs = true;
$wgMinimalPasswordLength = 1;
$wgLDAPGroupLowerCaseUsername = false;

Am I missing something here?

Thanks for the help.

Starting in 1.1d, I enforced start_tls (like I should have been doing to begin with). If start_tls fails, the plugin will die. In 1.1c, the plugin would continue even if the communication wasn't encrypted. You need to check your openldap configuration, and make sure that your web server trusts your AD server. Also, I'm not sure if AD supports LDAP with start_tls. You should switch to using LDAPS:

$wgLDAPEncryptionType = array( "DOMAIN"=>"ssl" );

--Ryan lane 21:45, 19 May 2009 (UTC)

Bug in group parsing?

Trying to work out my group assignment problems. I've got

$wgLDAPGroupsUseMemberOf['domain'] = true;

Unfortunately, the code path this seems to follow pushes the group name on the $groups["dn"] array, but NOT on the $groups["short"] array. This causes a problem later in function hasLDAPGroup. My PHP-fu is abysmal, but I'll look for a patch.

I'll look into this. I'm pretty sure this should be working, but the code is new so there are likely bugs.
--Ryan lane 18:21, 26 May 2009 (UTC)

Here's a (clunky) patch

--- LdapAuthentication.php.orig 2009-05-26 15:16:46.000000000 -0400
+++ LdapAuthentication.php.new  2009-05-26 15:28:53.000000000 -0400
@@ -1278,9 +1278,12 @@
                global $wgLDAPGroupSearchNestedGroups;
                global $wgLDAPGroupsPrevail;
                global $wgLDAPGroupsUseMemberOf;
+               global $wgLDAPGroupNameAttribute;

                $this->printDebug("Entering getGroups", NONSENSITIVE);

+               $nameattribute = $wgLDAPGroupNameAttribute[$_SESSION['wsDomain']];
+
                //Find groups
                if ( isset( $wgLDAPRequiredGroups[$_SESSION['wsDomain']] ) || ( isset( $wgLDAPUseLDAPGroups[$_SESSION['wsDomain']] ) && $wgLDAPUseLDAPGroups[$_SESSION['wsDomain']] ) ) {
                        $this->printDebug( "Retrieving LDAP group membership", NONSENSITIVE );
@@ -1307,9 +1310,15 @@
                                if ( isset( $this->userInfo[0]["memberof"] ) ) {
                                        # The first entry is always a count
                                        $memberOfMembers = $this->userInfo[0]["memberof"];
                                        array_shift( $memberOfMembers );
                                        $groups = array( "dn"=> array(), "short"=>array() );
                                        foreach( $memberOfMembers as $mem ) {
+                                               if (eregi("$nameattribute=([^,]*),.*", $mem, $attribs))
+                                                       $short = $attribs[1];
+                                               else
+                                                       $this->printDebug("Failed to get short name of group $mem", NONSENSITIVE);
+                                               array_push( $groups["short"], strtolower( $short ) );
                                                array_push( $groups["dn"], strtolower( $mem ) );
                                        }
                                        $this->userLDAPGroups = $groups;

Nice. Thanks for the patch. This does indeed look like it'll solve that problem. I'll include this in the next release. What's your name, so that I can give you credit in the changelog?
--Ryan lane 20:12, 26 May 2009 (UTC)

I'm Brent Powers. Unfortunately, though, this isn't done yet. Nested groups aren't working. I'm shrugging in despair.

I need to review this code. I'm not sure if I'm even searching for nested groups when using memberOf. I don't even remember if that is required. I'll get back with you on this. Not having an AD server to test against makes this fairly difficult.
--Ryan lane 21:37, 26 May 2009 (UTC)

Another feature request

Although I found a patch that purported to solve the primary group problem with AD, it didn't work for me (using memberof, at least). However, the patch below gives a kludgy work around, allowing specification of a $wgLDAPAdditionalGroups (an array of arrays, like

$wgLDAPAdditionalGroups = 
  array(
    'addomain' => array('autowikigroup1','autowikigroup2'),
    'ldapdomain' => array('autowikigroup2','autowikigroup3')
  );

Authentication against the ldap domain would cause the two indicated groups to be added, if there is a reason for the groups.

--- LdapAuthentication.php.predefault   2009-05-27 01:46:23.000000000 -0400
+++ LdapAuthentication.php      2009-05-27 02:17:50.000000000 -0400
@@ -1496,6 +1496,7 @@
   function setGroups( &$user ) {
     global $wgLDAPGroupsPrevail, $wgGroupPermissions;
     global $wgLDAPLocallyManagedGroups;
+    global $wgLDAPAdditionalGroups;

     //TODO: this is *really* ugly code. clean it up!

@@ -1515,7 +1516,14 @@
       $locallyManagedGrps = $defaultLocallyManagedGrps;
       $this->printDebug( "Locally managed groups is unset, using defaults: ", SENSITIVE, $locallyManagedGrps );
     }
-
+
+# add additional groups
+    if ( isset( $wgLDAPAdditionalGroups ) &&
+        isset( $wgLDAPAdditionalGroups[$_SESSION['wsDomain']] ) &&
+        $wgLDAPAdditionalGroups[$_SESSION['wsDomain']] )
+      $AdditionalGroups = $wgLDAPAdditionalGroups[$_SESSION['wsDomain']];
+    else
+      $AdditionalGroups = array();

 # Add ldap groups as local groups
     if ( isset( $wgLDAPGroupsPrevail[$_SESSION['wsDomain']] ) && $wgLDAPGroupsPrevail[$_SESSION['wsDomain']] ) {
@@ -1527,6 +1535,7 @@

     $this->printDebug( "Available groups are: ", NONSENSITIVE, $localAvailGrps );
     $this->printDebug( "Effective groups are: ", NONSENSITIVE, $localUserGrps );
+    $this->printDebug( "Additional groups are: ", NONSENSITIVE, $AdditionalGroups );

 # note: $localUserGrps does not need to be updated with $cGroup added,
 #       as $localAvailGrps contains $cGroup only once.
@@ -1534,7 +1543,9 @@
 # did we once add the user to the group?
       if ( in_array( $cGroup,$localUserGrps ) ) {
        $this->printDebug( "Checking to see if we need to remove user from: $cGroup", NONSENSITIVE );
-       if ( ( !$this->hasLDAPGroup( $cGroup ) ) && ( !in_array( $cGroup, $locallyManagedGrps ) ) ) {
+       if ( ( !$this->hasLDAPGroup( $cGroup ) ) &&
+            ( !in_array( $cGroup, $locallyManagedGrps ) ) &&
+            ( !in_array( $cGroup, $AdditionalGroups ) ) ) {
          $this->printDebug( "Removing user from: $cGroup", NONSENSITIVE );
 # the ldap group overrides the local group
 # so as the user is currently not a member of the ldap group, he shall be removed from the local group
@@ -1542,7 +1553,7 @@
        }
       } else { # no, but maybe the user has recently been added to the ldap group?
        $this->printDebug( "Checking to see if user is in: $cGroup", NONSENSITIVE );
-       if ( $this->hasLDAPGroup( $cGroup ) ) {
+       if ( in_array($cGroup, $AdditionalGroups) || $this->hasLDAPGroup( $cGroup ) ) {
          $this->printDebug( "Adding user to: $cGroup", NONSENSITIVE );
          $user->addGroup( $cGroup );
        }

memberOf support is fairly new, and isn't the only way to have group support in AD. Use the regular group restrictions and group synchronization. I really would like to avoid adding any other methods for handling groups.
--Ryan lane 13:10, 27 May 2009 (UTC)

Huh... I wish I'd known that (that memberOf support is new) before getting started. The issue is that these groups don't exist at the domain. I understand the problem with the primary AD group - I need, and this provides a flexible way, to replicate the 'Domain Users' group in an AD situation, without addition of a new AD group, and the (ongoing) maintenance hassles that that would entail.

Whats the difference between the domain user group, and the user role that mediawiki automatically assigns to every logged in user? Just assign whatever default permissions you want logged in users to have to the user role.
--Ryan lane 14:16, 27 May 2009 (UTC)

Which domain user group? And which domain? 'user' is fine iff you have one and only one domain.

Also, if you want to have some groups that are just managed at the MediaWiki level, it is possible to have groups that only have partial synchronization; meaning AD can add users to the group if the AD group exists, but won't remove any users. See the $wgLDAPLocallyManagedGroups option.
--Ryan lane 14:19, 27 May 2009 (UTC)

Right. Again, that's fine, but, if the Domain Users group isn't reliable (which, as it is by default primary), that requires the administrators to add every user in AD to a given group. I'll withdraw the request.

No. users is a built in role. If a user authenticates, they are automatically part of the user role - no exceptions. This isn't a group you manage. You can decide to remove/add permissions from the default user role via LocalSettings.php, but authenticated users will always be in this role. My recommendation was to just add the permissions you want to this role via LocalSettings.php instead of relying on a primary group that every user is a part of.
--Ryan lane 13:41, 28 May 2009 (UTC)

Login error: Incorrect password entered. Please try again.

Hi I'm trying to login and create accounts however I get the above error, which is coupled with the Debug information:

Binding as the user
Failed to bind as domain\user
with password: #########
Entering allowPasswordChange
Entering modifyUITemplate

I would think I've got something wrong in the localsettings.php, however one particular user is able to login using their domain credentials.

I'm using version 1.2a of the plugin and version 1.13.3 of media wiki, running on Windows 2k3 Server using IIS.

My local settings are:

require_once("AuthPlugin.php");

require_once 'extensions/LdapAuthentication.php';
 
$wgAuth = new LdapAuthenticationPlugin();
 
$wgLDAPDomainNames = array(
  'DOMAIN'
);
 
$wgLDAPServerNames = array(
 'DOMAIN' => 'SERVER.PLACE.COM'
);

$wgLDAPSearchStrings = array(
 'DOMAIN' => 'DOMAIN\\USER-NAME'
);

$wgLDAPEncryptionType = array( 'DOMAIN' => 'Clear' ); 

$wgMinimalPasswordLength = 1;

$wgLDAPDebug = 5; //debugging
  
# This means that you can login using Wiki managed users
$wgLDAPUseLocal = false;

Any help would be greatly appreciated, I just can't see what's wrong, particularly considering one user can login successfully.

Try:

$wgLDAPSearchStrings = array( 'DOMAIN' => 'USER-NAME@YOUR.FULLY.QUALIFIED.DOMAIN' );

Some people have issues with one format over the other; I'm not exactly sure why.
--Ryan lane 19:50, 3 June 2009 (UTC)

Hi I've tried that. No good still the same problem. Ed (12:30 Aug 19th 2009 GMT)

Maybe your Active Directory server doesn't allow clear text binds? Most secured environments don't allow that.
--Ryan lane 14:29, 20 August 2009 (UTC)

Using LDAP to automatically recognize users from NT

I have a wiki (using MediaWiki) that I am working on that is on a local enterprise network that uses authentication from NT. I want to be able to authenticate users automatically (with NT) as the user access the wiki. The main goals are keep track of who edits according to their NT login and prevent the user from having to log on to the network and the wiki site as well. One seamless authentication would be nice.

If this does not work with LDAP, is there another extension/add-on that will allow me to do this?

You are using an Active Directory domain, and not an NT domain right? If so, this does work with the LDAP extension; but, it may be overkill if you only want authentication. See the kerberos configuration examples for this.
--Ryan lane 19:53, 3 June 2009 (UTC)

Can't set user rights because of lower case conversion issue

Ryan,

We have both Ldap authenticated users and local users on our wiki. When an authenticated user tries to change user rights for a local user, at some point the username gets passed to the getCanonicalName function. Since the user doing the rights change is logged in via LDAP, the domain is set to our company domain. This causes the username to be converted to all lowercase even though the user whose rights are being changed is in the local domain. So long story short, the user rights change fails because its trying to look the user up using an all lowercase (minus the first letter) version of their username. --Cneubauer 12:50, 5 June 2009 (UTC)

Looks to be related to this post above: Extension talk:LDAP Authentication#usedomain.2C useemail.2C getCanonicalName.28.29.2C and email confirmation. On second thought, it seems like the lowercasing should be limited to the case where the function is called to log a user into the Ldap. In all other cases, the user name should be left alone. Hmm... --Cneubauer 14:02, 5 June 2009 (UTC)

Remove Sysop, Bureaucrat, Bot from locally managed groups

Hi Ryan,

i managed to set up the plugin and it's working mighty fine so far. One thing i'd like to do is to have sysop, bureaucrat and bot groups completely managed from LDAP. What works, is that if i create a sysop group in ldap and add users to it, these users in fact become sysops once they log in the first them. Problem is, when i remove them from the group, they still stay inside sysop in the wiki because the group is locally managed. Is there a specific reason why you decided to have these groups locally managed, only, or can I safely patch them out from the code? An option to make this configurable would be nice in a future version. -- Jan Thomae, June 9th, 2009

I know there was a good reason for this, but I can't seem to remember it now. I'll change this behavior so that by default those groups are locally managed, but the behavior can be overridden. You can safely hack this out, but for compability with future versions, you should add this to your LocalSettings.php file:

$wgLDAPLocallyManagedGroups = array( "yourdomain"=>array() );

Of course, if you do want some groups to be locally managed, you should add them into the array.
--Ryan lane 21:44, 15 June 2009 (UTC)

Group authentication works for some accounts but not for all

I've got an issue with group authentication where one account will be found in the built in group domain users but another account will not. I've not been able to find a correlation between accounts that work and accounts that do not.

code used is as follows:

require_once('extensions/LDAPAuthentication/LdapAuthentication.php');

$wgAuth = new LdapAuthenticationPlugin();

$wgLDAPDomainNames = array('ad');

$wgLDAPServerNames = array('ad' => 'adserver.com');

$wgLDAPBaseDNs = array('ad' => 'DC=adserver,DC=com');

$wgLDAPSearchStrings = array("ad"=>"aes\\USER-NAME",);

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

$wgLDAPProxyAgent = array ("ad" => "cn=account,cn=users,dc=ad,dc=com");

$wgLDAPProxyAgentPassword = array ("ad" => "**********");

$wgLDAPRequiredAuthAttribute = array ("ad" => true );

$wgLDAPRequiredGroups = array( "ad"=>array("cn=domain users,cn=users,dc=ad,dc=com") );

$wgLDAPGroupUseFullDN = array( "ad"=>true );

$wgLDAPGroupObjectclass = array( "ad"=>"group" );

$wgLDAPGroupAttribute = array( "aes"=>"member" );

$wgLDAPGroupSearchNestedGroups = array( "ad"=>true );

$wgLDAPGroupNameAttribute = array( "ad"=>"cn" );

$wgLDAPBaseDNs = array( "ad"=>"dc=ad,dc=com" );

$wgLDAPSearchAttributes = array( "ad"=>"sAMAccountName", "email" );

$wgLDAPRetrievePrefs = array("ad"=>true);

$wgLDAPGroupUseRetrievedUsername = array("ad"=>true);

$wgHooks['SetUsernameAttributeFromLDAP'][] = 'SetUsernameAttribute';function SetUsernameAttribute(&$LDAPUsername, $info) {$LDAPUsername = $info[0]['samaccountname'][0];return true;};

$wgLDAPPreferences = array("ad"=>array( "email"=>"mail","realname"=>"cn","nickname"=>"sAMAccountName"),"ad"=>array( "email"=>"mail","realname"=>"displayName","nickname"=>"cn","language"=>"preferredLanguage"));

$wgMinimalPasswordLength = 1;

$wgLDAPDisableAutoCreate = array("ad"=> false);

$wgLDAPDebug =3;

I can see in the debug output one accounts that work that the plugin will find membership in domain users with: Returned groups:domain users,abq administration,#aes blackberry,#aes vpn accounts,#aes employees albuquerque,abq lidar,#aes e-time approvers,#aes ebuyitt,abq remote assistance,#aes it leads,#aes it employees,matlab users,noprmselfservice,#aes department y,alx lidar group,zone 1-north annex printers,#aes albuquerque it,#aes playbook pilot users

but an account that doesn't work returned groups: comes up blank. The test account only has domain users membership, if I add it to another group, returned groups: will return the other group but not domain users.

All user accounts are in various OUs and not in the builtin users container.

Curious about what might be happening. I've seen this on other non-builtin groups as well were it is catch as catch can.

thanks, --Phil Bryant151.190.254.108 14:39, 11 June 2009 (UTC)

additional info

We're running media wiki 1.13.3 and ldapauth 1.2a

--Phil Bryant151.190.254.108 15:31, 11 June 2009 (UTC)

Are all your user's primary group "Domain Users", or do some users have "Domain Users" and some don't?
--Ryan lane 17:23, 17 June 2009 (UTC)

Interestingly enough, the account that always works has a different group set as primary group, the default for most accounts should be Domain Users. I removed the ldaprequiredgroups option as I also needed to do some group synchronization and it allowed for AD authentication but I still need to be able to require a specific group. --Phil Bryant

That actually makes perfect sense. If the plugin isn't finding the user's primary group (which is likely), then anyone with that primary group will be denied.

Why do you need to require a specific group? You are currently letting everyone in Domain Users log in. If nearly everyone is in that group, how is that any different than just requiring authentication? If you need to exclude specific people, you can use exclusion groups.

I'm working on support for finding the user's primary group; however, it may not be out for a while.
--Ryan lane 20:47, 30 June 2009 (UTC)

That's not a bad idea using group exclusion; the project needed to specifically exclude non-US persons from viewing ITAR and EAR specific data posted on the wiki. I suppose as long as I can be sure that non-US persons aren't in the Domain Users group then I'm fine. As an added precaution I'll look at group exclusions. Thanks! --Phil Bryant

Creating a separate wiki username associated with an LDAP username

First, I would like to say that the LDAPAuthentication plugin is nice and works well. I am using it for our department's wiki, and we would like to have a way for users to specify a "wiki username" which the user can specify when creating their new account (in addition to their LDAP name). This is done for reasons of (semi-)anonymity. What I am envisioning is that the wiki username will be associated to the LDAP name, and when the user attempts to login using their wiki name, an SQL query could grab the person's username to run the LDAP authentication. Do you know of a way this could be done within this plugin?

--Emptydubs

This isn't possible with the plugin unless you hack it. On the other hand, you can do semi-anonymous logins through other means, but the end-user won't be able to select the name. I'll write up a blog post on doing this, and post the link here.
--Ryan lane 13:56, 18 June 2009 (UTC)

See my blog post on this.
--Ryan lane 15:33, 18 June 2009 (UTC)

Thanks for the post, Ryan. I don't think this is what I am looking for, however. I want to let the user have a custom username that is associated, but independent of, their LDAP username, and which is displayed on the wiki instead of the LDAP name. Could I store the two usernames in a table and grab the LDAP username when the user attempts to login to the wiki? I imagine this could be done in either the connect() or authenticate() functions, and I could use the "email" field for the user to put their LDAP username when they create an account (this would be fine since 'email' is currently not utilized in our wiki). What are your thoughts on this solution?

--Emptydubs

I'm not sure exactly how you'd want to do this; however, you could have probably use the create an account form to initially do this, and hack the script to use the email address to authenticate. Then you could store the username in another table, and hack the authenticate function to yank the email address from the database and authenticate to ldap using that...

I don't think this is going to be easy, but I'm sure it's doable.
--Ryan lane 17:58, 18 June 2009 (UTC)

Thank you very much for the support. One quick thing: at what point in the code are the username and password sent to LDAP? In other words, where would be the best place to replace the LDAP username with the Wiki username? After that, I believe I have it figured out. --Emptydubs

I would like to do something similar to this. I also need the LDAP username to be hidden, i.e. it should never appear in the wiki. What I'd like to do is allow users to log in with their LDAP username, but have the MediaWiki username set to a more useful field from LDAP, e.g. displayName. This seems on the face of it to be a relatively simple change -- at the point where the MediaWiki username is set it could be substitued with the displayName. Would it really be that simple? Any pointers as to where in the code I should start? - Borofkin 06:51, 25 June 2009 (UTC)

Ahhh, I think the blog post answers my question. - Borofkin 06:54, 25 June 2009 (UTC)

Did you get this working? Notice that my blog post obfuscates the user name. If you simply want to use another attribute, you can just remove all the stuff that obfuscates the field pulled.
--Ryan lane 21:04, 25 June 2009 (UTC)

That's exactly what I intend to do -- just use the displayName attribute. I haven't tried it out yet. I'll let you know how it goes. - Borofkin 05:04, 30 June 2009 (UTC)

This does not appear to work. I've even hardcoded $LDAPUsername to a string in the SetUsernameAttribute function but it doesn't appear to have any effect. Also, for some reason the debug messages don't appear. I've set the debug level to 3, and I get messages prior to login, but after entering username/password, no more debug messages appear. I'm using MW 1.5.0 and LDAP Auth 1.2a. - Borofkin 00:46, 6 July 2009 (UTC)

Okay, I have modified some of the code (in the function getSearchString) and I can now log in to the wiki using a unique username (but only for those who have already input their email address and are in the Wiki database ). Obviously, this means that I cannot currently create new accounts using a unique wiki username. I am trying to figure out how one could grab the information about the user from the "Create Account" form within this plugin. I know that it is done in SpecialUserlogin, but can it be done here? Would it be possible to grab the user's submission before the plugin authenticates? Thoughts? -- Emptydubs 15:55, 25 June 2009

Maybe in the UserExists function?
--Ryan lane 21:05, 25 June 2009 (UTC)

Using LDAP data in pages

Users of this extension may be interested in a recent addition to Extension:External Data. It can now query LDAP servers and make the results available to be used in wikipages via a parser function call. The extension was written with Semantic MediaWiki in mind, but it doesn't depend on SMW and can still be quite useful without it. - Borofkin 04:50, 24 June 2009 (UTC)

I saw the announcement for this; very cool. Can it pull information from LDAP, then display the output in vcard format? I could see this being extremely useful.
--Ryan lane 21:02, 25 June 2009 (UTC)

Well, I pull information from LDAP based on a userid, and then assign the results to semantic properties. The #get_ldap_data call resides on a template, and each user has a wikipage containing the template. I've never used it, but I assume you could produce vcard output using the Semantic Result Formats vcard format. - Borofkin 05:09, 30 June 2009 (UTC)

AD Login doesn't work for a subset of users

When I initially deployed this LDAPAuth and AD configuration, it worked (for myself and another user). However, now it no longer works and no new users can login in. I'm using a relatively standard.

Notice how when I login it works, and after "Munged username:" it calls "Entering authenticate". However, for an unsuccessful login (any new user) it calls "Entering allowPasswordChange". I can confirm 100% all new users are in the wiki-users group, and have valid/working LDAP credentials.

Any idea what is happening here? Greatly appreciated.

I can log in, and the other original person can log in. When we login and it works without a problem, the log displays:

2009-06-30 06:13:35  wikidb-mw_: Entering validDomain
2009-06-30 06:13:35  wikidb-mw_: User is not using a valid domain.
2009-06-30 06:13:35  wikidb-mw_: Setting domain as: invaliddomain
2009-06-30 06:13:35  wikidb-mw_: Entering allowPasswordChange
2009-06-30 06:13:35  wikidb-mw_: Entering modifyUITemplate
2009-06-30 06:13:37  wikidb-mw_: Entering validDomain
2009-06-30 06:13:37  wikidb-mw_: User is using a valid domain.
2009-06-30 06:13:37  wikidb-mw_: Setting domain as: MYDOMAIN
2009-06-30 06:13:37  wikidb-mw_: Entering getCanonicalName
2009-06-30 06:13:37  wikidb-mw_: Username isn't empty.
2009-06-30 06:13:37  wikidb-mw_: Munged username: user1
2009-06-30 06:13:37  wikidb-mw_: Entering authenticate
2009-06-30 06:13:37  wikidb-mw_: 
2009-06-30 06:13:37  wikidb-mw_: Entering Connect
2009-06-30 06:13:37  wikidb-mw_: Using TLS or not using encryption.
......

When a new user, who is in AD and is inside the "wiki-users" group, they only get this and an error saying "Login error: There is no user by the name "user1". Check your spelling."

2009-06-30 06:28:37  wikidb-mw_: Entering validDomain
2009-06-30 06:28:37  wikidb-mw_: User is not using a valid domain.
2009-06-30 06:28:37  wikidb-mw_: Setting domain as: invaliddomain
2009-06-30 06:28:37  wikidb-mw_: Entering allowPasswordChange
2009-06-30 06:28:37  wikidb-mw_: Entering modifyUITemplate
2009-06-30 06:28:41  wikidb-mw_: Entering validDomain
2009-06-30 06:28:41  wikidb-mw_: User is using a valid domain.
2009-06-30 06:28:41  wikidb-mw_: Setting domain as: MYDOMAIN
2009-06-30 06:28:41  wikidb-mw_: Entering getCanonicalName
2009-06-30 06:28:41  wikidb-mw_: Username isn't empty.
2009-06-30 06:28:41  wikidb-mw_: Munged username: user3
2009-06-30 06:28:41  wikidb-mw_: Entering allowPasswordChange
2009-06-30 06:28:41  wikidb-mw_: Entering modifyUITemplate
... no more output...

This is the configurarion:

$wgLDAPDomainNames = array('MYDOMAIN');
$wgLDAPServerNames = array('MYDOMAIN' => 'dc1.MYDOMAIN.com dc2.MYDOMAIN.com');


# Search based bind
# Username/passwd for searching AD
$wgLDAPSearchAttributes = array( "MYDOMAIN"=>"sAMAccountName");
$wgLDAPBaseDNs = array("MYDOMAIN" => "ou=Location,dc=MYDOMAIN,dc=com" );
$wgLDAPProxyAgent = array( "MYDOMAIN"=>"wiki");
$wgLDAPProxyAgentPassword = array( "MYDOMAIN"=>"password");

$wgLDAPEncryptionType = array( 'MYDOMAIN' => 'clear');
$wgLDAPPreferences = array( "MYDOMAIN"=>array( "email"=>"mail","realname"=>"cn","nickname"=>"sAMAccountName"));

# An array of the groups the user is required to be a member of.
$wgLDAPRequiredGroups = array(
   "MYDOMAIN"=>array( "CN=wiki-users,OU=Groups,DC=MYDOMAIN,DC=com")
);
$wgLDAPGroupObjectclass = array("MYDOMAIN"=>"group");
$wgLDAPGroupAttribute = array( "MYDOMAIN"=>"member");
$wgLDAPGroupUseFullDN = array( "MYDOMAIN"=>true );
$wgLDAPUseLDAPGroups = array( "MYDOMAIN"=>true);
$wgLDAPGroupObjectclass = array( "MYDOMAIN"=>"group" );
$wgLDAPGroupNameAttribute = array( "MYDOMAIN"=>"cn" );

# Our specific Ldap Mediawiki options
$wgLDAPUseLocal = false;
$wgLDAPLoweCaseUsername = array( "MYDOMAIN"=>true);
$wgLDAPDisableAutoCreate = array( "MYDOMAIN"=>true);
$wgMinimalPasswordLength = 1;

Why are you disabling auto create? This is almost definitely your issue. When a user logs in for the first time, the wiki generally creates the user automatically. When you disable auto-create, after the user authenticates, the wiki won't create an account for the user, and as such will tell you that the user doesn't exist (because the user doesn't, in the wiki database). wgLDAPDisableAutoCreate should only be used if you have a *really* good reason, as it is mostly a hack imo. It especially doesn't make sense since you are using groups to restrict login.
--Ryan lane 13:35, 30 June 2009 (UTC)

Can local users change their passwords?

I have a fairly large wiki with lots of local users, and (recently) lots of LDAP users. After installing the LDAP extension, my local users can't change their passwords anymore. I understand why the LDAP users shouldn't be able to do this, but can this behavior be changed for the local users? Having local users with unchangeable passwords seems like a bad thing. 66.232.252.214 22:22, 2 July 2009 (UTC)

If they can't, this is a regression. I'll look into it.
--Ryan lane 20:16, 9 July 2009 (UTC)

Unable to authntify against OpenLDAP

debug output :

Entering validDomain
User is using a valid domain.
Setting domain as: LDAPwikiAuth
Entering getCanonicalName
Username isn't empty.
Munged username: Testf
Entering userExists

Entering authenticate

Entering Connect
Using TLS or not using encryption.
Using servers: ldap://localhost
Connected successfully
Entering getSearchString
Doing an anonymous bind
Entering getUserDN
Created a regular filter: (uid=Testf)
Entering getBaseDN
basedn is not set for this type of entry, trying to get the default basedn.
Entering getBaseDN
basedn is dc=test,dc=fr
Using base: dc=test,dc=fr
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.
userdn is: cn=test compte,ou=people,dc=test,dc=fr

Binding as the user
Bound successfully
Authentication passed
Entering allowPasswordChange
Entering initUser
Entering updateUser
Entering allowPasswordChange
Entering modifyUITemplate

Error message at the login : Login error Incorrect password entered. Please try again.

From the debug output, i don't see where the problem is. Could you help ? Thanks.

Can you post your configuration with sensitive stuff snipped out please?
--Ryan lane 14:08, 13 July 2009 (UTC)

$wgLDAPDomainNames = array('LDAPwikiAuth');
$wgLDAPServerNames = array('LDAPwikiAuth' => 'localhost');
$wgLDAPSearchAttributes = array('LDAPwikiAuth' => 'uid');
$wgLDAPBaseDNs = array('LDAPwikiAuth' => 'dc=test,dc=fr');
$wgLDAPEncryptionType = array('LDAPwikiAuth' => 'clear');
$wgLDAPDebug = 5;

I don't see anything wrong. What version of the plugin, and what version of MediaWiki are you using?
--Ryan lane 17:44, 13 July 2009 (UTC)

I just upgraded mediawiki to 1.15.1 and it seems to be working now. I was in 1.15.0. And got the last version of the plugin.
Thanks.

Complete LDAP migration

Hi,

This is maybe a bit complex. What we want to do is to migrate a wiki wich is currently on a hoster that does not support ldap, to another hoster that support ldap. We would also have to use some other tools than mediawiki with shared logins so that we have to migrate all the current users database to ldap

I'm a bit noob at this, what I would like to know is if there is a way to do it simplely. I did not find any info about mediawiki to LDAP. There is about 30 users, so we can make it by hand if necessary, the only thing would be passwords.

Thanks !

--Thibho 23:19, 16 July 2009 (UTC)

If you mean you are going to have a brand new LDAP database, and import the users from MediaWiki into your new LDAP database, you'll need to export the users into LDIF format, then import them into LDAP. Unfortunately, the passwords will be an issue; MediaWiki hashes the user's passwords in the database, and hashes the passwords in a way that is unlikely to be supported by the LDAP server.

You can probably email your users temporary passwords (which you've set in LDAP manually), and ask them to change them when they log in. I recommend making a script that generates a random password for each user, sets it in LDAP, then emails them the new password.
--Ryan lane 21:34, 21 July 2009 (UTC)

Ok thanks ! This is what I mean ! --Ttibot 21:46, 21 July 2009 (UTC)

Security Groups vs Distribution Groups

When I try to use security groups in $wgLDAPRequiredGroups I do not have success. But if I try to use distribution groups it seems to work alright. Any idea why this may be the case?

Is there a difference in the schema for the two different groups? Maybe they use different object classes, or use different naming attributes? I don't have an Active Directory server to test with, so it'll be fairly hard to help you with this issue. I mention this in the supporting the extension section of the documentation ;). I can probably help you troubleshoot though.
--Ryan lane 02:06, 13 August 2009 (UTC)

Using both Auto-authentication and LDAP-authentication

I'm using NTLM via Apache to set up $REMOTE_USER, and am able to use LDAP to auto-authenticate, BUT I want to enable BOTH this type of authentication and normal LDAP to enable logout and switching users. which is currently (hardcodedly) disabled.

any thought?

I've noticed I can change a few things, like comment:

/*if ( isset( $wgLDAPAutoAuthDomain ) ) {
                        $this->printDebug( "Allowing auto-authentication login, removing the domain from the list.", NONSENSITIVE );

                        //There is no reason for people to log in directly to the wiki if the are using an
                        //auto-authentication domain. If they try to, they are probably up to something fishy.
                        unset( $tempDomArr[array_search( $wgLDAPAutoAuthDomain, $tempDomArr )] );
                }*/

and maybe change "userAutoAuth" function, but is there an easier way and are there ramifications?

As the documentation mentions, if you want to do auto-authentication and regular authentication, you should set up two domains (domain1 and auto-domain1 or similar), and only protect a specific page with NTLM using a location directive. Then, edit your system messages to change your login page to include a link like "Log in automatically using your system credentials" that points to the protected page. The protected page in your wiki should have a redirect to a login landing page of your choosing. Users who want to log in with regular credentials can use the login box instead of the link. The auto-authentication domain won't show in the drop down list, as people should never log directly into that.

I put that check in because it simplifies the code, and avoids any possible unforeseen vulnerabilities. I'd really rather not take it out or modify it as I'd have to do a pretty thorough code review to ensure it is safe to do.
--Ryan lane 02:03, 13 August 2009 (UTC)

Login falling back to the database even when $wgLDAPUseLocal is false

I converted a plugin-less MediaWiki install to use the LDAP plugin (reported version: 1.2a beta, though the download link doesn't mention beta). While I can log in just fine using credentials stored in LDAP, I noticed that the credential check falls back to the credentials stored in the users table if LDAP authentication fails because of a bad password. For example, if I have user johndoe who has set his password in LDAP to foobar, while his password is barbaz in the users table, he can log in using either password. Setting $wgLDAPUseLocal to false doesn't seem to prevent the authentication check from falling back to the database. The only way I could find to prevent the fallback from working was to set the user_password field in the users table to "" (empty string).
--Chris 173.88.22.164

I'll look into this ASAP.
--Ryan lane 01:54, 13 August 2009 (UTC)

I just took a look over the code in User.php, SpecialUserlogin.php, and LdapAuthentication.php, and I don't see how this is possible unless you are setting:

$wgLDAPUseLocal = true;

or

$wgLDAPMailPassword = true;

You wouldn't happen to be setting:

$wgLDAPUseLocal = "false";

right? false as a string is true in PHP.

Can you post your configuration and debug info with sensitive stuff snipped out? Please include the MediaWiki version and the plugin version.
--Ryan lane 02:20, 13 August 2009 (UTC)

I don't know how fast I'll be able to respond to you. I'm in the process of moving and don't have very convenient access to the MediaWiki installation in question. I can tell you that it is version 1.15.1 running the most recent version of the LDAP plugin. As for the config file, I'll have to get back to you on that. Also, what debug information do you need? FYI, I didn't enter the value false as a string. I know well enough not to do that.
--Chris 173.88.22.164 02:50, 13 August 2009 (UTC)

You can get the debug info by setting the debugging options. I need to see the output of that to see what is going wrong.

As for false as a string, everyone does it every once in a while (even I've done it in my own configuration before ;) ). I was just hoping that was the problem; I wasn't expecting it.
--Ryan lane 14:13, 13 August 2009 (UTC)

I'm sorry, but I can't help you track down the issue anymore. It seems that my VPN access has already been revoked, even though my contract doesn't expire for another week. Since I'm no longer able to physically access the computer in question either, there's nothing I can do to access the wiki.
--Chris 173.88.22.164 17:31, 13 August 2009 (UTC)

It's ok. I'll test this soon with a test install, and ensure it isn't a problem in the plugin or mediawiki. I don't see any issues by looking over the code, but I may find some strange problem during testing.
--Ryan lane 18:09, 13 August 2009 (UTC)

Undefined index: wsDomain error

Hey, I just upgraded from MediaWiki 1.13 to 1.15.1 and am getting an error when clicking on my username link in the top right of the page (this should take you to the preferences page). When using MediaWiki 1.13 it would take me to the preferences page as expected, however it appears broken now. If I click the my preferences link it goes to the page without any issues. It gives a server error. This error occurs using version 1.2a and 1.2b The php error log messages i'm getting are:

[11-Aug-2009 15:35:36] PHP Notice: Undefined index: wsDomain in C:\inetpub\wwwroot\mediawiki\extensions\LdapAuthentication.php on line 785
[11-Aug-2009 15:35:36] PHP Notice: Undefined index: wsDomain in C:\inetpub\wwwroot\mediawiki\extensions\LdapAuthentication.php on line 789
[11-Aug-2009 15:35:36] PHP Notice: Undefined index: wsDomain in C:\inetpub\wwwroot\mediawiki\extensions\LdapAuthentication.php on line 793

I noticed another post above was getting a similar issue, but it didn't seem to be resolved. At this link it looks like this issue was fixed in version 1.1f -Extension:LDAP Authentication/Changelog Any help would be appreciated
--Richardj87

• Just an update: I'm also sometimes getting the same undefined index errors on lines 606, 609, and 613
  --Richardj87

I really don't get this. I haven't been able to replicate this. Ever. I've seen bug reports for this multiple times, and can't track it down. There must be something environmental happening. Does your server have session issues? Does this happen every time you try this, or only sometimes?

I also don't get the scenario you are describing. The only way you should be able to arrive at your preferences from the top of the page is by clicking the "My preferences" link. Clicking your username at the top should bring you to your user page. What other extensions do you have installed? Maybe there is an incompatibility between extensions?
--Ryan lane 01:53, 13 August 2009 (UTC)

• • Ok, turns out it wasn't the LDAP extension giving the server error. That was an issue with the way red mediawiki links (links that lead to a page not yet created) are handled in mediawiki version 1.15. In that version apparently it throws a 404 server error now. I had to change some settings in IIS on my server, as described in this bug report here - bugzilla:18270#c23. Also, you were right about it not taking me to the "my preferences" page. I made a mistake there, I meant to say it should take me to the user page. Anyway, i'm not sure i've gotten rid of those PHP messages about wsDomain, but everything seems to be working fine now.
    --Richardj87

Ah, you are using IIS? I wonder if that is the common thread behind this. I can't test in IIS because I don't have Windows Server 2003. It could be that IIS handles session stuff differently. wsDomain is added to your session when you log in, so as long as you have a valid session (which is kind of a requirement if you are logged in), wsDomain should always be set.
--Ryan lane 14:05, 13 August 2009 (UTC)

Yeah, using IIS (Server Manager) on Windows Server 2008. The wsDomain must be getting set fine because users are logging in fine. Sorry for the scare that it was some issue with the extension. I realise now the user and talk links have nothing to do with the ldap extension. It just so happened I was getting the server error at the same time those PHP warnings were coming up about wsDomain. Those php messages mustn't be causing any fatal problems, from what I can tell anyway.
--Richardj87

Well, they aren't fatal errors, but they still show an issue with MediaWiki, the plugin, or IIS. wsDomain is a session variable. There is some weirdness with your session if you are seeing those warnings; which could mean that your session is being reset at some point in time.
--Ryan lane 13:17, 17 August 2009 (UTC)

PHP 5.2.10 warnings

I started getting these warnings after updating to PHP 5.2.10

Warning: Invalid argument supplied for foreach() in /var/www/localhost/mediawiki-1.13.5/extensions/LdapAuthentication.php on line 1442
Warning: array_shift() [function.array-shift]: The argument should be an array in /var/www/localhost/mediawiki-1.13.5/extensions/LdapAuthentication.php on line 1438

Turns out ldap_get_entries now returns NULL instead of an empty array when there are no entries. This patch will remove the warnings:

--- LdapAuthentication.php-orig 2009-08-24 11:03:19.314425784 -0500
+++ LdapAuthentication.php      2009-08-24 11:10:37.693453065 -0500
@@ -1435,16 +1435,20 @@
                $entries = @ldap_get_entries( $this->ldapconn, $info );
 
                //We need to shift because the first entry will be a count
+               if( $entries ) {
                array_shift( $entries );
+               }
 
                //Let's get a list of both full dn groups and shortname groups
                $groups = array( "short"=>array(), "dn"=>array() );
+               if( $entries ) {
                foreach ( $entries as $entry ) {
                        $shortMember = strtolower( $entry[$nameattribute][0] );
                        $dnMember = strtolower( $entry['dn'] );
                        $groups["short"][] = $shortMember;
                        $groups["dn"][] = $dnMember;
                }
+               }
 
                $this->printDebug( "Returned groups:", SENSITIVE, $groups["dn"] );
 

Thanks for the patch. I'll include this in the next release.
--Ryan lane 17:31, 24 August 2009 (UTC)

Creating all lowercase entries in LDAP

Hi Ryan,

In my installation, I'm using Mediawiki as application responsible for creating new user accounts in LDAP. As you know, there are other alternatives, like OpenSSO, OpenPTK, simpleSAMLphp, Joomla, etc, but all require a lot of work and maintenance costs just to provide a very simple thing which is a form for self service user provisioning. Oh well, Mediawiki already provides it. :)

The only problem is that I find inconvenient the way wikis handle usernames. I find inconvenient having uid=Jsmith instead of uid=jsmith (and also dn=Jsmith,... instead of dn=jsmith,...) because there are other applications sharing the same LDAP repository and all assume all lowercases for the sake of simplicity. A wiki is an exception in this scenario.

I've patched v1.2b in order to create entries all lowercase in LDAP. Other small change is that I'd like to be able to require a not null email address during registration.

--- LdapAuthentication.php-1.2b 2009-09-01 00:26:48.000000000 +0100
+++ LdapAuthentication.php      2009-09-01 02:02:58.000000000 +0100
@@ -391,7 +391,9 @@
                }

                $template->set( 'usedomain', true );
-               $template->set( 'useemail', false );
+
+               global $wgEnableEmail;
+               $template->set( 'useemail', $wgEnableEmail );

                $tempDomArr = $wgLDAPDomainNames;
                if ( $wgLDAPUseLocal ) {
@@ -632,6 +634,7 @@
                global $wgLDAPWriteLocation;
                global $wgLDAPRequiredGroups, $wgLDAPGroupDN;
                global $wgLDAPAuthAttribute;
+               global $wgLDAPLowerCaseUsername;

                $this->printDebug( "Entering addUser", NONSENSITIVE );

@@ -692,7 +695,11 @@
                        }

                        //Set up LDAP attributes
-                       $values["uid"] = $username;
+                       if ( isset( $wgLDAPLowerCaseUsername[$_SESSION['wsDomain']] ) ) {
+                               $values["uid"] = strtolower( $username );
+                       } else {
+                               $values["uid"] = $username;
+                       }
                        //sn is required for objectclass inetorgperson
                        $values["sn"] = $username;
                        if ( '' != $this->email ) { $values["mail"] = $this->email; }
@@ -941,6 +948,7 @@
        function getSearchString( $username ) {
                global $wgLDAPSearchStrings;
                global $wgLDAPProxyAgent, $wgLDAPProxyAgentPassword;
+               global $wgLDAPLowerCaseUsername;

                $this->printDebug( "Entering getSearchString", NONSENSITIVE );

@@ -949,7 +957,11 @@
                        $this->printDebug( "Doing a straight bind", NONSENSITIVE );

                        $tmpuserdn = $wgLDAPSearchStrings[$_SESSION['wsDomain']];
-                       $userdn = str_replace( "USER-NAME", $username, $tmpuserdn );
+                       if ( isset( $wgLDAPLowerCaseUsername[$_SESSION['wsDomain']] ) ) {
+                               $userdn = str_replace( "USER-NAME", strtolower( $username ), $tmpuserdn );
+                       } else {
+                               $userdn = str_replace( "USER-NAME", $username, $tmpuserdn );
+                       }
                } else {
                        //This is a proxy bind, or an anonymous bind with a search
                        if ( isset( $wgLDAPProxyAgent[$_SESSION['wsDomain']] ) ) {

Kind Regards

Richard Gomes http://www.jquantlib.org/index.php/User:RichardGomes twitter: frgomes

JQuantlib is a Library for Quantitative Finance written in Java. http://www.jquantlib.org/ twitter: jquantlib

Requirements: Links

We need to add links for the latest update files located in the requirements section. --207.88.135.146 19:23, 3 September 2009 (UTC)

Successful login not recognized by MediaWiki - 2

Hi, after entering User and PW I'm getting the "Login required: You must log in to view other pages." Screen ?

Config

require_once( "$IP/extensions/LdapAuthentication2.php" );
$wgAuth = new LdapAuthenticationPlugin();

#$wgLDAPSearchAttributes = array( "bonn"=>"sAMAccountName", "berlin"=>"sAMAccountName" );
$wgLDAPSearchStrings = array( 'bonn' => 'bonn\\USER-NAME', 'berlin' => 'berlin\\USER-NAME' );
$wgLDAPDomainNames = array(
  "bonn","berlin"
  );

$wgLDAPServerNames = array(
  "bonn"=>"XXX03.bonn.iz-soz.de",
  "berlin"=>"XXX03.berlin.iz-soz.de",
  );
 
$wgLDAPUseLocal = true;
 
$wgLDAPEncryptionType = array(
  "bonn"=>"clear",
  "berlin"=>"clear"
  );

$wgLDAPGroupUseFullDN = array(
  "bonn"=>true,
  "berlin"=>true
  );

$wgLDAPLowerCaseUsername = array(
  "bonn"=>true,
  "berlin"=>true
  );
 
$wgLDAPGroupUseRetrievedUsername = array(
  "bonn"=>true,
  "berlin"=>true
  );
 
$wgLDAPGroupObjectclass = array(
  "testLDAPdomain"=>"group",
  "testADdomain"=>"group"
  );
 
$wgLDAPGroupAttribute = array(
  "bonn"=>"user",
  "berlin"=>"user"
  );
 
//The naming attribute of the group
$wgLDAPGroupNameAttribute = array(
  "bonn"=>"cn",
  "berlin"=>"cn"
  );
 
$wgLDAPGroupsUseMemberOf = array(
  "bonn"=>true,
  "berlin"=>true
  );



#$wgLDAPBaseDNs = array(
#  "bonn"=>"DC=bonn,DC=iz-soz,DC=de",
#  "berlin"=>"DC=berlin,DC=iz-soz,DC=de",
#  );

$wgLDAPGroupBaseDNs = array(
  "bonn"=>"ou=Gruppen und Listen,ou=IZ-Users,dc=bonn,dc=iz-soz,dc=de",
  "berlin"=>"ou=langroup,ou=IZ-Users,dc=iz-soz,dc=de",
  );

$wgLDAPUserBaseDNs = array(
  "bonn"=>"OU=langroup,OU=IZ-Users,DC=bonn,DC=iz-soz,DC=de",
  "berlin"=>"OU=Users,DC=berlin,DC=iz-soz,DC=de",
  );

$wgLDAPWriterDN = array(
  "bonn"=>"CN=ad-reader,OU=Organisatorisches,OU=IZ-Users,DC=bonn,DC=iz-soz,DC=de",
  "berlin"=>"CN=user-name,OU=Users,DC=berlin,DC=iz-soz,DC=de",
  );

$wgLDAPWriterPassword = array(
  "bonn"=>"pass",
  "berlin"=>"pass",
  );

$wgLDAPRetrievePrefs = array(
 'bonn' => true ,
 'berlin' => true 
);

$wgLDAPPreferences = array(
'bonn'=>array( "email"=>"mail","realname"=>"cn","nickname"=>"sAMAccountName"),
'berlin'=>array( "email"=>"mail","realname"=>"cn","nickname"=>"sAMAccountName")
);

$wgLDAPDebug = 3;
$wgDebugLogGroups["ldap"] = "$IP/LDAPdebug.log" ;

$wgHooks['SetUsernameAttributeFromLDAP'][] = 'SetUsernameAttribute';
 
function SetUsernameAttribute(&$LDAPUsername, $info) {
        $LDAPUsername = $info[0]['samaccountname'][0];
        return true;
}

Log

I tried logging in local the first time and the second i tried the LDAP. When i try to loggin local I get the message "Incorrect password"

2009-10-01 12:34:02  wikidb: Entering validDomain
2009-10-01 12:34:02  wikidb: User is not using a valid domain.
2009-10-01 12:34:02  wikidb: Setting domain as: invaliddomain
2009-10-01 12:34:02  wikidb: Entering allowPasswordChange
2009-10-01 12:34:02  wikidb: Entering modifyUITemplate
2009-10-01 12:34:02  wikidb: Allowing the local domain, adding it to the list.
2009-10-01 12:34:10  wikidb: Entering validDomain
2009-10-01 12:34:10  wikidb: User is using a valid domain.
2009-10-01 12:34:10  wikidb: Setting domain as: local
2009-10-01 12:34:10  wikidb: Entering getCanonicalName
2009-10-01 12:34:10  wikidb: Username isn't empty.
2009-10-01 12:34:10  wikidb: Munged username: Ba
2009-10-01 12:34:10  wikidb: Entering authenticate
2009-10-01 12:34:10  wikidb: User is using a local domain
2009-10-01 12:34:10  wikidb: Entering strict.
2009-10-01 12:34:10  wikidb: Returning false in strict().
2009-10-01 12:34:10  wikidb: Entering allowPasswordChange
2009-10-01 12:34:10  wikidb: Entering modifyUITemplate
2009-10-01 12:34:10  wikidb: Allowing the local domain, adding it to the list.
2009-10-01 12:34:29  wikidb: Entering validDomain
2009-10-01 12:34:29  wikidb: User is using a valid domain.
2009-10-01 12:34:29  wikidb: Setting domain as: bonn
2009-10-01 12:34:29  wikidb: Entering getCanonicalName
2009-10-01 12:34:29  wikidb: Username isn't empty.
2009-10-01 12:34:29  wikidb: Munged username: Ba
2009-10-01 12:34:29  wikidb: Entering authenticate
2009-10-01 12:34:29  wikidb: 
2009-10-01 12:34:29  wikidb: Entering Connect
2009-10-01 12:34:29  wikidb: Using TLS or not using encryption.
2009-10-01 12:34:29  wikidb: Using servers:  ldap://Madbonn01.bonn.iz-soz.de
2009-10-01 12:34:29  wikidb: Connected successfully
2009-10-01 12:34:29  wikidb: Lowercasing the username: Ba
2009-10-01 12:34:29  wikidb: Entering getSearchString
2009-10-01 12:34:29  wikidb: Doing a straight bind
2009-10-01 12:34:29  wikidb: userdn is: bonn\ba
2009-10-01 12:34:29  wikidb: 
2009-10-01 12:34:29  wikidb: Binding as the user
2009-10-01 12:34:29  wikidb: Bound successfully
2009-10-01 12:34:29  wikidb: Entering getUserDN
2009-10-01 12:34:29  wikidb: Created a regular filter: (=ba)
2009-10-01 12:34:29  wikidb: Entering getBaseDN
2009-10-01 12:34:29  wikidb: basedn is OU=langroup,OU=IZ-Users,DC=bonn,DC=iz-soz,DC=de
2009-10-01 12:34:29  wikidb: Using base: OU=langroup,OU=IZ-Users,DC=bonn,DC=iz-soz,DC=de
2009-10-01 12:34:29  wikidb: Couldn't find an entry
2009-10-01 12:34:29  wikidb: Pulled the user's DN:
2009-10-01 12:34:29  wikidb: Entering getGroups
2009-10-01 12:34:29  wikidb: Entering checkGroups
2009-10-01 12:34:29  wikidb: Entering getPreferences
2009-10-01 12:34:29  wikidb: Retrieving preferences
2009-10-01 12:34:29  wikidb: Entering synchUsername
2009-10-01 12:34:29  wikidb: Authentication passed
2009-10-01 12:34:29  wikidb: Entering updateUser
2009-10-01 12:34:29  wikidb: Setting user preferences.
2009-10-01 12:34:29  wikidb: Saving user settings.

info

We've had the MantisAuth plugin before which uses User from the Mantisbug tracker to loggin, wich used LDAP for authentication. So we have all Users in the WikiDB but want to change now to a direkt LDAP login for the Wiki.

We use a Win2003 Server with Xampp and Mediawiki 15.1

Solved

it was the Cookie Problem again!

I removed the following Cookie Settings:

#$wgCookieDomain = 'Mantis';
#$wgCookiePath = '/';

Not updating Groups in the MW Database

Hi,

we use the LDAP extension to sync LDAP groups with the MW Database, so that other extensions like accesscontrol can use these groups. But its not working anymore and i dont know what to do about it.

Here is our current configuration and debug logs of a test user logging in:

$wgAuth = new LdapAuthenticationPlugin();
$wgLDAPDebug = 3;
$wgDebugLogGroups["ldap"] = "/tmp/test-wiki/ldap.debug.log";
$wgLDAPDomainNames = array( "domain" );
$wgLDAPServerNames = array( "domain"=>"server.com" );
$wgLDAPUseLocal = false;
$wgLDAPEncryptionType = array( "domain"=>"ssl" );
$wgLDAPSearchStrings = array( "domain"=>"domain\\USER-NAME" );
$wgLDAPProxyAgent = array( "domain"=>"cn=searchonly,cn=Users,dc=server,dc=domain,dc=com" );
$wgLDAPProxyAgentPassword = array( "domain"=>"xxx" );
$wgLDAPSearchAttribudomains = array( "domain"=>"sAMAccountName" );
$wgLDAPBaseDNs = array( "domain"=>"dc=server,dc=domain,dc=com" );
$wgLDAPMailPassword = false;
$wgLDAPPreferences = array ( "domain"=>array( "email"=>"mail","realname"=>"displayName","nickname"=>"cn","language"=>"preferredLanguage") );
$wgLDAPDisableAutoCreate = array( "domain"=>false );
$wgMinimalPasswordLength = 1;
$wgLDAPGroupUseFullDN = array( "domain"=>true );
$wgLDAPGroupBaseDNs = array( "domain"=>"ou=Groups,ou=department,dc=server,dc=domain,dc=com" );
$wgLDAPLowerCaseUsername = array( "domain"=>true );
$wgLDAPGroupUseRetrievedUsername = array( "domain"=>false );
$wgLDAPGroupObjectclass = array( "domain"=>"group" );
$wgLDAPGroupAttribudomain = array( "domain"=>"member" );
$wgLDAPGroupNameAttribudomain = array( "domain"=>"cn" );
$wgLDAPUseLDAPGroups = array( "domain"=>true );
$wgLDAPGroupLowerCaseUsername = array( "domain"=>true );

2009-10-28 09:47:26  wikidb_test: Entering validDomain
2009-10-28 09:47:26  wikidb_test: User is not using a valid domain.
2009-10-28 09:47:26  wikidb_test: Setting domain as: invaliddomain
2009-10-28 09:47:26  wikidb_test: Entering allowPasswordChange
2009-10-28 09:47:26  wikidb_test: Entering modifyUITemplate
2009-10-28 09:47:29  wikidb_test: Entering validDomain
2009-10-28 09:47:29  wikidb_test: User is not using a valid domain.
2009-10-28 09:47:29  wikidb_test: Setting domain as: invaliddomain
2009-10-28 09:47:29  wikidb_test: Entering allowPasswordChange
2009-10-28 09:47:29  wikidb_test: Entering modifyUITemplate
2009-10-28 09:47:34  wikidb_test: Entering validDomain
2009-10-28 09:47:34  wikidb_test: User is using a valid domain.
2009-10-28 09:47:34  wikidb_test: Setting domain as: domain
2009-10-28 09:47:34  wikidb_test: Entering getCanonicalName
2009-10-28 09:47:34  wikidb_test: Username isn't empty.
2009-10-28 09:47:34  wikidb_test: Munged username: Testneu
2009-10-28 09:47:34  wikidb_test: Entering authenticate
2009-10-28 09:47:34  wikidb_test:
2009-10-28 09:47:34  wikidb_test: Entering Connect
2009-10-28 09:47:34  wikidb_test: Using SSL
2009-10-28 09:47:34  wikidb_test: Using servers:  ldaps://server.com
2009-10-28 09:47:34  wikidb_test: Connected successfully
2009-10-28 09:47:34  wikidb_test: Lowercasing the username: Testneu
2009-10-28 09:47:34  wikidb_test: Entering getSearchString
2009-10-28 09:47:34  wikidb_test: Doing a straight bind
2009-10-28 09:47:34  wikidb_test: userdn is: domain\testneu
2009-10-28 09:47:34  wikidb_test:
2009-10-28 09:47:34  wikidb_test: Binding as the user
2009-10-28 09:47:39  wikidb_test: Bound successfully
2009-10-28 09:47:39  wikidb_test: Entering getUserDN
2009-10-28 09:47:39  wikidb_test: Created a regular filter: (sAMAccountName=testneu)
2009-10-28 09:47:39  wikidb_test: Entering getBaseDN
2009-10-28 09:47:39  wikidb_test: basedn is not set for this type of entry, trying to get the default basedn.
2009-10-28 09:47:39  wikidb_test: Entering getBaseDN
2009-10-28 09:47:39  wikidb_test: basedn is dc=server,dc=domain,dc=com
2009-10-28 09:47:39  wikidb_test: Using base: dc=server,dc=domain,dc=com
2009-10-28 09:47:39  wikidb_test: 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.
2009-10-28 09:47:39  wikidb_test: Pulled the user's DN: CN=test userNEU,OU=Users,OU=department,DC=server,DC=domain,DC=com
2009-10-28 09:47:39  wikidb_test: Entering getGroups
2009-10-28 09:47:39  wikidb_test: Retrieving LDAP group membership
2009-10-28 09:47:39  wikidb_test: Searching for the groups
2009-10-28 09:47:39  wikidb_test: Entering searchGroups
2009-10-28 09:47:39  wikidb_test: Entering getBaseDN
2009-10-28 09:47:39  wikidb_test: basedn is ou=Groups,ou=department,dc=server,dc=domain,dc=com
2009-10-28 09:47:39  wikidb_test: Search string: (&(member=CN=test userNEU,OU=Users,OU=department,DC=server,DC=domain,DC=com)(objectclass=group))
2009-10-28 09:47:39  wikidb_test: Binding as the proxyagent
2009-10-28 09:47:39  wikidb_test: Returned groups: cn=test123,ou=groups,ou=department,dc=server,dc=domain,dc=com
2009-10-28 09:47:39  wikidb_test: Entering checkGroups
2009-10-28 09:47:39  wikidb_test: Entering getPreferences
2009-10-28 09:47:39  wikidb_test: Retrieving preferences
2009-10-28 09:47:39  wikidb_test: Retrieved email (test123@test.com) using attribute (mail)
2009-10-28 09:47:39  wikidb_test: Retrieved nickname (test userNEU) using attribute (cn)
2009-10-28 09:47:39  wikidb_test: Entering synchUsername
2009-10-28 09:47:39  wikidb_test: Authentication passed
2009-10-28 09:47:39  wikidb_test: Entering updateUser
2009-10-28 09:47:39  wikidb_test: Setting user preferences.
2009-10-28 09:47:39  wikidb_test: Setting nickname.
2009-10-28 09:47:39  wikidb_test: Setting email.
2009-10-28 09:47:39  wikidb_test: Setting user groups.
2009-10-28 09:47:39  wikidb_test: Entering setGroups.
2009-10-28 09:47:39  wikidb_test: Locally managed groups is unset, using defaults:  bot::sysop::bureaucrat
2009-10-28 09:47:39  wikidb_test: Available groups are:  bot::sysop::bureaucrat
2009-10-28 09:47:39  wikidb_test: Effective groups are:  *::user::autoconfirmed
2009-10-28 09:47:39  wikidb_test: Checking to see if user is in: bot
2009-10-28 09:47:39  wikidb_test: Entering hasLDAPGroup
2009-10-28 09:47:39  wikidb_test: Checking to see if user is in: sysop
2009-10-28 09:47:39  wikidb_test: Entering hasLDAPGroup
2009-10-28 09:47:39  wikidb_test: Checking to see if user is in: bureaucrat
2009-10-28 09:47:39  wikidb_test: Entering hasLDAPGroup
2009-10-28 09:47:39  wikidb_test: Saving user settings.
2009-10-28 09:47:43  wikidb_test: Entering allowPasswordChange

If i understand the log correctly the group is returned but when i check the database its not updated there.

MediaWiki won't add the groups to the database, unless they are defined with permissions in LocalSettings.php; see: Manual:User_rights#Changing_group_permissions. Also, depending on the access control extension you are using, you may also need to set "$wgLDAPGroupsPrevail"; see Extension:LDAP_Authentication/Options#Group_options
--Ryan lane 15:39, 17 November 2009 (UTC)

Hi, we use this extension: Extension:Group_Based_Access_Control. I tried with $wgLDAPGroupsPrevail set but it wont work anyway.
So your LDAP extension wont add the ldap groups to the MW database? Only to the $wgGroupPermissions array... Maybe thats the problem?

No. The code calls $user->addGroup() to add users to a group. $wgLDAPGroupsPrevail tells the plugin to add all LDAP groups to $wgGroupPermissions, which should add those groups to the database. I don't test this use case, because I never use any access control plugins (they are flawed, and in my opinion, not worth using).

However, looking at the code, there is a possibility that there is a bug. The following block of code:

        # Add ldap groups as local groups
        if ( isset( $wgLDAPGroupsPrevail[$_SESSION['wsDomain']] ) && $wgLDAPGroupsPrevail[$_SESSION['wsDomain']] ) {
            $this->printDebug( "Adding all groups to wgGroupPermissions: ", SENSITIVE, $this->allLDAPGroups );
                        foreach ( $this->allLDAPGroups["short"] as $ldapgroup )
                                if ( !array_key_exists( $ldapgroup, $wgGroupPermissions ) )
                                        $wgGroupPermissions[$ldapgroup] = array();
        }

May need to be placed above:

        # add groups permissions
        $localAvailGrps = $user->getAllGroups();
        $localUserGrps = $user->getEffectiveGroups();

As later in the code, I iterate over $localAvailGrps. $localAvailGrps may be missing the groups from the $wgLDAPGroupsPrevail code block. Try moving that code block, and let me know if it works. If it does, I'll add this change in SVN.
--Ryan lane 16:11, 18 November 2009 (UTC)

Hi, i tested your changes with both versions stable and alpha. It works great now! Thank your for investigating and pls add the changes to your svn tree.