Unable to authenticate MediaWiki (on LAMP/Ubuntu) users using AD (on Windows Server 2012 R2) via LDAP

I am working in an AD domain with a single DC running Windows Server 2012 R2. On the domain's network (though not formally domain-joined) is a LAMP web server running Ubuntu Server 14.04.3 LTS. All machines are able to reach one another by both IP address and DNS record, and the LAMP stack is (as far as I can tell) appropriately configured; HTTP requests are served as expected.

The aim is to set up an instance of MediaWiki on the LAMP server. Moreover, MediaWiki should - using Ryan Lane's excellent extension LdapAuthenticate - contact the AD DC to authenticate user logins.

I have tried to follow setup instructions as closely to the book as possible. LAMP installation is mostly taken care of by the Ubuntu Server installer, and I additionally install via apt-get the packages php5-intl php5-gd texlive php5-xcache imagemagick mediawiki mediawiki-math and their dependencies.

I next uncomment the #Alias... line in /etc/mediawiki/apache.conf, run the commands a2enconf mediawiki and php5enmod mycrypt, and lastly install the LdapAuthenticate MediaWiki extension according to tutorials at the author's website.

Appended to my /etc/mediawiki/LocalSettings.php are:

ldap_set_option(NULL, LDAP_OPT_DEBUG_LEVEL, 7);


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

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

$wgAuth = new LdapAuthenticationsPlugin();

$wgLDAPDomainNames = array("MYDOMAIN");
$wgLDAPServerNames = array("MYDOMAIN" => "addc.local.domain.com");
$wgLDAPSearchStrings = array("MYDOMAIN" => "USER-NAME@local.domain.com");


$wgLDAPEncryptionType = array("MYDOMAIN" => "tls");

I next add the AD DC's self-signed CA certificate to /etc/ssl/certs on the LAMP server, run c_rehash, and restart everything.

At this point I am able to get into MediaWiki and navigate to the login form no problem. The login form shows MYDOMAIN, and PHP reports no errors - the LdapAuthentication plugin looks good to go.

When I try to login using an AD credential set, however, MediaWiki reports a wrong password. A PHP error on the web page reports that PHP was unable to start TLS (Warning: ldap_start_tls(): Unable to start TLS: Connect error in...), and this same message is reconfirmed by the LdapAuthentication plugin's debug log which I set earlier to /tmp/debug.log.

Looking now at the AD DC, I note the following event in the system log:

Error from Schannel, Event ID 36874
An TLS 1.2 connection request was received from a remote client application, but none of the cipher suites supported by the client application are supported by the server. The SSL connection request has failed.

This error coincides with repeated attempts to authenticate user logins on MediaWiki with AD via LDAP.

I don't know enough about managing cipher suites to approach resolving this issue. Moreover, days upon days of Google searching hasn't yielded me any productive results. Could someone point me in the right direction?

Answer

After hacking at the LdapAuthentication (version 2.0d) MediaWiki extension and introducing my own break points, I was able to track down the problem. It turns out that binding to my AD server over SSL only works following a call to PHP's ldap_connect() that looks like,

ldap_connect("myserver.com", 636);

rather than,

ldap_connect("ldaps://myserver.com:636");

upon which LdapAuthenticate insists.

I note also that LdapAuthenticate wraps PHP's ldap_connect() in the following way,

public static function ldap_connect( $hostname=null, $port=389 ) {
    wfSuppressWarnings();
    $ret = ldap_connect( $hostname, $port );
    wfRestoreWarnings();
    return $ret;
}

but then only ever passes in $hostname, as a URI formatted as one of,

ldapi://myserver.com:port
ldap://myserver.com:port
ldaps://myserver.com:port

leaving $port to its default value of 389. This means that, say you're attempting to bind over SSL, the actual call to PHP's ldap_connect() looks like this,

ldap_connect("ldaps://myserver.com:636", 389);

which must be causing some problems!

I think this might be a bug in LdapAuthenticate, but then again it might just be me totally misinterpreting the PHP (it's been a while). In any case I managed to get the authentication working by hacking LdapAuthenticate to force a call to,

ldap_connect("myserver.com", 636);

This does, however, leave one unanswered question. Why does my AD server happily accept binds to myserver.com, but not to ldaps://myserver.com? (I have confirmed that this is the case using ldp.exe on Windows). I suspect that this is a DNS issue, since myserver.com is actually handled according to a record on my local DNS server (on which I may have indeed missed a trick!) I will ask another question elsewhere!