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

How do I grant SysOp privileges to a certain LDAP group?

Let's say that in my LDAP server I have a group called "trainers". Of all the members of that group there are a select few that are also in a group called "aces". In other words, all users that are in the group "aces" are also in "trainers" but not all "trainers" are "aces".

I have my MediaWiki set up so that you cannot create a new account and that only and all "trainers" are able to log in using LDAP Authentication. However, now I want "aces" to have SysOp privilege without the Bureaucrat manually granting each "ace" the privilege using the interface.

How do I go about doing this? 134.223.230.151 (talk) 02:31, 10 January 2019 (UTC)

You can use group mapping and set group permissions. Smth like:

$wgLDAPUseLDAPGroups = array(

'testADdomain' => true,

);

$wgGroupPermissions['aces']['edit'] = true;

$wgGroupPermissions['aces']['delete'] = true;

$wgGroupPermissions['aces']['move'] = true;

... Urfiner (talk) 16:55, 7 February 2019 (UTC)

BadMethodCallException

When try to get LDAP working with AD I am getting this BadMethodCallException on the logon page when I try to log on.

I installed veresion 1.32 of mediawiki on Windows with PHP 7.3 enabled ldap. I kept the ldap setting the same as my previous wiki installation which used to work (version 1.24). However it does not look like the extension is loading?

My entry :

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

$wgAuth = new LdapAuthenticationPlugin();

When I get to the logon page it is not showing my ad domain which it used to show on the previous version?

196.35.254.180 (talk) 12:39, 11 February 2019 (UTC)

Please try the new LDAP extensions. Major changes were made to authentication around MW 1.27. ☠MarkAHershberger☢(talk)☣ 17:02, 11 February 2019 (UTC)

Ldap Authentication on Mediawiki V1.32

Anyone got this working yet? 2A00:18C8:3E27:3012:8002:DB88:3E26:B009 (talk) 10:21, 12 February 2019 (UTC)

Works just fine after upgrade from mw 1.31 Urfiner (talk) 08:49, 8 March 2019 (UTC)

User DN is blank

Hi! I installed the Extension on my MediaWiki 1.32 running on Xampp (PHP 7). Setup the configs as following:

$wgLDAPDomainNames = array(

  'MYDOMAIN',

);

$wgLDAPServerNames = array(

  'MYDOMAIN' => 'MYLDAPSERVER',

);

$wgLDAPEncryptionType = array(

  'MYDOMAIN' => 'ssl',

);

$wgLDAPSearchAttributes = array(

  'MYDOMAIN' => 'sAMAccountName',

);

$wgLDAPBaseDNs = array(

  'MYDOMAIN' => 'DC=manz,DC=lc',

);

$wgLDAPGroupBaseDNs = array(

'MYDOMAIN' => 'OU=DE,OU=RT,OU=User,DC=MYDOMAIN,DC=lc',

);

$wgLDAPUserBaseDNs = array(

'MYDOMAIN' => 'OU=DE,OU=RT,OU=User,DC=MYDOMAIN,DC=lc',

);

There is an actual domain name and the ip for the LDAP Server,however for privacy reasons I would like to hide them. It seems like there is a connection established, however the Extension can not find the user. Log tells me:

2019-03-04 10:22:34 WINWIKI x: 2.1.0 Couldn't find an entry

2019-03-04 10:22:34 WINWIKI x: 2.1.0 userdn is:

2019-03-04 10:22:34 WINWIKI x: 2.1.0 User DN is blank

195.85.237.130 (talk) 10:26, 4 March 2019 (UTC)

I got it to work, the problem was actually that a proxy user was needed in order to do the search. 195.85.237.130 (talk) 11:58, 4 March 2019 (UTC)

How did you configured your Proxy? Like in the docs?

$wgLDAPProxyAgent = array(

'testLDAPdomain' => 'cn=proxyagent,ou=profile,dc=LDAP,dc=example,dc=com',

);

$wgLDAPProxyAgentPassword = array(

'testLDAPdomain' => 'S0M3L0ngP@$$w0r6ofS0meV@rie222y!',

);

80.157.191.124 (talk) 06:41, 21 March 2019 (UTC)

Mapping LDAP Groups to Wiki Groups

