Extension talk:LDAP Authentication

About - Requirements - Examples - Configuration Options - Changelog - Roadmap - Suggestions - User provided info - FAQ - Support

How to ask for support

There's a couple key pieces of info I always need:

1. The MediaWiki version you are using
2. The LdapAuthentication extension version you are using

I very often will need to see two other things when you ask for support, so you should have them prepared:

1. Your configuration, with sensitive stuff snipped out
2. The extension's debug log, with sensitive stuff snipped out

When you are trying to debug an authentication problem, you should always use the most basic configuration possible. For instance, if you don't have basic authentication working yet, you shouldn't have group restrictions or group synchronization enabled yet. I will generally ask you to disable these things when debugging.

Also, $wgLDAPUseLocal is almost never what you want to use. It's a frequent cause of configuration issues, and unless you really know what you are doing, it should not be set (or explicitly set to false, which is the default).

Most importantly of all: ensure you are using the newest version of the extension. From the extension distributor, that's the "master" version. If you are using git, just make sure you use git pull && git reset --hard origin/master. This is one of the more common cause of problems.

How to submit a bug

If you've found a bug, please submit it here.

Archives

• Archive 1
• Archive 2
• Archive 3

Previous page history was archived for backup purposes at Extension talk:LDAP Authentication/LQT Archive 1 on 2015-07-10.

Hi,
We are using Mediawiki 1.26wmf1 with LdapAuthentication 1.24.
Centos 6.2.
We are trying to authenticate against a Kerberos realm, pulling users from a LDAP v3 directory.
Server apache Kerberos setup is OK. PHP bind to LDAP server works too tested separately.
Configuration /debug follows.
The wiki will not authenticate.
It appears that adding the AutoAuthDomain bit removes the domain chooser. Can't make it work either way.
Must be missing something. Any help appreciated. FYI have tried other encryption types.
Best regards,
Tim.

require_once "$IP/extensions/LdapAuthentication/LdapAutoAuthentication.php";
require_once "$IP/extensions/LdapAuthentication/LdapAuthentication.php";
$wgLDAPDomainNames = array( "rushesfx" );
$wgLDAPServerNames = array( "rushesfx" => "ldap0.rushesfx.co.uk", "rushesfx-kerberos" => "kerberos0.rushesfx.co.uk" );
$wgLDAPEncryptionType = array( "rushesfx" => "clear" );
$wgLDAPSearchStrings = array( "rushesfx" => "uid=USER-NAME,ou=people,dc=rushesfx,dc=co,dc=uk" );
$wgLDAPLowerCaseUsername = array( "rushesfx" => true );
$wgLDAPAutoAuthDomain = "rushesfx-kerberos";
$wgLDAPSearchAttributes = array( "rushesfx" => "uid", "rushesfx-kerberos" => "samaccountname" );
$wgLDAPBaseDNs = array( "rushesfx" => "dc=rushesfx,dc=co,dc=uk", "rushesfx-kerberos" => "dc=rushesfx,dc=co,dc=uk" );
$wgLDAPUseLocal = false;
AutoAuthSetup();

