Topic on Extension talk:LDAPProvider/Flow

Recently upgrade an existing instance to 1.35 from 1.31. Had been using the original LDAPAuthentication app. Can authenticate successfully without TLS, but not after turning on. Trying to hit an AD server.

When I run the debug test (php extensions/LDAPProvider/maintenance/ShowUserInfo.php --domain YourDomain --username SomeUser), I get this error stack:

MWException from line 139 of /var/lib/mediawiki-1.35.0/extensions/LDAPProvider/src/Client.php: Could not start TLS!

#0 /var/lib/mediawiki-1.35.0/extensions/LDAPProvider/src/Client.php(90): MediaWiki\Extension\LDAPProvider\Client->maybeStartTLS()

#1 /var/lib/mediawiki-1.35.0/extensions/LDAPProvider/src/Client.php(229): MediaWiki\Extension\LDAPProvider\Client->init()

#2 /var/lib/mediawiki-1.35.0/extensions/LDAPProvider/maintenance/ShowUserInfo.php(49): MediaWiki\Extension\LDAPProvider\Client->getUserInfo()

#3 /var/lib/mediawiki-1.35.0/maintenance/doMaintenance.php(107): MediaWiki\Extension\LDAPProvider\Maintenance\ShowUserInfo->execute()

#4 /var/lib/mediawiki-1.35.0/extensions/LDAPProvider/maintenance/ShowUserInfo.php(72): require_once('/var/lib/mediaw...')

#5 {main}

Here's my ldap.json, which for now I keep in the main MediaWiki folder:

{
  "lc": {
    "connection": {
      "server": "lc.luther.edu",
      "user": "CN=hdwiki,OU=Vendor,DC=lc,DC=luther,DC=edu",
      "pass": "***secret***",
      "port": 1389,
      "enctype": "tls",
      "options": {
        "LDAP_OPT_DEREF": 1
      },
    "basedn": "DC=lc, DC=luther, DC=edu",
    "userbasedn": "DC=lc, DC=luther, DC=edu",
    "groupbasedn": "OU=Groups,DC=lc, DC=luther, DC=edu",
    "searchattribute": "samaccountname",
    "usernameattribute": "samaccountname",
    "realnameattribute": "cn",
    "emailattribute": "mail",
      "grouprequest":"MediaWiki\\Extension\\LDAPProvider\\UserGroupsRequest\\UserMemberOf::factory",
    "presearchusernamemodifiers": [ "spacestounderscores", "lowercase" ]
    },
    "userinfo": [],
    "authorization": [],
    "groupsync": {
      "mapping": {
        "bureaucrat": "CN=Help_Desk_Managers,OU=Groups,DC=lc, DC=luther, DC=edu"
      }
    }
  }
}

Here's the relevant portion of my LocalSettings.php:

error_reporting( -1 );  //debugging. Comment out when in production
ini_set( 'display_errors', 1 ); //debugging. Comment out when in production
$wgDebugLogGroups['PluggableAuth'] =
$wgDebugLogGroups['LDAP'] =
$wgDebugLogGroups['MediaWiki\\Extension\\LDAPProvider\\Client'] =
$wgDebugLogGroups['LDAPAuthentication2'] =
$wgDebugLogGroups['LDAPAuthorization'] = '/tmp/LDAP.log';

.
.
.

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

// Load LDAP Config from JSON
$ldapJsonFile = "$IP/ldap.json";
$ldapConfig = false;
if (is_file($ldapJsonFile) && is_dir("$IP/extensions/LDAPProvider")) {
  $testJson = @json_decode(file_get_contents($ldapJsonFile),true);
  if (is_array($testJson)) {
    $ldapConfig = true;
  } else {
   error_log("Found invalid JSON in file: $IP/ldap.json");
  }
}

// Activate Extension
if ( $ldapConfig ) {

  wfLoadExtension( 'PluggableAuth' );
  wfLoadExtension( 'LDAPProvider' );
  wfLoadExtension( 'LDAPAuthentication2' );
  wfLoadExtension( 'LDAPAuthorization' );
  $LDAPProviderDomainConfigs = $ldapJsonFile;
  $wgPluggableAuth_ButtonLabel = "Log In";
  $LDAPAuthentication2AllowLocalLogin = true;
}

Error logs at /tmp/LDAP.log look like:

2020-11-24 16:51:11 wiki hdwiki_test: ldap_connect( $hostname = 'ldap://lc.luther.edu:1389', $port = 389 );
2020-11-24 16:51:11 wiki hdwiki_test: # __METHOD__ returns Resource id #773
2020-11-24 16:51:11 wiki hdwiki_test: Setting LDAP_OPT_PROTOCOL_VERSION to 3
2020-11-24 16:51:11 wiki hdwiki_test: ldap_set_option( $linkID, $option = 17, $newval = 3 );
2020-11-24 16:51:11 wiki hdwiki_test: # returns 1
2020-11-24 16:51:11 wiki hdwiki_test: Setting LDAP_OPT_REFERRALS to 0
2020-11-24 16:51:11 wiki hdwiki_test: ldap_set_option( $linkID, $option = 8, $newval = 0 );
2020-11-24 16:51:11 wiki hdwiki_test: # returns 1
2020-11-24 16:51:11 wiki hdwiki_test: Setting LDAP_OPT_DEREF to 1
2020-11-24 16:51:11 wiki hdwiki_test: ldap_set_option( $linkID, $option = 2, $newval = 1 );
2020-11-24 16:51:11 wiki hdwiki_test: # returns 1
2020-11-24 16:51:11 wiki hdwiki_test: ldap_start_tls( $linkID );

We thought it was odd that first line of the last error code uses one port for $hostname and then another in the $port. We tried not specifying the port in the ldap.json file, same result.