I did not quite understand how the mapping works. We have a lot of Wiki AD Groups, e.g(Public_C and Public_E etc.)

How do I tell the config that I want one of that group to match another group in the wiki that is called different? 195.85.237.130 (talk) 12:00, 4 March 2019 (UTC)

Looks like you cannot map groups if group names are different in wiki and AD. Urfiner (talk) 08:48, 8 March 2019 (UTC)

Username with _ fails to connect

Upgrade path from 1.23 to 1.31?

I know this is not fully supported on 1.31, but this extension is the only thing that does what we need and I'm trying to make it work. We are running RHEL6, with the software collections apache 2.4 and php7.0. This combo is needed for our other websites, and the wikis happen to live on the same server. But this combo doesn't work with mediawiki + LdapAuthentication, and the current "replacement" is not functional in any way.

So my question is: do I need to update in steps from 1.23 to 1.31 to make this work? Or is it ok to upgrade straight to 1.31? Has anyone gotten this path to work before? 192.150.187.199 (talk) 23:44, 10 April 2019 (UTC)

You can upgrade mediawiki straight to 1.31 Ciencia Al Poder (talk) 09:13, 11 April 2019 (UTC)

No, I cannot upgrade straight to 1.31 with ldap Authentication installed. I am asking if I need to take an intermediate step to make this extension work, not whether the mediawiki base install can be upgraded. 192.150.187.199 (talk) 17:44, 12 April 2019 (UTC)

Please use the replacement at LDAP hub. ☠MarkAHershberger☢(talk)☣ 17:28, 16 April 2019 (UTC)

Query: INSERT INTO `ldap_domains` (domain,user_id) VALUES (NULL,'2') Function: LdapAuthenticationPlugin::saveDomain Error: 1048 Column 'domain' cannot be null (127.0.0.1)

After upgrading Mediawiki und LDAP extension from 1.26 to 1.32.1 I have a problem to login whith the ldap extension. I use one Domain.

The following SQL shows, that there is no domain to insert into the table.

Query: INSERT INTO `ldap_domains` (domain,user_id) VALUES (NULL,'2')

Function: LdapAuthenticationPlugin::saveDomain

Error: 1048 Column 'domain' cannot be null (127.0.0.1)

Is there somebody who has the same error and an solution? 139.18.118.1 (talk) 12:47, 6 May 2019 (UTC)

LDAP Using CentOS7 (Active Directory)

Hello everyone,

Feel like I'm going crazy. Installed MediaWiki on a brand new CentOS7 VM (iso 1810).

MediaWiki version 1.32.0

MariaDB10.3.14

PHP version 7.3.5

Got the LDAP extension off this website, created a folder called LdapAuth under /extensions

Installed php-ldap

composer install --no-dev

Added the following settings to my LocalSettings.php (and tried countless variaties on this):

#added by me

require_once ('/var/log/www/html/extensions/LdapAuth/src/Auth/LdapAuthenticationRequest.php');

require_once ('includes/AuthPlugin.php');

wfLoadExtension( 'LdapAuth' );

$wgAuth = new AuthPlugin()

$wgLDAPDomainNames = array('mytest.lan');

$wgLDAPServerNames = array('mytest.lan' => 'ad01.mytest.lan');

$wgLDAPSearchAttributes = array('mytest.lan' => 'sAMAccountName');

$wgLDAPBaseDNs = array('mytest.lan' => 'dc=mytest,dc=lan');

$wgLDAPAuthEncryptionType = array('mytest.lan' => 'false');

$wgLDAPPort = array('mytest.lan' => '389');

$wgLdapAuthIsActiveDirectory = true;

$wgMinimalPasswordLength = 1;

#Debugging options

$wgShowExceptionDetails = true;

$wgLDAPDebug = 3

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

This and all kinds of variaties but to no success.

- I don't see packets incoming on the domain controller except DNS. DNS-resolving itself works fine and there are no ACL's between the two machines.

- The logging for whatever reason does not work. I turned off SELinux to make sure it isn't blocking anything but no luck. Gave the /tmp/debug.log all access for the time being but still nothing is being written to it.

- Documentation says to make sure /etc/php.d/ldap.ini has the line containing: extension=ldap.so

