Extension:LDAP Authentication/Requirements

From MediaWiki.org
Jump to: navigation, search

About - Requirements - Examples - Configuration Options - Changelog - Roadmap - Suggestions - User provided info - FAQ - Support


MediaWiki extensions manual
Crystal Clear action run.png
LDAP Authentication

Release status: stable

Implementation User identity
Description Provides LDAP authentication, and some authorization functionality for MediaWiki
Author(s) Ryan Lane (Ryan lanetalk)
Latest version 2.0d (2012-11-21)
MediaWiki 1.19+
Database changes Yes
License GNU General Public License
Download
Hooks used
LoadExtensionSchemaUpdates

Translate the LDAP Authentication/Requirements extension if it is available at translatewiki.net

Check usage and version matrix; code metrics


Overview[edit | edit source]

  • MediaWiki 1.19+ for current version of the plugin
  • PHP must be compiled with LDAP support for any functionality at all
  • PHP must be compiled with SSL support if you wish to authenticate over SSL (highly recommended!)
    • Your server must trust the LDAP server's Certificate's Root CA for SSL to work (mostly affects you if you are using self signed certificates)
    • The DNS name for your LDAP server must match the name in the LDAP server's certificate for SSL to work
    • This support should be included with your distribution's PHP
  • Smartcard (SSL Client) authentication requires a PEM encoded list of CAs, proxy or anonymous (if allowed on your network) LDAP credentials, and an SSL enabled webserver
  • If you would like to use LDAP as a backend for MediaWiki (creating users, changing passwords, etc), you must provide a user who has write permissions to specific user attributes (please only give this user the minimum amount of access that is required)

Meeting requirements per platform[edit | edit source]

If you have instructions for any of these sections, don't hesitate to add them.

Red Hat Enterprise Linux and Fedora[edit | edit source]

PHP LDAP support[edit | edit source]

yum -y install php-ldap

Certificate trusts[edit | edit source]

First, place your CA certificates in /etc/pki/tls/certs. If you do not have the CA certificate, you can fetch it using openssl:

# openssl s_client -showcerts -connect google.com:443
CONNECTED(00000003)
depth=2 /C=US/O=VeriSign, Inc./OU=Class 3 Public Primary Certification Authority
verify return:1
depth=1 /C=ZA/O=Thawte Consulting (Pty) Ltd./CN=Thawte SGC CA
verify return:1
depth=0 /C=US/ST=California/L=Mountain View/O=Google Inc/CN=www.google.com
verify return:1
---
Certificate chain
 0 s:/C=US/ST=California/L=Mountain View/O=Google Inc/CN=www.google.com
   i:/C=ZA/O=Thawte Consulting (Pty) Ltd./CN=Thawte SGC CA
-----BEGIN CERTIFICATE-----
MIIDITCCAoqgAwIBAgIQL9+89q6RUm0PmqPfQDQ+mjANBgkqhkiG9w0BAQUFADBM
MQswCQYDVQQGEwJaQTElMCMGA1UEChMcVGhhd3RlIENvbnN1bHRpbmcgKFB0eSkg
THRkLjEWMBQGA1UEAxMNVGhhd3RlIFNHQyBDQTAeFw0wOTEyMTgwMDAwMDBaFw0x
MTEyMTgyMzU5NTlaMGgxCzAJBgNVBAYTAlVTMRMwEQYDVQQIEwpDYWxpZm9ybmlh
MRYwFAYDVQQHFA1Nb3VudGFpbiBWaWV3MRMwEQYDVQQKFApHb29nbGUgSW5jMRcw
FQYDVQQDFA53d3cuZ29vZ2xlLmNvbTCBnzANBgkqhkiG9w0BAQEFAAOBjQAwgYkC
gYEA6PmGD5D6htffvXImttdEAoN4c9kCKO+IRTn7EOh8rqk41XXGOOsKFQebg+jN
gtXj9xVoRaELGYW84u+E593y17iYwqG7tcFR39SDAqc9BkJb4SLD3muFXxzW2k6L
05vuuWciKh0R73mkszeK9P4Y/bz5RiNQl/Os/CRGK1w7t0UCAwEAAaOB5zCB5DAM
BgNVHRMBAf8EAjAAMDYGA1UdHwQvMC0wK6ApoCeGJWh0dHA6Ly9jcmwudGhhd3Rl
LmNvbS9UaGF3dGVTR0NDQS5jcmwwKAYDVR0lBCEwHwYIKwYBBQUHAwEGCCsGAQUF
BwMCBglghkgBhvhCBAEwcgYIKwYBBQUHAQEEZjBkMCIGCCsGAQUFBzABhhZodHRw
Oi8vb2NzcC50aGF3dGUuY29tMD4GCCsGAQUFBzAChjJodHRwOi8vd3d3LnRoYXd0
ZS5jb20vcmVwb3NpdG9yeS9UaGF3dGVfU0dDX0NBLmNydDANBgkqhkiG9w0BAQUF
AAOBgQCfQ89bxFApsb/isJr/aiEdLRLDLE5a+RLizrmCUi3nHX4adpaQedEkUjh5
u2ONgJd8IyAPkU0Wueru9G2Jysa9zCRo1kNbzipYvzwY4OA8Ys+WAi0oR1A04Se6
z5nRUP8pJcA2NhUzUnC+MY+f6H/nEQyNv4SgQhqAibAxWEEHXw==
-----END CERTIFICATE-----
 1 s:/C=ZA/O=Thawte Consulting (Pty) Ltd./CN=Thawte SGC CA
   i:/C=US/O=VeriSign, Inc./OU=Class 3 Public Primary Certification Authority