I have php7.4-ldap installed.

Thanks to anyone who read this far. :)

I have seen the same issue where my TLS fails. I have done a lot of configuration and been running mediawiki since 1.26 in production. I can test PHP client program from my linux server to the LDAP/AD server just fine; bind and connect.

Yet the server fails every login and gives the same odd message of port configuration error .

Here is the requirement, when you use SSL or TLS against an LDAP server.

- The Server-Cert in the LDAPS response will be verified by the php-ldap openssl library.

- The Server-Cert is provided by an MS-AD DC when hitting 389 with SmartTLS enabled, or 636 SSL

- Also, your can use Global Catalog Ports 3268 with SmartTLS enabled, or 3269 SSL.

PHP LDAPS

- PHP LDAPS uses openssl under the hood - e.g. the system-wide CA-Bundle, a set of trusted Cert-Authorities.

- For SmartTLS or SSL methods to work, your box must trust the MS-AD CA, which signed the Server-Cert.

- This means the MS-AD CA certificate needs to be merged with your system's CA bundle.

- This is usually done with a tool named 'update-ca-certificates' or similar.

One way of determining whether your box is verifying TLS with the DC, is to use openssl at the CLI.

echo "" | openssl s_client -connect foobar-dc:389 -starttls ldap -prexit -showcerts

Firstly, look at the last line: "Verify return code" - it will be 0, when the TLS/SSL is all OK.

The CA Cert ( e.g. the Certificate Chain ) is included at the top of the output.

1. You need to place the CA Cert into your system-wide CA import directory.
2. Then run 'update-ca-certificates'
3. Then test again with openssl, the CA must be trusted for the TLS verify return code to be 0.

Adding the Additional CA File for DC:

Example dir, for placing extra CA files into: /usr/local/share/ca-certificates/

Check man update-ca-certificates to see if your directory is different...

Simply copy-and-paste the Cert header, content, and footer lines, into a new file.

/usr/local/share/ca-certificates/foobar-dc.ca2020.cert

-----BEGIN CERTIFICATE-----

cert content, in base64 format

-----END CERTIFICATE-----

And run 'update-ca-certificates'.

This checks for new CA files in a location like /usr/local/share/ca-certificates/, and merges into the global bundle file, usually somewhere within /etc/ssl/

Long story short, when the openssl verify works against a DC, you should find that PHP LDAPS also works using SmartTLS on TCP389. Or, SSL on 636.

I automate this process in some of my PHP applications, by using a non-TLS LDAP query, to obtain the TLS CA Certificate via LDAP, and then write the certificate to filesystem, and run 'update-ca-certificates' under the hood. It's complex, but allows for automatic import of the MS-AD CA, because the CA can often change if PKI changes occur in the domain, or after a CA Certificate is renewed.

That was helpful and well thought out, thanks. I do have both my system and my openssl standard certs location have my CA cert in their lists and the update ca command. The two do not really share locations well today, w/o symlinks in one direction or the other.

In the end I was able to get this to work w/AD. There was some real insight needed that I only obtained through enabling all the logs and watching that output.

@Emikulic I'm experiencing a similar issue as we're now staring to enforce TLS on all our LDAP servers. However all the debugging I've done shows that the operating system is able to connect "start TLS". But still MediaWiki is giving the error below. What exactly did you do to fix the problem? I've even pointed php.ini at our known good CA certificate file for PHP to use it. openssl.cafile=/etc/ssl/certs/ca-bundle.crt

[48099cecdbcdab00e2a66cbd] /Special:PluggableAuthLogin MWException: Could not start TLS!

We run another PHP application "Booked Scheduler" and connect with TLS enabled using this exact same CA file. I'm stuck.

@Osnard I just noticed that the MediaWiki Docker image I'm using includes PHP 7.4.29 which isn't currently supported. Could that be causing the problem I'm seeing?

I've done quite a bit of debugging both on the client and LDAP server side. I'm able to bind and use TLS using LDAP utilities, openssl cli and a rudimentary PHP script. But no luck getting the enctype 'tls' to work.

I'm using the 1.37.2 MediaWiki image from here: https://hub.docker.com/_/mediawiki

We run another PHP application "Booked Scheduler" and connect with TLS enabled using this exact same CA file. I'm stuck.

This "Booked Scheduler", does it run in the same environment (server/container) as MediaWiki?

Sorry, I don't have much expierience with running the LDAP-Stack applications in the MediaWiki Docker environment.

Thanks. The Booked Scheduler software runs on a similar container. It uses the Docker Hub PHP image which is Debian based and uses the docker-php-ext-* scripts also found on the MediaWiki container for installing and configuring PHP modules.

https://hub.docker.com/_/php

https://hub.docker.com/_/mediawiki

But is is two separated environments then. Well, the LDAP-Stack extensions to not implement anything special regarding tue use of CA files, but rely completely on the environment.

Can you maybe try to create a little testing script like https://www.php.net/manual/en/function.ldap-bind.php#example-4353 in the MediaWiki environment and run ti from within?

Also looking at the output of `phpinfo();` may reveal something about the environment specific configuration. You may compare this to the working environment.

Also check the php.ini files on the MediaWiki container for differences to the "Booked Scheduler".

@Osnard thanks for the tips. I've been working on other projects but just came back to this. It's very strange. Today I tried setting up the 1.37.2 MediaWiki on a standard RHEL7 virtual machine and connected to the database with tls enabled just fine. I've also got another MediaWiki instance which has even more extensions like "Math" and "Semantic" enabled. I can only reproduce the problem intermittently there. It's very odd. Anyway, since this appears to be operating system or otherwise related to the Linux environment I'll keep debugging on my end. Thanks again.