This is not entirely the case, this OS had: /etc/php.d/20-ldap.ini containing the line extension=ldap (so without the.so, though I changed that as well but it did not help)

- put the following line in /etc/openldap/ldap.conf: TLS_REQCERT never

Ran the maintenance/update.php after pretty much every change as well restarting the httpd (and the server itself at times).

But whenever I try to logon with a domainuser It just tells me "username or password is not correct". Truly at a loss. The same settings work fine on Zabbix => Active Directory authentication. 185.46.212.117 (talk) 14:41, 8 May 2019 (UTC)

Hi,

From a fresh CentOS 7 install too (CentOS Linux release 7.6.1810), here is what I did and it works like a charm :

Download LdapAuthentication extension :

[root@myserver ~]# wget -O downloads/LdapAuthentication-REL1_32-e2cab88.tar.gz https://extdist.wmflabs.org/dist/extensions/LdapAuthentication-REL1_32-e2cab88.tar.gz

Extract archive file in the mediawiki extensions directory :

[root@myserver ~]# tar -xzf downloads/LdapAuthentication-REL1_32-e2cab88.tar.gz -C /data/www/mediawiki/current/extensions

Add the following configuration options in the /data/www/mediawiki/current/LocalSettings.php file :

## Beginning of LDAP Authentication/AD Configuration
require_once ("$IP/extensions/LdapAuthentication/LdapAuthentication.php");
$wgAuth = new LdapAuthenticationPlugin();
$wgLDAPDomainNames = array(
  'adomainname'
);
$wgLDAPServerNames = array(
  'adomainname' => 'myADserver.mydomain.local'
);
$wgLDAPSearchStrings = array(
'adomainname' => 'USER-NAME@myreal.domain' // <== to be sure of this value, you can view a record in you AD and compare
);
$wgLDAPEncryptionType = array(
  'adomainname' => 'clear'
);
$wgLDAPUseLocal = false;
$wgMinimalPasswordLength = 1;
$wgLDAPBaseDNs = array(
  'adomainname' => 'DC=mydomain,DC=local'
);
$wgLDAPSearchAttributes = array(
  'adomainname' => 'sAMAccountName'
);
$wgLDAPRetrievePrefs = array(
  'adomainname' => true
);
$wgLDAPPreferences = array(
  'adomainname' => array(
    'email' => 'mail',
    'realname' => 'displayName',    // <== adapt with you needs
    'nickname' => 'samaccountname'
  )
);
$wgLDAPProxyAgent =  array(
  'adomainname' => 'CN=myserviceaccount,OU=serviceaccounts,DC=mydomain,DC=local'
);
$wgLDAPProxyAgentPassword = array(
  'adomainname' => 'myservicepassword'
);
$wgLDAPDisableAutoCreate = array(
  'adomainname' => true
);
$wgLDAPGroupUseFullDN = array(
  'adomainname' => true
);
$wgLDAPLowerCaseUsername = array(
  'adomainname' => true
);
$wgLDAPGroupObjectclass = array(
  'adomainname' => 'group',
);
$wgLDAPGroupAttribute = array(
  'adomainname' => 'member',
);
$wgLDAPGroupNameAttribute = array(
  'adomainname' => 'cn',
);
$wgLDAPGroupsUseMemberOf = array(
  'adomainname' => false,
);
$wgLDAPUseLDAPGroups = array(
  'adomainname' => true,
);
$wgLDAPRequiredGroups = array(
  'adomainname' => array(
    'CN=MyReserverGroup,OU=IT,OU=Users,DC=mydomain,DC=local',
)
);
$wgLDAPGroupsPrevail = array(
  'adomainname' => true,
);
$wgLDAPGroupSearchNestedGroups = array(
  'adomainname' => true,
);
$wgLDAPActiveDirectory = array(
  'adomainname' => true,
);
$wgLDAPAuthAttribute = array(
  'adomainname' => '!(userAccountControl:1.2.840.113556.1.4.803:=2)',
);
$wgHooks['SetUsernameAttributeFromLDAP'][] = 'SetUsernameAttribute';
function SetUsernameAttribute(&$LDAPUsername, $info) {
        $LDAPUsername = $info[0]['samaccountname'][0];
        return true;
}
$wgLDAPDebug = 1; //for debugging LDAP
## End of LDAP Authentication/AD Configuration