2015-04-10 17:19:16 mediawiki.rushesfx.co.uk mediawiki: 2.1.0 User is not using a valid domain ().
2015-04-10 17:19:16 mediawiki.rushesfx.co.uk mediawiki: 2.1.0 Entering getDomain
2015-04-10 17:19:16 mediawiki.rushesfx.co.uk mediawiki: 2.1.0 Setting domain as: rushesfx
2015-04-10 17:19:16 mediawiki.rushesfx.co.uk mediawiki: 2.1.0 Entering getCanonicalName
2015-04-10 17:19:16 mediawiki.rushesfx.co.uk mediawiki: 2.1.0 Username is: Twharton
2015-04-10 17:19:16 mediawiki.rushesfx.co.uk mediawiki: 2.1.0 Entering getDomain
2015-04-10 17:19:16 mediawiki.rushesfx.co.uk mediawiki: 2.1.0 Munged username: Twharton
2015-04-10 17:19:16 mediawiki.rushesfx.co.uk mediawiki: 2.1.0 Entering getCanonicalName
2015-04-10 17:19:16 mediawiki.rushesfx.co.uk mediawiki: 2.1.0 Username is an IP, not munging.
2015-04-10 17:19:16 mediawiki.rushesfx.co.uk mediawiki: 2.1.0 Entering getCanonicalName
2015-04-10 17:19:16 mediawiki.rushesfx.co.uk mediawiki: 2.1.0 Username is an IP, not munging.
2015-04-10 17:19:16 mediawiki.rushesfx.co.uk mediawiki: 2.1.0 Entering getDomain
2015-04-10 17:19:16 mediawiki.rushesfx.co.uk mediawiki: 2.1.0 Entering userExists
2015-04-10 17:19:16 mediawiki.rushesfx.co.uk mediawiki: 2.1.0 Entering getDomain
2015-04-10 17:19:16 mediawiki.rushesfx.co.uk mediawiki: 2.1.0 Entering getDomain
2015-04-10 17:19:16 mediawiki.rushesfx.co.uk mediawiki: 2.1.0 Entering authenticate for username Twharton
2015-04-10 17:19:16 mediawiki.rushesfx.co.uk mediawiki: 2.1.0 Entering getDomain
2015-04-10 17:19:16 mediawiki.rushesfx.co.uk mediawiki: 2.1.0 Entering getDomain
2015-04-10 17:19:16 mediawiki.rushesfx.co.uk mediawiki: 2.1.0 Entering getDomain
2015-04-10 17:19:16 mediawiki.rushesfx.co.uk mediawiki: 2.1.0 Entering Connect
2015-04-10 17:19:16 mediawiki.rushesfx.co.uk mediawiki: 2.1.0 Entering getDomain
2015-04-10 17:19:16 mediawiki.rushesfx.co.uk mediawiki: 2.1.0 Using TLS or not using encryption.
2015-04-10 17:19:16 mediawiki.rushesfx.co.uk mediawiki: 2.1.0 Entering getDomain
2015-04-10 17:19:16 mediawiki.rushesfx.co.uk mediawiki: 2.1.0 Entering getDomain
2015-04-10 17:19:16 mediawiki.rushesfx.co.uk mediawiki: 2.1.0 Entering getDomain
2015-04-10 17:19:16 mediawiki.rushesfx.co.uk mediawiki: 2.1.0 Using servers:  ldap://ldap0.rushesfx.co.uk:389
2015-04-10 17:19:16 mediawiki.rushesfx.co.uk mediawiki: 2.1.0 Entering getDomain
2015-04-10 17:19:16 mediawiki.rushesfx.co.uk mediawiki: 2.1.0 PHP's LDAP connect method returned true (note, this does not imply it connected to the server).
2015-04-10 17:19:16 mediawiki.rushesfx.co.uk mediawiki: 2.1.0 Entering getSearchString
2015-04-10 17:19:16 mediawiki.rushesfx.co.uk mediawiki: 2.1.0 Entering getDomain
2015-04-10 17:19:16 mediawiki.rushesfx.co.uk mediawiki: 2.1.0 Doing a straight bind
2015-04-10 17:19:16 mediawiki.rushesfx.co.uk mediawiki: 2.1.0 userdn is: uid=twharton,ou=people,dc=rushesfx,dc=co,dc=uk
2015-04-10 17:19:16 mediawiki.rushesfx.co.uk mediawiki: 2.1.0 Entering getDomain
2015-04-10 17:19:16 mediawiki.rushesfx.co.uk mediawiki: 2.1.0 Binding as the user
2015-04-10 17:19:16 mediawiki.rushesfx.co.uk mediawiki: 2.1.0 Failed to bind as uid=twharton,ou=people,dc=rushesfx,dc=co,dc=uk

Does anyone even answer these anymore? 2 years is not good response

Hi

