Extension talk:LDAP Authentication/Archive 1

= Requirements =

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


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

= I can't find the code! =

Quick Answer!
Answer: See LDAP_Authentication

Can't find AuthPlugin.php
OK, I have also spent ages trying to find where to download the code. I tried the link above and downloaded a file called LdapAuthentication.php, the first line of this code isrequire_once( 'AuthPlugin.php' ); Where do I get AuthPlugin.php??? --62.242.235.2 13:10, 11 January 2007 (UTC)


 * Umm... There are links to the code everywhere, shouldn't have been hard to find. LdapAuthentication.php is the correct file. AuthPlugin.php is in the includes directory; it is the object that is being extended (and it comes with the software). Don't forget to read the documentation specific to the version of the plugin you downloaded, or you'll have a pretty hard time configuring this. --Ryan Lane 15:13, 11 January 2007 (UTC)

MediaWiki 1.4
Can we get working patches for 1.4.0? Both of the patches on that bug seem to be saved as some unspecified binary format. Can you re-post them as text/plain?

Don.


 * MediaWiki 1.4 is no longer supported

= Compatibility =

Mediawiki 1.6
Has anybody tested compatibility of this extension with Mediawiki 1.6? I am interested in upgrading, but depend on LDAP Authentication! --Jonathanking 23:27, 6 April 2006 (UTC)


 * No, but I'll be testing it soon. I'll let you know what is up. --Ryan Lane


 * Using an older version (says 1.0a) here and it works great. --DonSeiler 17:13, 7 April 2006 (UTC)
 * Works with 1.0e as well. --DonSeiler 19:53, 7 April 2006 (UTC)

Mediawiki 1.7
How about 1.7? I'm trying to bring up a new wiki. Do I still have to patch the wiki software, or just drop in the plugin? --Dmcdonald 22:37, 7 July 2006 (UTC)


 * You only had to patch for a username fix in 1.5 and below... Mediawiki 1.6+ should work without any core code changes now. I haven't seen any changes in 1.7 that should cause the plugin to not work as documented. I don't have php 5 so I can't test it yet. Try it out with the current documentation, and let us know if it works. -- Ryan Lane


 * I found my mistake. I neglected the require_once statement in LocalSettings.php.  Works fine with MediaWiki 1.7.1 on Mandriva Corporate Server 4.0 Beta 4, PHP 5.1.4, and MySQL 5.0.22

New User Authentication against AD does not work
Error: "password-change-forbidden" on new users.

Hi, I am using mediawiki 1.9 and can not get the AD auth working using the LDAP plugin 1.c. There are no users in the wiki, and they should all have an account created when logging in. Meaning that the only thing done in AD should be auth.

I have tried all sorts of settings, but can not figure this out. Any help would be appreciated!


 * My config

require_once( 'LdapAuthentication.php' ); $wgAuth = new LdapAuthenticationPlugin; $wgLDAPDomainNames = array("MYDOMAIN","MYDOMAIN"); $wgLDAPServerNames = array("MYDOMAIN"=>"mydomain.server.com"); $wgLDAPUseLocal = false; $wgLDAPEncryptionType = array("MYDOMAIN"=>"clear"); $wgLDAPSearchStrings = array("MYDOMAIN"=>"MYDOMAIN\\USER-NAME"); $wgMinimalPasswordLength = 1; $wgShowExceptionDetails = true; $wgLDAPDebug = 4;


 * Debug

Entering validDomain User is using a valid domain. Setting domain as: MYDOMAIN Entering getCanonicalName Username isn't empty. Munged username: MyUser Entering userExists Entering authenticate Entering Connect Using TLS or not using encryption. Using servers: ldap://myldapserver Connected successfully Entering getSearchString Doing a straight bind userdn is: MYDOMAIN\MyUser Binding as the user Binded successfully Authentication passed Entering setPassword Wiki is set to not allow updates

--194.150.212.39 13:45, 16 January 2007 (UTC) Regards, Robert
 * Backtrace
 * 1) 0 /home/basis/webwiki/includes/SpecialUserlogin.php(311): User->setPassword('myPassWord')
 * 2) 1 /home/basis/webwiki/includes/SpecialUserlogin.php(352): LoginForm->initUser(Object(User))
 * 3) 2 /home/basis/webwiki/includes/SpecialUserlogin.php(407): LoginForm->authenticateUserData
 * 4) 3 /home/basis/webwiki/includes/SpecialUserlogin.php(103): LoginForm->processLogin
 * 5) 4 /home/basis/webwiki/includes/SpecialUserlogin.php(19): LoginForm->execute
 * 6) 5 /home/basis/webwiki/includes/SpecialPage.php(625): wfSpecialUserlogin(NULL, Object(SpecialPage))
 * 7) 6 /home/basis/webwiki/includes/SpecialPage.php(431): SpecialPage->execute(NULL)
 * 8) 7 /home/basis/webwiki/includes/Wiki.php(183): SpecialPage::executePath(Object(Title))
 * 9) 8 /home/basis/webwiki/includes/Wiki.php(47): MediaWiki->initializeSpecialCases(Object(Title), Object(OutputPage), Object(WebRequest))
 * 10) 9 /home/basis/webwiki/index.php(47): MediaWiki->initialize(Object(Title), Object(OutputPage), Object(User), Object(WebRequest))
 * 11) 10 {main}


 * Ignore my old comments (I just erased them). Try changing:

//We are creating an LDAP user, it is very important that we do               //NOT set a local password because it could compromise the //security of our domain. $user->setPassword( ' );


 * to:

//We are creating an LDAP user, it is very important that we do               //NOT set a local password because it could compromise the //security of our domain. $user->mPassword = ';


 * Let me know if that works. If so, i'll add this change next release. --Ryan Lane 15:34, 16 January 2007 (UTC)

Hi Ryan, I'm also running MediaWiki 1.9.0rc2 and trying to authenticate using the LDAP plugin with nearly the same config and receiving the same debug messages. I tried to change the line from setPassword(  ) to mPassword =  in the LdapAuthentication.php file but, after the change, starting getting page cannot be displayed. Any other ideas? Thank you.

Ryan, thanks for the quick response, but that did not work either. Still getting the same output as above. --80.202.161.155 18:52, 16 January 2007 (UTC) Regards, Robert


 * This may take a little while to resolve. This may be an issue with the MediaWiki code base clashing with normal operations of auth plugins. I'll need to track it down when I have time, and put it into the bugzilla. --Ryan Lane 23:10, 16 January 2007 (UTC)

Possible fix for using LDAP Authentication in 1.9.

I think the wiki formatting left out some important text in your suggestion to add to the LdapAuthentication.php page. By changing:

$user->setPassword( '' );

To:

$user->mPassword = '' ;

I was able to successfully log in as an AD user. The only problem I had after that was the log in was not persistent. As soon as I navigated to another page within the wiki, it lost the log in unless I checked the box to remember my login on this computer. Is this something I'm doing wrong? When I was using local login this was not a problem, however. I have the same problem running 1.10alpha, although interestingly the LDAP plugin worked without the need to change the setPassword line.


 * Crap. Look at that... I coulda swore putting a space in front of a line is supposed to make the text preformatted. Thanks for the catch. I'll look into the other stuff. I can't see a reason as to why you'd be losing your session. I really need to install the newer MediaWiki versions at home. --Ryan Lane 14:39, 17 January 2007 (UTC)

Hi Ryan, I am also trying to get it to work, but I get the same messages. I tried to change  to , but I still get the same Messages. Do you have any other idea for me? Thanks in advance.

Workarounds for authentication against AD using MediaWiki 1.9
All, I ran into the exact same issues getting mediawiki 1.9 to work with AD auth using the LDAP plugin 1.c. I ended up having to make two changes to get this to work -


 * The change suggested by Ryan above for replacing $user->setPassword with $user->mPassword.
 * Additionally, the issue was that the Login Page calls setPassword after authentication succeeds. This with the out of the box code for the LDAP Auth plugin, ends up returning false and the login fails. So you need to hack the Login Page or LdapAuthentication.php (in setPassword to not return false for a new user).

All the best and thanks to Ryan for this plugin!

--207.207.34.162 18:18, 23 January 2007 (UTC) / Vivek Agarwal

I change according to previous suggestions by "Vivek Agarwal". It seems works fine for me now. (I will work on group access from now)

--Mihu 22:37, 24 January 2007 (UTC)

http://www.xtivia.com | http://jroller.com/page/vagarwal

Thanks a lot! This finally worked! Great work. I'll publish my settings in the configuration Part. --JenZ 11:54, 24 January 2007 (UTC)

Hi All,

I am having an issue even after I used the above suggestions. I have an account in AD which works but I have another one in AD that does not work. The difference between the two is the one that works has a local username and password stored in the Wiki database, but it uses my domain credentials.

My errors are the same as what was posted above. I do not fully understand what this means since I am not an avid programmer: "Additionally, the issue was that the Login Page calls setPassword after authentication succeeds. This with the out of the box code for the LDAP Auth plugin, ends up returning false and the login fails. So you need to hack the Login Page or LdapAuthentication.php (in setPassword to not return false for a new user)".

Can someone point me in the right direction?

Thanks!


 * Try to put the following line into your LocalSetting.php
 * $wgLDAPUseLocal = true; //Allow the use of the local database as well as the LDAP database
 * You should be able to see a dropdown list, which you can specify which password you are going to use.
 * This is *not* a valid workaround for this, it does something completely different. I don't recommend doing it. $wgLDAPUseLocal is meant more for transitional purposes. --Ryan Lane 19:20, 29 January 2007 (UTC)


 * I have put my configuration here. You have to edit the LDAPAuthentication.php or it won't work. You can also use the debug functions (also commented in my Config. Just delete the // in front of the lines). --JenZ 15:51, 24 January 2007 (UTC)

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

$user->setPassword( '' );

to:

$user->mPassword = '' ;

and add the following function to LdapAuthentication.php:

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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


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

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

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


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


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


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


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


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


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

= How do I install this thing? =

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

Installation instructions
Can anyone provide a simple README that would describe how to apply these LDAP patches? They're not patching cleanly for me, and I'm not enough of a guru to figure out what's going wrong. --Tim
 * For version MediaWiki 1.5+, you don't need to patch, you just need to drop "LdapAuthentication.php" into the "includes" or "extensions" directory. The rest of the patch has already been merged into the core code. If you are using version 1.4, you'll need to merge the patch. Unfortunately, I do not have a version that will merge cleanly with the newest version of 1.4, so you'll have to merge it by hand using an editor. I am no longer supporting 1.4, only focusing my attention on 1.5+. -- Ryan Lane

Can one put LdapAuthentication.php in extensions instead of includes?
Is it OK to put LdapAuthentication.php in the extensions directory, instead of in includes? I.e. will that break anything, be more of of a security risk, etc.? It seems to me that includes should be reserved for files that come with the vanilla MediaWiki distribution, whereas extensions, by its very name, is intended for files that get added later.

