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#Plugin_downloads

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

MediaWiki 1.9

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

• Backtrace

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

--194.150.212.39 13:45, 16 January 2007 (UTC) Regards, Robert

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 $user->setPassword( '' ); to $user->mPassword = '' ;, 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)

Official workaround

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?

changing $serverpre = "http"; to $serverpre = ""; in LdapAuthentication.php fixed the issue for me on Solaris 11
--Bart Lamboo

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?

1. 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.
2. 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

1. Yes, this is the default behavior.
2. 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.
   1. 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.

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

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.
-- Rahul Upakare and Cyril Chacko

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

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.
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 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 /<path>/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"=>"ou=bluepages, o=ibm.com -s sub mail=USER-NAME" );
$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)

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 = "<location of your proxyagent>"; //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: CPPFLAGS="-I/usr/local/ssl/include/openssl -I/usr/local/include" LDFLAGS="-L/usr/local/lib -L/usr/local/ssl/lib" ./configure --disable-slapd --disable-slurpd --with-tls
  • OpenLDAP has been configured at /usr/local/etc/openldap/ldap.conf with TLS_REQCERT never
  • 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: './configure' '--with-apxs=/usr/local/apache/bin/apxs' '--with-gd=/usr/local/' --with-mysql '--with-mysql=/usr/local/mysql' '--with-libxml-dir=/usr/local/include/libxml2/' '--with-jpeg-dir=/usr/sfw' '--with-png-dir=/usr/sfw' '--with-zlib-dir=/usr/lib' --with-ldap=/usr/local --with-openssl=/usr/local/ssl

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

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

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 from mozldap-tools
ldapsearch -s sub -x -b "dc=ams,dc=com" -D "AMS\KatK" -h 172.21.0.100 -p 389 -W

This works perfect!

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?

<?php

#
##
###
####Ldapauthentication mod START

require_once( "includes/LdapAuthentication.php" );
$wgAuth = new LdapAuthenticationPlugin();
$wgLDAPDomainNames = array( "USCOMP" );
$wgLDAPServerNames = array( "USCOMP"=>"server1.uscomp.local" );
$wgLDAPSearchStrings = array( "USCOMP"=>"USER-NAME@uscomp.local" );
$wgLDAPUseSSL = false; //not recommended but OK for testing
$wgLDAPUseLocal = false;
$wgMinimalPasswordLength = 1;
$wgLDAPRetrievePrefs = false;

####Ldapauthentication mod STOP
###
##
#

# This file was automatically generated by the MediaWiki installer.
... the rest of the file below

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. Multiple roles/groups is not supported for now. I may add that in later though (and hopefully support for nested groups/roles).

--Ryan Lane

Thanks, Ryan - not sure what you mean by "roles"

I have a situation where there is a support group and student workers who use the same wiki for IT group documentation. The students are not a part of the support group, and shouldn't be. Creating another group with both support and the student workers isn't a good solution as many in the support group have hit the 16 group limit in UNIX already.

Currently using apache + mod_auth_ldap via .htaccess to restrict the wiki directory to the individual users, but then they have to log into the wiki itself as well. Be nice to have one login instead of two.

No love (Solved)

I am very new to php AND ldap so I wouldn't be surprised if this is a result of my incompetence, but I cannot get ldap authentication to work whatsoever. I installed MediaWiki 1.5 and got it up and running. I then put LdapAuthentication.php into my includes directory. Next i put the following at the bottom of LocalSettings.php before the >?

require_once( 'LdapAuthentication.php' );
$wgAuth = new LdapAuthenticationPlugin();
$wgLDAPDomainNames = array( "comair.com" );
$wgLDAPServerNames = array( "exampleNonADDomain"=>"ldap.comair.com"  );
$wgLDAPSearchStrings = array( "exampleNonADDomain"=>"cn=USER-NAME,ou=CVG,o=Comair"  );
$wgLDAPUseSSL = false;
$wgLDAPUseLocal = false;
$wgLDAPAddLDAPUsers = false;
$wgLDAPUpdateLDAP = false;
$wgLDAPMailPassword = false;
$wgLDAPRetrievePrefs = false;
$wgMinimalPasswordLength = 1;

For the life of me, I can not get it to authenticate. Everytime I try, I get the wrong password error and am kind of baffled. To add a user in our portal software, this is the ldap notation we use: cn=username,ou=CVG,o=Comair

Any ideas on what I can do to further troubleshoot? The Apache error_log doesn't show a thing and I can't just turn up the verbosity like I can with Tomcat. By the way, i installed mediawiki 1.5 stable on SUSE Enterprise Linux 9. I made sure that php4-ldap is installed.

Change the following:

$wgLDAPServerNames = array( "exampleNonADDomain"=>"ldap.comair.com" );

$wgLDAPSearchStrings = array( "exampleNonADDomain"=>"cn=USER-NAME,ou=CVG,o=Comair" );

to:

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

$wgLDAPSearchStrings = array( "comair.com"=>"cn=USER-NAME,ou=CVG,o=Comair" );

You may also want to change "comair.com" to just "comair".

Also, Are your user's entries in "ou=CVG,o=Comair"?

-- Ryan Lane

I'm not really sure what the "domain" is. This is not Active Directory, so I don't really understand why I need a "domain". The users I want are all in ou=CVG,o=Comair. In our portal software, adding cn=jschroed,ou=CVG,o=Comair will give me access to that page. Can the domain be any name whatsoever, or does it actually matter? I'll try this out tomorrow and let you know.

Worked like a charm, Thanks! So you know, changing comair.com to comair would not allow me to authenticate, but keeping it comair.com works.

Whether you use AD or not, you always have a domain. In the case of non-AD ldap, generally people refer to the basedn as the domain, so for instance, you are using o=Comair, so your domain would be comair. It doesn't really matter what you call the domain however, in this patch you can call the domain "sonofcthulu" as long as you used that domain name everywhere else in LocalSettings.php.

-- Ryan Lane

AD groups in wiki

Hi folks hi Ryan Lane,

hey Ryan you did a really good job with the Ldap Authentication. But i have question about AD groups to import in wiki(table usergroups). Is it possible to import all groups(cn), ou() and dc, so they can be selected from Spezial:Userrights? And is it possible to restrict people the access to articel where are not in

cn=IT, dc=office, dc=air, dc=com

for example.

I posted an answer to this question in the bugzilla, but I guess this is really a better place for the answer. Currently, this is not possible. It is possible to write code for this functionality, but it wouldn't be easy, and it would cause a LDAP hit every time someone accessed the wiki. I'm interested in this functionality myself, and will look into it, but I'm really busy right now, and don't have reliable internet access at home. If someone else wants to look into getting this working, I'd be happy to accept a patch.

-- Ryan Lane

The sample Group Based Restrictions is not working for me error:

Warning: ldap_get_entries(): supplied argument is not a valid ldap result resource in /var/www/html/dewiki/includes/LdapAuthentication.php on line 567 

thx

Bernhard Schuller

Unfortunately, I didn't write the group access restrictions, so it is hard for me to troubleshoot this part for you. I can try though. I'd need to see your setup in LocalSettings.php (with sensitive information edited of course).

-- Ryan Lane

Had this same issue. This will occur if you are using domain style logins of DOMAIN\login. Reason is that in the function 'isMemberOfLdapGroup' the inner call of ldap_get_entries is failing. Look for

                $info=ldap_get_entries($ldapconn,@ldap_search($ldapconn, $groupD
N, $filter));

Remove the '@' from ldap_search and you'll see the error. Whats happing is the filter is malformed. The $filter variable must be a properly formated LDAP DN. Such as CN=user,DC=domain,DC=com. The way I fixed it was totally hax0red, but basically, you need to fix the userDN. You need to transpose DOMAIN\username to username. Then perform an ldap_search for username with a filter of something like $filter = "(&(objectClass=User)(samAccountName=".$login."))" where login is simply the samAccountName. Once you get the search result, grab the distinguishedName and reassign it to the userDN.

-- Andrew Storms

Wouldn't it conceivably be possible for the extension to simply create groups in mediawiki on the fly at login time? For example, I'm using the PageProtection extension, which permits restriction of pages by groups in mediawiki (sysop, etc). I would think that when I log in using your extension, that the extension should create groups in wiki that parallel my groups in LDAP. -- Chris Verlo

That is a seperate issue. I do plan on supporting that in the future, but this part of the plugin is essentially a "is the user allowed to login or create a wiki account" check. What you are suggesting would take place after the user is verified to be in the required group, and after the user's wiki account has been created. The upfront check is important.
-- Ryan Lane

I am having a similar error to the above, and also believe that $filter is to blame. However, I'm not uding DOMAIN\login to my knowledge. (We're using eDirectory for LDAP services.) This was in the error log:

 [Tue Apr 03 16:49:56 2007] [error] [client 140.xxx.xxx.xxx] PHP Warning:  ldap_get_entries(): supplied argument is not a valid ldap result resource in /srv/www/htdocs/wiki/includes/LdapAuthentication.php on line 1254, ... 

That line number reveals the code where removing the @ from @ldap_search demonstrates the $filter bug. Oddly enough, using the depreciated version of the group statement works for me, so this must be something new.  :-- John McCreight

You aren't giving me enough info. What version of mediawiki and the plugin are you using? What does the debug output look like (especially the "Search string" line)? That generally happens when the search returns nothing (I really should fix that so that it returns if nothing comes back from the search)
--Ryan lane 21:14, 3 April 2007 (UTC)

My apologies, Ryan. I'm using MediaWiki 1.9.3, with plugin 1.1e. I've applied the fix to the "SpecialLogin" code as mentioned earlier on this page. This is on SLES10. I'm appending the debug info. As I mentioned previously, using the depreciated method does find me in the proper group and behaves as expected. It's just the new method can't seem to find my group for some reason.  :-- John McCreight

Entering validDomain
User is using a valid domain.
Setting domain as: CoW
Entering getCanonicalName
Username isn't empty.
Munged username: myuser
Entering authenticate
Entering Connect
Using SSL
Using servers: ldaps://ldap.myorg.edu
Connected successfully
Entering getSearchString
Doing a proxy bind
Entering getUserDN
Created a regular filter: (cn=myuser)
Using base: o=MyO
Fetched username is not a string (check your hook code...).
userdn is: cn=myuser,ou=Net_Telcom,ou=Staff,o=MyO
Binding as the user
Binded successfully
Checking for (new style) group membership
Entering isMemberOfRequiredLdapGroup
Required groups:cn=it-docs-auth,ou=net_telcom,ou=staff,o=MyO
Entering getUserGroups
Entering getGroups
Search string: (&(member=myuser)(objectclass=))
Binding as the proxyagentDN
Returned groups:
Returned groups:
Couldn't find the user in any groups (1).
Entering strict.
Returning false in strict().
Entering modifyUITemplate
Allowing the local domain, adding it to the list.

Ah, I see why: "Search string: (&(member=myuser)(objectclass=))". You need to set "$wgLDAPGroupObjectclass" to the objectclass of your group object.
--Ryan lane 18:59, 4 April 2007 (UTC)

Ryan, again you are correct. Adding the objectclass of the group object fixes this issue. Perhaps add this requirement to the docs until the code can handle it more gracefully? Thank you!  :--John McCreight

Username modified (capital letter), authentication fails

I've installed the patch in the includes folder. I get the appropriate login form. However I get a password wrong or missing error. I'm pretty sure I'm using the right password, I use it for a number of other web applications linked to the same LDAP server.

In the file LdapAuthentication.php I looked at a number of things.

In function connect() I echoed $ldapconn. A resource ID showed up, so I assume there is a connection to the LDAP server. I also removed the @ from before ldap_connect( $servers ); No errors there.

Then I moved on to function authenticate() I added an echo statement right after $bind=@ldap_bind($ldapconn, $userdn, $password); echo "*1*".$ldapconn."*2*".$userdn."*3*".$password; This shows me that the connection resource is still available, and the login ($userdn) and password are available to the script.

Now that I look carefully, I see that my username has been modified somewhere in the process. The first letter is turned into a capital letter. I assume this is why authentication fails on my LDAP.

the 'damage' is done before the username is passed to this function: getSearchString($username). I'm guessing the change occurs before the LdapAuthentication.php script is called. I'll keep on looking, but any help would be grately appreciated.

Hanne 13:16, 23 December 2005 (UTC)

I find it strange that your directory really cares what case your username is in... Isn't it standard for LDAP to be case insensitive for usernames? You shouldn't be getting failed authentication.
-- Ryan Lane

The fix for this is documented. For now you'll have to modify the core code. I've looked at the latest version of AuthenticationPlugin.php in cvs, and it offers a solution. So in the future my plugin with handle this problem.
-- Ryan Lane

There is now a fix available in 1.0f that doesn't require modifications to the core code. The fix does require mediawiki 1.6+ though.
-- Ryan Lane

I had this issue with 1.1d and MediaWiki 1.9; considering the age of the above comments I was wondering what I was doing wrong. It turns out that if you use $wgLDAPSearchStrings (i.e. a straight bind) things won't work. If you transform that into two different variables, things will.

Change:

$wgLDAPSearchStrings = array("example"=>"uid=USER-NAME,ou=people,dc=example,dc=com");

into

$wgLDAPSearchAttributes = array("example"=>"uid");
$wgLDAPBaseDNs = array("example"=>"ou=people,dc=example,dc=com");

And you ought to be able to use a lowercase LDAP name to login properly.

Notice that my previous comments were a little over generic. Depending on the schema, usernames can in fact be case sensitive (and in the case of the posix schema, they are always case sensitive); however, DNs are generally case insensitive for most schemas.

I would find it strange that casing issues would affect a DN, and not a uid. There must be some other problem here. Is your naming attribute uid? If it isn't, this would make sense as the first would fail, and the second would find the user's DN, and then bind as the DN. If your naming attribute is cn, you should be using "cn=USER-NAME,ou=people,dc=example,dc=com".
--Ryan lane 13:14, 2 April 2007 (UTC)

Cannot Login

I have posted this mail to the wikitech-l@wikipedia.org. But got Ryan's instruction to post it here.

I have just started hacking mediawiki. I am trying to apply the LDAP authentication plugin to mediawiki-1.5.2 in a FC-4. I'm using openldap-2.2.23-5. I have read the documentation at : m:LDAP Authentication and downloaded the plugin from :http://bugzilla.wikipedia.org/attachment.cgi?id=1042&action=view

I have dropped the above file in /includes and changed Localsettings.php accordingly. Luckily everything seems to be working fine. But everything crashed when I tried to Group based authentication in mediawiki. I have added group entry to the ldap server, restarted it and then inlcuded the configuration parameters for group basedauthentication. Now my Localsettings.php looks like this:

require_once( 'LdapAuthentication.php' );
$wgAuth = new LdapAuthenticationPlugin();
$wgLDAPDomainNames = array( "libregeek" );
$wgLDAPServerNames = array( "libregeek"=>"localhost" );
$wgLDAPSearchStrings = array(
"libregeek"=>"uid=USER-NAME,ou=People,dc=libregeek,dc=net" );
$wgLDAPUseSSL = false;
$wgLDAPUseLocal = false;
$wgLDAPAddLDAPUsers = false;
$wgLDAPUpdateLDAP = false;
$wgLDAPMailPassword = false;
$wgLDAPRetrievePrefs = false;
$wgMinimalPasswordLength = 1;

$wgLDAPGroupDN = "cn=itpeople,ou=Groups,dc=libregeek,dc=net";
$wgLDAPProxyAgent = "cn=root,dc=libregeek,dc=net";
$wgLDAPProxyAgentPassword = "secret"; //this should work with hashes btw
$wgLDAPBaseDNs = array("libregeek"=>"dc=libregeek,dc=net");
$wgLDAPSearchAttributes =
array("libregeek"=>"(uid=USER-NAME)(wikiAccess=TRUE)");

With this configuration I can't login . It simply says "The password you entered is incorrect (or missing). Please try again.". is there any missing configuration items ?? I just tried to print the global variables corresponding to Proxies in LdapAuthentication.php and it gives nothing. One more thing I didn't got the correct idea of Proxy. is it like the "Manager" account who has read permission to all the directory entries.

what may have gone wrong?
please help
regards

Manilal

You are using both proxy style binding, and straight binds at the same time. This is a clash in configuration options. Remove everything after $wgLDAPGroupDN

-- Ryan Lane

Blank Screen

By --203.99.211.41 12:19, 13 January 2006 (UTC)

Hi I have developed a site using mediawiki on windows environment, its working nice.

Now I am trying to use LDAP authentication .I have read the documentation at : m:LDAP Authentication and downloaded the plugin from :http://bugzilla.wikipedia.org/attachment.cgi?id=1042&action=view

I have dropped the above file in /includes and changed Localsettings.php accordingly. but after clicking log in button I am getting a blank page.

pls help me

It is possible that your php windows install doesn't have LDAP enabled (as it isn't enabled by default on windows installs). Look through directions on how to do this on php.net. It may be just as easy as uncommenting the module in your php.ini, or you may have to install the DLLs, and then uncomment the module in php.ini. If you are getting a blank screen, it is because of php errors (any other problems would result in the wiki telling you that you are giving it a bad password).

The next issue you are sure to run into is using SSL. Unfortunately, I haven't been successful in helping anyone troubleshoot that problem on windows systems, as I don't know how to test it on windows systems (I always use ldapsearch on linux/unix systems, and mess with the ldap.conf until I've figured out the problem, but these don't come with windows...).

-- Ryan Lane

Hi! I too am getting a blank screen. I can cope with the LDAP not being configured correctly just yet, so I have $wgLDAPUseLocal = true; in my LocalSettings.php. Unfortunately, even logging in locally gets me a blank screen at the login page <domain>/wiki/index.php?title=Special:Userlogin&action=submitlogin . Is this still likely to be caused by LDAP not being a part of PHP regardless of the lack of usage of the include? --Barthax 16:54, 15 February 2006 (UTC)

Are you trying to log in with an already created user, or does the user not exist yet? If the user doesn't exist, the wiki will try to create the user. When it tries to create the user, it'll check with the authentication plugin to see if the user exists, and if it does not, it will try to authenticate. This isn't a bug per se. If you are using local, you should be creating an account before you try to log in.
Even if the user does exist, it looks like it still tries to hit the LDAP server first. This looks like a bug. The authenticate method in the ldap plugin should be returning false if the domain is local, otherwise it'll try to hit the LDAP server first. This is what is causing the problem. This is only causing a blank page because PHP doesn't have LDAP support, but this is a bug either way (although a fairly benign one). I'll fix it as soon as I can (and make sure my changes won't cause a security problem).

-- Ryan Lane

I'm definitely using a local user which is already created, thanks for covering the point. Many thanks for the speedy response also. I'll take a gander myself & see if I can come up with a suggestion - naturally, I don't expect anything to be integrated if I do find something. --Barthax 09:02, 16 February 2006 (UTC)

Well, it seems obviously where the check should be (beginning of userExists), but I think I'd be more productive if I were to teach you how to suck eggs! :( I understand the lack of importance this has, but if the LDAP functionality fails (libraries corrupt, for example), then the fall back would remain an option. Again, many thanks for your timely response & sorry I can't be of more use in figuring out how best to circumvent this minor problem. --Barthax 09:52, 16 February 2006 (UTC)

I've fixed the problem for users who already exist (check the bugzilla for the newest version of the plugin). There is no fix for creating new users, as using local login is only supposed to be used as a failover or a transition tool, I specifically do not want local users to be able to create users in the wiki with LDAP account names. Notice that userExists only gets called when a user is being created, not when they already exist in the wiki, so really, the only change required was at the beginning of authenticate.

There is something you need to keep in mind though. Unless you change the default functionality of the plugin, you cannot fall back onto local users after they have logged in as domain users, as the plugin sets blank passwords for the users (this is why I say that $wgMinimumPasswordLength needs to be 1 or more!); it is a security hazard to cache domain passwords in a web app. You'd need to comment out the the spot in "initUser" where I blank out the password.
Suck eggs... Indeed. (sheesh)
-- Ryan Lane

Hello, we are now also getting this blank page error once users submit login requests. We are running our Wiki on SLES9 with PHP5 and using Windows 2000 AD/Ldap auth. It was working like a champ until 2 days ago, and of course no one changed anything on the system.. :) If I change login to local, it does work. Any clue on what I can check out first? I only set up the wiki, and my php/ldap admin is out sick. thanks!

