title: wpDirAuth link: https://onemoretech.wordpress.com/2015/09/09/wpdirauth/ author: phil2nc description: post_id: 10092 created: 2015/09/09 10:09:45 created_gmt: 2015/09/09 14:09:45 comment_status: closed post_name: wpdirauth status: publish post_type: post

wpDirAuth

The wpDirAuth plugin for WordPress provides LDAP authentication capability to single and multisite blogging environments. I'm still trying to decide whether or not this is such a good idea. There are a number of plugins that claim to integrate WordPress with LDAP for authentication purposes. Most of them don't. In fact, some fail spectacularly. But wpAuthDir works, at least with a generic, standards-compliant LDAP directory like OpenDJ. My reservations about using this plugin are mostly due to (a) the fact that while it looks like an enterprise SSO solution, it is not; and (b) it will almost certainly require a high level of attention from web site system administrators.

Configuration

In a multisite WordPress instance, configuration of the plugin is done from the multisite Network dashboard, under Settings... wpDirAuth. The plugin is also enabled at the Network level. An LDAP directory server hostname (and port if other than 389/636), login attribute (called an "Account Filter"), basedn and optional binddn and password are entered on the configuration page. The plugin is slightly Active Directory-centric, using samAccountName as the default login attribute. In most configurations uid (the LDAP attribute usually employed for user login names in non-AD LDAP deployments) would be explicitly set as the "Account Filter" instead. Selecting LDAPS (LDAP over SSL) had mixed results in testing, but should be possible (this is due to the poor implementation of php's LDAP client, not the plugin itself).

WP Login and Account Creation

Once enabled, wpDirAuth will create a new WP user account for each successfully logged in user. In creating the WP account the plugin provides WP with the user's first and last names (givenname and sn) from LDAP, as well as their e-mail address (LDAP mail) and a nickname created by stripping the "@domain" component from the email address. It also sets a meta_key ("wpDirAuthFlag") and meta_value ("1") in the wp_usermeta table to flag the account as LDAP authenticated. Existing users are not affected by the plugin, and can continue to log in with their local WP account password. They will only be able to use their LDAP password when the above-mentioned meta_key and meta_value is associated with their WP user_id. There is no gui to make this change, it must be done with a SQL query against the WP database.

What wpDirAuth does not do

The plugin does not provide an SSO solution. The user does not receive a cookie or token that can authenticate them to another WordPress instance, even if that instance is also configured to use LDAP authentication. There is no password management facility provided by the plugin. WP's standard password change mechanisms are not affected by enabling the plugin. LDAP-enabled users who attempt to change their passwords using WP's built in methods will be sorely disappointed: changes to the password stored in the WP database will not affect their LDAP login as any such change is not being made on the LDAP directory.

Adding the wpDirAuthFlag to Existing User Accounts

The SQL for this is straightfoward. Here is an example: [code language="sql" gutter="false"] insert into pablogs.wp_usermeta (user_id,meta_key,meta_value) values('2','wpDirAuthFlag','1'); [/code] Note: the umeta_id key and value are not included in the query, as umeta_id is configured in the database as a non-NULL integer value that increments automatically. This query can be use to identify all the users who have the flag set: [code language="sql" gutter="false"] select user_id from pablogs.wp_usermeta where meta_key = 'wpDirAuthFlag'; [/code] Note "user_id" here is not the same as "user_login" (e.g. "c123456" or "plembo", I favor numeric system IDs over e-mail addresses or aliases because the uniqueness of the latter can't be guaranteed -- making them useless for building audit trails over long periods where staff turnover results in reuse), but a sequential number assigned to the user's account at the time of creation. For most systems backed by a standards-based (non-Microsoft) LDAP directory "user_login" would be their login name (usually LDAP uid) with a leading lowercase letter (this matters to WordPress and the plugin because they rely on Unix system ID naming conventions, whereas real LDAP servers always treat attribute names case-insensitively). The mapping of user_id to user_login values can be found in the wp_users table.

Copyright 2004-2019 Phil Lembo