-- Eric


 * Yeah, it works fine. Just make sure you change:
 * require_once( 'LdapAuthentication.php' );
 * to:
 * require_once( 'extensions/LdapAuthentication.php' );
 * This is really the way it *should* have be done; however, with all the documentation the way it is, and all the info on this talk page, it is hard for me to change it now. -- Ryan Lane

= How do I configure it? =

Configuration examples are here:

Configuration Examples

Explanation of the plugin is in the content page.

= Bug or bad installation? =

Eric's problems
Set up...


 * Solaris
 * MediaWiki: 1.7.1
 * PHP: 5.1.2 (apache2handler)
 * MySQL: 5.0.22

Warning: ldap_set_option
I am getting the following error message. Warning: ldap_set_option: supplied argument is not a valid ldap link resource in /export/home/web/docs/wiki_gen/includes/LdapAuthentication.php on line 126 I think it is really failing at the line above it here.... $ldapconn = @ldap_connect( $servers ); Is there any way to check that @ldap_connect function from a command line perhaps or a smaller test script?


 * Did you compile ldap support against openldap, or sun's ldap client? What shows up when you actually try to log in (in both the server logs, and whatever debug info gets printed out)? --Ryan Lane


 * It was compiled with the --with-ldap option and not against openldap. The only errors I see in the apache logs are about favicon.ico.  This is what gets printed out.  I added a debug line "ldapconnection ... ($ldapconn)" so that is where the "ldapconnection ... " came from.

Entering validDomain User is using a valid domain Entering getCanonicalName Munged username: Eric.frederich@siemens.com Entering userExists Entering Connect Entering Connect Using servers: ldap://xxxxxxxx.yyyyy.siemens.net ldapconnection ... 

Warning: ldap_set_option: supplied argument is not a valid ldap link resource in /export/home/web/docs/wiki_gen/includes/LdapAuthentication.php on line 127

Warning: ldap_set_option: supplied argument is not a valid ldap link resource in /export/home/web/docs/wiki_gen/includes/LdapAuthentication.php on line 128 Failed to connect


 * If you didn't compile against openldap, then you compiled against the solaris client. Although it is possible the solaris client *could* work, no one has ever tried it, and I've never had luck getting any GNU apps working with it. Sudo so far has been the only thing I've had SOME luck with, but even it doesn't completely work with it... I would recommend installing the openldap client and compiling against it (you can try compiling it statically, then you can take back off the openldap client). --Ryan Lane

User is not using a valid domain, failing
I get these errors right when I go to the log in screen Entering validDomain User is not using a valid domain, failing I found that debug statement and added ($domain) to the line and got nothing... User is not using a valid domain, failing

Is this the normal behavior or is something wrong?

This was discussed on the MediaWiki-l mailing list and I was asked to put my questions in here.


 * This is normal I believe. It has something to do with the wiki hitting the auth plugin when the page is first accessed (it shouldn't...). However, this wouldn't cause your problem to fail. --Ryan Lane

What is the default behavior?
I have a fresh installation of mediawiki and have an administrator account. Once I tried getting this LDAP plugin working I can't log in as the administrator any more.


 * 1) When this plugin is enabled does this mean that only AD users can log into it? This is what I want except for an admin account here an there.
 * 2) For a user logging in the first time do they have to "create an account" before "logging in" or can anybody with an account on Active Directory log in?


 * Yes. As of now there isn't really anyway to exclude your admin accounts. I hadn't actually thought of that... I may add functionality for that in the future.
 * They shouldn't have to create an account, they should just have to log in. Mediawiki 1.7 changed how the login/create account stuff looks, and I haven't gotten around to sending in patches for the core code to make it work better with external authentication sources... If your users want to, they CAN create accounts, but it will do the same thing as them just logging in. -- Ryan Lane

I followed the instructions you linked to about adding a WikiSysop user to LDAP. I found that the user was being munged from WikiSysop to Wikisysop by your plugin, and with what appears to be new features in MediaWiki 1.7, MediaWiki automatically creates new permissions for a user called "Wikisysop" that by default will not have admin privs. I've written this patch as a workaround to make the WikiSysop user case insensitive and use the default WikiSysop admin privs. I look forward to your thoughts. Thank you for your great work! -- Scott McLeod

--- LdapAuthentication.php (revision 32) +++ LdapAuthentication.php (working copy) @@ -724,7 +724,9 @@   $username = $this->LDAPUsername; }

- if ( $username != '' ) { + if ( strtolower($username) == "wikisysop" ) { +  return "WikiSysop"; + } else if ( $username != '' ) { $this->printDebug("Username isn't empty.",1); //Change username to lowercase so that multiple user accounts //won't be created for the same user.


 * Well, actually, I don't recommend creating a WikiSysop user in LDAP. It really is better to just add sysop privileges to another user, and not use WikiSysop (you can give the user a blank password to ensure it never gets in).


 * The case sensitivity problem is a pretty annoying issue overall because you are out of luck whatever path you decide to take. If you allow case sensitivity, then when you'll end up having multiple names in the wiki for the same user, if you don't then you run into issues like this, and the one that keeps popping up about group membership, etc. I really wish case sensitivity wasn't required, and the first letter of usernames didn't have to be capitalized, as it causes major headaches, but you get what you get right? -- Ryan Lane 15:19, 19 December 2006 (UTC)

What does the plugin do, and does it support groups?
Couple of Questions:
 * 1) I just want to verify that I can have a clean wiki install, set up ldap authentication, and when a user first goes to the wiki, they'll be asked for their ldap credentials, and if they authenticate, they will be added as a wiki user.
 * 2) Can the ldap code handle nested ldap group searches?  e.g. in a large organisation where an ldap entry may contain groups (which may contain groups) etc it may require nested/recursive searching.  I sure hope so...