Go to your mediawiki instalaltion directory and run the following command in order to adapt you BDD to this new extension :

[root@myserver ~]# cd /data/www/mediawiki/current/
[root@myserver current]# php7 maintenance/update.php
MediaWiki 1.32.0 Updater
Your composer.lock file is up to date with current dependencies!
Going to run database updates for mediawiki_db
Depending on the size of your database this may take a while!
..................................
Attempted to insert 0 IP revisions, 0 actually done.
Purging caches...done.
Done in 2.7 s.

Jordan LE NUFF (talk) 08:48, 13 May 2019 (UTC)

SSL on RHEL8

I have been using LDAP Authentication with LDAPS without any issues for many years. I'm now trying to use the same configuration on a RHEL8 server and cannot get it to work. The debug log isn't very helpful, it just says "failed to bind". When using "clear" option, everything works, so I know it's something with SSL. Certificates are fine because they are set up identical to a RHEL7 where everything is working.

Does anyone has any idea? 162.96.9.2 (talk) 21:11, 13 June 2019 (UTC)

$wgAuth removed in MediaWiki 1.33

I'm currently on MediaWiki 1.32.2 and using the LDAP Authentication extension version REL1_32-e2cab88 - everything works fine.

I have a pretty simple setup - connection to one Active Directory server using ssl, restricting users that are able to login to a certain AD group.

As of 7/3/19 the current stable MediaWiki version is now 1.33.

I tried to upgrade and use the LDAP Authentication extension version REL1_33-d82149e with the same ldap settings that were working on 1.32 and REL1_32-e2cab88, but it does not work.

The version REL1_33-d82149e has some accommodations for the new mediawiki version - the update.php script runs without errors.

But it seems like the extension is completely ignored by mediawiki - users can login using the local user credentials, but the login does not work with login credentials from Active Directory.

The logs are also missing despite using $wgLDAPDebug, $wgDebugLogGroups configuration variables.

My guess is that this is caused by the removal of the $wgAuth variable (as stated in the release notes for mediawiki 1.33).

The newer configuration variables for authentication purposes are now $wgAuthManagerAutoConfig or $wgAuthManagerConfig.

The problem is that i don't know how to configure these variables or if they are supported by the LDAP Authentication extension at all.

The configuration examples are still using the old variable $wgAuth.

Did someone figure out how to configure this extension to work with MediaWiki 1.33 and can help out? 81.14.176.5 (talk) 09:45, 4 July 2019 (UTC)

Could you look at the LDAP hub. It says it is in draft, but people have successfully been using those new extensions for a while now. ☠MarkAHershberger☢(talk)☣ 18:22, 4 July 2019 (UTC)

I can confirm this issue. I've got freshly installed 1.33 mediawiki and LDAP_Authentication extension is not working at all. There is no errors from update.php script and I've tried different configuration options in LocalSettings.php but no success. It looks like this extension is not activated at all. Any advice? 2001:67C:2344:50:0:0:0:85 (talk) 09:32, 8 July 2019 (UTC)

I have exactly the same problem after the update to 1.3.3. Did you find any solution for this? I also didn't found any information on how to switch to this new LDAP hub. TheNetStriker (talk) 13:48, 29 July 2019 (UTC)

I have added a first full fledged example configuration for LDAP Stack here: LDAP hub/Migration from extension LDAPAuthentication

Hopefully I can add additional examples soon. Please feel free to add your own examples. Osnard (talk) 06:36, 30 July 2019 (UTC)

Here the same. Would be nice, when it can be fixed. 217.114.64.90 (talk) 10:17, 1 August 2019 (UTC)

Same here, the plugin is dead on my 1.3.3 Mediawiki, it even doesn't write debug information to the configured file. Any suggestions to get it to life again? UnplanedDowntimer (talk) 13:07, 8 August 2019 (UTC)

@UnplanedDowntimer please have a look at LDAP Stack and LDAP hub/Migration from extension LDAPAuthentication. Hopefully this will provide a solution. Osnard (talk) 14:39, 12 August 2019 (UTC)

Does anyone know if the LdapAuthentication for Versions extension will be adjusted for v1.33+ at all?