-----BEGIN CERTIFICATE-----
MIIDIzCCAoygAwIBAgIEMAAAAjANBgkqhkiG9w0BAQUFADBfMQswCQYDVQQGEwJV
UzEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xNzA1BgNVBAsTLkNsYXNzIDMgUHVi
bGljIFByaW1hcnkgQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkwHhcNMDQwNTEzMDAw
MDAwWhcNMTQwNTEyMjM1OTU5WjBMMQswCQYDVQQGEwJaQTElMCMGA1UEChMcVGhh
d3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEWMBQGA1UEAxMNVGhhd3RlIFNHQyBD
QTCBnzANBgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEA1NNn0I0Vf67NMf59HZGhPwtx
PKzMyGT7Y/wySweUvW+Aui/hBJPAM/wJMyPpC3QrccQDxtLN4i/1CWPN/0ilAL/g
5/OIty0y3pg25gqtAHvEZEo7hHUD8nCSfQ5i9SGraTaEMXWQ+L/HbIgbBpV8yeWo
3nWhLHpo39XKHIdYYBkCAwEAAaOB/jCB+zASBgNVHRMBAf8ECDAGAQH/AgEAMAsG
A1UdDwQEAwIBBjARBglghkgBhvhCAQEEBAMCAQYwKAYDVR0RBCEwH6QdMBsxGTAX
BgNVBAMTEFByaXZhdGVMYWJlbDMtMTUwMQYDVR0fBCowKDAmoCSgIoYgaHR0cDov
L2NybC52ZXJpc2lnbi5jb20vcGNhMy5jcmwwMgYIKwYBBQUHAQEEJjAkMCIGCCsG
AQUFBzABhhZodHRwOi8vb2NzcC50aGF3dGUuY29tMDQGA1UdJQQtMCsGCCsGAQUF
BwMBBggrBgEFBQcDAgYJYIZIAYb4QgQBBgpghkgBhvhFAQgBMA0GCSqGSIb3DQEB
BQUAA4GBAFWsY+reod3SkF+fC852vhNRj5PZBSvIG3dLrWlQoe7e3P3bB+noOZTc
q3J5Lwa/q4FwxKjt6lM07e8eU9kGx1Yr0Vz00YqOtCuxN5BICEIlxT6Ky3/rbwTR
bcV0oveifHtgPHfNDs5IAn8BL7abN+AqKjbc1YXWrOU/VG+WHgWv
-----END CERTIFICATE-----
---
Server certificate
subject=/C=US/ST=California/L=Mountain View/O=Google Inc/CN=www.google.com
issuer=/C=ZA/O=Thawte Consulting (Pty) Ltd./CN=Thawte SGC CA
---
No client certificate CA names sent
---
SSL handshake has read 1772 bytes and written 307 bytes
---
New, TLSv1/SSLv3, Cipher is RC4-SHA
Server public key is 1024 bit
Secure Renegotiation IS supported
Compression: NONE
Expansion: NONE
SSL-Session:
    Protocol  : TLSv1
    Cipher    : RC4-SHA
    Session-ID: 44C62AF7EF45180DE9253BB25D2F7EBE09FCADFD8B62A9EDEE3212E598F9AF1F
    Session-ID-ctx:
    Master-Key: BE476D80B3343BDF2576F6A15BC4C0AEB9374F41CC089C10B63CDD8A13081D49AC75C9E2C02FCAB89FE08A3A48086D74
    Key-Arg   : None
    Krb5 Principal: None
    Start Time: 1274190671
    Timeout   : 300 (sec)
    Verify return code: 0 (ok)