Thanks in advance JR


 * Yes, this is the default behavior.
 * The code doesn't support search by groups at all, only by users. The newest version supports filtered LDAP searches though. I may add support for groups in the future.
 * Good news, another user submitted a patch for this, it is in the bugzilla! Ryan Lane

Using the LDAP plugin with IIS
Hi! Need help :) I must create an Wiki, that runs on an IIS Windows Webserver. But it gets the users from our Active Directoy Server. I dont understand this, really.

Can anyone help me? need it.

Contact me pleas @ Brockmeyer.S@atlas.de or ICQ 177440248.

LG Sascha Brockmeyer


 * I don't know if this patch has been tested using IIS. It may or may not work. However, if the patch itself works, you should be able to follow the examples provided for AD. All you'll need to know is your server's dns name pretty much.
 * --Ryan Lane

Cannot modify header information
Hello guys!

Seems to be a very interesting mod of mediawiki.


 * Just installed 1.5rc4 - works fine.
 * Copy'n pasted your script to includes/LdapAuthentication.php

What now?

I tried to copy and paste what you said to LocalSettings.php but do not really know, what to do know. I would like MediaWiki to authenticate against an Windows 2003 Active Directory...

But I just get "No such user" and

Warning: Cannot modify header information - headers already sent by (output started at /data/wiki-edv/includes/LdapAuthentication.php:552) in  /data/wiki-edv/includes/OutputPage.php on line 455 Warning: Cannot modify header information - headers already sent by (output started at /data/wiki-edv/includes/LdapAuthentication.php:552) in /data/wiki-edv/includes/OutputPage.php on line 456 at the beginning (login-page) and

Warning: Cannot modify header information - headers already sent by (output started at /data/wiki-edv/includes/LdapAuthentication.php:552) in /data/wiki-edv/includes/OutputPage.php on line 359 Warning: Cannot modify header information - headers already sent by (output started at /data/wiki-edv/includes/LdapAuthentication.php:552) in /data/wiki-edv/includes/OutputPage.php on line 387 Warning: Cannot modify header information - headers already sent by (output started at /data/wiki-edv/includes/LdapAuthentication.php:552) in /data/wiki-edv/includes/OutputPage.php on line 388 at the end (login-page)

Any ideas? Could you give me a sample of what to paste within LocalSettings.php?

Regards, Martin aka onestone


 * Wow. Those are weird errors. I don't have echo or print statements anywhere in my code, and line 552 is the last line of the patch. This may be a bad install (of the patch). Might want to try again. The new examples should help.
 * --Ryan Lane


 * This error message usually means that you are trying to send headers in php using header or some other php command in an extension even though the headers have already been sent by OutputPage. If you have any other extensions installed that modify headers make sure they turn off OutputPage by calling $wgOut->disable before they send their headers.

Call to a member function on a non-object
First

We've applied the patch on an fresh installation of the wiki. We're athentication vs. a Novell eDirectory (LDAP).

User is going to log in, the following message apears: Fatal error: Call to a member function on a non-object in /srv/www/htdocs/wiki-test/includes/SpecialUserlogin.php on line 291

When I click on the "back" button in my browser an try again to authenticate, it works fine. Any hints where to look further?


 * This seems like a strange bug. I don't even modify code around this area. Did you manually add the patch in? Like I say above, I'm not terribly familiar with making patches. It'll go a lot easier if you patch by hand (its pretty small). Ryan Lane


 * It came up sometimes when playing around with Wiki and patch. It's coming up right now. Freshly installed 1.4.0 with your patch 8.14. Using the patch-command there was no error.


 * I just installed 1.5.0 today (Oct 13, 2005) and the LdapAuthentication.php 1.0+, i got the same error message except the line number is 314 (no patching occurred, i just dropped in the LdapAuthentication.php file). I also did the back button thing and it started working. Weird. --Alex

-- Rahul Upakare and Cyril Chacko
 * We are also facing the same problem. But, we have changed "$u =& $this->initUser($u);" to just "$this->initUser($u);" in includes/SpecialUserlogin.php and it is working fine now.


 * Strange thing is, I just tested this on a brand new install (mediawiki 1.5.2, RHEL4, Sun Directory Server 5.2, Ldap Authentication plugin 1.0b), and I don't seem to have this problem. I don't see how doing this change fixes the problem. What enviroment are you using, and what line number is the bug reporting for you? --Ryan Lane

The function initUser takes the address of the User object. So, any change in the User variables in the function will be reflected in the original object. The error was on line number 314, but this change was made on line no 301 of the SpecialUserlogin.php file. The funny part is this error occurs after the user is added to the database and just before logging in. It seemed as if the call in line 301 was somehow breaking the object. --Rahul Upakare and Cyril Chacko
 * We are on a Suse Linux 9 Enterprise Server, we are using mediawiki 1.5.2, LdapAuthentication.php version 1.0c, php version is 4.3.4 and Zend engine 1.3.0.


 * We get the same problem sometimes. I explain: we've installed LdapAuthentication.php (1.0c) with Mediawiki 1.5.2 on several servers (dev., proof of concept, and so on), but we don't have bug on all of them. We have noticed bug are occuring when profil is being created (i.e. profil is recorded in DB) and only with RHAS 3.0 platform (i.e PHP: 4.3.2 (apache2filter) MySQL: 3.23.58). Just do a refresh and it's Ok. Directory is a Oracle Internet Directory. -- Marc DeXeT

