0

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?

snoopy91
  • 243
  • 3
  • 10

2 Answers2

0

I don't know about MediaWiki - but I have DokuWiki doing what you are looking for. I use the Apache / Kerberos integration to get things going - perhaps you could do that too. To get going, you need to:

  • Generate a Kerberos keytab file. This is sort of a pre shared credentials set needed for Kerberos trusts. Do this by issuing

    ktpass -princ HTTP/<service host name>@<DOMAIN NAME> -mapuser <security principal> -crypto RC4-HMAC-NT -ptype KRB5_NT_PRINCIPAL -pass <password> -out <filename>.keytab

    on your AD server.

  • If your Apache is on a Linux box (mine is), install the libpam-krb5 package (or equivalent on your system). Then, edit your /etc/krb5.conf:

     [libdefaults]
 default_realm = <YOUR DOMAIN>

  • Modify the Directory section of your apache.conf that applies to your Media Wiki setup. Add Kerberos integration like this:

    # Kerberos Auth
<Directory>
    .... # Your Media Wiki stuff here
    AuthType Kerberos
    KrbAuthRealms <YOUR DOMAIN>
    KrbServiceName HTTP/<service hos name>
    Krb5Keytab /etc/apache2/<filename>.keytab
    KrbMethodNegotiate on
    KrbMethodK5Passwd on
    require valid-user
</Directory>

Once you have this, browsers will be able to sign in local users SSO style (if you configure browsers accordingly). If they are not local users, they will get a basic login prompt that accepts AD credentials.

This setup works nicely for me using the DokuWiki authad plug-in. Whether it adapts to Media Wiki, I don't know, but the Apache / Kerberos Stuff is really nice for a lot of things. Hope it helps!

MrMajestyk
  • 1,048
  • 7
  • 9
  • Thank you for the suggestion - it's always good to hear how people are solving these problems in other labs! Unfortunately we're bound to MediaWiki, and I'd very much like to have the MediaWiki-integrated account features (such as who edited what and when). – snoopy91 Nov 19 '15 at 10:38
0

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!

snoopy91
  • 243
  • 3
  • 10