---

The above example pulls CA certificates from a web server (particularly google.com:443), but the example would work the same on an LDAP server. You'd want to use <your-server.com>:636 instead of google.com:443.

To pull the CA certificates, you'll want to save all certificates returned greater than 0 (as certificate 0 is the server's certificate). To do so, copy all text in between and including -----BEGIN CERTIFICATE----- and -----END CERTIFICATE-----, and place them into a file called <CAname>.crt.

You can ensure the certificate was copied properly by testing it with openssl:

# openssl x509 -noout -text -in <CAname>.crt
Certificate:
    Data:
        Version: 3 (0x2)
        Serial Number: 805306370 (0x30000002)
        Signature Algorithm: sha1WithRSAEncryption
        Issuer: C=US, O=VeriSign, Inc., OU=Class 3 Public Primary Certification Authority
        Validity
            Not Before: May 13 00:00:00 2004 GMT
            Not After : May 12 23:59:59 2014 GMT
        Subject: C=ZA, O=Thawte Consulting (Pty) Ltd., CN=Thawte SGC CA
        Subject Public Key Info:
            Public Key Algorithm: rsaEncryption
            RSA Public Key: (1024 bit)
                Modulus (1024 bit):
                    00:d4:d3:67:d0:8d:15:7f:ae:cd:31:fe:7d:1d:91:
                    a1:3f:0b:71:3c:ac:cc:c8:64:fb:63:fc:32:4b:07:
                    94:bd:6f:80:ba:2f:e1:04:93:c0:33:fc:09:33:23:
                    e9:0b:74:2b:71:c4:03:c6:d2:cd:e2:2f:f5:09:63:
                    cd:ff:48:a5:00:bf:e0:e7:f3:88:b7:2d:32:de:98:
                    36:e6:0a:ad:00:7b:c4:64:4a:3b:84:75:03:f2:70:
                    92:7d:0e:62:f5:21:ab:69:36:84:31:75:90:f8:bf:
                    c7:6c:88:1b:06:95:7c:c9:e5:a8:de:75:a1:2c:7a:
                    68:df:d5:ca:1c:87:58:60:19
                Exponent: 65537 (0x10001)
        X509v3 extensions:
            X509v3 Basic Constraints: critical
                CA:TRUE, pathlen:0
            X509v3 Key Usage:
                Certificate Sign, CRL Sign
            Netscape Cert Type:
                SSL CA, S/MIME CA
            X509v3 Subject Alternative Name:
                DirName:/CN=PrivateLabel3-15
            X509v3 CRL Distribution Points:
                URI:http://crl.verisign.com/pca3.crl
 
            Authority Information Access:
                OCSP - URI:http://ocsp.thawte.com
 
            X509v3 Extended Key Usage:
                TLS Web Server Authentication, TLS Web Client Authentication, Netscape Server Gated Crypto, 2.16.840.1.113733.1.8.1
    Signature Algorithm: sha1WithRSAEncryption
        55:ac:63:ea:de:a1:dd:d2:90:5f:9f:0b:ce:76:be:13:51:8f:
        93:d9:05:2b:c8:1b:77:4b:ad:69:50:a1:ee:de:dc:fd:db:07:
        e9:e8:39:94:dc:ab:72:79:2f:06:bf:ab:81:70:c4:a8:ed:ea:
        53:34:ed:ef:1e:53:d9:06:c7:56:2b:d1:5c:f4:d1:8a:8e:b4:
        2b:b1:37:90:48:08:42:25:c5:3e:8a:cb:7f:eb:6f:04:d1:6d:
        c5:74:a2:f7:a2:7c:7b:60:3c:77:cd:0e:ce:48:02:7f:01:2f:
        b6:9b:37:e0:2a:2a:36:dc:d5:85:d6:ac:e5:3f:54:6f:96:1e:
        05:af

Next, create hash links to the certificates:

# Create hash links to the certs
cd /etc/pki/tls/certs
for i in `ls *.crt`;do
        [ ! -e $i.0 ] && ln -s $i $(openssl x509 -hash -noout -in $i).0 > /dev/null 2>&1 || :
done

Next, create a CA bundle, as some applications only work properly with a bundled file of CAs (notice that *.crt is assumed be your CA certificates):

for i in `ls *.crt`
do
     cat $i >> /etc/pki/tls/certs/local-bundle.crt
done

Finally, add the trust to openldap's client configuration:

  1. Edit /etc/openldap/ldap.conf
  2. Add the following lines:
TLS_CACERTDIR   /etc/pki/tls/certs
TLS_CACERT      /etc/pki/tls/certs/local-bundle.crt

Ubuntu and Debian[edit | edit source]

PHP LDAP support[edit | edit source]

apt-get install -y php5-ldap

Certificate trusts[edit | edit source]

Extract your custom CA-certificates same way as above (Red Hat Enterprise Linux and Fedora) but put .crt-file in /usr/local/share/ca-certificates

Automatically update certificate directory and Ubuntus bundled CA-file using the following command:

root@server:~# update-ca-certificates 
Updating certificates in /etc/ssl/certs... WARNING: Skipping duplicate certificate ca-certificates.crt
1 added, 0 removed; done.
Running hooks in /etc/ca-certificates/update.d....done.
root@server:~#

Ignore the warning.

Finally, add the trust to openldap's client configuration:

  1. Edit /etc/ldap/ldap.conf
  2. Add the following lines:
TLS_CACERTDIR   /etc/ssl/certs
TLS_CACERT      /etc/ssl/certs/ca-certificates.crt

Usually, the TLS_CACERTDIR statement only should be sufficient, but due to a bug (probably in libgnutls26) this doesn't work. Another (risky) workaround is to replace the two lines with the following:

TLS_REQCERT never

The communication with the ldap server is still encrypted, but the client will not compare the server URL with the name in the servers' certificate, thus there is no protection from man-in-the-middle attacks.

SLES/OpenSUSE[edit | edit source]

PHP LDAP support[edit | edit source]

zypper install php53-ldap

Certificate trusts[edit | edit source]

You need the Root CA certificate which was used to issue the Active Directory server CA certificate. Ask your Windows AD administrator for this certificate or export it yourself in Windows by:

  • Starting Certification Authority snap-in
  • Select the Server Certificate, right-click and choose properties
  • Open tab 'Certification Path'
  • Select the Root CA and click 'View Certificate'
  • Open tab 'Details' and click 'Copy to File...'
  • Choose to export the certificate in .P7B format

Next extract the .pem format certificate on your Linux using openssl:

openssl pkcs7 -in <rootca_filename>.p7b -out <rootca_filename>.pem -inform DER -text -print_certs

and place it under /etc/ssl/certs

You can test the certificate against your AD servers using openssl: (this should return verify result: 0 (ok))

openssl s_client -connect <AD server address>:636 -CAfile /etc/ssl/certs/<rootca_filename>.pem

Next, create hash links to the certificates:

# Create hash links to the certs
cd /etc/ssl/certs
c_rehash

Now the openssl test should work (verify result: 0 (ok)) without -CAfile option:

openssl s_client -connect <AD server address>:636

Next, create a CA bundle, as some applications only work properly with a bundled file of CAs (notice that *.crt is assumed be your CA certificates):

for i in `ls *.pem`
do
     cat $i >> /etc/ssl/certs/CA-bundle.crt
done

Finally, add the trust to openldap's client configuration:

  1. Edit /etc/openldap/ldap.conf
  2. Add the following lines:
TLS_CACERTDIR   /etc/ssl/certs
TLS_CACERT      /etc/ssl/certs/CA-bundle.crt

Solaris 10 and OpenSolaris[edit | edit source]

TODO.

Windows Server 2003 and 2008[edit | edit source]

PHP LDAP support[edit | edit source]

If you're fortunate enough to be running WAMP, enable the LDAP extension via the WAMP Manager.

TODO: How can I check if my Wiki is running WAMP? How can I enter WAMP Manager?

If not, see the FAQ entry for this.

Certificate trusts[edit | edit source]

First, see the example of how to get CA certificates using openssl to get the CA certificates needed for the trusts.

Next, create the file and directories: C:\openldap\sysconf\ldap.conf. ldap.conf must be at that exact location, as it is compiled into PHP in the Windows installer.

Next, concatenate all certificates you got using openssl, and place them into: C:\openldap\sysconf\certs.pem.

Next, edit ldap.conf and add:

TLS_CACERT C:\openldap\sysconf\certs.pem

Finally, restart IIS/Apache.

FreeBSD[edit | edit source]

To Do.


Mac OS X[edit | edit source]

Follow the directions for RedHat Linux but put the certificates in the /System/Library/OpenSSL/certs directory and create a combined CA. You shouldn't need the hash links. (<-- needs translation into English)

vi /etc/openldap/ldap.conf and add:

TLS_CACERTDIR /System/Library/OpenSSL/certs TLS_CACERT /System/Library/OpenSSL/certs/CA.crt