Problems with ldap and new users
I am trying to sort out the ldap authentication with sun1 v5.1. I have the authentication and information (email etc.) working for existing users. My problem is when a new user tries to login, they get an error of "Fatal error: Call to a member function on a non-object in / /includes/User.php on line 1531". I am sure this has to do with them not existing in the local database yet, since if they hit the back button and try again, they are successful. What is the fastest way (other than manually creating ALL user accounts ahead of time) to get around this? Is there a LocalSettings.php item that I overlooked?

-- Andy Marcus


 * If you look towards the top of the page, there are others who are having this same problem. I haven't been able to replicate the problem, so I can't fix it. Someone mentioned something that may be a fix though.
 * -- Ryan Lane

Similar problems
I am getting similar problems Warning: Missing argument 1 for inituser in \wiki\includes\LdapAuthentication.php on line 482 Fatal error: Call to a member function on a non-object in wiki\includes\LdapAuthentication.php on line 489 I have installed a fresh version of Media Wiki 1.5 and LDAP Authentication 1.0. I wish there were more of an explanation on the different variables that need to be added to LocalSettings.php. I am not sure what exactly it is asking for. Could someone please give some clear instructions on how to use this? Please!

I get the errror "The password you entered is incorrect (or missing). Please try again."
I have uploaded the latest version 1.0d of LDAPAuthentication.php. My LocalSettings.php has these lines in the end require_once( 'LdapAuthentication.php' ); $wgAuth = new LdapAuthenticationPlugin; $wgLDAPDomainNames = array( "IBM Intranet" ); $wgLDAPServerNames = array( "IBM Intranet"=>"bluepages.ibm.com" ); $wgLDAPSearchStrings = array( "IBM Intranet"=>"USER-NAME" ); // USER-NAME must map to "mail" $wgLDAPUseSSL = true; $wgLDAPUseLocal = false; $wgLDAPAddLDAPUsers = false; $wgLDAPUpdateLDAP = false; $wgLDAPMailPassword = false; $wgLDAPRetrievePrefs = false; $wgMinimalPasswordLength = 8; I have been trying various combinations for the last two days, but could not get the login to succeed. Can someone tell me how I could print debug messages so that I can see more accurate error messages and fix them? --John 01:26, 24 February 2006 (UTC)
 * 1) $wgLDAPSearchStrings = array( "IBM Intranet"=>"ou=bluepages, o=ibm.com -s sub mail=USER-NAME"  );


 * Sorry, I've been meaning to put debug code in for a while... Lemme try to help you out without the debug info. Are you using AD or some other product (tivoli?)?


 * It looks like you need to do a search below ou=bluepages for anything with the mail attribute. I'm assuming you can do anonymous searches. Try this:


 * $wgLDAPSearchAttributes = array( "IBM Intranet"=>"mail" );
 * $wgLDAPBaseDNs = array( "IBM Intranet"=>"ou=bluepages, o=ibm.com" );


 * and remove $wgLDAPSearchStrings


 * If you require a proxyagent for searches, add:


 * $wgLDAPProxyAgent = " "; //ex: "cn=proxyagent,ou=Users,dc=exampledomain,dc=example,dc=com"
 * $wgLDAPProxyAgentPassword = "eX@mP1eP$$wRd";


 * If you are still having problems, try authenticating without SSL. -- Ryan Lane


 * Thank you Ryan (or anonymous helper ). That helped a lot. It did not work completely but it was very helpful. Especially the new settings $wgLDAPSearchAttributes and $wgLDAPBaseDNs. Here is what happened.


 * When I added these two settings exactly like you said, mediawiki was able to authenticate fine with the LDAP server. Proxyagent was not required. Also changing the SSL setting either way did not make a difference.


 * If I enter an incorrect password, the login fails correctly. But if I enter the correct password, it authenticates and then gives me a page with only this text in it: Fatal error: Call to a member function on a non-object in /home/john.varghese@us.ibm.com/public_html/wiki/includes/SpecialUserlogin.php on line 314.


 * Lines 314 to 317 are

if (!$u->checkPassword( $this->mPassword )) { $this->mainLoginForm( wfMsg( 'wrongpassword' ) ); return; }


 * If I comment out these four lines, the same error occurs the next time the code encounters $u (which is a User.php object which was successfully referenced a few lines ago).


 * The workaround is to comment out the lines except "return". This causes the resulting page to be ugly with just a title like "Create an account or login". But the user now gets into the local DB. After that if I uncomment the commented lines, this user is able to login fine -- apparently because he is already in the local user table.


 * Do you know what is wrong? How can I fix this?


 * Thanks in advance
 * John Varghese

I have a similar problem. I was able to login using LDAP and IIS in a clear text password format, but when I tried to deploy using the SSL method, I receive the incorrect password error. This is what I have for my localsettings.php
 * require_once( 'includes/LdapAuthentication.php' );
 * $wgAuth = new LdapAuthenticationPlugin;
 * $wgLDAPDomainNames = array( "sea2");
 * $wgLDAPServerNames = array( "sea2"=>"wikiserver.seacon2.com" );
 * $wgLDAPSearchStrings = array( "sea2"=>"sea2\\USER-NAME" );
 * $wgLDAPUseSSL = true;
 * $wgLDAPUseLocal = false;
 * $wgLDAPAddLDAPUsers = false;
 * $wgLDAPUpdateLDAP = false;
 * $wgLDAPMailPassword = false;
 * $wgLDAPRetrievePrefs = false;
 * $wgMinimalPasswordLength = 1;

