LDAPAuthentication

This page is devoted to the LDAPAuthentication plugin and it's implementation and failure as part of the upgrade to mediawiki 1.25.1

It has been stable since 2012 and should probably be watched during future upgrades for loss of functionality as the developers give it less intensive attention.

Notice: Undefined index: IC in /var/www/html/mediawiki-1.25.1/extensions/LdapAuthentication/LdapAuthentication.php on line 1046 Fatal error: Call to a member function toString() on a non-object in /var/www/html/mediawiki-1.25.1/includes/User.php on line 3639 

I have set up a debug log for the ldap plugin. I have also added some PHP trace code ( ... in LdapAuthentication.php )to let me see what it is doing. The result is that, for the most part, it seems to be doing what is expected.

It identifies the user and the Domain. It authenticates and binds to AD. It then tries to send the result into the bowels of the mediawiki code.

This is the code that produces the Fatal error which complains that it cannot call a member function for an object which (for whatever reason) it cannot find.

I have read through the plugin documentation in case the problem might lie in some subtlety of configuration. The basic configuration is solid, and though I have tried various configuration tweaks, none have made a difference so far. If there is a configuration issue, then it is more subtle than I can see at this point.

It is not yet clear if an object is unsuccessfully sent or unsuccessfully received. I will try and extract some output to tell us if the plugin no longer speaks LDAP, or the wiki no longer speaks plugin.

For information: Local user account creation is currently disabled. It could be enabled if current work flows would not be comprised.

Local user accounts DO clash with similarly named LDAP accounts.

User accounts are listed in the table called user. Column 'user_id' is the internal numeric key and column 'user_name' contains the login name.

There appears to be a schema change that is absent from the existing wiki, which relates to ldapauthentication. I have added the following code which was present in a subdirectory of the LdapAuthentication plugin extension. This table collects 'user_id's for domain (LDAP) accounts for some mysterious purpose.

CREATE TABLE /*_*/ldap_domains (
	-- IF for domain
	domain_id int not null primary key auto_increment,

	-- domain itself
	domain varchar(255) binary not null,

	-- User to which this domain belongs
	user_id int not null

) /*$wgDBTableOptions*/;

CREATE INDEX /*i*/user_id on /*_*/ldap_domains (user_id);

Flushed and restarted sssd

New AD Logins still fail.

Addendum: This may not have actually failed. A few hours after the change was made, I logged in successfully with my AD test account. Asked, the holder of one of the problematic accounts to login, and it worked. Tried a second pristine AD account and that worked. My notes above mention sssd but not a full restart of services. I cannot remember if I did this at the same time. But definitely several times afterwards while pursuing other testing. Possibly the restart triggered new behaviour.

so, summary ...

The testing showed that the ldaputhentication plugin was authenticating as expected, the handover to the wiki was failing because of the missing table. Unfortunately no exception was thrown to signal that the table was missing, hence the first error we saw (Fatal error: Call to a member function toString() on a non-object) was one step on, from the native wiki code which (paraphrased) announced it had not received the object it was expecting. So, the previous conjecture is completed with 'object is unsuccessfully sent' and a third option to explore 'plugin no longer speaks wiki!'.

Current status working!

Final clean up

delete /tmp/debug.log for the plugin (contains authentication info) and edit LocalSettings.php to reduce debug level to 1

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