Hmmm... No one changed anything huh? Did you patch your AD server? Did you patch the system with your webserver? You *sure* nothing changed? Things don't just stop working for no reason... I'd say the first thing to check is who changed something (slap them...), and what changed. If nothing changed, check your hardware, and/or call your OS vendors. BTW, I didn't notice this, and I don't know when it was posted. Sorry if I took a while responding. If you have an urgent problem, you may want to put a new section at the bottom of the page when it happens.

Ryan Lane

By GeraldR 19:32, 12 February 2007 (CET)

Hello Ryan,

I have a blank screen problem too.

I can authenticate but if the account does not exist I'm not able to create a new account because the "Create an account" screen is blank.

I'm using mediawiki-1.6.0 and LdapAuthentication.php Version 1.1c / 12/04/2006 and openLDAP 2.2.26.

kind regards Gerald

Accounts should be created when the users log in. Users don't need to create accounts by using the "Create an account" screen. If you need it for psychological reasons, you can comment out "$template->set( 'create', false );" in the modifyUITemplate() function.
--Ryan Lane 19:01, 2 February 2007 (UTC)

Hello Ryan, thanks a lot for this very fast answer. It works the way you described. Thanks a lot. I don't like to have a dead or blind link to a page with no content. This seem not to be intuitive for users.

kind regards Gerald

You can actually remove that message by editing "MediaWiki:Nologin" and blanking it out (I think you need to put "-" instead of blanking it out in MediaWiki 1.9+).
--Ryan Lane 19:56, 2 February 2007 (UTC)

Hello Ryan, I do not understand your suggestions. Do you mean: If a user does not exist in my LDAP the system should generate automatically a "Create an account" screen after an unsuccessful login? This does not happen with release 1.6.0. Probably there is an option to enable this.

I would not like to have a feature which automatically create new users. For example someone tries to login with a misspelled name he or she should be able to restart the login procedure. In my opinion the way it works is just good.

No. There will not be a "Create an account" page at all, and the link to it will be gone. If a user has an account in LDAP, when they authenticate, their account will automatically be created in the wiki. There isn't any reason to force a user to create an account; if a user tries to login with a misspelled name, they won't be able to login and will have to retry.
--Ryan Lane 15:00, 5 February 2007 (UTC)

Active Directory Authentication w/ Nested Groups

--Justin Grote 20:39, 29 January 2006 (UTC)
Hi Ryan, great job with this module. I was able to get the Active Directory group-based authentication modifications working (eventually). I do have a customer however who is interested in both nested group support and per-domain group restrictions. I've already sketched out how to do this with the module and it's very possible while only adding 2+n (n for the level of recursion of the nested groups) LDAP queries. I just wanted to check if you were already working on this before I get started. Thanks.

Nope, not working on it currently. I haven't had much time lately. I'd love to get a patch for this (please send it in unified diff format).

-- Ryan Lane

Problem with preferences from LDAP

Hello all! Need some help :-) I have setup LDAP authentication from OpenLDAP. Authentication works well, but preferences pulling doesn't work :-( Of course, i have all necessary attributes in LDAP and $wgLDAPRetrievePrefs is set to true. I use $wgLDAPProxyAgent, because i need auth users from several OU's. Maybe, problem is related with ProxyAgent schema use?

-- Sergey Sholokh

Hmmm... It doesn't look like using a proxyagent would cause this problem as the plugin pulls preferences after it binds as the user. After the plugin binds as the user, it pulls the user's entry, and gets the associated preferences. What part of preferences pulling doesn't work? Does it not update the user's preferences? Do you get a php error? In function "authenticate", in the if statement "if ($wgLDAPRetrievePrefs) {", after the information is pulled, try echoing out some of the values. Does it echo anything when you log in? Try a "print_r($info)", is the plugin accessing the array correctly? I'll need to make sure this is still working with the newest version of the wiki, but looking at the code, I couldn't see why it wouldn't be working.

-- Ryan Lane

Update. I tested this using a proxy search, and it is working for me.

-- Ryan Lane

I have just had a similar problem but traced it to being because I had both wgLDAPRetrievePrefs and wgLDAPGroupDN set. Because the Group part is processed first in the authenticate function and finishing with a return it never reached the preferences pulling if statement. I switched these if statement blocks around (so group membership is now last) and it works great now. I suppose it does mean an additional pointless LDAP hit to get the preferences of someone who may not be in the group anyway (and therefore cannot log on).

I suppose another way of doing this may have been to set the return value to a variable in the group function and calling return if true at the end of the authenticate function. I may investigate this if I get the chance.

-- Tim Coles

I tried the variable method I suggested above (instead of moving the code block) and it worked fine.

In the authenticate function within LdapAuthentication.php, I changed the line:

 return $this->isMemberOfLdapGroup($ldapconn, $userdn, $wgLDAPGroupDN);

to:

 $isLDAPGroupMember = $this->isMemberOfLdapGroup($ldapconn, $userdn, $wgLDAPGroupDN);

and added the following line to the end of the authenticate function:

 if ($isLDAPGroupMember) return $isLDAPGroupMember;

I placed it after the ldap_unbind to enable the cleanup to occur. I don't know if this was the best place for it or if it doesn't really matter anyway.

-- Tim Coles

Setting the return value to a variable, and returning it at the end is generally good programming practice anyway. Some parts of the code are sloppy currently. Thanks for finding this, it'll be fixed in the next version of the plugin!
--Ryan Lane

This problem is now fixed as of 1.0f
-- Ryan Lane

generate MediaWiki user info based on LDAP content

I am trying to use MedaWiki with an existing user database, which was originally stored in MySQL tables. to make things a little easier, we decided to migrate part of the data (basic things like real name, email adress, phone) in an LDAP server and keep the rest in our MySQL tables. LDAP authentification worked fine and with no big trouble, with one exception: the numerical user_id should match the id used in our tables. however, MediaWiki just generates a user_id based on the auto_increment value. is there an easy way to fix this?

Second, it would be nifty if things like "user_real_name" and "user_email" could be retrieved from the LDAP directory on login. is this a hard thing to do?

If you want to mail me an answer, I'd love it (otherwise I'll just come back to check): ducon.lajoie@swissonline.ch. have a nice day..

Hmm... If your users are already in the wiki, then the LDAP authentication shouldn't cause new accounts to be created. BTW, you can use user real name, email, nickname, and preferred language from LDAP. You'll need to make sure the attributes in the function "authenticate" match up with the ones you are using in LDAP. If you want to, you can even have the wiki update your user's preferences. For that, you'll need to make sure that the attributes used in "updateExternalDB" match up with what you are using in LDAP. You can also allow users to change their password through the wiki. You can even let the wiki mail users a new password. You can also add new users to LDAP through the wiki if you want to.

Most of these are pretty easy to set up. For the preferences "$wgLDAPRetrievePrefs = true;". To let the wiki update preferences and passwords "$wgLDAPUpdateLDAP = true;", you'll also need to set "$wgLDAPWriterDN" and "$wgLDAPWriterPassword". To let the wiki add users "$wgLDAPAddLDAPUsers = true;", you'll need the writerdn and password for that too.

Hmmm... Are you saying that you want the uidnumber for the user to be the same as the ID used in the MySQL table? Unfortunately, unless you make your uidnumber match the wiki ID number, that probably isn't possible.
-- Ryan Lane

I gave up on having the same uidnumber, and will use the login to link the two tables. for the rest.. your answer just does it! thanks! -D

---

So it goes against all Wiki philosophy, but is there a way to make the values retrieved from LDAP unmutable? We have tight controls on our LDAP and don't want users to be able mess up their email addresses. I know you can prevent email changes from being written back to LDAP, but can you prevent them from being changed in MediaWiki in the first place?

On an only slightly related note, you can use this to confirm a bogus email address like this:

1. pull the correct email from LDAP
2. send a verification email
3. change your email to something else (does not write back to LDAP).
4. go to your email and click the confirm link
5. the wrong email is now verified

I'm not sure if this is due to not being set up to write back to LDAP or for all I know it may happen even if you're not using LDAP at all.

Thanks in advance for the help!

Vacao 15:50, 15 February 2007 (UTC)

I wouldn't necessarily think that goes aginst the wiki way... You are using the wiki in an intranet and expect your user's info to be correct. It is better for the users if their info is correct as well, especially from a consistency point of view. I'm not sure if you can lock down the user's info from being changed (unless you didn't let them go to Special:Preferences). Notice however, that even if the users change the info, the next time the users log in their info will be set back to what LDAP has set.

If you modified the plugin, it is probably possible to get this effect. Whenever a user updates their preferences, "$wgAuth->updateExternalDB( $user );" is called. You could add some logic in updateExternalDB to call "$this->updateUser( $user );". I'd do it right after "$this->printDebug("Entering updateExternalDB",1);" to ensure the logic gets called. If you did this when SpecialPreferences calls updateExternalDB, updateExternalDB would call updateUser, which would re-pull the info from LDAP, and overwrite any changes the user made to the preferences managed by LDAP.

If you get this working, and can provide a patch, I may be willing to include this into a future release (remember that you would need to make a new option, that is domain settable, and defaults to false).
--Ryan Lane 18:14, 15 February 2007 (UTC)

Where does the error message come from?

The error message "The password you entered is incorrect (or missing). Please try again."

I searched the all the files in the wiki installation folders. There was no file with this error message in it. How can debut this error message?

It is in wiki/languages/Language.php

As for debuging it, unfortunately, this error will come up for pretty much anything going wrong. There is no way to output more informative information to the user. I need to put debugging information into the code, and I plan on it, but I've been busy as hell recently.

-- Ryan Lane

Debug info is now available in version 1.0f.
-- Ryan Lane

Right. I'm sure this one's been seen before.......

All right. I'm sure someone's seen and fixed this before.

I have a basic installation of Mediawiki 1.5.6, Apache running SSL and that's about it. I'm not trying to do anything particularly fancy, just drop Ldap into includes and have it run. It isn't.

I've dropped the appropriate settings into the localsettings.php, and as far as I know, it should be doing it's thing, but it isn't even changing the web interface (much less working) Help?

--Confused

Are the permissions correct on LdapAuthentication.php? What does your LocalSettings.php file look like (with sensitive data snipped out please)?
-- Ryan Lane

LdapAuthentication is set: -rw-r--r-- 1 admin admin 17680 Mar 10 12:59 LdapAuthentication.php where admin is the owner/group of the wiki 'ware.

require_once( 'includes/LdapAuthentication.php' );
#require_once('includes/AuthPlugin.php');
#$wgAuth = new AuthPlugin();
$wgAuth = new LdapAuthenticationPlugin();
$wgLDAPDomainNames = array( "MyDomain" );
$wgLDAPServerNames = array( "MyDomain"=>"The Ldap Server" );
$wgLDAPSearchStrings = array( "MyDomain"=>"uid=USER-NAME,ou=MyGroup,dc=DC1,dc=DC2" );
$wgLDAPUseSSL = true;
#SSL is working, and it has been rewritten in Apache to redirect to the secure side on Special:Userlogin
$wgLDAPUseLocal = false;
$wgLDAPAddLDAPUsers = false;
$wgLDAPUpdateLDAP = false;
$wgLDAPMailPassword = false;
$wgLDAPRetrievePrefs = true;

No other changes have been made, save a url-shortening trick, and a bit of upload-file option fiddling.

A little tweaking (putting print statements in the head of the file) reveals that though it is being loaded, none of the functions are actually being called.

try:

require_once( 'LdapAuthentication.php' );

-- Ryan Lane

I did. It's in includes, not in the main directory. (Otherwise it would not have loaded, and spat an error on that line.) I have since fixed it, and think the gent above who was having similar 'page not loaing properly' issues may have the same problem. First, don't comment out the AuthPlugin lines that are there already. Secondarily, put all the modifications to the code at the very end of LocalSettings; otherwise they will generate the same odd error I was getting; everything will seem to be doing it's job, but you will not actually be getting anywhere.

Thanks, Enlightened (was Confused)

How to specify Admin user in LDAP?

Hello,

I have LDAP working without SSL on an IIS server connecting to a Windows 2003-based AD domain. Thanks for the fabulous work. At present, I have enabled the local accounts because I cannot sort out how to specify which LDAP user is the admin. Any ideas?

Thanks,

-jk

Which LDAP user is the admin (sysop) of the wiki? You use the wiki's normal interface to do that. Log in as the sysop you originally setup, and add sysop to yourself. Now you can turn off local access, and use your user as the sysop (and give sysop to others).
-- Ryan Lane

Thanks Ryan, that did the trick.
--jonathan

What do you mean by using Wiki's normal interface to set the LDAP user as admin? Can you please provide more elaborate steps?
--MD

LDAP Group Auth fails with Windows 2000 AD?

I'm having some problems getting Group authentication working with Active Directory on a Windows 2000 domain. I've hacked the code per the documentation and set up my $wgLDAPGroupDN variable to be "CN=wikitest,CN=Users,DC=ourdomain,DC=com" (where ourdomain obviously is the actual value).

Every time I try to log in I get an error that the password is missing or incorrect. This is on a user that was already able to login via LDAP Authentication prior to turning on group auth. I double checked that the User is a member of the wikitest group, I also double checked the distinguishedname of both the group and the user using the ADSIEdit program that comes with W2k server and they match up.

Any ideas as to why I'm having a problem? I have 1.0e.

Can you turn off the group authentication part in the LocalSettings.php, and try that user again to make sure that the code hacking didn't break anything?

Unfortunately, my help on this will probably be limited. I've never gotten to actually test this piece of the code, and I didn't write it. I'm sure someone here has gotten this working. Anyone else want to help me out on this one?
-- Ryan Lane

I just commented out the group variable and logged in and it was successful. As soon as I uncommented the line it no longer let me in. I'm at a loss now as I've already verified the DN and everything. Anyone else with help?

-- Mike

I have this working fine on Win2k AD, well as of today but it worked a treat. One thing I have spotted on your groupname above is that you have CN=Users. Shouldn't this be OU=Users? The rest looks ok to me.

-- Tim Coles

I just tried OU=Users instead but it still fails. The reason I was using CN=Users is because I verified the Distinguished name of the group in ADSIEdit as well as the distinguished name of the group inside of my account in ADSIEdit and both were CN=Users, instead of OU=Users. Neither appears to work though. I also tried changing the group to Domain Users and Domain\ Users just to see if that would work (in case there was a problem with the wikitest group) and neither of those works either. Anyone else have any ideas?

--Mike

Just a thought... What kind of group is this? Is it a security/distribution group and is it local/global or universal?

--Tim Coles

It's a standard global security group (basically the same as the "domain users" group, which I also tried)

--Mike

I have exactly the same problems that Mike is describing.
Can someone who has this working successfully please review the instructions provided on this page and verify its correctness? Thanks!
--Jonathan (2006/04/04)

Some more information. In function isMemberOfLdapGroup, $info["count'] equals 0 if the user/password exists in the domain, or nothing otherwise. If doesn't seem to be actually checking for group membership and is never greater than 0, thereby making it impossible to login.
Also, I think the problem lies somewhere in the wgLDAPSearchStrings variable. Mine is defined as
array( "mydomain"=>"mydomain\\USER-NAME" );
this is being used as the userdn in lookups, which are failing in the modified groups code. If you have groups working with AD, please show your search string! thanks again, --Jonathan (2006/04/04)

--- Personally I use wgLDAPSearchAttributes instead of wgLDAPSearchStrings

• $wgLDAPSearchAttributes = array( "mydomain.com"=>"sAMAccountName" );
• $wgLDAPBaseDNs = array( "mydomain.com"=>"ou=ou_to_start_searches_from,ou=next_ou_up,dc=mydomain,dc=com" );
• $wgLDAPGroupDN = "cn=wikiaccess,ou=ou1,ou=ou2,ou=ou3,dc=mydomain,dc=com";

-- Tim Coles

Still having problems :\ I tried it as listed above only with my own information and it still fails. As soon as I comment out the $wgLDAPGroupDN line it works just fine, it just won't authenticate correctly with the group. I've triple checked all the code, the DN to make sure its correct, the membership, and even went so far as to look up php_ldap functions to see how ldap_search is working. I can't figure out why this might be broken. Unfortunately without this functionality MediaWiki is useless for what we need it for, so we're going to have to find something else I suppose - I'm just baffled.

-- Mike

I think I igured out my problem but am not sure how to fix it. I looked more closely at my group and user information in AD, and found that the "member" attribute of my groups stores the DN of each user in the group instead of the sAMAccountName. So, when a user logs in with his sAMAccountName (such as "mike.vonderbecke") then it will authenticate correctly but not match up to anything in the group definition because as far as the group is concerned, the member is "Mike Vonderbecke". If I switch from sAMAccountName to just name, or dn, I can then login as "Mike Vonderbecke" with my standard password, and then I will be found in the right group. The question is, how do I switch my AD configuration to store sAMAccountNames in the member attribute of groups instead of the dn? This is breaking more than one area of my network now and AFAIK this was the default configuration as I never changed anything when creating the forest/domain. Any ideas?

--Mike

You did read [[[m:LDAP Authentication]]#Configuration_for_AD this] right? The situation explained there is pretty much exactly what you are describing... I know getting the group stuff working is a pain, especially in AD. I'll try to make this easier in some future version. I just need to get off my lazy butt and start releasing new versions....
--Ryan Lane

--- To make the group authentication work properly with Active Directory, I did two things:

1) Use the "search before binding" method of authenticating. This method uses a proxy account to search AD and return the actual DN of the authenticating user. This DN is passed to the function that performs the LDAP query to validate group membership. The "straight binding" method does not return the DN, which makes the subsequent group authentication function fail.

2) By default, user CNs in AD are "CN=lastname, firstname". Because commas are used as delimiters in LDAP, AD returns DNs that contain commas by prepending the comma with an escape character (\). As an example, when I attempt to logon using the wiki LDAP authentication module, AD returns my DN as "CN=Windham\, Ryan,OU=SanDiego,DC=mydomain,DC=com". The LDAP authentication module uses this string to search for all groups where this DN is contained in the "member" attribute. This is where the problem is -- when searching the member attribute, the escape charater should be omitted and instead the CN placed between double quotes to indicate a literal string.

I've written a quick patch to 1.0g that removes all escape characters and puts each component of the DN between double quotes:

--- LdapAuthentication.php	Fri Oct 06 08:56:00 2006
+++ LdapAuthenticationPATCH.php	Sun Oct 08 13:19:22 2006
@@ -816,6 +816,23 @@
 	}
 
 	function getGroups( $ldapconn, $dn ) {
+                
+		// remove escape characters from DN
+		$dn=str_ireplace("\\,",",",$dn);
+		
+		// open each component of DN with double quotes
+		$dn=str_ireplace("CN=","CN=\"",$dn);
+		$dn=str_ireplace("OU=","OU=\"",$dn);
+		$dn=str_ireplace("DC=","DC=\"",$dn);
+		
+		// close each component of DN with double quotes (except last component)
+		$dn=str_ireplace(",CN=","\",CN=",$dn);
+		$dn=str_ireplace(",OU=","\",OU=",$dn);
+		$dn=str_ireplace(",DC=","\",DC=",$dn);
+
+		// add closing double quotes to the last component of the DN
+		$dn=$dn."\"";
+
                 global $wgLDAPBaseDNs;
                 global $wgLDAPGroupObjectclass, $wgLDAPGroupAttribute;
 		global $wgLDAPProxyAgent, $wgLDAPProxyAgentPassword;

--Ryanwindham 21:15, 8 October 2006 (UTC)

An alternative to this is simply to replace occurrences of '\' with '\5c'. I did the following patch to 1.1c in function getGroups at line 1170

-              $filter = "(&($attribute=$dn)(objectclass=$objectclass))";
+              $filter = "(&($attribute=" . str_replace("\\","\\5c",$dn) . ")(objectclass=$objectclass))";

This is what the JXplorer open source LDAP browser does. John Yesberg 01:57, 17 January 2007 (UTC)

Redirect to requested article after authentication

After adding the LDAP Authentication, the login dialog box shows up on all requests to the site, including requests to specific articles. After authentication, it will always go to the Main page instead of the requested article pages. How can I redirect to the requested page after login? Thanks ... Edmund

I also have this behavior and wondered how to change it. Any thoughts?

--Jonathanking

Wow. This isn't the default behaviour? That has been driving me nuts for ages. I don't know why it does it, so I probably can't help you much. I'll take a look at the code, but I can't promise anything.
--Ryan Lane

Am also in search of solution to redirect after authentication; It seems to lose $returnto when url switch to index.php?title=Special:Userlogin&wpCookieCheck=login

I believe this is a bug in MediaWiki, not the plugin. I remember seeing a bugzilla entry on this somewhere...
-- Ryan Lane

Sysop rights for plugin users

Hi!

I want to give all users they authenticate over these PlugIn SYsOp Rights. Is this posible?

Oh i think it is :) but i searchs the Line, were the result of the LDAP query is written in the Database. Because i think i must only add the user ID in the prefix_usergroups?