I think my problem may be with the certificate binding between my Active Directory computer(wikiserver) and the computer hosting the wiki website (wikitest). I've tried adding and importing certificates between the computers, but I haven't come across a good tutorial in doing it.

Thanks,

Moises Jaramillo


 * Damn, this looks like the same exact problem some people are having above. I don't understand how this is causing some people an issue, and not others (especially me!). It makes it nearly impossible for me to fix since I can't replicate it. One person above mentioned that you may be able to fix it by changing "$u =& $this->initUser($u);" to just "$this->initUser($u);" in SpecialUserLogin.php in the function "processLogin". -- Ryan Lane


 * My GOD! That worked!!. I just removed the & and it works like a charm.  Could this be a bug in PHP?
 * Without knowing PHP here is my theory. The & represents an invocation of a function. But it is not really mandatory. In this instance, PHP somehow thinks that we want to reference the inner $u with an &. And when it goes out of scope immediately after that line, the assignee goes out of scope as well, or at least whatever it is referencing does.  Thanks again Ryan for poining out the solution to me. I was not sure if this was the right forum and was not sure if I would get the answer here.
 * --John Varghese


 * Yeah, I'm guessing it is that as well. This only seems to affect some people though (it doesn't affect me for instance). Which makes this a REALLY annoying bug. -- Ryan Lane


 * Ryan, it is not a bug, it is only affecting some people because only some people have register_globals = On in their php.ini. That setting messes with the scoping. -- Eric Russell

Authentication via SSL doesn't seem to work
Second

Authentication via SSL doesn't seem to work. The answer is: "bad password". Any hints?

THX KNEBB


 * Authentication with SSL should work with no problems. Does the system you are running this from trust the certificate on the LDAP server? If not, SSL will fail. There are a couple settings in "ldap.conf" that can you set to ignore the fact that you don't trust the certificate (this bypasses a security measure, but it is still more secure than not using SSL). One is "tls_checkpeer no" the other is "TLSREQCERT never" or "TLS_REQCERT never". Check "man ldap.conf" to be sure those are right. Ryan Lane


 * Ok, also my fault. As written above, we're playing around with eDirectory. There is SSL enabled, by on out OPENLDAP it isn't- so it couldn't work. I'll try to test it only with eDirectory.

Same issue, different system - SSL Doesn't seem to work
Aloha,

I've been trying to get ldaps:// working, but it gives me the same vague error message. I'm trying to authenticate to an AD server, and clear works, but ssl doesnt:

userdn is: ADDOMAIN\user1 Binding as the user Failed to bind as ADDOMAIN\user1

Here's the loadout:
 * Solaris 10 (x86, Release 11/06)
 * Apache 1.3.x w/ ModSSL
 * MediaWiki 1.9
 * MediaWiki's SpecialUserlogin.php has been modified to allow auto-user creation to work arround the Password Modification Forbidden problem
 * OpenSSL 0.9.7j
 * OpenLDAP 2.3.34
 * Compiled with:
 * OpenLDAP has been configured at /usr/local/etc/openldap/ldap.conf with
 * I've also tried using the CA certificate from the AD server (from Godaddy.com), but no dice.
 * PHP 5.2.1 w/ GD, OpenSSL, OpenLDAP
 * Compiled with:

Here's the LocalConfiguration.php section for LDAPAuthentication.php: // Active Directory LDAP Authentication require_once( "LdapAuthentication.php" ); $wgAuth = new LdapAuthenticationPlugin;

// Server Info $wgLDAPDomainNames = array( "ADDOMAIN" ); $wgLDAPServerNames = array( "ADDOMAIN"=>"dc.addomain.com" ); $wgLDAPEncryptionType = array( "ADDOMAIN"=>"ssl" );

// Auth Attributes $wgMinimalPasswordLength = 8; $wgLDAPBaseDNs = array( "ADDOMAIN"=>"dc=ADDOMAIN,dc=com" ); $wgLDAPSearchAttributes = array( "ADDOMAIN"=>"sAMAccountName" ); $wgLDAPSearchStrings = array( "ADDOMAIN"=>"ADDOMAIN\\USER-NAME" );

// Debug $wgLDAPDebug = 3; //for debugging $wgShowExceptionDetails = true; //for debugging MediaWiki

Also, I can't figure out how to compile OpenLDAP with ldap_start_tls_s for PHP. OpenLDAP finds OpenSSL (or rather I find it, and shove it into its compilation parameters) and compiles in TLS, but PHP doesn't seem to be able to pick it up from OpenLDAP thereafter. Hopefully when I figure this all out, I can compile a tutorial for getting this all up on Solaris.

Thanks for your help in advance.

--Jeremych 10:43, 8 April 2007 (UTC)


 * I know someone around here has gotten this plugin working on Solaris with ssl, but I'm sure it can be a nightmare. I'd make sure that php is definitely using the OpenLDAP libraries instead of accidentally getting the netscape libraries off of the system. Also, make sure that you can authenticate to AD using OpenLDAP on the system without errors. Once you ensure OpenLDAP is working properly, try using a simple PHP app to authenticate. --Ryan lane 13:18, 9 April 2007 (UTC)

Wiki+LDAP on an OES
Another question

I've installed the wiki on the new Novell OpenEnterpriseServer (OES). It's an SuSE Linux Enterprise Server 9 with Novell components.

I installed my wiki (1.4.0) an could log in as WikiSysop. Good.

