Translates the WordPress user database to an LDAP store of the same; manage your LDAP DIT using your WordPress Dashboard.
Installation Instructions
For most systems, WordPress’s automatic plugin installation will correctly install WP-LDAP. However, you can also install the plugin manually by following these steps:
- Upload and unzip the
wp-ldap.zip archive to your WordPress install’s /wp-content/plugins/ directory.
- Network-activate the plugin through the Network Admin → Plugins menu in WordPress. Again, the plugin must be network-activated.
- Configure your LDAPv3 server address and authentication parameters in the Network Settings admin screen:
- Enter the LDAP URI referring to where your server is listening for connections. (Only
ldaps:/// is usable for remote connections; an unsecured ldap:/// connection URI will only be accepted if the server IP address is 127.0.0.1. Please read the remarks at OpenLDAP Administrator Guide ยง Security Considerations for more information.)
- Enter the binding DN and its password.
- Optionally, enter a custom search base, or accept the default. (The default for a WordPress Multisite at
example.com is dc=example,dc=com.)
Requirements
- PHP 5.3 or later is required, as WP-LDAP makes use of PHP Namespaces.
- The PHP LDAP extension must be installed. On a Debian system, this is usually as simple as running
sudo apt install php-ldap. The plugin will automatically deactivate itself if this requirement is not met.
- Your WordPress installation must be configured as a Multisite instance. (WordPress single-site installs are not currently supported.)
- You must be able to bind to an LDAPv3 directory server. (LDAPv2 is not supported.)
- To configure the LDAP connection over the Web interface, you must be able to serve your website over HTTPS. (Unsecured HTTP Web-based configuration is not supported.)
Configuration
If your web server does not serve pages over HTTPS, you will need to use the WP-CLI or the mysql command-line client to configure the plugin as follows:
mysql> SELECT meta_key,meta_value FROM wp_sitemeta WHERE site_id = 1 AND meta_key LIKE 'wp_ldap_%';
+------------------------+----------------------------+
| meta_key | meta_value |
+------------------------+----------------------------+
| wp_ldap_bind_dn | cn=admin,dc=example,dc=com |
| wp_ldap_bind_password | password |
| wp_ldap_connect_uri | ldaps://ldap.example.com/ |
| wp_ldap_search_base_dn | dc=example,dc=com |
+------------------------+----------------------------+
Of course, you should replace the specific details shown above with values appropriate for your deployment. You should also consider configuring your LDAP server such that the bound DN has restrictive access controls enforced on it, as its password must be stored in the clear within WordPress’s database for the plugin to function.
Security
The extreme convenience this plugin offers makes it even more important that you take your LDAP DIT’s security seriously. Here are some highly recommended additional configuration steps you should take if setting up a directory server for the first time.
OpenLDAP slapd(8) will by default listen on both the IPv4 and IPv6 “any” address, exposing your directory contents to the Internet if you have not configured a firewall. Worse, the unsecured ldap:// protocol is used out-of-the-box, which will further expose the contents of LDAP traffic to eavesdroppers. This is almost certainly not what you want.
This is bad, and not what you want to see:
$ sudo netstat --listening --numeric --program --tcp | grep slapd
tcp 0 0 0.0.0.0:389 0.0.0.0:* LISTEN 20244/slapd
tcp6 0 0 :::389 :::* LISTEN 20244/slapd
$ ps -ef | grep slapd | head -n 1
openldap 12932 1 0 03:28 ? 00:00:00 /usr/sbin/slapd -h ldap:/// ldapi:/// -g openldap -u openldap -F /etc/ldap/slapd.d
The above shows us that slapd is listening for incoming TCP network connections on its default port (389). This is happening because slapd was invoked with the -h ldap:/// option.
In contrast, this is good, and what you probably want to see instead:
$ sudo netstat --listening --numeric --program --tcp | grep slapd
tcp 0 0 127.0.0.1:389 0.0.0.0:* LISTEN 20282/slapd
tcp 0 0 0.0.0.0:636 0.0.0.0:* LISTEN 20282/slapd
tcp6 0 0 :::636 :::* LISTEN 20282/slapd
$ ps -ef | grep slapd | head -n 1
openldap 20282 1 0 10:51 ? 00:00:00 /usr/sbin/slapd -h ldap://127.0.0.1:389/ ldaps:/// ldapi:/// -g openldap -u openldap -F /etc/ldap/slapd.d
The above shows us that slapd is still listening for connections on any configured IP address, but only with the secured ldaps:// scheme (LDAP over TLS). It is still accepting unsecured connections, but only on IP address 127.0.0.1, the local host. This means cleartext LDAP traffic is not transiting the network; it is contained within the machine itself, only traveling over the loopback interface.
On a typical Debian GNU/Linux system, you invoke slapd as sudo service slapd start (which runs the /etc/init.d/slapd script). This sources the file at /etc/default/slapd to set the invocation arguments. Look for the SLAPD_SERVICES variable in the /etc/default/slapd file and set it to sensible values, as shown above, to make the change persistent across system reboots.