It depends on what you mean. Do you want to give every user sysop rights? If so, that is handled by mediawiki, not my plugin. If you want to give sysop rights only to LDAP users, and not local database users, no that isn't possible, unless you do it by hand.
-- Ryan Lane

Version numbers

Can you change a string or something in the top of the file indicating the version? While it's at 1.0e - any of the attachments to the case still show a file with version 1.0a in the top of it ;-)

Yeah, that was mentioned on the bugzilla. I noticed that a couple days before it was posted too. It'll be fixed in forthcoming releases.
-- Ryan Lane

This is now fixed as of 1.0f.
-- Ryan Lane

Setting groups before first login

Can anyone think of a way to set the groups before the first login.

i.e. we have the restricted namespaces plugin and would like to add the username to the group before the user logs in for the first time and populates the database from LDAP.

We could just add a row to the user table but are unsure if this will cause data dependency problems elsewhere. -Dave

A solution that could work is the following: Remove all permissions for logged in users. Create a secondary group that gives the permissions of normal users. When a user logs in for the first time, their account will be created. Then you add all of their secondary groups.

Another solution would be to be to include a patch to the plugin that will enumerate a user's groups from LDAP, and add them to those groups in the wiki if they are not already members (kind of like how the wiki pulls preferences from LDAP). If you are interested, please write this patch; I'd definately include it. I'll work on it when I get the time (I still have a couple other things I'm planning on including first, so it'll be a while).
Ryan Lane

Help...

Do you have any examples that would work with Novell's edirectory?

Please email to me at sgeggie@tiu.edu.

Thanks, Steve

The non-ad configuration examples should work with eDirectory, as eDirectory is set up similar to how sun directory server, or openldap would be. It is better to avoid email for issues so that other people can see the resolutions. Although, I don't think you'll have any issues...
-- Ryan Lane

Using SSL on Login Page to protect domain passwords

I am using the LDAP plugin to enable wiki logins with domain usernames/passwords. I am running on Windows Server 2003 with an IIS/MySQL/Perl install and was wondering what the recommended method is to secure the login page itself. I'm not particularly comfortable having my domain credentials sent across the 'net in cleartext.... I have managed to use SSL on the entire site, but that seems unneccessary.

-- Jonathanking 19:04, 26 April 2006 (UTC)

Unless your site has a large amount of traffic, it probably won't hurt to use SSL on the entire site. If you would like to use SSL on only the login page, the help for that is probably in mediawiki's user guide somewhere (I don't know how to do it, I'm required to use SSL for the whole site at my organization).
--Ryan Lane

Thanks Ryan, I am using SSL on entire sites, but would like to reduce the server load. I have looked through the online help and haven't been able to sort it out. On IIS I can protect a specific page, but of course with mediawiki, there isn't an actual login page! -- Jonathanking 01:14, 28 April 2006 (UTC)

Jonathanking have you got far implementing it? I've got it working and trying to solve cookie issues at the moment because my secure server domain is different to the mediawiki domain. I'll post how I did it if you request, its quite hacky though, all core code changes. Please check it all yourself though, I'm nowhere near a security expert! --Rick(Talk) 19:17, 21 June 2006 (UTC)

Question

I am new to MediaWiki but I managed to install it on a local machine. But how does this LDAP Authentication work exactly in a corporate environment? can this be used instead of normal login of MediaWiki? I'm thinking of using MediaWiki in the company I work, but I would like to connect a Windows Server 2003 AD to my MediaWiki so that users are logged in with their AD account. Is this possible with this extension? --Alexander 09:25, 19 May 2006 (UTC)

Well, you are in luck, this is exactly what you are looking for.
--Ryan Lane

Problems with AD integration

Hi Ryan

I seem to be having troubles with AD integration with mediawiki and LDAP AD integration

require_once( 'includes\LdapAuthentication.php' );
$wgAuth = new LdapAuthenticationPlugin();
$wgLDAPDomainNames = array( "dev.test" );
$wgLDAPServerNames = array( "dev.test"=>"10.231.237.4" );
$wgLDAPSearchStrings = array( "dev.test"=>"dev.test\\mediawiki" );
$wgLDAPUseSSL = true;
$wgLDAPUseLocal = false;
$wgLDAPAddLDAPUsers = false;
$wgLDAPUpdateLDAP = false;
$wgLDAPMailPassword = false;
$wgLDAPRetrievePrefs = false;
$wgMinimalPasswordLength = 1;

I copied the ldapAuthentication.php into the includes directory and made the ffg changes. When I login it comes up with a blank screen. How can I troubleshoot this?

Thanks

change:

$wgLDAPSearchStrings = array( "dev.test"=>"dev.test\\mediawiki" );

to:

$wgLDAPSearchStrings = array( "dev.test"=>"dev.test\\USER-NAME" );

Also, is dev.test your actual AD domain name? You need to make that match your domainname.

--Ryan Lane

Open Directory

Does anyone have any experience with LDAP authentication against Apple's OD implementation? I'm running into a few roadblocks and hoped there was a configuration example out there.

-- Jonathanking

Solved my own problem by using LDAPSearchAttributes instead of LDAPSearchStrings. -- Jonathanking

Troubleshooting Login error: Incorrect password entered. Please try again error for Apple's Open Directory

Jona (or anybody else): I'm also trying to integrate MediaWiki using LDAP authentication via this plugin with Apple's Open Directory. I noted on the main article page that someone had success with OS X 10.3 Server. I'm using Mac OS X 10.4 Server (DirectoryService 2.1 and OpenLDAP 2.2.19) and MediaWiki 1.6.7. Read the documentation, downloaded the plugin, dropped it into the includes directory in the wiki root, and added the following to my LocalSettings.php file:

require_once( 'LdapAuthentication.php' );

$wgAuth = new LdapAuthenticationPlugin();
$wgLDAPDomainNames = array( "myserver.mydomain.com" );
$wgLDAPServerNames = array( "myserver.mydomain.com"=>"localhost"  );
$wgLDAPSearchAttributes = array( "myserver.mydomain.com"=>"uid=USER-NAME,dc=myserver,dc=mydomain,dc=com"  );
$wgLDAPUseSSL = true;
$wgLDAPUseLocal = false;
$wgLDAPAddLDAPUsers = false;
$wgLDAPUpdateLDAP = false;
$wgLDAPMailPassword = false;
$wgLDAPRetrievePrefs = false;
$wgMinimalPasswordLength = 1;

I also tried several combinations of the above, using $wgLDAPSearchStrings instead of $wgLDAPSearchAttributes, and the full name for my domain server in the $wgLDAPServerNames array (that is, array( "myserver.mydomain.com"=>"myserver.mydomain.com" ); instead of localhost). I've tried it with PHP's register_globals on as well as off just to be sure, and I've verified that the LDAP server (Open Directory server) isn't using an ou, so I'm pretty sure the LDAP search base is accurate. I also tried setting $wgLDAPUseLocal to true and $wgLDAPUseSSL to false.

Nevertheless, I'm still getting the can't login error. No matter what user name or password I enter (a known-valid local (wiki) user, or a known-valid LDAP (network) user) I get the same error. I can't find a meaningful error in the php error log nor can I find one in the DirectoryService.error.log on the server. Is my ignorance regarding LDAP to blame? Any help appreciated. Thanks in advance. --Maymay 18:58, 22 June 2006 (UTC)

You have the configuration set to do straight binds. Are your users really right in the root? It seems strange that you can't log in as a local use if you have $wgLDAPUseLocal set to true...

Try the following:

require_once( 'LdapAuthentication.php' );
$wgAuth = new LdapAuthenticationPlugin();
$wgLDAPDomainNames = array( "myserver.mydomain.com" );
$wgLDAPServerNames = array( "myserver.mydomain.com"=>"localhost"  );
$wgLDAPSearchAttributes = array( "myserver.mydomain.com"=>"uid" );
$wgLDAPBaseDNs = array( "myserver.mydomain.com"=>"dc=myserver,dc=mydomain,dc=com" );
$wgLDAPUseSSL = true;
$wgLDAPUseLocal = false;
$wgLDAPAddLDAPUsers = false;
$wgLDAPUpdateLDAP = false;
$wgLDAPMailPassword = false;
$wgLDAPRetrievePrefs = false;
$wgMinimalPasswordLength = 1;

Also, if you notice, you are using $wgLDAPSearchAttributes when you should be using $wgLDAPSearchStrings...

Ryan Lane

Oh yeah, are you sure SSL is working for you? I would imagine that using localhost would kill SSL. Try it without ssl as well (you are going to localhost after all...).

Ryan Lane

Ryan, thanks for your response, and apologies on my late reply. It's just now that I've gotten a chance to try and get this to work again. I've tweaked the above configurations in an attempt to get the plugin to work, but I still turned up empty. To clarify:

• All my users are in the root of my LDAP tree under "dc=myserver,dc=mydomain,dc=com"
• I do not have a special Wiki user set up the LDAP database.
• In order to eliminate potential problems, I have turned most things off. My configuration now reads:

require_once( 'LdapAuthentication.php' );
require_once( 'LdapAuthentication.php' );
$wgAuth = new LdapAuthenticationPlugin();
$wgLDAPDomainNames = array( "myserver.mydomain.com" );
$wgLDAPServerNames = array( "myserver.mydomain.com"=>"localhost" );
$wgLDAPSearchAttributes = array( "myserver.mydomain.com"=>"uid" );
$wgLDAPBaseDNs = array( "myserver.mydomain.com"=>"dc=myserver,dc=mydomain,dc=com" );
$wgLDAPUseSSL = false;
$wgLDAPUseLocal = false;
$wgLDAPAddLDAPUsers = false;
$wgLDAPUpdateLDAP = false;
$wgLDAPMailPassword = false;
$wgLDAPRetrievePrefs = false;
$wgMinimalPasswordLength = 1;

$wgLDAPDebug = 3;

• I am still running up against the same "Login error: Incorrect password entered. Please try again." message whenever the LDAP Authentication plugin comes into play. This occurs even if $wgLDAPUseLocal = true; and I attempt to log in with a known-valid local user.
• The above error is reproducible regardless of whether I'm using $wgLDAPSearchStrings or $wgLDAPSearchAttributes. In other words, I've also used this configuration with the same results described above:

require_once( 'LdapAuthentication.php' );
$wgAuth = new LdapAuthenticationPlugin();
$wgLDAPDomainNames = array( "myserver.mydomain.com" );
$wgLDAPServerNames = array( "myserver.mydomain.com"=>"localhost"  );
$wgLDAPSearchStrings = array( "myserver.mydomain.com"=>"uid=USER-NAME,dc=myserver,dc=mydomain,dc=com"  );
$wgLDAPUseSSL = false;
$wgLDAPUseLocal = false;
$wgLDAPAddLDAPUsers = false;
$wgLDAPUpdateLDAP = false;
$wgLDAPMailPassword = false;
$wgLDAPRetrievePrefs = false;
$wgMinimalPasswordLength = 1;

• In my PHP log, I get the following each time I attempt (and fail, with the above error) to login with a tail php.log:

[17-Jul-2006 14:31:03] PHP Notice:  Undefined index:  ldapdomain in /Library/WebServer/Documents/mediawiki_test-1.6.7/includes/LdapAuthentication.php on line 85
[17-Jul-2006 14:31:03] PHP Notice:  Undefined index:   in /Library/WebServer/Documents/mediawiki_test-1.6.7/includes/LdapAuthentication.php on line 86
[17-Jul-2006 14:31:03] PHP Notice:  Undefined variable: servers in /Library/WebServer/Documents/mediawiki_test-1.6.7/includes/LdapAuthentication.php on line 92
[17-Jul-2006 14:37:38] PHP Notice:  Undefined index:  ldapdomain in /Library/WebServer/Documents/mediawiki_test-1.6.7/includes/LdapAuthentication.php on line 85
[17-Jul-2006 14:37:38] PHP Notice:  Undefined index:   in /Library/WebServer/Documents/mediawiki_test-1.6.7/includes/LdapAuthentication.php on line 86
[17-Jul-2006 14:37:38] PHP Notice:  Undefined variable: servers in /Library/WebServer/Documents/mediawiki_test-1.6.7/includes/LdapAuthentication.php on line 92
[17-Jul-2006 14:37:38] PHP Notice:  Undefined index:   in /Library/WebServer/Documents/mediawiki_test-1.6.7/includes/LdapAuthentication.php on line 94
[17-Jul-2006 14:52:54] PHP Notice:  Undefined index:  ldapdomain in /Library/WebServer/Documents/mediawiki_test-1.6.7/includes/LdapAuthentication.php on line 85
[17-Jul-2006 14:52:54] PHP Notice:  Undefined index:   in /Library/WebServer/Documents/mediawiki_test-1.6.7/includes/LdapAuthentication.php on line 86
[17-Jul-2006 14:52:54] PHP Notice:  Undefined variable: servers in /Library/WebServer/Documents/mediawiki_test-1.6.7/includes/LdapAuthentication.php on line 92

• In an effort to debug what could be happening, I've added the line, $wgLDAPDebug = 3; to my LocalSettings.php file. However, when I look at my PHP log I don't see anything different from the above output. To my most careful eye, everything looks like it's configured okay (or so it seems). I am now concerned that perhaps I have installed the plugin incorrectly...or that it doesn't work on this platform properly?

Are there any other suggestions you can offer to hopefully get this working properly? Is there a fundamental concept I'm not understanding about this plugin? As always, thanks very much in advance. --Maymay 19:06, 17 July 2006 (UTC)

It looks like there are problems with however the plugin is looking for your server names and domain names in the arrays. Lets try this instead:

require_once( 'LdapAuthentication.php' );
$wgAuth = new LdapAuthenticationPlugin();
$wgLDAPDomainNames = array( "GenericDomainName" ); # Just letters, nothing else
$wgLDAPServerNames = array( "GenericDomainName"=>"localhost" );
$wgLDAPSearchAttributes = array( "GenericDomainName"=>"uid" );
$wgLDAPBaseDNs = array( "GenericDomainName"=>"dc=myserver,dc=mydomain,dc=com" );
$wgLDAPUseSSL = false;
$wgLDAPUseLocal = false;
$wgLDAPAddLDAPUsers = false;
$wgLDAPUpdateLDAP = false;
$wgLDAPMailPassword = false;
$wgLDAPRetrievePrefs = false;
$wgMinimalPasswordLength = 1;

$wgLDAPDebug = 3;

Remember that the "DomainNames" array is just how you will refer to specific domains later. You can call these anything, as it isn't specific to your configuration. Whatever you put here is what your users will see as a domain though. Also, searching for users before you bind as them won't work on every directory server. Some servers disallow anonymous binding; you may have to use a proxyagent.

In this case it looks like the plugin is failing to ever try to authenticate to begin with; it is failing when it tries to connect (possibly even before then). I'm thinking using a strange domain name is causing it. (I hope so anyway)
-- Ryan Lane

Hi ryan -- again, thanks for your incredibly prompt assistance. I do appreciate it. Unfortunately, it looks like using generic domain names as the keys to these arrays (letters only), are not working either. I'm still running up against the same error, "Incorrect password entered...". I've tried generic domain names with both wgLDAPSearchAttributes as well as wgLDAPSearchStrings with the same configurations mentioned before. Just to reiterate, I'm using MediaWiki 1.6.7, PHP 5.1.4, running on Apache (1.3). All I did to install the plugin was place the LdapAuthentication.php file in the includes directory and then, as documented above, modify my LocalSettings.php file. That seemed to be what was required as far as installation is concerned...did I do something wrong somewhere? --Maymay 11:10, 26 July 2006 (UTC)

No, those are the instructions to make it work. No debug info is showing at all with $wgLDAPDebug = 3? At minimum *something* should show up on the login screen. You don't have any blank lines before or after the <?php or ?> lines do you? You are adding the extension info to the bottom of the LocalSettings.php file right? When you go to the login screen, is there a drop down list of domains to choose through (probably in your case only one choice)? Is anything showing up in your LDAP server logs (I'm guessing probably not...). I'm running out of ideas here ;).
-- Ryan Lane

Hey Ryan. Nope, nothing's showing up in the PHP log at all with the debug variable set to 3. Everything else you mentioned, save for seeing a drop-down list of domains to choose through, is a check. I didn't even know to expect a drop-down list. I've never seen that on my login page. However, after running out of all my other ideas, I decided to insert a ton of error_log(some_variable_to_dump, 0); statements throughout the LdapAuthentication.php plugin file and removed the error-suppressing operator from the ldap_bind and friends commands, and ended up making some headway. It turns out, after discovering that for some reason the LdapAuthentication.php plugin file was not getting passed the server name correctly (I still don't know why), the bind was failing with the error "Invalid DN syntax". All the other errors generated by the LdapAuthentication.php file are finally gone, save for the failure to bind. Can you give me an example of what the plugin is expecting a valid DN to be? When I error_log the $userdn variable using $wgLDAPSearchStrings I get a string such as uid=myusername,dc=myserver,dc=mydomain,dc=com...again, with all my users in the LDAP root, is this "valid"? Thanks again, --Maymay 20:35, 30 July 2006 (UTC)

You should change the way I send out my errors, to the method you are using... Otherwise. The DN you are using doesn't look invalid. Although, your directoryserver may be expecting spaces, like: uid=myusername, dc=myserver, dc=mydomain, dc=com. I don't have open directory (and can't afford OSX server), so I can't test this. However, one of your biggest problems seems to be that the login interface isn't working correctly for you. The plugin should modify the login interface to show a list of domains (in your case just one domain). Do you have any other extensions loaded?
-- Ryan Lane

Is it possible to configure automatic login?

Hi, I've tried to sift through most of the documentation and I cannot resolve this issue without custom hacks (which don't fully work I must add).

Using LdapAuthentication.php, is there built-in functionality that once the binding is complete, the user will be automatically logged in to MediaWiki with their LDAP uid? If it is their first time visiting the wiki, it would be preferable that a wiki account be created with user->Mname = Ldap:uid, user->Nickname = Ldap:cn, etc. If a wiki account has already been created, the user account should just be loaded.

If the LDAP Authentication plugin was not intended to incorporate this behavior, can someone help point me in the right direction?

Here is the hack I wrote to automatically create an account/log in (does NOT use LdapAuthentication.php, but it also breaks certain user preference rights, such as Special:Emailuser)

I am using the mod_ntlm module on Apache to pass the particular user's authentication token from the Active Directory when they visit the wiki.

code removed

And that's it. Sorry if I posted this in the wrong place. Thanks in advance.

I think you are looking for this in the wrong plugin. I believe this is what you are looking for; it'll do NTLM. It also works GREAT with the email stuff because it was written by the same guy who wrote most of the email stuff.
--Ryan Lane

Ryan, thanks for your reply - never saw that on Bugzilla. Unfortunately, the last patch came out 18 months ago and was for MediaWiki 1.4. I'll try to mod it and post a new patch at that link. Thanks again.

You may want to contact the author of the plugin. He may have an up to date version somewhere.
--Ryan Lane

Allowing login from Multiple LDAP groups ($wgLDAPGroupDN as an array)

I wanted $wgGroupDN to be an array so that one could allow membership in one of several groups. Here is a diff to 1.0f to show what I did. There are some details about the distinguished name and the ldap search that I had to change slightly to get it to work against our AD setup. Someone more knowledgeable than I explain why I had to get the distinguished name the way I did.

The patch:

151c151,152
< 
---
>               global $wgLDAPBaseDNs;
> 
198,203c199,212
<                               $this->printDebug("Checking for group membership",1);
<                               if (!$this->isMemberOfLdapGroup($ldapconn, $userdn, $wgLDAPGroupDN)) {
<                                       $this->printDebug("Failed group membership check",1);
< 
<                                       //No point in going on if the user isn't in the required group
<                                       return false;
---
>                               $entry = @ldap_search($ldapconn, $wgLDAPBaseDNs[$_SESSION['wsDomain']], "sAMAccountName=$username");
>                               $info = @ldap_get_entries($ldapconn, $entry);
>                               $dn = $info[0]["dn"];
>                               $found=false;
>                               foreach ( $wgLDAPGroupDN as $grp) {
>                                   $this->printDebug("Checking for group membership $grp",1);
>                                   if ($this->isMemberOfLdapGroup($ldapconn, $dn, $grp)) {
>                                           $this->printDebug("Success: group membership check for $grp",1);
>                                           $found=true;
>                                           break;
>                                   }
>                                   else {
>                                           $this->printDebug("Failed group membership check for $grp",1);
>                                   }
204a214,215
>                               //No point in going on if the user isn't in the required group
>                               if (!$found) return false;
701c712,714
<               $info=ldap_get_entries($ldapconn,@ldap_search($ldapconn, $groupDN, $filter));
---
>               #$info=ldap_get_entries($ldapconn,@ldap_search($ldapconn, $groupDN, $filter));
>               $res = ldap_search($ldapconn, $groupDN, $filter);
>                 $info=ldap_get_entries($ldapconn, $res);

Bkhess 18:03, 12 July 2006 (UTC)

Thanks for the patch. I have a development version of the plugin with a new method of doing group searching, which supports multiple groups, and nested groups. I have left in the old method for backwards compatability for now, so I probably shouldn't add this patch as it will break that compatibility. I was planning on doing a couple more things before the next release of the plugin, but if enough people are interested in the new group functionality, I'll release it now.
-- Ryan Lane

Authenticating against Windows AD with Groups

I was able to get WikiMedia to authenticate against our AD server using $wgLDAPSearchStrings. Here is my working configuration for that:

require_once( 'LdapAuthentication.php' );
$wgAuth = new LdapAuthenticationPlugin();
$wgLDAPDomainNames = array( "CORP" );
$wgLDAPServerNames = array( "CORP"=>"ldap.corp.espn.pvt" );
$wgLDAPSearchStrings = array( "CORP"=>"CORP\\USER-NAME" );
$wgLDAPBaseDNs = array( "CORP"=>"dc=corp,dc=espn,dc=pvt" );
$wgLDAPUseSSL = false; 
$wgLDAPUseLocal = false;
$wgMinimalPasswordLength = 1;
$wgLDAPRetrievePrefs = false;
$wgLDAPDebug = 99;

However, when trying to do group-based authentication, it doesnt pull the proper UserDN, no matter what I try. Here is my config for Group-based authentication:

### Group-Based Auth
require_once( 'LdapAuthentication.php' );
$wgAuth = new LdapAuthenticationPlugin();
$wgLDAPDomainNames = array( "CORP" );
$wgLDAPServerNames = array( "CORP"=>"ldap.corp.espn.pvt" );
$wgLDAPSearchStrings = array( "CORP"=>"CORP\\USER-NAME" );
$wgLDAPGroupDN = "cn=UNIX Account Management,ou=Functional Groups,ou=Bristol,dc=corp,dc=espn,dc=pvt";
$wgLDAPUseSSL = false; //not recommended but OK for testing
$wgLDAPUseLocal = false;
$wgMinimalPasswordLength = 1;
$wgLDAPRetrievePrefs = false
$wgLDAPDebug = 99;

The debug output comes back as:

Entering validDomain
User is using a valid domain
Entering getCanonicalName
Munged username: Pearsala
Entering Connect
Entering Connect
Not Using SSL
Using servers: ldap://ldap.corp.espn.pvt
Connected successfully
Entering getSearchString
Doing a straight bind
userdn is: CORP\Pearsala
Checking for group membership
Entering isMemberOfLdapGroup
Failed group membership check

Problem is, my userdn is really: CN=Pearsall\, Alex,OU=Users,OU=Bristol,DC=corp,DC=espn,DC=pvt

How exactly does WikiMedia pull the group information? Does it query for sAMAccount and compare the memberOf group information to the group mentioned in $wgLDAPGroupDN? I'm running the latest LdapAuthentication.php, and I've tried all the patches mentioned in the examples and other wiki pages.

Any help appriciated.

I have a new group method in the upcoming release. I have a hard time debugging the old one, so I'll release the group stuff early (it is easier to use IMO). I'll probably send it out tomorrow.
--Ryan Lane

User info not available with USER-NAME?

After running into problems with authenticaing with 2003 AD, I used Sasha's example to get it working, the USER-NAME thing worked great, but one thing that isn't working is user info retrival... I realized its just not picking up any of the info, yet according to the article user info works with AD. With debug it shows its retrieving empty values... Retrieving preferences
Retrieved: , , ,
... any ideas? is this related to using USER-NAME instead of default. Thanks.

You must look at your php.ini. There are an entry like ;extension=php_ldap.dll. Search on your system for the php_ldap.dll copying the file in the /windows root/system32/ and remove the ;. SO that in php.ini the line shows like extension=php_ldap.dll.

-- 194.156.172.86 05:41, 3 April 2006 (UTC)

--- Like i said, authentication is working fine, hence, ldap is enabled and working properly.

Although this does work with AD, the preferences you are trying to pull may not. The LDAP attributes used may not match ones that are defined in AD. You'll need to figure out what attributes you want to use for which preference, and set it in the plugin (this is in the authenticate method). If this doesn't fix it for you, you'll need to see what is being searched for.
-- Ryan Lane

Group membership check fails

We have successfully connected our Wiki with this extension to our Novell eDirectory (NON-AD). As long as we do not use groups the login works fine.

Using groups we have an authorisation problem.

not using a proxy:

1. bind anonymous
2. bind user
3. search group with user rights (does not work, as the user has not search rights, here there must a technical user be used -> how?)

using a proxy

1. bind with proxy user
2. bind user
3. search group with user rights (does not work, as the user has not search rights, here should be an unbind and the proxy user be used again)

Change of code or other solution available?

$wgAuth = new LdapAuthenticationPlugin();
$wgLDAPDomainNames = array( "REF-EDIR" );
$wgLDAPServerNames = array( "REF-EDIR"=>"ldapedir.kons.dlh.de"  );
$wgLDAPSearchAttributes = array( "REF-EDIR"=>"uid" );
$wgLDAPBaseDNs = array( "REF-EDIR"=>"ou=LH,o=LH-DIR" );
$wgLDAPGroupDN = "cn=LHT-WIKI,ou=ADG,ou=Roles (PW),ou=LH,o=LH-DIR";
$wgLDAPProxyAgent = "cn=LHTWikiProxy,ou=SVC,o=ADM";
$wgLDAPProxyAgentPassword = "password"; 
$wgLDAPUseSSL = true;
$wgLDAPUseLocal = false;
$wgLDAPAddLDAPUsers = false;
$wgLDAPUpdateLDAP = false;
$wgLDAPMailPassword = false;
$wgLDAPRetrievePrefs = false;
$wgMinimalPasswordLength = 8;
$wgLDAPDebug = 3;

Hmmm. I think even my new solution uses the user's credentials to search... I'll see if I rebind as the proxyagent to search if it is available. I'll release this soon.
-- Ryan Lane

The new method is available, please take a look at the documentation on the content page, and the changelog. Let me know if there are any bugs. I'll try to have more updated documentation for the new method soon.
-- Ryan Lane

Setup login page to work SSL (https)

How does one best set up the server to make the Special:Userlogin page use SSL (https)?

I would like to secure that traffic from my server to LDAP otherwise my user passwords are sent in the clear.

Should I use .htaccess and rewriting rules?

I tried unsuccessfully to use the information referenced in Karen Coombs's site.

I am working in an Apache/2.0.52 (CentOS) MediaWiki 1.6.7 environment. Nslonim 14:17, 13 August 2006 (UTC)

This was asked somewhere else on this discussion page. This is a MediaWiki configuration issue, and I have no clue how to do it (I use https for my whole site). I don't believe the issue was ever solved, but this probably isn't the best place to ask.
-- Ryan Lane

More restrictive login behaviour?

My apologies if this has been covered before, I've had a look around, and not managed to find anyone else talking about quite what I'm after.. basically a slightly more 'integrated' login experience.

Ok. I've managed to get LDAP Auth working (incredibly easy, It worked first try!), but rather than the current:

1. User clicks log in
2. User enters ldap credentials, and selects the ldap 'domain'
3. Login succeeds, wiki account created, all's well.

I'd rather have:

1. User clicks log in.
2. User enters credentials, but there's no 'domain' to select
3. Login proceeds as follows:
   1. User account exists in the local database? yes: carry on. no: fail.
   2. User object exists in ldap? no: carry on yes: try this:
      1. bind succeeds? yes: login complete no: fail
   3. Try authenticating against local account. Succeeds? yes: login complete no: fail

Or, in simple terms, There are no 'domains' to select from. Accounts must exist locally to log in. If the user exists in ldap, that is the only place that authentication is tried, otherwise auth locally.

So, this is required for a project at work - If it's possible to do this now, with a little clever config trickery, that'd be cool. If not, I'm going to dive into the code and add it myself, but pointers as to where to start or where to implement this would be most appreciated (even ideas on how to implement would be awesome too! - The coding is not an issue, PHP is an old friend, I just don't know MediaWiki terribly well at the moment).

This is possible, however, it will require some modification to the plugin (and possibly, but hopefully not, modification to the core code). I'm assuming need to authenticate users who have LDAP accounts and users that do not have LDAP accounts? If this is *NOT* the case, there are much easier ways to enforce behavior than a dirty hack like this.

So, on with the modifications...

1. Change the return type of the autoCreate function to false
2. In the function modifyUITemplate comment out "$template->set( 'usedomain', false );"
   • This will cause problems with the domain not getting sent correctly to the plugin, you'll need to add a hidden input field for the domain name you'll be using in includes/templates/Userlogin.php like:

     <hidden input type="text" name="wpDomain" value="TheDomainNameYouWantToUse" />

3. Set the option $wgLDAPUseLocal = true
4. Follow the MediaWiki documentation on how to not allow users to create accounts

That should give you the functionality you require.
-- Ryan Lane

Performance issues with the new group searching

moving to our production environment, I have a serious performance problem.

The group check takes about 4 Minutes. I included the debug listing, where I added a time stamp.

Search string: (&(member=cn=X1234,ou=HAM,ou=LHT,ou=LH,o=LH-DIR)(objectclass=groupofnames))Wed, 23 Aug 2006 18:12:48 Binding as the proxyagentDN Wed, 23 Aug 2006 18:12:48 +0200 Binding finished Wed, 23 Aug 2006 18:12:48 +0200 Returned groups:cn=role-hamtisfa,ou=governor,ou=roles (pw),ou=lh,o=lh-dir,cn=wlan,ou=applications,ou=roles (pw),ou=lh,o=lh-dir, --- snip --- Wed, 23 Aug 2006 18:17:07 +0200 GroupCount = 14 Found user in a group. Wed, 23 Aug 2006 18:17:07 +0200

Has anybody noticed similar problems or is this a configuration problem of our LDAP-Server?

What does your configuration look like? Are you using nested groups? If you are using nested groups, do you have a loop somewhere? The plugin should be taking into account for loops, but it is new and there is a chance for bugs. It *definately* shouldn't take 4 minutes.
-- Ryan Lane

Problem!

Hello ryan

I have mediawiki-1.5.8 installed and is configured to authenticate with the local DB setup. I have downloaded this plugin (LdapAuthentication.php) and put it in includes and made changes to LocalSettings.php as shown in the example. The problem is that it still is authenticating me with the DB and not connecting with the LDAP at all. I tried checking error_logs etc but nothing appears in log either. (tried configuring my php.ini for logging errors!). As u said version -1.5.8 does not requires any patch, what else needs to be done. please help me out..

thanks in advance,

- Niks

Hmmm... That's odd. Try moving LdapAuthentication.php to LdapAuthentication.php.bak and see if mediawiki crashes. It sounds as if the extension isn't being loaded. Can you post the ldap part of your LocalSettings.php (don't forget to snip out any sensitive info)?
-- Ryan Lane

Hi

Sorry for the trouble. I was declaring Ldapvariables ($wgAuth) in the file LocalSettings.php prior to including the file DefaultSettings.php in which $wgAuth variable was set to null again. The problem was solved by adding the parameters at the end of LocalSettings.php (and by commenting the variable $wgAuth in DefaultSettings.php) But it still does not authenticates me. after I submit my user id and passwd.. it dumps the folowing info on my page.. Entering validDomain User is using a valid domain

Entering getCanonicalName Munged username: Username Entering userExists Entering Connect Entering Connect Not Using SSL Using servers: ldap://myldap.server.com Connected successfully Entering getSearchString Doing a proxy or anonymous bind Entering getUserDN Doing an anonymous bind Resource id #82Created a regular filter: (=Username) Using base: ou=people,dc=myldap,dc=server,dc=com Couldn't find an entry userdn is: User DN is blank

and returns with "The password you entered is incorrect (or missing). Please try again." what could be the problem.

thanks -- Niks

sorry again! did not set $wgLDAPSearchAttributes!! of all. everything works fine!

---

Problem: WikiSysop Cannot login

Hi,
After adding the LdapAuthentication.php and modifying the LocalSettings.php file, my WikiSysop user can't seem to login using the local domain. Error: Incorrect password.

My other local username has no problem including those on other domain. Do anyone have any idea what when wrong? I have MediaWiki 1.7.1, PHP5 on Ubuntu6.06LTS server. - Thanks, jon

Extension:LDAP Authentication#Adding WikiSysop
--Ryan Lane

Thanks Ryan - Jon

Cannot get groups working...PLEASE HELP

Please help. I can login fine but when I try to use the groups settings I get errors. Here is a sample of what I am seeing: (of course, all things in bold have been changed)

Entering validDomain
User is using a valid domain
Entering getCanonicalName
Munged username: username
Entering Connect
Entering Connect
Not Using SSL
Using servers: ldap://LDAPserver
Connected successfully
Entering getSearchString
Doing a straight bind
userdn is: domain\username
Binding as the user
Binded successfully
Checking for (new style) group membership
Entering isMemberOfRequiredLdapGroup
Required groups:cn=group,ou=ous,dc=domain,dc=edu
Entering getGroups
Search string: (&(member=username)(objectclass=group))
Returned groups:
Couldn't find the user in any groups (1).

Here is my LocalSettings.php

require_once( "includes/LdapAuthentication.php" );
$wgAuth = new LdapAuthenticationPlugin();
$wgLDAPDomainNames = array( "domain" );
$wgLDAPServerNames = array( "domain"=>"server" );
$wgLDAPSearchStrings = array( "domain"=>"domain\USER-NAME" );
$wgLDAPUseSSL = false; //not recommended but OK for testing
$wgLDAPUseLocal = false;
$wgMinimalPasswordLength = 8;
$wgLDAPRetrievePrefs = false;
$wgLDAPDebug = 99;
$wgLDAPRequiredGroups = array( "domain"=>array("cn=cns,ou=ous,dc=domain,dc=edu") );
$wgLDAPGroupUseFullDN = array( "domain"=>false );   HAVE TRIED TRUE ALSO
$wgLDAPGroupObjectclass = array( "domain"=>"person" );    NOT SURE IF THIS IS RIGHT
$wgLDAPGroupAttribute = array( "domain"=>"member" );     NOT SURE IF THIS IS RIGHT
$wgLDAPGroupSearchNestedGroups = array( "domain"=>true );   HAVE TRIED FALSE ALSO
$wgLDAPBaseDNs = array( "domain"=>"dc=domain,dc=edu" );

I know I'm a member of the group. Does anyone have any help? I think it's something to do with the Search string.

Thanks 206.132.94.6 18:11, 21 September 2006 (UTC)

If you notice, the userdn it is using to search the groups is 'domain\username'. This is a known problem when searching groups in AD because groups use the full DN of user, and not the 'domain\username' syntax. The fix below (for pulling preferences in AD) may work for groups as well. I'm working on a way to make this work with AD a little smoother. Hopefully it'll be soon. For now, if you know PHP, you may want to try hacking support in yourself.
-- Ryan Lane

Fix for retrieving preferences and group membership from a Windows AD LDAP server

I wanted to retrieve preferences and group membership from a Windows AD LDAP server and came across an issue (and a fix). It appears that one can use a bind dn of "USER-NAME@ad.example.com" or "EXAMPLEAD/USER-NAME", but that string isn't valid as a base dn for queries against the Windows AD LDAP server. The true user base dn can be corrected by finding the dn of the object containing the entry "sAMAccount=USER-NAME". The corrected user dn can then be used to successfully retrieve preferences and test for group membership.

Here is a diff that will take the submitted username and convert it to a correct base dn for use against a Windows AD LDAP server. This works for me using a straight binding to a Windows AD LDAP server. Now user preferences and group membership can be obtained from the AD.

--- LdapAuthentication.php.orig	Mon Sep 25 17:13:14 2006
+++ LdapAuthentication.php	Mon Sep 25 18:22:53 2006
@@ -184,6 +184,46 @@
 			}
 			$this->printDebug("Binded successfully",1);
 
+			//// BASE USER DN CHANGE - START
+			// change userdn to the true userdn we need for
+                       // windows AD LDAP, for some odd reason (i'm sure it
+			// makes sense to someone) the bind dn of form
+                       // DOMAIN\USER-NAME or USER-NAME@DOMAIN can't be used
+                       // as the base dn for queries.  To account for this, 
+			// we search for the dn associated with the 
+			// sAMAccountName attribute associated with $username
+			//
+			// requires: $wgLDAPBaseDNs entry for the domain
+			//
+			global $wgLDAPBaseDNs;
+			$domain = $_SESSION['wsDomain'];
+			if($wgLDAPBaseDNs[$domain]) {
+				$domainbasedn = $wgLDAPBaseDNs[$domain];
+                        	$filter = str_replace(
+					"USER-NAME",
+					$username,
+					"sAMAccountName=USER-NAME");
+                        	$lookfor = array("dn");
+				$result = @ldap_search(
+					$ldapconn,
+					$domainbasedn,
+					$filter,
+					$lookfor);
+                        	$entries = @ldap_get_entries(
+					$ldapconn,
+					$result);
+				if($entries[0]["dn"]) {
+                        		$userbasedn = $entries[0]["dn"];
+					$this->printDebug("userdn conversion succeeded:  $userdn -> $userbasedn", 2);
+					$userdn = $userbasedn;
+				} else {
+					$this->printDebug("userdn conversion failed:  no 'dn' entry found for $filter in $domainbasedn", 2);
+				}
+			} else {
+				$this->printDebug("userdn conversion failed:  no wgLDAPBaseDNs entry for $domain", 2);
+			}
+			//// BASE USER DN CHANGE - END
+
 			if ($wgLDAPRequireAuthAttribute) {
 				$this->printDebug("Checking for auth attributes",1);
 				$filter = "(" . $wgLDAPAuthAttribute[$_SESSION['wsDomain']] . ")";

Entries in LocalSettings.php

• domain is "ad.example.com"
  
• domain controller "dc1.ad.example.com"
  
• required group is "wiki" in organizational unit "groups"
  

require_once( 'LdapAuthentication.php' );
$wgAuth = new LdapAuthenticationPlugin();
$wgLDAPDomainNames = array( "ad.example.com" );
$wgLDAPServerNames = array( "ad.example.com"=>"dc1.ad.example.com"  );
$wgLDAPSearchStrings = array( "ad.example.com"=>"USER-NAME@ad.example.com"  );
$wgLDAPUseSSL = true;
#$wgLDAPUseSSL = false;
$wgLDAPUseLocal = false;
$wgLDAPAddLDAPUsers = false;
$wgLDAPUpdateLDAP = false;
$wgLDAPMailPassword = false;
$wgLDAPRetrievePrefs = true;
$wgMinimalPasswordLength = 1;
$wgLDAPRequiredGroups = array( "ad.example.com"=>array("cn=wiki,ou=groups,dc=ad,dc=example,dc=com") );
$wgLDAPGroupUseFullDN = array( "ad.example.com"=>true );
$wgLDAPGroupObjectclass = array( "ad.example.com"=>"group" );
$wgLDAPGroupAttribute = array( "ad.example.com"=>"member" );
$wgLDAPGroupSearchNestedGroups = array( "ad.example.com"=>false );
$wgLDAPBaseDNs = array( "ad.example.com"=>"dc=ad,dc=example,dc=com" );

LDAP Groups

For some reason, when I turn on LDAP Required groups, whenever a username matches a group (as best I can tell) all I get is firefox trying to download index.php or internet explorer saying page cannot be displayed.

$wgLDAPRequiredGroups = array( "domain"=>array("cn=specialgroup,ou=subgroupou,ou=groups,dc=company,dc=org") );
$wgLDAPGroupUseFullDN = array( "domain"=>true );
$wgLDAPGroupObjectclass = array( "domain"=>"groupOfNames" );
$wgLDAPGroupAttribute = array( "domain"=>"member" );
$wgLDAPGroupSearchNestedGroups = array( "domain"=>true );

It isn't because ldap isn't compiled into my php (seemed to be the other 'blank page' problems) because it auths just fine unless I put in this code..

I haven't run into this, and I can't replicate it. Have you tried using "$wgLDAPDebug = 4;" to see what is happening?
-- Ryan Lane

I have also run into this problem when I change certain settings in the LocalSettings.php file. It has happened when I was working with the LDAP Proxy Agent settings as well as when I accidentally leave both the $wgLDAPSearchStrings and $wgLDAPSearchAttributes on together. It is impossible to use $wgLDAPDebug to diagnose this because it never actually loads the page, just tries to download it.
-- Cisox

It sounds like your LocalSettings.php file is somehow getting corrupted. Ensure the editor you are using is not somehow messing up the file.
--Ryan Lane 15:43, 21 February 2007 (UTC)

I believe I have actually have narrowed down the problem here. When checking log files I noticed that the script had used all of the memory PHP had allocated for a script. This is probably caused by using a BaseDN with a lot of entries (40k+ in my case). You can either narrow down your BaseDN to an Organizational Unit (OU) which actually has the User objects in it, or try increasing the "memory limit" variable in your php.ini file.
-- Cisox 18:41, 21 February 2007 (UTC)

---

I am having an issue here as well but in mediawiki 1.9.0 and PHP 5.2.0... I am able to authenticate on a per user basis, but when I try to require groups it just doesn't work. Below is my debug information.

Using servers: ldap://dc1.mydomain.com ldap://dc2.mydomain.com Connected successfully Entering getSearchString Doing a straight bind userdn is: myuser@mydomain.com Binding as the user Binded successfully Checking for (new style) group membership Entering isMemberOfRequiredLdapGroup Required groups:cn=wikigroup,cn=Users,dc=mydomain,dc=com Entering getUserGroups Entering getGroups Search string: (&(member=myuser@mydomain.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 is my Localsettings.php configuration:

require_once( 'LdapAuthentication.php' ); $wgAuth = new LdapAuthenticationPlugin(); $wgLDAPDomainNames = array( "mydomain.com" ); $wgLDAPServerNames = array( "mydomain.com"=>"dc1.mydomain.com dc2.mydomain.com" ); $wgLDAPSearchStrings = array( "mydomain.com"=>"USER-NAME@mydomain.com" ); $wgLDAPUseLocal = false; $wgLDAPAddLDAPUsers = false; $wgLDAPUpdateLDAP = false; $wgLDAPMailPassword = false; $wgLDAPRetrievePrefs = true; $wgMinimalPasswordLength = 1; $wgLDAPRequiredGroups = array( "mydomain.com"=>array("cn=wikigroup,cn=Users,dc=mydomain,dc=com") ); $wgLDAPGroupUseFullDN = array( "mydomain.com"=>true ); $wgLDAPGroupObjectclass = array( "mydomain.com"=>"group" ); $wgLDAPGroupAttribute = array( "mydomain.com"=>"member" ); $wgLDAPGroupSearchNestedGroups = array( "mydomain.com"=>false ); $wgLDAPBaseDNs = array( "mydomain.com"=>"dc=mydomain,dc=com" ); $wgLDAPDebug = 4; $wgShowExceptionDetails = true; $wgLDAPEncryptionType = array("mydomain.com"=>"clear");

Can anyone give me any input on what is going on? It doesn't even tell me the groups I am a part of (wikigroup is one of the groups I am a part of).

Any help would be great.

Thanks,

Russ

Group syncronization does not currently work with the configuration you have (using USER-NAME@domain straight binding). For the time being you'll need to use proxy credentials. See this discussion for more info. I plan on having this fixed next release (1.1d; no release date planned yet).
--Ryan Lane 16:09, 25 January 2007 (UTC)

Still doesn't work :(. I have the following after using a proxyagent.

Munged username: myuser Entering authenticate Entering Connect Using TLS or not using encryption. Using servers: ldap://dc1.mydomain.com ldap://dc2.mydomain.com Connected successfully Entering getSearchString Doing a straight bind userdn is: myuser@mydomain.com Binding as the user Binded successfully Checking for (new style) group membership Entering isMemberOfRequiredLdapGroup Required groups:cn=wikigroup,cn=Users,dc=mydomain,dc=com Entering getUserGroups Entering getGroups Search string: (&(member=myuser@mydomain.com)(objectclass=group)) Binding as the proxyagentDN Returned groups: Returned groups: Couldn't find the user in any groups (1). Entering strict. Returning true in strict(). Entering modifyUITemplate

Below is my Localsettings.php:

require_once( 'LdapAuthentication.php' ); $wgAuth = new LdapAuthenticationPlugin(); $wgLDAPProxyAgent = array( "mydomain.com"=>"CN=ldapquery,CN=Users,DC=mydomain,DC=com" ); $wgLDAPProxyAgentPassword = array( "mydomain.com"=>"passwordgoeshere" ); $wgLDAPDomainNames = array( "mydomain.com" ); $wgLDAPServerNames = array( "mydomain.com"=>"dc1.mydomain.com dc2.mydomain.com" ); $wgLDAPSearchStrings = array( "mydomain.com"=>"USER-NAME@mydomain.com" ); $wgLDAPUseLocal = false; $wgLDAPAddLDAPUsers = false; $wgLDAPUpdateLDAP = false; $wgLDAPMailPassword = false; $wgLDAPRetrievePrefs = true; $wgMinimalPasswordLength = 1; $wgLDAPGroupLowerCaseUsername = false; $wgLDAPBaseDNs = array( "mydomain"=>"dc=mydomain,dc=com" ); $wgLDAPRequiredGroups = array( "mydomain.com"=>array("cn=wikigroup,cn=Users,dc=mydomain,dc=com") ); $wgLDAPGroupUseFullDN = array( "mydomain.com"=>true ); $wgLDAPGroupObjectclass = array( "mydomain.com"=>"group" ); $wgLDAPGroupAttribute = array( "mydomain.com"=>"member" ); $wgLDAPGroupSearchNestedGroups = array( "mydomain.com"=>true ); $wgLDAPBaseDNs = array( "mydomain.com"=>"dc=mydomain,dc=com" ); $wgLDAPDebug = 4; $wgShowExceptionDetails = true; $wgLDAPEncryptionType = array("mydomain.com"=>"clear");

I still have the same issue using the proxyagent option.

You are still using straight binding. When you use a proxy agent, you need to specify a search attribute too. Look at the configuration examples, and at the options on the content page. You need to remove "$wgLDAPSearchStrings = array( "mydomain.com"=>"USER-NAME@mydomain.com" );".
--Ryan Lane 18:32, 25 January 2007 (UTC)

Stuck at "Using servers:"

Hello, I'm trying to implement LDAP Authentication on my new MediaWiki, but I can't get it to work. I'm running MediaWiki on Windows Server 2003 (+Apache), and I wish to connect it to a Windows Server 2003 Active Directory.

This is what I get by debugging while trying to log-in:

Entering validDomain
User is using a valid domain
Entering getCanonicalName
Munged username: USERNAME
Entering Connect
Entering Connect
Using SSL
Using servers: ldaps://dc1.domain.add

It freezes at that point, without debugging I only get a blank white.

I've tried solving it for a while (also by changing every single option), but alas, with no success so far. I would highly appreciate any assistance.

The line of code right after that debugging statement is where PHP connects to the LDAP servers. This usually happens when you don't have LDAP support enabled in PHP. There are Windows instructions on how to configure PHP with LDAP support on the content page near the bottom. I've only used PHP on Windows a few times, so I probably won't be much help with this.
-- Ryan Lane

LDAP doesn't work with apache 2.2

Hi, I got a MediaWiki 1.7.1 System running on a other machine (ADM64, Suse 10.0, apache 2.0.54, PHP5.0.4, here works LDAP with SSL fine too) but on the New system the LDAP Authentication doesn't work.

New System (here LDAP doesn't work, no LDAP with SSL or LDAP without SSL):

MediaWiki 1.7.1
Suse 10.1
Apache 2.2
i586 System
PHP 5.1.2
openssl 0.9.8a

When i am entering my name and password for my Domaine a Blank page with the following message comes:

Entering validDomain
User is using a valid domain
Entering getCanonicalName
Munged username: xxxxx
Entering userExists
Entering Connect
Entering Connect
Using servers: ldap://xxxx.xxxx.xxxxx.de

We have looked up if any Errors got screened on the LDAP Machine but nothing there shows any errors.

the part of my Localsettings.php where i added the LDAP authentication:

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

$wgLDAPDomainNames = array("Alias");
$wgLDAPServerNames = array("Alias"=>"xxxx.xxxxx.xxxxx.de");

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

$wgLDAPUseSSL = false;
$wgLDAPUseTLS = false;

$wgLDAPUseLocal = false;
$wgMinimalPasswordLength = 1;
$wgLDAPRetrievePrefs = false;
$wgLDAPBaseDNs = array("Alias"=>"o=xxxx,dc=xxxxx");
$wgLDAPDebug = 3;

I am Using the LdapAuthentication.php Version: 1.0f 07.10.2005 (Everything is the same like on the Working System)

p.s. I got a Third System here LDAP works fine but no LDAP with SSL works :/ and the Konfigurationfiles are the Same like in the Working system. My LDAP server says Client has broken up the connection.

thx much and if any more Informations are needed tell me :-) (apache Log has no error Messages reportet)

As for your first problem, it looks to me like you don't have LDAP support in PHP.

For you second problem (can't use SSL), most likely your webserver doesn't trust the SSL certificate coming from your LDAP server. You need to modify your webserver's trust using /etc/ldap.conf or /etc/openldap/ldap.conf (I usually delete /etc/openldap/ldap.conf and link it to /etc/ldap.conf). You'll need to use "tls_cacertfile" and/or "tls_cacert" options to point to a file which has the CA certificates you trust.
-- Ryan Lane

I just noticed this, but I believe this:

require_once( "includes/LdapAuthentication.php" );

should be this:

require_once( "LdapAuthentication.php" );

Solved Problem 1 there was no Support for LDAP in PHP and it works now

Solved Problem 2 there was a line missing in /etc/ldap.conf and now it is working fine too

TLS_REQCERT allow

thx much :-)

Windows Configuration issues

I had weird issues using v. 1.0h with mw 1.8.2. It logs me in fine, but when I try to save a page, I get a windows password prompt dialog box. I'm using iis 5/php 5.1.2 - Isaac Gonzalez 00:45, 6 December 2006 (UTC)

IIS had "integrated authentication" enabled, as well as anonymous access (roughly taken from mediawiki-enterprise)

Is it possible to change the login error message?

I've got the LDAP auth plugin working well, including with groups, but I'd like to have a different login error message if someone is not a member of an authorized group, compared to if they get their password wrong - is this possible? I'd rather it say "You are not authorised to view these pages" rather than "Incorrect password entered" - at the moment I've edited the login error page to say both, but it would be better if there were a different page for each.

Unfortunately not. SpecialUserlogin.php defines what error messages are sent to the user, and essentially only two messages are used: wfMsg( 'wrongpassword' ) and wfMsg( 'nosuchuser', htmlspecialchars( $this->mName ) ). SpecialUserlogin doesn't support messages generated from a plugin.

I may file a bug on this eventually though, as this is something I need as well.
-- Ryan Lane

LDAP SSL Connection with Self-Signed Certs

I am connecting my Wiki (Windows 2003 Server IIS) to my openLDAP (OS X 10.4 default) and can connect successfully using no authentication, but when I try to use SSL I get this from the plugin:

Entering validDomain
User is using a valid domain
Entering getCanonicalName
Munged username: Michaelk
Entering Connect
Entering Connect
Using SSL
Using servers: ldaps://pei.animationcollective.com
Connected successfully
Entering getSearchString
Doing a proxy or anonymous bind
Entering getUserDN
Doing an anonymous bind
Failed to bind as
with password:
Failed to bind
userdn is:
User DN is blank  

I am not sure if I added the certificated wrong to the Windows server or what. Any help to point me forward would be appreciated.

--Kirschey

Has anyone figured out how to enable SSL support for a domain that did not have SSL enabled already? I have authentication working without SSL, but not when I flip the switch. Are there instructions on creating SSL certificates (especially in CPanel) and getting this to work? Does this require purchasing an SSL certificate?

ALSO - Do I need root access in order to connect the LDAP Server with the web server hosting MediaWiki? I'm a bit confused on the steps required to enable SSL.

Essentially, you just need your LDAP server to have an SSL certificate installed, and for your web server to trust the CA of the SSL certificate. You can use a self signed, but it may be a little more difficult. There is some helpful info about how to enable LDAP with SSL on IIS on the main page under user provided info section. There is also some info on the configuration examples page.
--Ryan Lane 17:00, 26 December 2006 (UTC)

Oh yeah, and you shouldn't need root.
--Ryan Lane 17:01, 26 December 2006 (UTC)

Ryan, thanks for your comments. Here is my current situation: I have one server with AD (with an equifax SSL cert) and another server (linux) running mediawiki and trying to connect to the AD. As I mentioned earlier, the authentication works fine with the security switched off. When turning on SSL and/or TLS, would the user navigate to an https:// login page in mediawiki? I would then need to change of the configurations in the ldap.conf to allow the AD server's SSL certificate, correct? Earlier, you said I would not require root access, however, I do not have access to the ldap.conf file and/or cannot restart apache processes. Any suggestions on how I can proceed is greatly appreciated! - Jonathan (00:33, 29 December 2006)

Hmm. If your AD has an equifax SSL cert installed, you shouldn't be having any problems. I believe most default configurations of Linux you'll find out there trust equifax certs by default. However, if the Linux server in question doesn't trust the certificate, you may actually need root to make this work. There may be a way to change the SSL trusts through php, but I haven't been able to find any documentation on how to do it.

As for the https:// thing... Using encryption with LDAP and using encryption with HTTP aren't the same thing. Ideally you would want to be using HTTPS and LDAPS or LDAP with start-tls. HTTPS ensures that info between the user and your server are encrypted; LDAPS ensures that info between your server and the LDAP server is encrypted. If you do not currently have HTTPS enabled on the web server, you definately will need root.
--Ryan Lane 05:12, 2 January 2007 (UTC)

Very simple setup

We have a pertty simple setup, on one server there is LDAP running, SVN, some PHP scripts and a few other services. SVN and the PHP Scripts use all LDAP for authentication. Configuring SVN to use LDAP and use LDAP with some PHP scripts was pretty easy. However I was unable to get the LDAP plugin for mediawiki running with the examples provided.

When I tried first, I always got the following error:

<b>Warning</b>:  ldap_start_tls() [<a href='function.ldap-start-tls'>function.ldap-start-tls</a>]: Unable to start TLS: Connect error in <b>/var/www/mediawiki/LdapAuthentication.php</b> on line <b>167</b><br />

I set

$wgLDAPUseSSL = false;

since I don't need encryption if it's running on the same machine as LDAP.

Then I just commented out line 167 and tried again, but i was still not able to autheticate myself. I'm also confused by

$wgLDAPDomainNames = array( "exampleNonADDomain" );

and

$wgLDAPUseLocal = true;

. Do I need a domain name if i use the local ldap database? Below there is the LDAP part of my

dav_svn.conf

. I would be grateful if anybody could write a small example how to configure it with these settings:

 #LDAP password support
 # all people in the group wikiusers get access to the svn
 AuthType Basic
 AuthName "Subversion Repository"
 AuthLDAPUrl ldap://127.0.0.1/ou=People,dc=blah,dc=domain,dc=ch?uid?sub?(objectClass=posixAccount)
 AuthLDAPGroupAttribute memberUid
 AuthLDAPGroupAttributeIsDN off

 require group cn=wikiuser,ou=Groups,dc=blah,dc=domain,dc=ch
 require valid-user

Nils

You aren't giving us enough info. We need the version of mediawiki and the version of the plugin you are using. Also, if you could include the configuration you are currently using, that would be good. Also, what type of LDAP server are you using? OpenLDAP?

$wgLDAPUseLocal means use the local MediaWiki database, not the local LDAP database. If you are using version 1.1a or 1.1b of the plugin you need to turn off SSL and TLS to disable encryption. If you are using 1.1c, set $wgLDAPEncryptionType = "clear". The current documentation is for 1.1c; I'd recommend using this version.
--Ryan Lane 15:13, 28 December 2006 (UTC)

Thanks for the quick reply!

- MediaWiki is Version 1.8.2 - Plugin is Version 1.1c / 12/04/2006 - LDAP Server is OpenLDAP

The settings I tried so far, looked like this:

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

$wgAuth = new LdapAuthenticationPlugin();
$wgLDAPDomainNames = array( "sg" );
$wgLDAPServerNames = array( "sg"=>"localhost");
$wgLDAPSearchAttributes = array( "sg"=>"uid=pseudouser,ou=People,dc=sg,dc=blah,dc=org" );
$wgLDAPBaseDNs = array( "sg.blah.org"=>"cn=wikiusers,ou=Groups,dc=sg,dc=blah,dc=org" );
$wgLDAPUseSSL = false;
$wgLDAPUseLocal = true;
$wgLDAPAddLDAPUsers = true;
$wgLDAPUpdateLDAP = false;
$wgLDAPMailPassword = false;
$wgLDAPRetrievePrefs = false;
$wgMinimalPasswordLength = 1;

$wgLDAPDebug = 1;

Didn't try $wgLDAPEncryptionType = "clear", but will do when I have time.

You need to look over the documentation again for the options, in 1.1c some options changed syntax, some dissapeared, others appeared, etc. You also need to look at the configuration examples as well. in $wgLDAPSearchAttributes, you don't substitute the name of a user with USER-NAME. USER-NAME is substituted automatically by the plugin with the name of the user you are logging in with; it is a special string needed by the plugin. Also, you have a different domainname listed for $wgLDAPBaseDNs, you need to use the same exact domain name all the way through, the plugin uses options based upon that domainname. As far as the plugin is concerned, you don't have a BaseDN set up. You don't want to use "$wgLDAPAddLDAPUsers = true" unless you want the wiki to add users to LDAP, and since you don't have a writerDN set up, I'm doubting thats what you want. That right there could cause authentication to fail. However, to look at your first problem, TLS is failing. Try setting '$wgLDAPEncryptionType = array( "sd"=>"clear" )'. if it works like that, you'll need to fix your TLS/SSL problem. There are a few places in the documentation that work to solve this problem. The user provided documentation sections are particuarly good (but were written for old versions of the plugin, so you'll need to change options as needed).
--Ryan Lane 14:38, 5 January 2007 (UTC)

Windows 2000 AD / Debian Apache2 PHP MySQL

Hello, I tried to use the plugin with Mediawiki 1.8 but it doesnt work. Can somebody tell me if its working on 1.8?

I put the LdapAuthentication.php in includes and added in the LocalSettings.php this:

 require_once( 'includes/LdapAuthentication.php' );
 $wgAuth = new LdapAuthenticationPlugin();
 $wgLDAPDomainNames = array( "COMPANY0" );
 $wgLDAPServerNames = array( "COMPANY0"=>"SERVER1.company.com" );
 $wgLDAPSearchAttributes = array( "COMPANY0"=>"sAMAccountName" );
 $wgLDAPBaseDNs = array( "COMPANY0"=>"dc=company,dc=com" );
 $wgLDAPEncryptionType = array( "COMPANY0"=>"ssl" );
 $wgMinimalPasswordLength = 1;

Btw: putting in extensions doesnt work for me, because in this case it is not able to find the other Auth.php script.

Did I missed something or did I get it right? COMPANY0 is the Netbios-name and company is the DNS-name? Thats important to know for me, because the one who did our ad-setup gave our domain different netbios(COMPANY0) and dns(company.com) names.

Everytime if try to log in, mediawiki says "Fehler bei der Anmeldung: Der Benutzername „Wiki“ existiert nicht. Überprüfen Sie die Schreibweise, oder melden Sie sich als neuer Benutzer an." (means: Error at sign-in, username "wiki" doesnt exist.) I added a user "Wiki" to the AD and gave him a password. Have I to add the "wiki"-users somewhere else? The user "Wiki" doesnt exist in the "local"-wiki-database, have I to add the users first to the Wiki?

I tried a simple php-script to verify the ldap binding and it returns a list of my domainusers, so I assume that php and apache are working fine.

Sorry for my bad english, thanks for the fish. Regards Mike

Your configuration looks ok if your Active Directory allows anonymous binds. Try adding "$wgLDAPDebug = 4" to your configuration and see where it is failing.
--Ryan Lane 04:50, 2 January 2007 (UTC)

Thanks your the fast reply, I dont think that my AD allows anonymous access, because I had to use a real user and his password in the phpscript that I used. I added "$wgLDAPDebug = 4" but there is any additional output. (It should say something at the login page after the login attempt, right?) I used tcpdump to watch the connection and there is no traffic going from the wiki to the domaincontroller at all. If the testscript runs, there is traffic at port 389. There should be at least an attempt of a refused connection, right? Mike

If you aren't getting any output from "$wgLDAPDebug = 4" then the plugin isn't even active. Actually looking at your configuration, and your comments, it looks like the plugin isn't being used at all. The documentation on the content page says if the plugin is dropped in includes, you should use "require_once( 'LdapAuthentication.php' );" not "require_once( 'includes/LdapAuthentication.php' );". Also, make sure you put this at the bottom of LocalSettings.php before the "?>".
--Ryan Lane 18:17, 3 January 2007 (UTC)

Thanks again Ryan, I added the lines at the top of the config. After putting them at the end of the script now the plugin seams to be active. I still cant connect to my domain, but at least I can see the debuggingmessages from the plugin now. With using a proxyagent the script echos just the first letter the "c" of the "cn=..." and the first letter of the agents password.

That's kinda strange. What does your configuration look like now, and what does the debug output look like?
--Ryan Lane 18:47, 4 January 2007 (UTC)

Hi Ryan, here is my debugoutput and config:

 Entering validDomain
 User is using a valid domain.
 Setting domain as: company.com
 Entering getCanonicalName
 Username isn't empty.
 Munged username: someusername
 Entering userExists
 Entering authenticate
 Entering Connect
 Using SSL
 Using servers: ldaps://SERVER1.company.com
 Connected successfully
 Entering getSearchString
 Doing a proxy or anonymous bind
 Entering getUserDN
 Doing a proxy bind
 Failed to bind as c
 with password: x
 Failed to bind
 userdn is:
 User DN is blank
 Entering modifyUITemplate

at the end of LocalSettings.php:

 require_once( 'LdapAuthentication.php' );
 $wgAuth = new LdapAuthenticationPlugin();
 $wgLDAPDomainNames = array( "company.com" );
 $wgLDAPServerNames = array( "company.com"=>"SERVER1.company.com" );
 $wgLDAPBaseDNs = array( "company.com"=>"dc=company,dc=com" );
 $wgLDAPEncryptionType = array( "company.com"=>"ssl" );
 $wgMinimalPasswordLength = 1;
 $wgLDAPDebug = 7;
 $wgLDAPProxyAgent = "cn=wikiproxy,dc=company,dc=com";
 $wgLDAPProxyAgentPassword = "xxxxxxxx";

I tried it on Mediawiki 1.6.8 and 1.7.1, PHP is version 5.2.0-8. If I modify some lines in the plugin like $wgLDAPProxyAgent[$_SESSION['wsDomain']] to $wgLDAPProxyAgent, its not anymore just printing out "Failed to bind as c", than its says than "cn=wikiproxy,dc=company,dc=com".

I guess I should have asked this earlier, but what version of the plugin are you using?
--Ryan Lane 21:19, 4 January 2007 (UTC)

No, but I should have mentioned this ealier. Its version 1.1c.

You are missing the domain info in the proxy agent config. Try this:

 $wgLDAPProxyAgent = array("company.com"=>"cn=wikiproxy,dc=company,dc=com");
 $wgLDAPProxyAgentPassword = array("company.com"=>"xxxxxxxx");

Also, in this one you are missing '$wgLDAPSearchAttributes = array( "COMPANY0"=>"sAMAccountName" );' like you had before, was that just a typo?
--Ryan Lane 22:30, 5 January 2007 (UTC)

Hi,

I'm also struggling with the same problem for many days.

here's my configuration:

//LDAP authentication

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

$wgAuth = new LdapAuthenticationPlugin();

$wgLDAPUseLocal = true;

$wgLDAPEncryptionType = array( "suntecsbs.com"=>"ssl" );

$wgLDAPDebug = 4;

$wgLDAPDomainNames = array("suntecsbs.com");

$wgLDAPServerNames = array("suntecsbs.com"=>"adserver.suntecsbs.com");

//$wgLDAPSearchStrings = array("suntecsbs.com"=>"CN=USER-NAME,OU=SunTec Business Solutions,DC=suntecsbs,DC=com");

$wgLDAPSearchAttributes = array("suntecsbs.com"=>"sAMAccountName");

$wgLDAPBaseDNs = array("suntecsbs.com"=>"OU=SunTec Business Solutions,DC=suntecsbs,DC=com");

$wgLDAPProxyAgent = array( "suntecsbs.com"=>"CN=bind_user,OU=Misc,DC=suntecsbs,DC=com" );

$wgLDAPProxyAgentPassword = array( "suntecsbs.com"=>"secret" );

$wgShowExceptionDetails = true;

and here's the dubug messages:

Entering validDomain

User is using a valid domain.

Setting domain as: suntecsbs.com

Entering getCanonicalName

Username isn't empty.

Munged username: Elearning

Entering userExists

Entering authenticate

Entering Connect

Using SSL

Using servers:ldaps://adserver.suntecsbs.com

Connected successfully

Entering getSearchString

Doing a proxy bind

Failed to bind as CN=bind_user,OU=Misc,DC=suntecsbs,DC=com

with password: secret

Failed to bind

User DN is blank

Entering modifyUITemplate

Allowing the local domain, adding it to the list.

if I use the $wgLDAPProxyAgent value in a simple php script to bind to the server, it works fine. i have many other applications running which authenticates using LDAP, but mediawiki fails. My environment is Mediawiki 1.8.2, PHP 5.2, Apache 1.3 on Windows XP. please help me quickly

Jack

Group Synchronization

This is a great plugin, and a huge help in getting Mediawiki implemented where I work. I have a question though. Can this plugin be used in conjunction with group memberships in AD? I'm looking to see if I can create an AD group that would allow read only access to the wiki, another for read/write access, and another for SysOps access. Thanks for the help, and once again, great plugin.

The Hero Of Canton 17:17, 3 January 2007 (UTC)

Yes. The newest version of the plugin (1.1c) allows for this specifically. I couldn't actually test this with AD, so you'll have to be the test subject, but from a technical point of view it shouldn't be any different than using posix, or groupofuniquenames groups. To configure it, you'll need to use the same options as you'd use for group based login restriction, except you just don't use the group restrictions. Here is info on how to configure it for AD; also, here is the [[m:LDAP Authentication#Group_options|description of the options]], which explains which options are required for group syncronization, and which are required for group restriction.

After configuring the plugin to sync groups, you just need to add users to the LDAP groups you want them in, and then add the groups to MediaWiki with the permissions you want. When users log in they will either be added to or removed from groups according to what is in LDAP(AD).
--Ryan Lane 18:13, 3 January 2007 (UTC)

Could you please explain this a little further Ryan? I've got two NDS groups, Test and Test-admin and I can't see what setting says that users in the Test group are members of the user group in the wiki and members of the Test-admin group are sysops in the wiki.

Sure; all the LDAP plugin does is syncronize the groups. You use MediaWiki's built in permissions to assign groups permissions. So, if you had Test and Test-admin, you'd give regular permissions to Test, and give sysop permissions to Test-admin. Here is an example of how you would give sysop permissions to Test-admin:

$wgGroupPermissions['Test-admin'] = $wgGroupPermissions['sysop'];

Well, that *should* work anyway. I'm trying to take a shortcut obviously, and just assign all the permissions of sysop to Test-admin... See Help:User_rights for more information about how to set user rights. Notice however that groups don't actually exist until rights are assigned to them. MediaWiki's group functionality is pretty painful from a usability standpoint...
--Ryan Lane 14:17, 22 January 2007 (UTC)

Hi again Ryan, sorry for the late response but I'm not sure if this is working. When I log in as a user that is in the test-admin group they're able to log in:

Using base: o=XXXX
Fetched username is not a string (check your hook code...).
userdn is: cn=XXXXX,ou=xxxxx,ou=xxxx,ou=xx,o=xxxx
Binding as the user
Binded successfully
Checking for (new style) group membership
Entering isMemberOfRequiredLdapGroup
Required groups:cn=test,ou=groups,ou=xxxx,ou=xx,o=xxxx,cn=test-admin,ou=groups,ou=xxxx,ou=xx,o=xxxx
Entering getUserGroups
Entering getGroups
Search string: (&(uniquemember=cn=xxxxxx,ou=xxxxx,ou=xxx,ou=xx,o=xxxx)(objectclass=groupofuniquenames))
Returned groups:cn=test-admin,ou=groups,ou=xxxx,ou=xx,o=xxxx
Returned groups:,,,,,,,,,,,,,,,
Found user in a group.
Authentication passed
Entering updateUser

and I have the following in LocalSettings.php:

#Assign NDS groups to their correct wiki group permissions
$wgGroupPermissions['test-admin'] = $wgGroupPermissions['sysop'];
$wgGroupPermissions['test'] = $wgGroupPermissions['user'];

Yet when the user in the test-admin group logs in they have no protect or delete tab on the main page and so don't appear to have sysop rights. Am I missing something?

Well, if you notice, it says it found the user in a group, it should be working. However, the way you are setting user rights may not be correct (remember I said that was a shortcut I was hoping would work...). Check out Help:User_rights, that may be enough info.
--Ryan Lane 16:28, 1 February 2007 (UTC)

Hi again Ryan. I'm not sure what I'm not doing correctly, I've read the Help:User_rights section and might be missing something, but this is what I have set;

$wgGroupPermissions['sysop']['block']           = true;
$wgGroupPermissions['sysop']['createaccount']   = true;
$wgGroupPermissions['sysop']['delete']          = true;
$wgGroupPermissions['sysop']['deletedhistory']  = true;
$wgGroupPermissions['sysop']['editinterface']   = true;
$wgGroupPermissions['sysop']['import']          = true;
$wgGroupPermissions['sysop']['importupload']    = true;
$wgGroupPermissions['sysop']['move']            = true;
$wgGroupPermissions['sysop']['patrol']          = true;
$wgGroupPermissions['sysop']['protect']         = true;
$wgGroupPermissions['sysop']['rollback']        = true;
$wgGroupPermissions['sysop']['upload']          = true;
$wgGroupPermissions['sysop']['reupload']        = true;
$wgGroupPermissions['sysop']['reupload-shared'] = true;
$wgGroupPermissions['sysop']['unwatchedpages']  = true;
$wgGroupPermissions['sysop']['autoconfirmed']   = true;

which is the default for sysops, yet the users who are logging in and supposedly getting sysop rights aren't (no delete tabs etc on pages). This is the correct way to set rights for this method of logging in isn't it?

You are explicitly setting rights for the sysop group, instead, please change all occurances of 'sysop' above to 'test-admin'. Also, please read the section below. It looks like I was missing a configuration option on the content page that is required for this to work properly.
--Ryan Lane 18:19, 13 February 2007 (UTC)

I'm trying to do the same thing, with version 1.1d, but I'm not retrieving the full dn:

Entering validDomain
User is using a valid domain.
Setting domain as: aenetad.net
Entering getCanonicalName
Username isn't empty.
Munged username: Mcdonalddj
Entering authenticate
Entering Connect
Using TLS or not using encryption.
Using servers: ldap://***elided***
Using TLS
Connected successfully
Lowercasing the username: mcdonalddj
Entering getSearchString
Doing a straight bind
userdn is: MUNGED\mcdonalddj
Binding as the user
Binded successfully
Entering getUserDN
Created a regular filter: (=mcdonalddj)
Using base: dc=munged,dc=net
Couldn't find an entry
Pulled the user's DN:

My user is uid=mcdonalddj,ou=users,ou=something,ou=somethingelse,ou=departments,dc=...

The groups are in ou=FS,ou=groups,dc=...

It authenticates fine, just no group information. Clues appreciated. --198.214.232.10 21:25, 5 February 2007 (UTC)

Support for what you are trying to do was just added in 1.1d. You are using straight AD style binds. Take a look at the options on the content page again. The option for straight binds mentions that if you want to use AD style straight binds, and also want to be able to do group sync, preference pulling, etc., that you'll need to $wgLDAPBaseDNs, and $wgLDAPSearchAttributes. You are missing $wgLDAPSearchAttributes. If you notice the filter, it says "=mcdonalddj" it should say "sAMAccountName=mcdonalddj". Set the search attribute and you should be good to go.
--Ryan Lane 21:47, 5 February 2007 (UTC)

Notice that this is exactly the issue you are having, and is slated to be fixed in 1.1e.
--Ryan Lane 23:48, 5 February 2007 (UTC)

I applied the patch, and it does work. I determined that I also had to define

$wgLDAPGroupNameAttribute = array("ad.example.com"=>"cn");

In order to find the group names. That directive doesn't appear to be documented anywhere.--198.214.232.10 19:17, 6 February 2007 (UTC)

Wow. Good catch, I didn't even notice that. I've updated the documentation on the content page. Thanks.
--Ryan Lane 13:58, 7 February 2007 (UTC)

One other caveat. The user-group table limits group name length to 16 characters. It works fine if you truncate the name of the group. For example, if my group's CN was "A very long and useless group name" you would have to specify the permissions as $wgGroupPermissions['A very long and ' ]['read'] = true;

PATCH for group synchronization (2007-04-05 19:20 +0200)

We saw that group synchronization does not really work in 1.1d. Here is a patch that puts users into wikigroups based on his ldap groups:

--- LdapAuthentication.php-orig 2007-03-08 13:37:22.070548000 +0100
+++ LdapAuthentication.php      2007-04-05 19:00:56.267368111 +0200
@@ -1237,6 +1237,8 @@
                foreach ($info as $i) {
                        $mem = strtolower($i['dn']);
                        $shortnamemem = strtolower($i[$nameattribute][0]);
+                       //removing bogus AD groups with SSIDs or such in curly brackets behind name
+                       if (strstr($mem, '{')) continue;

                        array_push($groups,$mem);
                        array_push($shortnamegroups,$shortnamemem);
@@ -1290,7 +1292,7 @@
                $this->printDebug("Pulling groups from LDAP.",1);

                # add groups permissions
-               $localAvailGrps = $user->getAllGroups();
+               $localAvailGrps = array_merge($user->getAllGroups(), $this->allLDAPGroups);
                $localUserGrps = $user->getEffectiveGroups();

                $this->printDebug("Available groups are: " . implode(",",$localAvailGrps) . "",1);

Regards, Bjoern

Failed to bind as.

I am having problems with mediawiki authenticating to our LDAP.

From LocalSettings.php

require_once( 'LdapAuthentication.php' );
$wgAuth = new LdapAuthenticationPlugin();
$wgLDAPDomainNames = array( "Company" );
$wgLDAPServerNames = array( "Company"=>"ldapserver"  );
$wgLDAPSearchStrings = array( "Company"=>"uid=USER-NAME,ou=user,dc=company,dc=com" );
$wgLDAPUseSSL = true;
$wgLDAPUseLocal = false;
$wgLDAPAddLDAPUsers = false;
$wgLDAPUpdateLDAP = false;
$wgLDAPMailPassword = false;
$wgLDAPRetrievePrefs = false;
$wgMinimalPasswordLength = 1;

$wgLDAPDebug = 99;

And debug info:

Entering validDomain
User is using a valid domain
Entering getCanonicalName
Munged username: User
Entering userExists
Entering Connect
Entering Connect
Using SSL
Using servers: ldaps://ldapserver
Connected successfully
Entering getSearchString
Doing a straight bind
userdn is: uid=user,ou=user,dc=yarde,dc=com
Binding as the user
 Failed to bind as uid=user,ou=user,dc=yarde,dc=com
with password: XXXX

The only difference I made was to change code in LdapAuthentication.php so it connects to the server with a lowercase username. It is still a no go... I am able to browse the directory with gq or ldapexplorer and all looks good. Any help would be appreciated. I have no further details...

What do you see in the LDAP logs? Since you have debugging on well above 4, it should show the user's password in clear text in the debug output, is that the correct password? Are you sure SSL is working properly? Does anything show up in PHP's logs?
--Ryan Lane 18:46, 4 January 2007 (UTC)

If you are using Windows box, don't forget that the Apache service has to run under a valid account and not under the default service account. --Nagy.zolo 05:08, 23 January 2007 (UTC)

User creation errors, user still created

Hello, I'm using the LDAP plugin version 1.1c with NDS. When creating an account I get the following error: Login error: There was either an external authentication database error or you are not allowed to update your external account. and with $wgLDAPDebug=3 the last few lines are: Entering addUser The wiki is requiring users to be in specific groups, cannot add users as this would be a security hole. Entering modifyUITemplate

Yet if I then wait any amount of time and try to log in there is no initial error and it returns me to the Main Page with the "You must log in to view other pages" error. There is no anonymous read on this wiki. If I then try to log in again with the same account I can return to the logged in page as a registered user. Basically what I'm trying to say is that despite two error messages suggesting that the account doesn't exist, the account exists. Can I provide any more information to explain why this is the case?

Are you trying to add users to your LDAP directory from the wiki, or are you just trying to have the wiki automatically create accounts in its local database? If you are trying for the latter, then you should not be using $wgLDAPAddLDAPUsers. Both the documentation, and the variable itself mention adding users to LDAP after all ;). By default the plugin tells MediaWiki to automatically create accounts for users (there is an option to disable that as well...).

If you are trying to add users to LDAP from the wiki, then there is a seperate issue: If you are restricting users by group, then the wiki can't add users to LDAP because it can't currently add the user into the required groups (I haven't written support for that yet). So, to avoid people creating accounts they'll never be able to log in with, I check for this condition and error out; however, MediaWiki shouldn't create the user at all in that case. If MediaWiki is creating the user, this is a bug, which is most likely in the MediaWiki source. I'll take a look soon to see if that is the case.
--Ryan Lane 14:13, 8 January 2007 (UTC)

Thanks for your prompt response Ryan. I'm not trying to add users to our LDAP directory, I'm trying to use a group created in our LDAP directory to be the sole group of NDS accounts that can create an account in the wiki. I have : $wgLDAPAddLDAPUsers = false; set and I'm not trying to add users to a group either, I was planning on manually manipulating their user levels later. If there are any other settings you need me to copy here I'd be happy to elaborate and am happy to test any steps you want me to as well.

Doh. Looks like you found a bug ;). I'm checking for "$wgLDAPRequiredGroups || $wgLDAPGroupDN" before I'm checking for "!isset($wgLDAPAddLDAPUsers[$_SESSION['wsDomain']])". The former has to return false to avoid a security hole, the latter has to return true so that the wiki won't stop the login process. Since I check the wrong thing first it is blocking the login process. Please move the block:

               if ($wgLDAPRequiredGroups || $wgLDAPGroupDN) {
                       $this->printDebug("The wiki is requiring users to be in specific groups, cannot add users as this would be a security hole.",1);
                       //It is possible that later we can add users into
                       //groups, but since we don't support it, we don't want
                       //to open holes!
                       return false;
               }

after the block:

               if ( (!isset($wgLDAPAddLDAPUsers[$_SESSION['wsDomain']]) || !$wgLDAPAddLDAPUsers[$_SESSION['wsDomain']]) ||
                       'local' == $_SESSION['wsDomain'] ) {
                       $this->printDebug("Either the user is using a local domain, or the wiki isn't allowing users to be added to LDAP",1);

                       //Tell the wiki not to return an error.
                       return true;
               }

in the addUser() function. I'll fix this in the next release. Also, if you are still having problems after this fix, please post your configuration, and the debug output (make sure to remove sensitive info in both).
--Ryan Lane 14:26, 9 January 2007 (UTC)

Thanks Ryan, commenting that out has worked perfectly for two new user creations from the LDAP group and doesn't allow me to create an account for a user outside of the LDAP group.

This is fixed in 1.1d
--Ryan Lane 18:50, 13 February 2007 (UTC)

ldap_get_entries resource error when searching groups

Problem

When enabling group lookup you get a resource error for ldap_get_entries. This can be caused by havering one of the following chars (*,(,),\,NUL) in value parts of a DN entry for a person. For example where I work the CN is in the format 'surname, forename' which AD escapes to 'surname\, forename' thus causing a problem when using this as part of a string for searching with.

The initial error is caused by ldap_search returning FALSE on an error where ldap_get_entries is not expecting a boolean. The error ldap_search is experiencing is having a bad search string.

Resolution

As per RFC 2254 the chars mentioned above should be escaped with \nn where nn is their two digit hex value. This requires the following changes to the codebase (as of writing 1.1c).

In the class LdapAuthenticationPlugin in LdapAuthentication.php

Add the following function

	/**
	 * Returns a string which has the chars *, (, ), \ & NUL escaped to LDAP compliant
	 * syntax as per RFC 2254
	 * 
	 * @param string $string
	 * @return string
	 * @access private
	 */
	function getLdapEscapedString ($string) {
		// Make the string LDAP compliant by escaping *, (, ) , \ & NUL
		return str_replace(array("*","(",")","\\","\x00"),array("\\2a","\\28","\\29","\\5c","\\00"),$string);
	}

Search for the following lines in the function getGroups

                //Search for the groups this user is in
                $filter = "(&($attribute=$dn)(objectclass=$objectclass))";

and replace with

		//Search for the groups this user is in
		$filter = "(&($attribute=" . $this->getLdapEscapedString($dn) . ")(objectclass=$objectclass))";

This means that the search string will be properly escaped and will work for ldap searches.

I know this is a bit obscure but it bit me and eliminates potential problems for other users.

Iain Colledge 18:35, 16 January 2007 (UTC)

Ah, very cool. Thanks for the research. I have yet to run into this problem, but now that you mention it, I've noticed this when looking through my LDAP server logs for netgroup entry info; I had wondered why they were formatted like that, and now I see the RFC to show me why. I'll make sure to add this into the next version.
--Ryan Lane 23:15, 16 January 2007 (UTC)

You're welcome, thanks for the very cool LDAP Auth mod. Looking through the code it's probably worth escaping all the filters submitted to ldap_search just to be safe, someone somewhere is going to have some other funky formatting. :)
--Iain Colledge 11:08, 17 January 2007 (UTC)

New users need to login twice...?

I've tried and tried to track this bug down on my own, but I just can't find it. Any help you can give would be greatly appreciated.

I have MediaWiki 1.8.2 running on apache 2.2.3 with php 5.2.0 and LdapAuthentication.php 1.1c. I have your script configured to use an AD 2003 to authenticate users. Users must log in to edit the wiki and only users in the AD can log in to the wiki. Users cannot create new accounts from the wiki itself, it must be created on the AD.

So, if a user has logged in to the wiki in the past, everything works great. However, if the user has never logged into the wiki before, that is when the trouble begins. The new user logs in and the next page says there was success. In the upper right corner it displays their user name correctly and it looks like it has worked. However, as soon as they navigate away from that page (or are taken away by the redirect), the username in the upper right goes back to their IP address and they are logged out. So, they click on edit again and it prompts them to log in. If they log in this second time, everything works just dandy. It seems that the first time my users want to edit something, they have to log in twice. If I go in to the MySQL user table and delete their row, then they have to log in twice again. So, there is something that mediawiki doesn't like about a user not existing in its database, but existing in the AD.

Please let me know if there is any debugging info you want me to post or anything else that would assist us tracking this bug down. Thanks ahead of time, and thanks for the great script!!

I don't believe I've seen this problem before. Maybe your session is getting dropped for some reason. When the user logs in the first time, is a user account created for them in the MediaWiki database? I wonder if I am somehow killing the session in the initUser() function... Please post your configuration info, and the debug info (making sure to snip anything sensitive out).
--Ryan Lane 14:20, 22 January 2007 (UTC)

I have the SAME problem: Mediawiki 1.8.2 running on Ubuntu Dapper (apache 2.0.55, PHP 5.1.2, MySQL 5.0.22) authenticating on a Fedora Directory Server 1.0.4.
--Bruno Clermont 09:45 23 January 2007 (EDT)

I had the same problem on a Mediawiki 1.8.3, LDAPAuthentication.php 1.1e running on Windows 2003 (IIs 6.0, PHP 5.1.2, MySQL 5). However upgrading to LDAP 1.1f and Mediawiki 1.9.3 fixed the problem--Joe Kuster 13:33, 26 April 2007 (UTC)

$wgLDAPDisableAutoCreate set to true

MediaWiki: 1.9.1 PHP: 5.2.0 (apache2handler) MySQL: 5.0.27-community-log

I post here, because I think that this problem is linked to the upper one (New users need to login twice...?).

From SpecialUserlogin.php

if ( $wgAuth->autoCreate() && $wgAuth->userExists( $u->getName() ) )
{
	if ( $wgAuth->authenticate( $u->getName(), $this->mPassword ) ) 
	{
		$u = $this->initUser( $u );
	} else
	{
		return self::WRONG_PLUGIN_PASS;
	}
} else
{
	return self::NOT_EXISTS;
}

with $wgLDAPDisableAutoCreate set to true, it's normal that my users will never be authentificated, no ?

if you add the autoCreate() method in the upper if :

if ( 0 == $u->getID() && $wgAuth->autoCreate() ) {

it solves the problem and the authentification rulez..

BUT - and it's why this issue is linked with the "second identification problem"- so BUT my users are disconnected. And as they are always new users, they are ALWAYS disconnected.. not fun... I m trying to find another fix, on an upper method in the code, or fix this disconnection problem..

I m not sure the pb is coming from your excellent plugin (i ve linked some others wiki to ldap, and you ve made the first plugin without easy pb of config) (User:Nin' on wp.en and wp.fr) 213.4.127.164 14:59, 14 February 2007 (UTC)

update

I ve decided to leave $wgLDAPDisableAutoCreate to false because MW seems to need more modifications than I can give for these first tests. So, except commenting the checks on the AllowPasswordChange of User.php's method setPassword() (that gets the ldapAllowPassChange option, we don t know why here because im changing MySql password), I don t have any problems : No deconnection with a new user, and update successful when I change my userpassword on my ldap. One more time, good job. User:Nin'

Real name not displayed on changes

Apologies in advance if this is not the right place to post this, but I'm not sure if it's an LDAP issue or a general Mediawiki issue. When I add my first name into the Real Name section of the preferences I get:

Entering updateExternalDB
Either the user is using a local domain, or the wiki isn't allowing updates

Which is to be expected as I have $wgLDAPUpdateLDAP = false; Whenever I make changes to the test wiki though my staff number is still given as the attribution on the article rather than my real name. Is this an LDAP issue (wiki ignoring the local real name setting and looking for an LDAP attribute of the same name) or should I be posting this question elsewhere? Thanks in advance, this LDAP patch is exceptionally useful.

Staff number? So, if you change your name in the preferences, then log out and log back in, what shows up there? Is your name still there? Do you have $wgLDAPRetrievePrefs set? Also, what version of MediaWiki, and the plugin are you using?
--Ryan Lane 14:27, 23 January 2007 (UTC)

Ldap plugin version Version 1.1c / 12/04/2006, Mediawiki version 1.8.2, $wgLDAPRetrievePrefs = false;. I'm creating an account using the LDAP plugin, with my Username being my staff number and my password my NDS password. As a part of that creation I'm also writing in my first name in the Real Name section as we have no Real Name attribute in the NDS. When I then make changes to the wiki my Username (staff number) is used as the attribution, not my Real Name. I was wondering if that was because the LDAP plugin ignores the manually set Real Name and looks for it in our NDS directory instead, and if so is there a way to change what attribute it looks for globally without going through every line that mentions realname? I'm not a coder in the least but it seems that in LdapAuthentication.php it seems to think cn=realname which in the NDS is our staff number, our actual name is fullName. Sorry if that's confusing...

I believe that MediaWiki will always use your username, and not the real name or nickname for the history list, recent changes, etc. It uses real name and nickname in signatures. You'll need to change MediaWiki to use the real name instead of the username. I remember this being on the MediaWiki-l mailing list, but I can't seem to find it...
--Ryan Lane 17:59, 24 January 2007 (UTC)

CMS::MediaWiki Breaks

I have properly configured CMS::MediaWiki, a Perl module that allows for script-based reading and editing of MediaWiki articles. (It's actually pretty nice.) I've created a Local MediaWiki user named "PerlBot" that CMS::MediaWiki uses to update wiki articles containing server information.

I have also properly configure LDAPAuthentication to allow for both Local and LDAPS authentication. The problem is that CMS::MediaWiki stopped working. I assume this has to do with the session variable wsDomain not being set to "local" on the new login page. I assume CMS::MediaWiki is doing some fancy auto-form-filling and ignores the "Domain" drop down. I am guessing that I'll need to either a) modify LDAPAuthentication to allow for CMS::MediaWiki type logins (defaults to Local) or b) modify CMS::MediaWiki to set the wsDomain session variable somehow.

Has anyone had any experience with LDAPAuthentication and CMS::MediaWiki playing nice together? -- dgooding -- 23:54, 23 January 2007 (UTC)

I would recommend that CMS::MediaWiki be fixed. wsDomain is a valid field, and clients probably shouldn't ignore it.
--Ryan Lane 16:00, 24 January 2007 (UTC)

I have contacted the author (retoh@cpan.org) and hope to get a response soon. Thanks for the info Ryan. -- dgooding -- 23:04, 25 January 2007 (UTC)

Bug in hasLDAPGroup() and isLDAPGroup()

In those functions:

        function hasLDAPGroup( $group ) {
                $this->printDebug("Entering hasLDAPGroup",1);
                return in_array($group, $this->userLDAPGroups);
        }

and

        
        function isLDAPGroup( $group ) {
                $this->printDebug("Entering isLDAPGroup",1);
                return in_array($group, $this->allLDAPGroups);
        }

in_array() search a group in all user/not_user LDAP groups. But arrays userLDAPGroups and allLDAPGroups had been created with lowercase only group name:

                //Let's get a list of both full dn groups and shortname groups
                $groups = array();
                $shortnamegroups = array();
                foreach ($info as $i) {
                        $mem = strtolower($i['dn']);
/* HERE --> */          $shortnamemem = strtolower($i[$nameattribute][0]);

                        array_push($groups,$mem);
                        array_push($shortnamegroups,$shortnamemem);
                }

when an LDAP group contain uppercase group name, check fail.
so, the argument $group must be strtolower()'ed before being pass to in_array().
--Bruno Clermont 16:53, 25 January 2007 (EDT).

This should be fixed in 1.1d. Let me know if it isn't.
--Ryan Lane 18:49, 13 February 2007 (UTC)

e-mail from Wiki DB into LDAP

Hello Ryan,

I want to configure that the Wiki stores user preferences and especially the e-mail address of a user in the LDAP and the Wiki's database. Is there a simple way to configure that?

My LocalSettings looks like that:

# LDAP support

$wgLDAPDisableAutoCreate = array("Ooops LDAP"=>false );
$wgLDAPAddLDAPUsers = array("Ooops LDAP"=>true);
$wgLDAPUpdateLDAP = array("Ooops LDAP"=>true);
$wgLDAPMailPassword = true;
$wgLDAPRetrievePrefs = array("Ooops LDAP"=>true);

User creation and updates etc. work fine.

I'm using one LDAP for the Wiki, phpbb and a planed WebMail server and it would be great to share generic data between these modules. Any idea?

kind regards Gerald R

05 February 2007 15:05 CET

Are you allowing the wiki to create and modify users in LDAP (if so I'll need to update that other thread I answered you on ;))? If creation is working ok, then I couldn't imagine that retreival isn't working. Can you post your full configuration, and debug log with anything sensitive snipped out?
--Ryan Lane 15:06, 5 February 2007 (UTC)

Hello Ryan,

I'm allowing the wiki to create and modify users in LDAP. Creation and retreival seems to work very well. You can try this, if you have some time, at my site. Just create a new user and than try to login into the BBS and than connect using phpLDAPadmin. It works except that the e-mail address is not stored automatically. The problem seems to be (if using a LDAP browser) that after creation and changes of the preferences the e-mail address is not stored in the LDAP but in the Wiki's database. Is this the normal behaviour?
http://www.oraforecast.com for the wiki
http://www.oraforecast.com/BBS for the BBS (use account created at wiki)
https://www.oraforecast.com/phpldapadmin for the LDAP admin
(use anonymous account (but I've blocked displaying mail attribute for anonymous in slapd.conf) or account created at wiki.
DN should be uid=<your name>,ou=user,ou=orawiki,dc=oraforecast,dc=com)

kind regards GeraldR

Sorry, I've been really busy lately and haven't had much time for support. I'll take a look at this when I get a chance (hopefully soon).
--Ryan Lane 18:48, 13 February 2007 (UTC)

I got a chance to take a look at this. It is definately strange that the mail attribute isn't getting updated. It may be because you have email verification turned on. I'll need to look at the email code to figure out what is breaking.
--Ryan Lane 06:31, 4 March 2007 (UTC)

AD shortnamegroups are empty while Full Name Groups are listed on debug

Hello Ryan,

Thanks for the great plug-in by the way.

I was able to make Group Sync on AD by adding:

$filter = "(&($attribute=" . str_replace("\\","\\5c",$dn) . ")(objectclass=$objectclass))";

Debug shows list of full group names from AD but shortnames are missing (e.g. ,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,)

I think it is something to do with $info structure and I made the following "quick&dirty" solution with my limited PHP coding skill:

		//Let's get a list of both full dn groups and shortname groups
		$groups = array();
		$shortnamegroups = array();
		foreach ($info as $i) {

			$mem = strtolower($i['dn']);
			//$shortnamemem = strtolower($i[$nameattribute][0]); // <-- *This returns empty value.*
			$mem_attr1 = explode(',',$mem); // explode cn=asdf,ou=asdf,dc=asdf,dc=asdf with comma
			$mem_attr2 = explode('=',$mem_attr1[0]); // explode the 1st value (cn=asdf) with equal sign 
			$shortnamemem = $mem_attr2[1]; // get second value of the cn=asdf and assign it to $shortnamemem.
			array_push($groups,$mem);
			array_push($shortnamegroups,$shortnamemem);
		}

		$both_groups = array();
		array_push($both_groups, $groups);
		array_push($both_groups, $shortnamegroups);

		$this->printDebug("Returned groups:" . implode(",",$groups) . "",2);
		$this->printDebug("Returned shortnamegroups:" . implode(",",$shortnamegroups) . "",2); // I would update this line to make it more obvious by the way

Could you provide right way to fix this issue?

Thanks,

Ypae 23:10, 5 February 2007 (UTC)

This will be fixed whenever I take care of the above issue (Talk:LDAP_Authentication#ldap_get_entries_resource_error_when_searching_groups)
--Ryan Lane 18:43, 13 February 2007 (UTC)

NestedUserGroup Search for Group Sync

Hi Ryan,

Please take a look at the following and either include them to your next release or optimize/enhance the code to make it better/efficient.

Thanks,

• • Summary

• • I found that wgLDAPGroupSearchNestedGroups is only designed for isMemberOfRequiredLdapGroup.
  • My intention was to create dedicated groups for WIKI group synchronization on our AD and recycle other pre-defined groups to them.
  • For example:

** Existing Groups: GroupA, GroupB, GroupC, WhateverGroupNameD (they have been created everywhere in AD for their original purposes)

** Dedicated Wikigroups on AD under "WIKI" OU: nsGroupARW, nsGroupARO, nsGroupBRW, nsGroupBRO...

** Wiki's local groups: nsGroupARW, nsGroupARO, nsGroupBRW, nsGroupBRO... (Matching with AD group names)

** Custom Namespace for the future Group based permission control: GroupA:, GroupB:, GroupC:, GroupD: ...

** Adding exsiting group to dedicated wikigroups (e.g. GroupA to nsGroupARW, GroupB to nsGroupBRW...) should resolve the nested groups and add the user into wiki's local group as expected.

• • Solution

** Add the following on Localsettings.php

$wgLDAPUserGroupSearchNestedGroups = array(
  "ADDomain"=>true
  );

** Add the following on LdapAuthenication.php

		//We haven't done a search yet, lets do it now
		list($groups, $shortnamegroups) = $this->getGroups( $ldapconn, $dn ); // <-- Right after this line.

		// 2007-02-07 ypae Adding nested userGroup search Begin
		// for each group (FQDN), get the group membership and add it to the $groups and $shortnamegroups array.

		$searchnested = $wgLDAPUserGroupSearchNestedGroups[$_SESSION['wsDomain']];

		if  ($searchnested) {
			$this->printDebug("Adding NestedGroups... ",1);
			foreach ($groups as $group1) {
				// 1st nested group
				$returnedgroups1 = $this->getGroups($ldapconn,$group1);												// Add whatever found on top of the list
				list($nestedgroups1, $nestedshortnamegroups1) = $this->getGroups($ldapconn,$group1);
				//merge nested groups to existing groups
				$groups = array_merge($groups,$nestedgroups1);													$shortnamegroups = array_merge($shortnamegroups,$nestedshortnamegroups1);
				$this->printDebug("2ndlevelNestedGroups:" . implode(",",$nestedshortnamegroups1) . "",2);

				// Uncomment the following to enable 2nd level search....
				// foreach ($returnedgroups as $group2) {
				// 	$returnedgroups2 = $this->getGroups($ldapconn,$group2);
				//	list($groups, $shortnamegroups) = $this->getGroups($ldapconn,$group2);
				//	$groups = array_merge($groups,$nestedgroups2);
				//	$shortnamegroups = array_merge($shortnamegroups,$nestedshortnamegroups2);
				//	$this->printDebug("2ndlevelNestedGroups:" . implode(",",$nestedshortnamegroups2) . "",1);
				// }
			}
		}
		
		// Clean up duplicate entries...
		$groups = array_unique($groups);
		$shortnamegroups = array_unique($shortnamegroups);
		
		// 2007-02-07 ypae Adding nested userGroup search End

Ypae 18:18, 7 February 2007 (UTC)

I was planning on adding nested group support for group syncing. I didn't add it originally because it was going to require some changes to the group restriction code... I'll probably just extend the current nested search to get all nested groups instead of stopping when it finds a required group.
--Ryan Lane 18:39, 13 February 2007 (UTC)

Unable to Authenticate(?) nor restrict by group (?)

Hi all,

I'm trying to setup LDAP authentication into the wiki and restrict based on LDAP group...
From what I can tell, Server had wiki 1.6.5 (I upgraded it to 1.6.10), and php4 with LDAP support existing.
here's my code block:

$wgLDAPDomainNames = array( "NVIDIA.COM" );
$wgLDAPServerNames = array( "NVIDIA.COM"=>"ldap.NVIDIA.COM"  );

$wgLDAPEncryptionType = array( "NVIDIA.COM"=>"tls" );

$wgLDAPUseSSL = true;
//$wgLDAPUseSSL = false;
$wgLDAPUseLocal = false;
$wgMinimalPasswordLength = 1;

$wgLDAPAddLDAPUsers = false;
$wgLDAPUpdateLDAP = false;
$wgLDAPMailPassword = false;
$wgLDAPRetrievePrefs = true;
$wgLDAPDebug = 99;

$wgLDAPProxyAgent = array( "NVIDIA.COM"=>"cn=someaccount,ou=Service Accounts,ou=Accounts,dc=nvidia,dc=com" );
$wgLDAPProxyAgentPassword = array( "NVIDIA.COM"=>"somepassword" );

###
# added this 3_15_07
$wgLDAPRequireAuthAttribute = array( "NVIDIA.COM"=>"true");
$wgLDAPAuthAttribute = array( "NVIDIA.COM"=>"!(userAccountControl:1.2.840.113556.1.4.803:=2)");
###

$wgLDAPSearchAttributes = array( "NVIDIA.COM"=>"sAMAccountName" );
//$wgLDAPSearchAttributes = array( "NVIDIA.COM"=>"uid" );

$wgLDAPUseLDAPGroups = array("NVIDIA.COM"=>true);

//$wgLDAPSearchStrings = array( "NVIDIA.COM"=>"NVIDIA.COM\\USER-NAME" );
//$wgLDAPSearchStrings = array( "NVIDIA.COM"=>"USER-NAME@NVIDIA.COM"  );

# testing group restriction below
###DNs in $wgLDAPRequiredGroups must be lowercase, as search result attribute values are...
//$wgLDAPRequiredGroups = array( "NVIDIA.COM"=>array("cn=neteng-contractors,ou=departments,ou=distribution lists,ou=groups,dc=nvidia,dc=com") );

$wgLDAPGroupUseFullDN = array( "NVIDIA.COM"=>true );

###
# added this 3_15_07
$wgLDAPLowerCaseUsername = array( "NVIDIA.COM"=>true);
$wgLDAPGroupUseRetrievedUsername = array( "NVIDIA.COM"=>false);
$wgLDAPGroupNameAttribute = array( "NVIDIA.COM"=>"cn");
###

$wgLDAPGroupObjectclass = array( "NVIDIA.COM"=>"group" );
$wgLDAPGroupAttribute = array( "NVIDIA.COM"=>"member" );
$wgLDAPGroupSearchNestedGroups = array( "NVIDIA.COM"=>true );
$wgLDAPBaseDNs = array( "NVIDIA.COM"=>"ou=departments,ou=distribution lists,ou=groups,dc=nvidia,dc=com" );

Ryan had mentioned in an email reply (thanks) that authentication didn't appear to be working. Running with this code gives me the following error:

User is using a valid domain.
Setting domain as: NVIDIA.COM
Entering getCanonicalName
Username isn't empty.
Munged username: Cvo
Entering authenticate
Entering Connect
Using TLS or not using encryption.
Using servers: ldap://ldap.NVIDIA.COM
Using TLS
Connected successfully
Lowercasing the username: cvo
Entering getSearchString
Doing a proxy bind
Entering getUserDN
Created a regular filter: (sAMAccountName=cvo)
Using base: ou=departments,ou=distribution lists,ou=groups,dc=nvidia,dc=com
Fetched username is not a string (check your hook code...).
userdn is: 
User DN is blank
Entering strict.
Returning true in strict().
Entering modifyUITemplate

Any help would be really appreciated, running dsquery on a separate win2k3 server worked fine with the above username.

This was worked out through email. I'm not sure if it is working now or not, but it was probably going in the right direction. I don't feel like routing through the emails right now though.
--Ryan lane 13:19, 27 March 2007 (UTC)

PHP warning generated by allowPasswordChange

With the latest version there are warnings on Undefined variable: updateLDAP and Undefined variable: mailPassword in allowPasswordChange. The fix is pretty straightforward, the variables need to be initialized!

 		if ( isset($wgLDAPUpdateLDAP[$_SESSION['wsDomain']]) ) {
			$updateLDAP = $wgLDAPUpdateLDAP[$_SESSION['wsDomain']];
		}
		else
		  $updateLDAP = false;

		if ( isset($wgLDAPMailPassword[$_SESSION['wsDomain']]) ) {
			$mailPassword = $wgLDAPMailPassword[$_SESSION['wsDomain']];
		}
		else
		  $mailPassword = false;

A couple other people have mentioned this, and it is in the todo list for version 1.1e. It is already fixed in SVN, you can test it out if you'd like.
--Ryan lane 04:05, 8 April 2007 (UTC)

Domain Group "Doman Users" Required???

I am struggling getting a very restricted user to work with the ldap plugin for mediawiki.

This user only needs to login to the wiki and should not have the ability to logon via a workstation. This user is part of a remote office and does not need anything other than to log into this wiki here.

Users wanted AD permissions - Only part of the associated wiki group and no other groups.

This configuration does not work.

The only time it does work is when I add the domain users group AND set it as the primary group before this user is allowed access to the wiki.

Can I get a hand with this?

Thanks,

Russ

This sounds like an Active Directory issue. I'm not an Active Directory guru by any means (I generally do interoperability with AD, and leave it at that ;)). However, it looks like AD isn't allowing the user to bind. If the user is in the guests group, or in a group that isn't allowed to log in, it is very likely that AD is disallowing all types of authentication. You'll need to find AD documentation for how to allow LDAP binds without allowing system login.
--Ryan lane 13:13, 27 March 2007 (UTC)

Mapping LDAP groups to Wiki groups

(This was lost in the move to mediawiki.org.)

This plugin seems to do a really good work of integrating MW with LDAP! However, I was missing an ability to map LDAP group names to MW groups, and couldn't find out how to do this -- not everyone has or wants to have ldap groups named like 'cn=bureaucrat' in their database.

Hence the following patch, which adds a global configuration option $wgLDAPGroupNameToWikiGroupMap. It can be used like this:

$wgLDAPGroupNameToWikiGroupMap = array("mydomain" => array("mywiki_admin" => array("bureaucrat", "sysop"),
                                                           "mywiki_user" => "user"));
$wgLDAPUseLDAPGroups = array("mydomain" => true);

This makes the LDAP authentication plugin to grant all users in the LDAP groups "mywiki_admin" the "bureaucrat", "sysop" rights, and those in "mywiki_user" the "user" rights. Note that if $wgLDAPGroupNameToWikiGroupMap is present, all groups used by the wiki must be listed in it! (The plugin won't see any LDAP groups not listed.) The mapping does not affect $wgLDAPRequiredGroups, it should still contain full DNs.

The patch (against 1.1d):

--- LdapAuthentication.php
+++ LdapAuthentication.php
@@ -1204,7 +1206,7 @@
        function getGroups( $ldapconn, $dn ) {
                global $wgLDAPBaseDNs;
                global $wgLDAPGroupObjectclass, $wgLDAPGroupAttribute, $wgLDAPGroupNameAttribute;
-               global $wgLDAPProxyAgent, $wgLDAPProxyAgentPassword;
+               global $wgLDAPProxyAgent, $wgLDAPProxyAgentPassword, $wgLDAPGroupNameToWikiGroupMap;

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

@@ -1212,6 +1214,7 @@
                $objectclass = $wgLDAPGroupObjectclass[$_SESSION['wsDomain']];
                $attribute = $wgLDAPGroupAttribute[$_SESSION['wsDomain']];
                $nameattribute = $wgLDAPGroupNameAttribute[$_SESSION['wsDomain']];
+               $group_map = $wgLDAPGroupNameToWikiGroupMap[$_SESSION['wsDomain']];

                //Search for the groups this user is in
                $filter = "(&($attribute=$dn)(objectclass=$objectclass))";
@@ -1238,6 +1241,19 @@
                        $mem = strtolower($i['dn']);
                        $shortnamemem = strtolower($i[$nameattribute][0]);

+                       if ($group_map) {
+                               $shortnamemem = $group_map[$shortnamemem];
+                               if (is_array($shortnamemem)) {
+                                       array_push($groups,$mem);
+                                       foreach ($shortnamemem as $x) {
+                                               array_push($shortnamegroups, $x);
+                                       }
+                                       continue;
+                               } elseif (!$shortnamemem) {
+                                       continue;
+                               }
+                       }
+
                        array_push($groups,$mem);
                        array_push($shortnamegroups,$shortnamemem);
                }

Would this be a useful feature to add to the LDAP auth extension?

Well, this isn't really necessary. You can use any group from LDAP you want, you just need to create that group in your wiki, and give it the appropriate rights. See meta:Help:User rights on how to create new groups in mediawiki, and Extension:LDAP_Authentication#Syncronizing_LDAP_groups_with_MediaWiki_security_groups for syncronizing LDAP groups with wiki groups. I guess I should really write up better documentation on how the group sync stuff works...
--Ryan lane 13:09, 27 March 2007 (UTC)

Users Login successfully via LDAP, but next page view show they aren't logged in

We're using MediaWiki 1.8.2, LDAP authentication 1.1d.

My webserver died, so I setup a new one. Authentication worked perfect on the old web server, and I made absolutely no changes to the mediawiki site files when I restored them from the good backup. So I think it this problem is related to my PHP install (PHP 5.2.1, IIS 6.0). The authentication definitely works, if I get the bad password wrong it tells me. When I login it tells me I've successfully logged on, and I see my username in the top right of the screen, but when I go to any other page from there it shows my IP address at the top instead of my username.

Has anyone run into this problems before? I'd appreciate any advice. - Paul

You may be having session problems. Unfortunately, I'm not a PHP expert, so I don't know how much help I'll be.
--Ryan lane 13:05, 27 March 2007 (UTC)

--160.36.191.167 20:20, 19 April 2007 (UTC) Found the problem, php install added this line to php.ini: session.save_path="C:\DOCUME~1\myusername\LOCALS~1\Temp\php\session" It worked fine after commenting that out and restarting IIS.

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)

Problem with spaces or hyphen or backslash in name

Hi, I'm using MW 1.9. I can get LDAP working but I'm having errors when using group authentication. Whenever I enter a username that has a space in it I get an error (see below).

Here are my confi settings:

$wgLDAPRequiredGroups = array( "domain"=>array("cn=group,ou=ldapgroups,dc=domain,dc=edu") );
$wgLDAPGroupUseFullDN = array( "domain"=>true );
$wgLDAPGroupObjectclass = array( "domain"=>"group" );
$wgLDAPGroupAttribute = array( "domain"=>"member" );
$wgLDAPGroupSearchNestedGroups = array( "domain"=>false );
$wgLDAPBaseDNs = array( "domain"=>"dc=domain,dc=edu" );
$wgLDAPSearchAttributes = array( "domain"=>"sAMAccountName" );

When I login with an account with no spaces it returns the group just fine:

Binded successfully
Entering getUserDN
Created a regular filter: (sAMAccountName=test)
Using base: dc=domain,dc=edu
Fetched username is not a string (check your hook code...).
Pulled the user's DN: CN=test,OU=AZNV,OU=Z_Non Specific Accounts,DC=domain,DC=edu
Checking for (new style) group membership
Entering isMemberOfRequiredLdapGroup
Required groups:cn=group,ou=ldapgroups,dc=domain,dc=edu
Entering getUserGroups
Entering getGroups
Search string: (&(member=CN=test,OU=AZNV,OU=Z_Non Specific Accounts,DC=domain,DC=edu)(objectclass=group))
Returned groups:cn=sjphx_citrix_access,ou=groups,ou=sjphx,ou=aznv,ou=regional_sites,dc=domain,dc=edu

However, whenever I try a regular username (that has Lastname, Firstname) I get an error:

Binded successfully
Entering getUserDN
Created a regular filter: (sAMAccountName=username001)
Using base: dc=domain,dc=edu
Fetched username is not a string (check your hook code...).
Pulled the user's DN: CN=Lastname\, Firstname - User,OU=Users,OU=PHX,OU=AZNV,OU=Regional_Sites,DC=domain,DC=edu
Checking for (new style) group membership
Entering isMemberOfRequiredLdapGroup
Required groups:cn=group,ou=ldapgroups,dc=domain,dc=edu
Entering getUserGroups
Entering getGroups
Search string: (&(member=CN=Lastname\, Firstname - User,OU=Users,OU=PHX,OU=AZNV,OU=Regional_Sites,DC=domain,DC=edu)(objectclass=group))

Warning: ldap_get_entries(): supplied argument is not a valid ldap result resource in /opt/lampp/htdocs/wiki/includes/LdapAuthentication.php on line 1254

Warning: array_shift() [function.array-shift]: The argument should be an array in /opt/lampp/htdocs/wiki/includes/LdapAuthentication.php on line 1257

Warning: Invalid argument supplied for foreach() in /opt/lampp/htdocs/wiki/includes/LdapAuthentication.php on line 1262
Returned groups:

I'm thinking it has a problem with one of the following:

1. The space in the name
2. The hyphen in the name
3. The backslash after the last name (eventhough I don't know how it gets there)

Has anyone else had this issue? Does anyone know of a fix for this? Thank you.

HotMonkeyAC 20:47, 6 April 2007 (UTC)

It is likely the backslash, and that bug will be fixed in the next release (that I'm working on at this current moment ;) ). If you try the alpha version in SVN, this should be fixed.
--Ryan lane 01:51, 8 April 2007 (UTC)

Thanks, that seemed to fix it :) One other question...is there a way to use BOTH LDAP and regular Mediawiki authentication at the same time? -- 162.135.0.6 13:27, 9 April 2007 (UTC)

Yep. $wgLDAPUseLocal = true; it is likely that you'll store domain user passwords in the database though, which some consider a security problem (I do...). The option is mostly meant for transition purposes, but many are using it for local-database+LDAP authentication.
--Ryan lane 13:36, 9 April 2007 (UTC)

LDAP attributes as groups

I'm new to LDAP and I'm trying to set up MediaWiki to only allow editing by users who have an LDAP attribute called "emailGroup" set to "staff". I have LDAP authentication working, but I'm not sure how to configure the group part. Here's what I have so far:

require_once( "$IP/extensions/LdapAuthentication.php" );
$wgAuth = new LdapAuthenticationPlugin();
$wgLDAPDomainNames = array( "university" );
$wgLDAPServerNames = array( "university"=>"ldap1.university.edu"  );
$wgLDAPSearchStrings = array( "university"=>"uid=USER-NAME,dc=university,dc=edu" );
$wgLDAPEncryptionType = array( "university"=>false );
$wgLDAPBaseDNs = array( "university"=>"dc=university,dc=edu" );
$wgMinimalPasswordLength = 1;
$wgShowExceptionDetails = true;

All the examples I've looked at seem to be handling LDAP groups differently. Any hints? Thanks!

Well, there are a bunch of ways to configure groups, so you are likely to see people do it very differently. It looks like you actually want attribute based restriction, and not group based restriction though. This is actually easier to set up. The following should do the trick:

$wgLDAPAuthAttribute = array( "university"=>"(emailGroup=staff)" );

Later on, if you wanted to check for more than just staff, you could do an or based filter like so: (|(emailGroup=staff)(emailGroup=somethingelse))

You are able to use any legitimate LDAP search filter. Realize though that this is going to only apply to attributes that exist on the user.

Also, in your above configuration, you are probably using TLS, because you have the encryption type set to false (which isn't a valid setting).
--Ryan lane 00:05, 11 April 2007 (UTC)

I tried adding the following:

$wgLDAPRequireAuthAttribute = array( "university"=>"true" );

$wgLDAPAuthAttribute = array( "university"=>"(emailGroup=staff)" );

...but it then wouldn't let me in as either staff or student (the debugging showed "Failed auth attribute check.").

I tried changing the $wgLDAPAuthAttribute line to read:

$wgLDAPAuthAttribute = array( "university"=>"!(emailGroup=student)" );

...and that did what I wanted, only letting non-students (ie, staff) log in. While that will work for now, I'm not sure why the first method didn't work. Any clues?

Thank you very much for your help!

I just looked at the code, and noticed that it wraps the filter in () already; try $wgLDAPAuthAttribute = array( "university"=>"emailGroup=staff" ); Maybe it isn't liking the syntax.
--Ryan lane 17:13, 11 April 2007 (UTC)

That did it! Thanks again!

LDAP and AbortNewAccount

I'm a little confused on how the LDAP authentication works with a local instance of the wiki. When a user logs in for the first time (and they've always/already existed/exists in AD), is an account created locally, and as such would be subject to all the hooks of user creation - specifically AbortNewAccount and AddAccount? 68.178.34.180 03:39, 12 April 2007 (UTC)

I think it depends. If you are using auto-authentication (using SSL authentication), then probably not. If using regular authentication, I would imagine it does.
--Ryan lane 13:22, 12 April 2007 (UTC)

Is there a part of the documentation that speaks about this a little more? I believe it is just being used to authenticate against in my setup, but I'm one of two developers, and am not sure how we have it set.

Unless you are using SSL authentication; using some type of PKI certificate, like a smartcard or soft cert; I'm pretty sure you are using regular authentication.

I never deal with the hooks, and as such, can't answer this authoritatively. You probably want to look through SpecialUserlogin.php, User.php, and LdapAuthentication.php, and see for yourself. You could probably just test it too.
--Ryan lane 17:49, 12 April 2007 (UTC)

I guess what I'm not sure on is when a user authenticates against LDAP successfully, are they stored in wikidb_user still, or do they only live in LDAP? I assume this is a setting, I just don't know which one yet, and would like to interject my extension between LDAP auth success and wikidb_user creation.

Ah. I see. I didn't realize you were trying to put an extension in between mine and MediaWiki. When a user authenticates against LDAP, the user is created in wikidb_user still. MediaWiki needs a user since LDAP isn't used as a complete backend (not all user options, and required information is stored in LDAP, just a few). I would imagine that the hooks you want to use will work, as MediaWiki still goes through the normal user account creation process (except in the case of auto-auth).
--Ryan lane 17:28, 13 April 2007 (UTC)

Sorry I haven't been signing my posts, first off. I haven't had a lot of time to play with this in a while, but I wanted to return since I'm still not having any luck. I'm getting the password-change-forbidden error as mentioned in other posts. Do you know how this may be related? It only happens when the account isn't in the local DB, and is blowing my mind to be honest. Thanks for the help. (Eddie) 161.225.1.12 16:06, 1 May 2007 (UTC)

I'm assuming you've read: Extension_talk:LDAP_Authentication#Official_workaround
--Ryan lane 16:20, 1 May 2007 (UTC)

Internal Server Error

Hey there,

Great extension. I'm having a weird issue with an Internal Server Error that some people are getting the first time they login. I'm using 1.1d. It authenticates fine but then seems to fail. Here's what I get...

.......
.......
.......
Authentication passed

Internal error
<password-change-forbidden>

Backtrace:

#0 /opt/lampp/htdocs/wiki/includes/SpecialUserlogin.php(311): User->setPassword('jonasu25')
#1 /opt/lampp/htdocs/wiki/includes/SpecialUserlogin.php(352): LoginForm->initUser(Object(User))
#2 /opt/lampp/htdocs/wiki/includes/SpecialUserlogin.php(407): LoginForm->authenticateUserData()
#3 /opt/lampp/htdocs/wiki/includes/SpecialUserlogin.php(103): LoginForm->processLogin()
#4 /opt/lampp/htdocs/wiki/includes/SpecialUserlogin.php(19): LoginForm->execute()
#5 /opt/lampp/htdocs/wiki/includes/SpecialPage.php(625): wfSpecialUserlogin(NULL, Object(SpecialPage))
#6 /opt/lampp/htdocs/wiki/includes/SpecialPage.php(431): SpecialPage->execute(NULL)
#7 /opt/lampp/htdocs/wiki/includes/Wiki.php(182): SpecialPage::executePath(Object(Title))
#8 /opt/lampp/htdocs/wiki/includes/Wiki.php(47): MediaWiki->initializeSpecialCases(Object(Title), Object(OutputPage), Object(WebRequest))
#9 /opt/lampp/htdocs/wiki/index.php(48): MediaWiki->initialize(Object(Title), Object(OutputPage), Object(User), Object(WebRequest))
#10 {main}

It seems like it only happens the first time they login, and then goes away. Does anyone know of a fix for this? I think it has to do with the line <password-change-forbidden>. Is this the issue that some were saying was fixed in 1.1e? Thanks for your help. HotMonkeyAC 20:33, 18 April 2007 (UTC)

I found the answer - I made the changes to SpecialUserLogin.php and all works well. HotMonkeyAC 21:01, 18 April 2007 (UTC)

What exactly did you change?! I got the same Problem. Can't find a clou.:( Thanks..

SeeExtension talk:LDAP Authentication#Official workaroundfor the fix - HotMonkeyAC 13:05, 19 April 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#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)

Need to update /includes/SpecialUserLogin.php for version 1.10.0rc1?

I noticed that there are a couple changes in the initUser function in includes/SpecialUserLogin.php for version 1.10.0rc1.

Line 320-322 has:

                # Update user count
		$ssUpdate = new SiteStatsUpdate( 0, 0, 0, 0, 1 );
		$ssUpdate->doUpdate();

Has anyone had any issues with this? Does it need to be removed to work with the LDAP Extension? I'd like to roll out MW version 1.10 but don't want to unless it will work correctly. Any ideas Ryan? - HotMonkeyAC 21:19, 1 May 2007 (UTC)

I don't see any reason why this would cause problems. This just updates the statistics; I'd imagine it updates the user count.
--Ryan lane 21:32, 1 May 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)

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)

Windows 2003 Active Directory and LDAP

Ok, I have gone through all the posts and I seem to have tried every config to get mediaWIKI setup to do LDAP authentication. but here is the output from the debug when I try to log in:

Entering authenticate

Entering Connect

Using SSL

Using servers: ldaps://aidc1.cpcuiia.org ldaps://aidc3.cpcuiia.org

Connected successfully

Entering getSearchString

Doing a proxy bind

Failed to bind as cn=Administrator,ou=Service Accounts,ou=cpcuiia,dc=cpcuiia,dc=org

Failed to bind

User DN is blank

Entering allowPasswordChange

Entering modifyUITemplate

It is failing to bind, I am confused. Any ideas? Thanks in advance!

-Wes

-UPDATE: I got this working on my test server so ignore this post, BUTTTT, we I try to apply this to my prod WIKI I get the following error:

Fatal error: Class 'AuthPlugin' not found in C:\Wamp\www\mediawiki\LdapAuthentication.php on line 54

Any ideas??????

-Wes