Now I applied the LDAP-Patches (for testing not on eDir an no SSL). When I try to login I run in an blank page after clicking on the login-button an can't edit any pages. It doesn't matter if I try to login with an existing or non-existing user or the wrong or right password. Even if the pwd is empty, there's a feedback.

Any hint's why I can't log-in? The URL is: path_to_wiki/index.php?title=Spezial:Userlogin&action=submit&returnto=Hauptseite (Haupseite means Mainpage)

THX KNEBB

--Bone
 * I had a similar problem with a blank page while I was hacking LdapAuthentication.php a bit and screwed something up. After replacing it with the original, the blank page problem was fixed.  Getting it to authenticate against eDirectory was much more fun, though.

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

$wgLDAPSearchStrings vs $wgLDAPSearchAttributes
Why do we need both the $wgLDAPSearchStrings and $wgLDAPSearchAttributes? Seems like we only really need one of them.

I have made a few updates to just use $wgLDAPSearchAttributes, and be able to use a search for binding rather than an exact bind with $wgLDAPSearchStrings. I updated the getUserDN to find the proper userdn, then use that userdn to bind and authenticate in authenticate.

function getUserDN($ldapconn, $username) { global $wgLDAPProxyAgent, $wgLDAPProxyAgentPassword; global $wgLDAPSearchAttributes, $wgLDAPBaseDNs; if (isset($wgLDAPProxyAgent)) { $bind = @ldap_bind( $ldapconn, $wgLDAPProxyAgent, $wgLDAPProxyAgentPassword ); $searchString = $this->getSearchString($username); } else { $bind = @ldap_bind( $ldapconn ); $searchString = $wgLDAPBaseDNs[$_SESSION['wsDomain']]; }       if (!$bind) { return ''; }       $filter = "(" . $wgLDAPSearchAttributes[$_SESSION['wsDomain']] . "=$username)"; //we need to do a subbase search for the entry $entry = @ldap_search($ldapconn, $searchString, $filter); if (!$entry) { return ''; }       $info = @ldap_get_entries($ldapconn, $entry); $userdn = $info[0]["dn"]; return $userdn; }

Any thoughts on just having one search criteria instead of two? or am I missing something.

- Chris Chan, cchan@spikesource.com


 * Not everyone searches for users, and binds with the found user. Some people need to do direct binds, or prefer to do direct binds. In this case, the script only requires $wgLDAPSearchStrings and not $wgLDAPSearchAttributes. To search for a user, you either have to allow anonymous searches, or you have to use a proxyagent. Many people (including myself) authenticate against the directory using straight binds. Maybe my logic is screwed up. I'll review this a little more and get back to you.
 * --Ryan Lane

Authenticating against Windows 2000 AD
I'm playing around with Authentication agains a W2K AD with these settings. (tried lots of variations already). But I keep getting ("Password wrong or missing")

For testing I use a user: distinguishedName = "dn=Kyle Katarn,OU=Test,dc=ams,dc=com" samAccountName = "KatK" require_once( "includes/LdapAuthentication.php" ); $wgAuth = new LdapAuthenticationPlugin; $wgUseLDAP = true; $wgLDAPDomainNames = array( "AMS" ); $wgLDAPServerNames = array( "AMS"=>"$fqdnOfDC" ); $wgLDAPSearchStrings = array( "AMS"=>"AMS\\$wpName" ); $wgLDAPUseSSL = false; $wgLDAPUseLocal = false; //$wgLDAPAddLDAPUsers = false; //$wgLDAPUpdateLDAP = false; //$wgLDAPWriterDN = "uid=priviledgedUser,ou=people,dc=LDAP,dc=example,dc=com"; //$wgLDAPWriterPassword = "{SHA}KqYKj/f81HPTIeAUav2eJt85UUc="; //$wgLDAPProxyAgent = ""; //$wgLDAPProxyAgentPassword = ""; // if you cannot do direct binds based upon $wgLDAPSearchStrings, then you'll need these two //$wgLDAPSearchAttributes = array( "AMS"=>"AMS\\$wpName" ); //$wgLDAPBaseDNs = array( "AMS"=>"dc=ams,dc=com" ); //This requires $wgLDAPWriterDN and $wgLDAPWriterPassword to be set! //$wgLDAPMailPassword = true; $wgLDAPRetrievePrefs = false;

Neither loging in with "KatK" or "Kyle Katarn" works. The LDAP server connection is opened the Authentication in WIKI fails.

LDAP itself works fine: ldapsearch -s sub -x -b "dc=ams,dc=com" -D "AMS\KatK" -h 172.21.0.100 -p 389 -W This works perfect!
 * 1) ldapsearch from mozldap-tools


 * By default, AD will not let you authenticate users over LDAP. Only over LDAPS. So you'll need to either tell AD not to require signed communications, or you'll need to install an SSL certificate. You can also install the certificate server software that comes with AD, which will install a self signed certificate. Make sure that the client trusts the CA (in this case it'll be your AD server).
 * --Ryan Lane

Tracking down the Problem
I did some debugging and what i found out is: In my LocalSettings.php I've added $wgLDAPSearchStrings = array( "AMS"=>"AMS\$wpName" But after doing some debug output I see that the $wpName variable is not set (it's empty) So in includes/LdapAuthentication.php when it comes to bind to the LDAP server

includes/LdapAuthentication.php ... $bind = @ldap_bind($ldapconn, $userdn, $password)

The $userdn variable only contains "AMS\"