Or is the switch to LDAP stack indispensable? Mark Ziegler (talk) 10:55, 16 August 2019 (UTC)

This might be something that @Cindy.cicalese might be able to answer. Osnard (talk) 17:14, 17 August 2019 (UTC)

Use the solution in Extension talk:LDAP Authentication/2016#h-LDAPAuthentication_with_Mediawiki_1.27.1-2016-11-22T18:37:00.000Z to solve. Change the original $wgAuth = new LdapAuthenticationPlugin(); to:

$wgAuthManagerAutoConfig['primaryauth'] += [

LdapPrimaryAuthenticationProvider::class => [

'class' => LdapPrimaryAuthenticationProvider::class,

'args' => [[

'authoritative' => true, // don't allow local non-LDAP accounts

]],

'sort' => 50, // must be smaller than local pw provider

],

]; Gslin (talk) 09:15, 19 August 2019 (UTC)

Error after importing database with phpmyadmin

[24dbcafdfdd1b46c128f4a7a] /NRTwiki/Main_Page Wikimedia\Rdbms\DBQueryError from line 1587 of /var/www/html/SNRTwiki/includes/libs/rdbms/database/Database.php: A database query error has occurred. Did you forget to run your application's database schema updater after upgrading?

Query: SELECT user_id,user_name,user_real_name,user_email,user_touched,user_token,user_email_authenticated,user_email_token,user_email_token_expires,user_registration,user_editcount,user_actor.actor_id FROM `user` JOIN `actor` `user_actor` ON ((user_actor.actor_user = user_id)) WHERE user_id = '1' LIMIT 1

Function: User::loadFromDatabase

Error: 1146 Table 'wikidb.actor' doesn't exist (localhost)

Backtrace:

#0 /var/www/html/SNRTwiki/includes/libs/rdbms/database/Database.php(1556): Wikimedia\Rdbms\Database->getQueryExceptionAndLog(string, integer, string, string)

#1 /var/www/html/SNRTwiki/includes/libs/rdbms/database/Database.php(1274): Wikimedia\Rdbms\Database->reportQueryError(string, integer, string, string, boolean)

#2 /var/www/html/SNRTwiki/includes/libs/rdbms/database/Database.php(1784): Wikimedia\Rdbms\Database->query(string, string)

#3 /var/www/html/SNRTwiki/includes/libs/rdbms/database/Database.php(1875): Wikimedia\Rdbms\Database->select(array, array, array, string, array, array)

#4 /var/www/html/SNRTwiki/includes/user/User.php(1442): Wikimedia\Rdbms\Database->selectRow(array, array, array, string, array, array)

#5 /var/www/html/SNRTwiki/includes/user/User.php(531): User->loadFromDatabase(integer)

#6 /var/www/html/SNRTwiki/includes/libs/objectcache/WANObjectCache.php(1253): User->{closure}(boolean, integer, array, NULL)

#7 /var/www/html/SNRTwiki/includes/libs/objectcache/WANObjectCache.php(1414): WANObjectCache->{closure}(boolean, integer, array, NULL)

#8 /var/www/html/SNRTwiki/includes/libs/objectcache/WANObjectCache.php(1258): WANObjectCache->doGetWithSetCallback(string, integer, Closure, array, NULL)

#9 /var/www/html/SNRTwiki/includes/user/User.php(555): WANObjectCache->getWithSetCallback(string, integer, Closure, array)

#10 /var/www/html/SNRTwiki/includes/user/User.php(474): User->loadFromCache()

#11 /var/www/html/SNRTwiki/includes/user/User.php(411): User->loadFromId(integer)

#12 /var/www/html/SNRTwiki/includes/session/UserInfo.php(89): User->load()

#13 /var/www/html/SNRTwiki/includes/session/CookieSessionProvider.php(122): MediaWiki\Session\UserInfo::newFromId(string)

#14 /var/www/html/SNRTwiki/includes/session/SessionManager.php(466): MediaWiki\Session\CookieSessionProvider->provideSessionInfo(WebRequest)

#15 /var/www/html/SNRTwiki/includes/session/SessionManager.php(191): MediaWiki\Session\SessionManager->getSessionInfoForRequest(WebRequest)

