Extension talk:LDAP Authentication/LQT Archive 1

= 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

= Archive =

I've archived this talk page, as it was getting way too long. The archive can be found here:

Extension_talk:LDAP_Authentication/archive1

= 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 Extension:LDAP_Authentication

= Compatibility =

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.

= How do I configure it? =

Configuration examples are here:

Configuration Examples

Explanation of the plugin is in the content page.

= Support =

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

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


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

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


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


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

Nested Groups option not working
Hello All,

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

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

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

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

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

Can anyone help me out with this?

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

Thanks :)

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

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

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

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

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

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

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


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

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

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

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

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

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


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

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

HotMonkeyAC 18:25, 27 April 2007 (UTC)


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

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

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


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

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

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

And here is my output:

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

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

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


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


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