I am trying to get LdapAuthentication extension work with my upgraded MediaWiki. Our previous setup was

Product	Version
MediaWiki	1.24.4
PHP	5.6.30 (apache2handler)
MySQL	5.6.16
Apache	2.4.16
OS	Windows Server 2012R2

The LdapAuthentication worked fine with the above version of MediaWiki.

Once we upgraded to the newer version, and I am getting errors below.

MediaWiki	1.28.0
PHP	7.0.15 (apache2handler)
MySQL	5.6.0
Apache	2.4.25
OS	Windows Server 2012R2

I am trying to run convertExtensionToRegistration.php on LdapAuthentication and I get the following error:

C:\PHP\php.exe : Error: Global functions cannot be converted to JSON. Please move the handler for LoadExtensionSchemaUpdates inside a class.

At line:1 char:1

This does create an extension file but when I run update.php I get the following error:

C:\PHP\php.exe : [2ede5ca9f218d5e8ed5d0e2a] [no req]   MWException from line 176 of E:\Websites\MediaWiki\includes\Hooks.php: Invalid callback 

efLdapAuthenticationSchemaUpdates in hooks for LoadExtensionSchemaUpdates

At line:1 char:1

+ C:\PHP\php.exe .\maintenance\update.php

+ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

    + CategoryInfo          : NotSpecified: ([2ede5ca9f218d5...onSchemaUpdates:String) [], RemoteException

    + FullyQualifiedErrorId : NativeCommandError 

Backtrace:

#0 E:\Websites\MediaWiki\includes\installer\DatabaseUpdater.php(122): Hooks::run(string, array)

#1 E:\Websites\MediaWiki\includes\installer\DatabaseUpdater.php(187): DatabaseUpdater->__construct(DatabaseMysqli, boolean, UpdateMediaWiki)

#2 E:\Websites\MediaWiki\maintenance\update.php(171): DatabaseUpdater::newForDB(DatabaseMysqli, boolean, UpdateMediaWiki)

#3 E:\Websites\MediaWiki\maintenance\doMaintenance.php(111): UpdateMediaWiki->execute()

#4 E:\Websites\MediaWiki\maintenance\update.php(217): require_once(string)

#5 {main}

Can anyone please help with this?

I am also having the same problem on 1.28.

I just realized that upgrading my PHP version from 5.5 to 7 breaks this extension. When I roll back to 5.5 it starts working again. I am using mediawiki 1.28

The error

> Error: Global functions cannot be converted to JSON. Please move the handler for LoadExtensionSchemaUpdates inside a class.

means that in LdapAuthentication.php the hook LoadExtensionSchemaUpdates is used. For this hook, function efLdapAuthenticationSchemaUpdates() is called and the problem with this is, that this function is inside LdapAuthentication.php.

The fix for this error is this:

• Move this function into a different file and there put it inside a class.
• Then adjust the hook definition so that it is calling the class function.

Why would you run convertExtensionToRegistration.php? Are you a developer and want to contribute to code base of the extension? Because this script is not meant to be run as part of a setup. It is a development tool to ease code migration.

LdapAuthentication should run with MediaWiki 1.28 even though it does not have an extension.json file. You just need to use the old require_once instead of wfLoadExtension.

When using PHP7, are there any error_log entries that give a hint on what exactly goes wrong?

I'm seeing this error as well. I'm getting "Failed to bind" error in the debug for the extension. I'm using php7.0 and mediawiki 1.27. Was working just fine couple weeks ago. I did just update so not sure if a newer version of php7 is breaking something.

wfLoadExtension() is the new way of loading extensions and plan is to one day remove support for the old require_once() way of doing things. Using convertExtensionToRegistration.php is the recommended way of bringing an extension up to date again. As already note above:

• Move this function into a different file and there put it inside a class.
• Then adjust the hook definition so that it is calling the class function.

That definitely is a step in the right direction and possibly already is enough to get the migration to wfLoadExtension() working for this extension.

That's totally true but makes only sense if this change finds its way back to the upstream. So please, if you successfully migrate to extension.json commit that change to the code review process of the extension.

Whenever I try to login, it displays a message, "Incorrect password entered. Please try again.".

I am using PHP 5.5.38 and upgraded to Mediawiki 1.28.0 version.

Mediawiki isn't compatible with MediaWiki 1.28 at present. The main problem is AuthManager.

Please let us know if this issue with compatibility will be resolved

I'm interested as well. Trying to upgrade from 1.23 and this one's a blocker. Happy to test anything you can come up with.

Ryan lane is the Author of LDAP Authentication but no answer.

That means if I am upgraded to Mediawiki 1.28, I can't use LDAP authentication i.e. I cant login my application which uses mediawiki 1.28. Is my understanding correct on this?

I am running Debian and using official Debian packages repo. After upgrade from Debian Jessie to Stretch, surprisingly, the package mediawiki-extensions-base has disappeared from Stretch, so its Jessie version has just been removed, including the Ldap extension.

That made MW corrupted of course. Current Debian package delivers 1.27.3 version of mediawiki in Debian Stretch, and apparently everyone who upgraded has to manually hack the .php files to

- no more include the removed extensions (to fix warning)

- manually download removed extensions like this Ldap one, and hack LocalSettings.php to load them

... currently I am stuck with Ldap extension, experiencing same problem as in the title of this topic. After the hacks, I ran the udpate.php eventually, even restarted apache, but still, when looking into mediawiki's SQL db ("wiki"), the table "ldap_domains" is empty. Only local accounts work.

What is the point with "AuthManager problem", is it what this commit talks about?

extension for mediawiki 1.28

I'm getting closer to figuring this out, but stuck on automatically creating accounts. Here's my current (sanitized) configuration. I can authenticate, but I then get the message:

Auto-creation of a local account failed: Automatic account creation is not allowed.

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

$wgLDAPDebug = 3;
$wgDebugLogGroups['ldap'] = '/tmp/debug.log';

$wgLDAPDomainNames       = array('LOCAL');
$wgLDAPServerNames       = array('LOCAL' => 'local-dc2.local.domain');
$wgLDAPEncryptionType    = array('LOCAL' => 'clear');
$wgMinimalPasswordLength = 1;
$wgLDAPBaseDNs           = array('LOCAL' => 'ou=Users,ou=LOCAL,dc=domain,dc=local');

$wgLDAPSearchStrings     = array('LOCAL' => 'LOCAL\\USER-NAME');
$wgLDAPSearchAttributes  = array('LOCAL' => 'sAMAccountName' );

$wgLDAPDisableAutoCreate = array('LOCAL' => false);

Any help would be greatly appreciated!

currently I am using Centos 7.3, MySql 5.7 and PHP 7.1 LDAP TLS

LdapAuthentication: REL1_28 2016-11-18T19:08:52 770c89e

in /etc/openldap/ldap.conf

I add

TLS_REQCERT allow    

TLS hard

and LocalSettings.php setting

$wgLDAPEncryptionType  = array('domain.com' => 'tls');

at this point cannot authenticate

so i tweak and change some code in LdapAuthenticationPlugin at line 547

if ( !ldap_start_tls( $this->ldapconn ) ) {

add @

if ( !@ldap_start_tls( $this->ldapconn ) ) {

for autocreation, I stuck at /includes/auth/AuthManager.php between line 1612 and 1626

// Is the IP user able to create accounts?

$anon = new User;

/*

if ( !$anon->isAllowedAny( 'createaccount', 'autocreateaccount' ) ) {

.....

}

*/

comment out this block, now working. (need better solution rather than comment out)

for group permission

# Implicit group for all visitors

$wgGroupPermissions['*']['createaccount'] = false; // ??? not working

$wgGroupPermissions['*']['autocreateaccount'] = false;  // ???

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

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

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

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

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

Same here. Any help is appreciated. My config:

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

$wgAuth = new LdapAuthenticationPlugin();

$wgLDAPDomainNames = array("iRedMail");

$wgLDAPServerNames = array("iRedMail" => "192.168.XX.XX");

$wgLDAPPort = array("iRedMail" => 389);

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

$wgLDAPBaseDNs = array( "iRedMail"=>"o=domains,dc=example,dc=com");

$wgLDAPProxyAgent = array("iRedMail"=>"cn=vmail,dc=example,dc=com");

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

$wgLDAPUserBaseDNs = array( "iRedMail"=>"o=domains,dc=example,dc=com");

$wgLDAPSearchAttributes = array( "iRedMail" => "mail");

$wgLDAPLowerCaseUsername = array( "iRedMail"=>true);

$wgLDAPUseLocal = true;

$wgLDAPDebug = 3;

$wgDebugLogGroups['ldap'] = '/tmp/debug.log';

Same issue

FWIW, I finally got it working. Not sure what the difference is here... the $wgGroupPermissions item is not listed on the LDAP extension instructions, but I think this is what did it.

require_once ("$IP/extensions/LdapAuthentication/LdapAuthentication.php");
$wgAuth = new LdapAuthenticationPlugin();
#$wgLDAPUseLocal = true;
$wgLDAPDomainNames       = array('LOCAL');
$wgLDAPServerNames       = array('LOCAL' => 'local-dc2.mydomain.local');
$wgLDAPEncryptionType    = array('LOCAL' => 'clear');
$wgMinimalPasswordLength = 1;
$wgLDAPBaseDNs           = array('LOCAL' => 'ou=Users,ou=LOCAL,dc=mydomain,dc=local');
$wgLDAPSearchStrings     = array('LOCAL' => 'LOCAL\\USER-NAME');
$wgLDAPSearchAttributes  = array('LOCAL' => 'sAMAccountName' );
$wgLDAPRetrievePrefs     = array('LOCAL' => true );
$wgGroupPermissions['*']['autocreateaccount'] = true;

I tried with that TroySettle but not luck. I receive same fails, what versions do you have installed? (Mediawiki and LDAP please) Thanks.

Did you create Wiki as Open? private?

NOTE: I solved using wiki 1.23 version.

I had to set $wgGroupPermissions['*']['createaccount'] = true;

That still did not work for me.

My other anonymous permissions are set to false.

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

I want this to be a private wiki.

It would seem I had to clear all session data and remove cookies from previous logon attempts with my test user as well as comment out self::saveDomain( $user, $_SESSION['wsDomain'] ); from one of the extension's configuration files. It now works.

I had this problem, too. In my case, the solution was the one that has already been mentioned above:

1. switch back to local auth in LocalSettings.php; then login with a *local* admin/bureaucrat account (the one you set up when installing the wiki).

2. create a local user with the same name as one that exists in LDAP (give him a bullsh*t password, no need to match the LDAP one). Not mandatory, but if you are smart, this user should be a bureaucrat as you need at least one LDAP-based bureaucrat anyways. Lets call this user "Ldapboss".

3. switch again to LDAP auth in LocalSettings.php; then login with the user Ldapboss you just created. Of course you need to use the user's actual LDAP password this time. Btw, your local admin is now locked out of the system (unless you set wgLDAPUseLocal to true). This is why you need an LDAP-based bureaucrat.

From this point on, weirdly enough, auto account creation works. It's like, you need at least one successful login to make it work. Not sure why, doesn't make sense.

Ask a colleague to log on, or alternatively, rename your Ldapboss user to Ldapboss_Trash (Renameuser extension) and logout. Then login again with Ldapboss using again the LDAP credentials. Now, you Ldapboss is auto-created (this time as a simple user, as it should).

Actually, on Ryan D Lane (creator and ex-maintainer of the plugin) has this written on a 2009 blog post --- Quote:

"Before enabling the plugin, you should create a user in the local wiki database that exists in AD, and promote that user to sysop. After the plugin is enabled, you will not be able to log in as any user who does not exist in AD."

Hi,

While I executed step 3, then use Ldapboss login with LDAP password, I got the following error:

[WMFhIqwRAAIAABOptNUAAAAG] 2017-03-09 14:05:24: Fatal exception of type "DBQueryError"

Is it normal?

But it looks I have already logged in.

Hi,

Any news on Brain Wang's problem? I experience the same issue. The user seems to be logged in, however logging in with an other user from LDAP still fails.

Today I ran into the same issue, and found that the LDAP plugin does not have the right to autocreate users, despite the allowed autocreateaccount Group Permission setting. Then I found that the referred table (ldap_domains) did not exist in the database (and thus throwing the authmanager-autocreate-noperm errors). Creating the table in the right database based on the extensions/LdapAuthentication/schema/ldap-mysql.sql seems to fixed the issue:

# mysql -u root -p

Enter password:

mysql> use my_wiki

Reading table information for completion of table and column names

You can turn off this feature to get a quicker startup with -A

Database changed

mysql> CREATE TABLE ldap_domains (domain_id int not null primary key auto_increment,domain varchar(255) binary not null,user_id int not null);

Query OK, 0 rows affected (0.00 sec)

This worked for me. Thanks

I am running a private Wiki

$wgGroupPermissions['*']['autocreateaccount'] = true;

fixed it for me. If you read the changelog of 1.27:

* MediaWiki will now auto-create users as necessary, removing the need for

  extensions to do so. An 'autocreateaccount' right is added to allow

  auto-creation when 'createaccount' is not granted to all users.

I resolved the problem by setting the $wgGroupPermissions['*']['autocreateaccount'] = true but also assigning CHMOD permissions to all .php files in /mediawiki to 777 for the local account I was using.

New install with Mediawiki 1.29 on Ubuntu 16.04 (PHP 7.0.18; apache2 2.4.18).

From Apache logs:

PHP Fatal error:  Uncaught Exception: /var/www/wiki/extensions/LdapAuthentication/extension.json does not exist! in /var/www/wiki/includes/registration/ExtensionRegistry.php:99

The following is also a failure (similar to the "LDAP Authentication extention to registration not working" post):

/var/www/wiki# php maintenance/convertExtensionToRegistration.php  extensions/LdapAuthentication/LdapAuthentication.php

Follow the instructions in Extension:LDAP Authentication/Examples about how to configure it in LocalSettings, don't use wfLoadExtension

However, i am not expecting that the extension works. Accoding to the warning MW 1.27+ is not compatible with it.

The extension should basically be working:

• wfLoadExtension() does not have to be used. You can still use require_once() to load the extension.
• According to the warning, only automatic authentication is not supported in MW 1.27 and newer. The rest should be working just fine.

And patches are definitely welcome!

Many thanks. Changing to require_once() and running the update.php script (to address a db error after login) seems to have cleared up the issues.

The problem and an idea of the solution is described at Topic:Tlz6fw5aasbglko8! See there for more details!

Version : Mediawiki 1.25.5 ----- PHP 5.5.38(apache2handler) ------ MySQL 5.7.15-log

Problem:

Unable to login using LDAP authentication extension.

Description:

While logging in, on entering username, password and domain from a drop down menu, after clicking on submit button, I am getting an error message--> 'Incorrect password entered. Please try again later' .

The url on which I want to use LDAP authentication is SSL enabled.

Please suggest on what the problem may be?

Check the Apache logs for the error occurring on the server side. For example, Mediawiki might be failing to load the ldap authentication module when you try to log in. This module does not yet seem to comply with the way that modules are called upon in newer versions of Mediawiki (lacks extensions/LdapAuthentication/extension.json) and trying to generate the extension.json file with the maintenance/convertExtensionToRegistration.php script also fails.

> trying to generate the extension.json file with the maintenance/convertExtensionToRegistration.php script also fails.

How is it failing? Is there an error message?

The problem and an idea of the solution is described at Topic:Tlz6fw5aasbglko8! See there for more details!

I saw many problems here about running LDAP Authentication with newer versions of MW. Especially in companies this feature is a very important requirement for the use of a Wiki. The description page gives the impression that the plugin is discontinued and that there is no acitivity to make it running again. It would be really important if someone with expertise could clarify at the descriptions page what users that want to use newer MWs should do and what are the future plans if there are some.

I use Mediawiki 1.27.3. LDAP authentication is required but since we upgraded the error "Automatic account creation is not allowed" occured for new LDAP users.

We used to authenticate using LdapAuthenticationPlugin() in LocalSettings.php, but since this is deprecated, the correct way to fix it would be using AuthManager, like below:

$wgAuthManagerAutoConfig['primaryauth'] += [

    LdapPrimaryAuthenticationProvider::class => [

    'class' => LdapPrimaryAuthenticationProvider::class,

    'args' => [ ['authoritative' => true, ] ],

    'sort' => 50,    ],

];

However, this didn't work for us, since it couldn't authenticate with the LDAP server (according to our logs). We even set the following in our LocalSettings:

$wgGroupPermissions['*']['autocreateaccount'] = true;

That didn't work either, *until* we restarted our apache service. So, keep in mind that you need to do that.

That is a temporary fix in my opinion, until AuthManager is updated so that it works with LDAP. Hope this helps...

Versions: Mediawiki 1.27.1, LDAPAuth 2.1.0 (Translate: MLEB 2017.01)

Problem:

I want to use this Extension and Extension:Translate, but: I cant publish Translations as long as LDAP_Authentication is active. This seems to be because LDAP_Authentication prevents the use of Translates Fuzzybot according to the php error log:

 UnexpectedValueException from line 273 of [base]\includes\auth\AuthPluginPrimaryAuthenticationProvider.php: AuthPlugin failed to reset password for Fuzzybot in the following domains: [all Domains]

According to Topic:Tfu65b5pncef5p6s this should work, but it doesn't:

$wgAuthManagerAutoConfig['primaryauth'] += [

    LdapPrimaryAuthenticationProvider::class => [

    'class' => LdapPrimaryAuthenticationProvider::class,

    'args' => [ ['authoritative' => true, ] ],

    'sort' => 50,    ],

];

What can I do?

Did you ever find a solution? I'm stuck in the exact same place.

I'm currently thinking about setting up a parallell wiki (accessing the same Database) without LDAP for Translators.

But that sucks because i'm pretty sure that would lead to some sort of conflict eventually...

I abandoned LDAP_Authentication. Instead I migrated to PluggableAuth+OpenId extensions married to Google Auth, which our organization also uses. Much better and easier configuration than LdapAuth. Now users are auto-logged in just by visiting our private wiki.

In my setup the direct use of $_SESSION['wsDomain'] at line 1237 of LdapAuthentication.php causes problems: Im my case there sometimes is a token but the wsDomain-member of the $_SESSION array is not (yet) set.

Looking through the code I came up with this solution:

diff --git a/LdapAuthentication.php b/LdapAuthentication.php
index 44e47d4..462f9c9 100644
--- a/LdapAuthentication.php
+++ b/LdapAuthentication.php
@@ -1234,7 +1234,7 @@ class LdapAuthenticationPlugin extends AuthPlugin {
                # We must set a user option if we want token based logins to work
                if ( $user->getToken( false ) ) {
                        $this->printDebug( "User has a token, setting domain in user options.", NONSENSITIVE );
-                       self::saveDomain( $user, $_SESSION['wsDomain'] );
+                       self::saveDomain( $user, $this->getDomain() );
                }
 
                # Let other extensions update the user

I think this is the correct way of doing it especially after reading the comments in getDomain(). :-)

What do you think?

Hi Hermann, You are 100% right - I totally agree with your saying. The $_SESSION['wsDomain'] cannot be use at that moment. It is better to use $this->getDomain()

By doing so the extensions works as expected.

- Michael