#16 /var/www/html/SNRTwiki/includes/WebRequest.php(748): MediaWiki\Session\SessionManager->getSessionForRequest(WebRequest)

#17 /var/www/html/SNRTwiki/includes/session/SessionManager.php(130): WebRequest->getSession()

#18 /var/www/html/SNRTwiki/includes/Setup.php(816): MediaWiki\Session\SessionManager::getGlobalSession()

#19 /var/www/html/SNRTwiki/includes/WebStart.php(77): require_once(string)

#20 /var/www/html/SNRTwiki/index.php(39): require(string)

#21 {main}

I tried doing this manually on the command line and it dropped a lot fo the tables I needed. So I decided to use phpmyadmin since we are using for our old wiki version 1.26. Tmhoskins (talk) 18:21, 29 August 2019 (UTC)

MediaWiki 1.26 doesn't have the actor table. And this stacktrace doesn't get any code path from Extension:LDAP Authentication. I don't know what are you trying to do TBH. Ciencia Al Poder (talk) 19:29, 29 August 2019 (UTC)

Also, MW 1.26 is not supported. You should upgrade to 1.31 at least. ☠MarkAHershberger☢(talk)☣ 15:31, 31 August 2019 (UTC)

I am trying to dump the database from an older version 1.26 into my new version 1.33. This is the error I get when I try to access the web interface of the new version 1.33. Sounds like I need a different LDAP authentication extension, but that still doesn't solve the database issue, which is why i am getting this error. Seems like dumping the DB from 1.26 into 1.33 isn't one to one? Tmhoskins (talk) 11:34, 16 September 2019 (UTC)

You need to run update.php after upgrading MediaWiki to 1.33 (or any other version more recent than the database schema you had) Ciencia Al Poder (talk) 09:29, 17 September 2019 (UTC)

Ran php update.php inside the html/site/maintenance folder and I get: symfony/ldap: 4.3.2 installed, ^4.3 required.

Error: your composer.lock file is not up to date. Run "composer update --no-dev" to install newer dependencies. After some googling I ran: composer upate --lock and it doesn't have anything to update. It's just going in circles.

Also, this is a fresh install of Mediawiki 1.33 on a VM its not an older Mediawiki that I upgraded. I do need to dump the old database from the another mediawiki 1.26 into the new version. That's where I am having issues. Not to mention I cannot get LdapAuth Extension to work at all. Tmhoskins (talk) 12:10, 17 September 2019 (UTC)

This is solved. Mediawiki is using the composer file for other things so to get php to update the schema I had to run "php maintenance/update.php --skip-external-dependencies" after I dumped the database in the new wiki with phpmyadmin.

However LdapAuth is still not working even though I used this other guys info for configuration that seemed to work for him: https://github.com/shanept/mediawiki-LdapAuth/issues/13bottom comment.

Please Advise. Tmhoskins (talk) 13:04, 17 September 2019 (UTC)

Incorrect username or password entered. Please try again.

I'm struggling to find any useful logs and have been stuck on this for sometime. Any and all help would be much appreciated. I'm pretty new to linux, php, mediawiki administration. Without a lot of information to go on I think the issue is the cert setup, but not sure how to confirm that.

Installed:

Configuration:

#LDAP Auth

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

$wgAuth = new LdapAuthenticationPlugin();

$wgLDAPDomainNames = array('DOMAIN');

$wgLDAPServerNames = array('DOMAIN' => 'DC1.domain.com');

$wgLDAPEncryptionType = array('DOMAIN' => 'tls'); ##I've tried clear and ssl

$wgLDAPProxyAgent =  array('DOMAIN' => 'CN=Wiki LDAP,OU=Service Accounts,DC=domain,DC=com');

$wgLDAPProxyAgentPassword = array('DOMAIN' => 'WikiLDAPPASSWORD');

$wgLDAPSearchAttributes = array('DOMAIN' => 'sAMAccountName');

$wgLDAPBaseDNs = array('DOMAIN' => 'cn=People,dc=domain,dc=com');

$wgMinimalPasswordLength = 1;

$wgLDAPDebug = 3;

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

Logs:

root@SERVER1:/var/lib/mediawiki# cat /tmp/ldap-debug.log

2019-12-02 16:49:45 SERVER1 site_wiki: 2.1.0 Entering strict.