So I only need to get the $wpName from the Login-Dialog then it whould work. (I tried it with hardcoded strings)


 * Ohhhhhhhhh.... Ok. I see what the problem is now then. You should be using:
 * $wgLDAPSearchStrings = array ( "AMS"=>"AMS\USER-NAME" )
 * This is how the patch is set to work. In LocalSettings.php $wpName doesn't exist, so it is substituting the variable with "AMS\"
 * --Ryan Lane


 * --Reinhard Brandstädter
 * I've figured this out and added an example to the documentation but someone removed it again. i think many more people run into the same problem because in my opinion Active directory is not well documented. Can you add the example again?


 * I agree that other people may find this useful. The example wasn't removed, just moved. It is now on the examples page I created recently.
 * --Ryan Lane
 * -Edited the link, wasn't pointing to the examples page -Thomas Callison

LdapAuthentication.php really being read?

 * I'm using Windows 2003 and IIS.
 * PHP installed fine.
 * After installation I was sure to uncomment the include php_ldap.dll line in php.ini
 * MySQL installed fine.
 * MediaWiki installed fine.

To install LDAP Authentication I went to your bugs page, and copied then pasted the source from LdapAuthentication.php 1.0a into includes/LdapAuthentication.php

I then tried entering virtually every ldap for Active Directory configuration I could find into LocalSettings.php. None of them work. None of them spit out any errors apart from the usual "There is no user by the name 'usernameIenter'" Wiki error.

If I change the include path to LdapAuthentication.php php complains it cant find the file so I know it works. If I add a print statement into the top of LdapAuthentication I get the print and a ton of expected headers already sent errors. So I know it's actually being read. However it's like NONE of the functions inside the file are actually being used by the wiki.

I even tried using some of the GUI tips and they don't have any effect.

Example: I added the two lines that are supposed to remove the send email button and create account options from the login screen into modifyUITemplate. $template->set( 'create', false ); $template->set( 'useemail', false );

They don't have any effect what-so-ever. Here's the entire function so you can be sure I'm adding them correctly.

function modifyUITemplate( &$template ) { global $wgLDAPDomainNames, $wgLDAPUseLocal; $template->set( 'usedomain', true ); $template->set( 'create', false ); $template->set( 'useemail', false ); $tempDomArr = $wgLDAPDomainNames; if ( $wgLDAPUseLocal ) { array_push( $tempDomArr, 'local' ); }   $template->set( 'domainnames', $tempDomArr ); }

What is going on here? I'm at a total loss. Pointing in any direction here would be great.


 * Have you checked the permissions on LdapAuthentication.php?
 * Have you had a look at the examples page? What does your LocalSettings.php look like?
 * Unfortunately, this patch really hasn't been tested much using IIS. I'd imagine it should work fine, but I can't promise that.
 * --Ryan Lane

In reply to Ryan:

I've used and applied all examples for active directory authentication and it simply doesn't fly. What I mean by it seems as if nothing is being read is that even though I have the create and useemail set as false I still see this as my login screen: http://img181.imageshack.us/my.php?image=ldapnoeffect7ii.gif

For testing purposes I just gave full control to IUSR to the entire mediawiki directory. It makes no difference. Here's my relavent settings in LocalSettings.php Note: This is .local instead of .com or .net to ensure this domain never goes public. That is the actual extension and works fine for everything active directory, but could that be part of the issue here?

"server1.uscomp.local" ); $wgLDAPSearchStrings = array( "USCOMP"=>"USER-NAME@uscomp.local" ); $wgLDAPUseSSL = false; //not recommended but OK for testing $wgLDAPUseLocal = false; $wgMinimalPasswordLength = 1; $wgLDAPRetrievePrefs = false; ### ## # ... the rest of the file below
 * 1) Ldapauthentication mod START
 * 1) Ldapauthentication mod STOP
 * 1) This file was automatically generated by the MediaWiki installer.

Any ideas here?

Ok, a bit more information here. I was getting concerned if PHP was even using LDAP correctly on IIS so I found and tested this set of tools: http://adldap.sourceforge.net/download.php

The examples work great. It is able to search out a user and reply with their full name, what group they're a part of, and correctly identify virtually every aspect of their active directory settings.

So it seems like everything is walking and talking together nicely. One of the variables they asked for in their script was a specific 'bind' user. Apparently Windows Server 2003 doesn't support clear text passwords or anonymous searching. Are either of these being applied in your script using the settings I have above? It doesn't appear so, but I guess you could be using the username/pass supplied to try and search AD instead if having a user specified in the source.

Ryan, I'm going to go ahead and send you an e-mail so we can be in more direct contact. I would love to have this work out for my situation, and I hope to help you advance your script however I can. If you can work with me a bit to get this done at the very least I can create a complete HowTo for anybody looking to start from the very beginning. A complete rundown of installing iis/php/mysql/mediawiki/ and finally ldapauthentication on Server 2003. I just have to get mine working first ;)

''Quick note to any other AD guys that try to use their script to test everything out. A line of their code is typo'd until the next version, so be sure you read https://sourceforge.net/forum/forum.php?thread_id=1370601&forum_id=358759 before scratching your head  on why the correct group for your user is listed, and yet the user is said not to be part of that very same group when it's actually tested.''

Either/Or?
Great patch, Thanks!

My understanding, please correct me if I'm wrong is that you can either authenticate against an entire directory tree, or against a group. Is that right?

Is there a way to get more granularity? Can I specify individual USER-NAMES that are allowed to authenticate? Or individual USER-NAMES in addition to a group? Or more than one group?

--mark


 * Well, if you want to get fancy with the search filter, I'm sure you can limit to individual users. It would probably be better to use the role or group feature though.