2019-12-02 16:49:45 SERVER1 site_wiki: 2.1.0 Entering getDomain

2019-12-02 16:49:45 SERVER1 site_wiki: 2.1.0 Returning true in strict().

2019-12-02 18:05:02 SERVER1 site_wiki: 2.1.0 Entering strict.

2019-12-02 18:05:02 SERVER1 site_wiki: 2.1.0 Entering getDomain

2019-12-02 18:05:02 SERVER1 site_wiki: 2.1.0 Returning true in strict().

2019-12-02 18:12:35 SERVER1 site_wiki: 2.1.0 Entering strict.

2019-12-02 18:12:35 SERVER1 site_wiki: 2.1.0 Entering getDomain

2019-12-02 18:12:35 SERVER1 site_wiki: 2.1.0 Returning true in strict().

2019-12-02 18:33:38 SERVER1 site_wiki: 2.1.0 Entering strict.

2019-12-02 18:33:38 SERVER1 site_wiki: 2.1.0 Entering getDomain

2019-12-02 18:33:38 SERVER1 site_wiki: 2.1.0 Returning true in strict().

I did at one point see this in the apache2 error.log but it stopped coming up.

[php7:warn] [pid 1465] [client 172.21.193.14:54312] PHP Warning:  ldap_start_tls(): Unable to start TLS: Connect error in /var/lib/mediawiki/extensions/LdapAuthentication/LdapAuthenticationPlugin.php on line 614, referer: https://SERVER1.domain.com/mediawiki/index.php?title=Special:UserLogin&returnto=Special:ListUsers Wrathofmcgrath (talk) 18:49, 2 December 2019 (UTC)

I just tried the latest version of the extension and I get this error when running the update.php script

PHP Fatal error:  Uncaught Error: Class 'LdapAuthenticationPlugin' not found in /var/lib/mediawiki/LocalSettings.php:165

Stack trace:

#0 /var/lib/mediawiki/maintenance/doMaintenance.php(65): require()

#1 /var/lib/mediawiki/maintenance/update.php(249): require_once('/var/lib/mediaw...')

#2 {main}

  thrown in /var/lib/mediawiki/LocalSettings.php on line 165 Wrathofmcgrath (talk) 19:07, 2 December 2019 (UTC)

Apparently, in LocalSettings.php you should have those lines:

require_once ('extensions/LdapAuthentication/LdapAuthentication.php');
require_once ('includes/AuthPlugin.php');
$wgAuth = new LdapAuthenticationPlugin();

See if any of them are missing. Ciencia Al Poder (talk) 10:11, 3 December 2019 (UTC)

Based on this link [1] I don't need the require_once ('includes/AuthPlugin.php'); line

[1] https://blog.ryandlane.com/2009/03/23/using-the-ldap-authentication-plugin-for-mediawiki-the-basics-part-1/

I re signed the cert and now when I enable this extension no one is able to login, including the local account. I feel like this is progress... I do have a local account that is also an AD account (because I read you needed that) and that account is a bureaucrat, and a wiki administrator. no new information in the /tmp/ldap-debug.log. Is there anything else I should check? Wrathofmcgrath (talk) 18:37, 3 December 2019 (UTC)

ok so I changed /etc/ldap/ldap.conf file to:

TLS_REQCERT     never

and now the local wiki account that exists in AD can login...not sure if its actually doing ldap auth though. and the other local account (not in AD) can't login, which I think(maybe) is normal behavior. Now, why can't other AD accounts login? do I have to have users create their AD account on mediawiki and then it'll work with ldap auth? or should this extension automatically check with the ldap server to see its an AD account and create the mediawiki user based on that? Wrathofmcgrath (talk) 19:28, 3 December 2019 (UTC)

Maybe this has something to do with that: Extension:LDAP Authentication/Configuration Options#MediaWiki user creation options Ciencia Al Poder (talk) 10:22, 4 December 2019 (UTC)

That comment is comment is confusing to me...

default is set to false so it should "automatically create an account for a user if the account exists in LDAP, but not in MediaWiki."?

Regardless I've tried both and it didn't change the behavior. Wrathofmcgrath (talk) 14:36, 4 December 2019 (UTC)