Why Use Active Directory with WordPress?
I recently set up a WordPress Blog internally for our company to use over our intranet to help improve communication, collaborate, share and develop ideas, and stay informed about company announcements or current events.. etc.
One of the requirements I had was to allow authentication against our Active Directory. Yes, we operate a Windows network primarily, but you can also authenticate against other LDAP directories as well. This was important from an IT position as well as the participants of the blog. I felt people would be more likely to participate if they didn’t have to manage separate user accounts for each service on the intranet. I also set up a Wiki that is Active Directory enabled. I’ll post about that at a later time. The point is, it makes little sense to create different credentials for each user with each new service. It not only becomes a hassle for IT to track and manage the accounts, it’s also a drag for participants to keep track of and manage their username and password pairs for each service. The result would most likely lead to lack of use and that is not what we want.
Integrating the existing Active Directory accounts means that each participant can access these services using the same credentials they use to access or log into their network accounts and desktops. When time comes to change passwords, you need only to update the Active Directory account and your done. Simple! What could be better?
Starting Point
The first thing we needed to do was find out how to include AD Authentication with WordPress 2.5. There are a small number of plugins that claim to allow AD Authentication, but from what I came across, most of them were older and no longer actively maintained. But…there were two in particular that still showed signs of being actively maintained and had promise.
The first was was aptly called “Active Directory Authentication”
The other plugin and the ultimately the one I managed to successfully include is wpDirAuth.
The Trials
Although I was able to get wpDirAuth to work with WordPress 2.5, there was a catch. The current “Official” release of wpDirAuth as of this writing is version 1.2 which is not compatible with WordPress 2.5 so there was some work involved to make this happen. I visited the wpDirAuth plugin page to look at the install directions. They seemed easy enough. It wasn’t until I actually installed and activated the plugin that I realized it wouldn’t work. My next stop was the support channel that the author set up to help troubleshoot install and authentication issues. It was here that I learned there was a patch already available and provided by a generous wpDirAuth user – Adam Yearout. I applied the patch and then tried to login with my network credentials again, and … No luck! By now I was scratching my head. Searching and reading all the information I could find, I finally found myself on the wpDirAuth Developer Support Channel. This was another channel set up specifically for developers. It was here that I uncovered some clues as to what was happening and a small code tweak that was necessary to overcome the problem. Apparently, the author of the plugin assumed that the login name was also the name associated with the Active Directory Account Email, which in most cases is true, but not always. For example username: johndoe would by default have an email johndoe@domain.com. In my case, my email and name and login name were not the same, so the logic that the plugin author used would not work. The good news is that the fix is a fairly simple one if you know where to look and the dev channel contained all the clues needed to find the info.
Setting up wpDirAuth with WordPress 2.5
For this how-to, I am using wordpress 2.5 installed on an Ubuntu 8.04 LTS server With Apache2 and PHP5. There is no GUI and I am not running an ftp server on this server so all settings and changes are completed using putty over SSL.
So lets get to it. Setting up AD Authentication was not as straight forward as I had hoped and required a few extra steps along the way.
The first step is to download the wpDirAuth plugin from the WordPress plugins section.
From a terminal or if logged into the server via Putty, change to your home directory and get the latest version of the wpDirAuth plugin.
wget http://downloads.wordpress.org/plugin/wpdirauth.1.2.zip
sudo apt-get install unzip
before you can extract the files.
Next extract the files by executing:
Now you have a new directory called wpdirauth.1.2 in your home directory.
Move into the new directory and list the contents using
ls
Now you will see the wpdirauth directory. You need to move this entire directory to your WordPress plugins directory.
To move the extracted wpdirauth directory, make sure you are in the wpdirauth.1.2 directory and execute the command:
Now we need to move into the actual WordPress Blog directory where our files are hosted by executing the command:
Now if you execute
you should see the wpdirauth plugin folder. Once again, we will change directories and move into the hosted wpdirauth directory using:
This is where the editing (and the fun) begins.
Remember, we need to make some changes before we activate this plugin in WordPress 2.5 or it will not work.
Patching the wpdirauth plugin
Before making any changes to our files, it’s alway a good idea to make some backups.
From the wpdirauth execute the command:
Next apply the patch that was just downloaded. This patch will make changes to the wpdirauth.php file, and update the Plug-in version for 1.2 to 1.3
Apply the patch by executing the command:
sudo apt-get install patch
Editing the plugin
Once the patch is installed, your Active Directory authentication should for most people. But we are not done yet.
There is an issue related to Active Directory users names and their email addresses. Active Directory user accounts that are also created with an email address, are by default given an address equal to the login name.
For example an Active Directory user created with a login name of johndoe would have an email address of johndoe@domain.com. The problem arises in the way that wpDirAuth authenticates against Active Directory using the email address. If at some point, the users default email address is changed, the login name does not match the email address and authentication fails. The fix is a simple one if you know where to look.
To prevent authentication failure due to the login name and email mismatch, you need to make a small edit to the wpdirauth.php file. Start by executing the following command:
Next, scroll through the file till you find the wpDirAuth_auth() function at line 246. It should be about 1/4 of the way down the page. Edit this function as follows:
At about line 273 find the line
and delete or comment it out.
Next move down to about line 284 and look for the line that reads:
Add a new line after this and enter the following:
Basicly, we are just moving the line “if ($accountSuffix) $username .= $accountSuffix;” down a few lines and adding it after the line ” $filterQuery = “($filter=$username)”; ”
This is the snippet of the the wpDirAuth_auth() function after I made the changes look like this.
{
….<PHP Code Lines removed for sample>….
/**
* This section commented out to enable AD email/username mismatch.
* if ($accountSuffix) $username .= $accountSuffix;
*/
/**
* Only setup protocol value if ldaps is required to help with older AD
* @see http://groups.google.com/group/wpdirauth-support/…
*/
$protocol = ($enableSsl) ? ‘ldaps://’ : ”;
if (!$filter) $filter = WPDIRAUTH_DEFAULT_FILTER;
$filterQuery = “($filter=$username)”;
/**
* Next Line added to enable AD email/username mismatch
*/
if ($accountSuffix) $username .= $accountSuffix;
// Connection pool loop – Haha, PooL LooP
foreach ($controllers as $dc) {
….<PHP Code Lines removed for sample>….
Activating the Plugin
One requirement that may still be missing is php’s LDAP support. If you do not already have support for LDAP enabled in php, you will need to enable it before you can authenticate against the Active Directory.
To enable LDAP in PHP, execute the following command
At this point, and assuming everything went well, it’s time to log into your WordPress Blog as the WordPress Admin and navigate to the “settings” page. From here, you will see a “Directory Auth” link at the top of your settings page. click this link to access the Directory Auth setup page and fill in the required fields as they apply to your Active Directory set up.
Enable Directory Authentication = yes
Require SSL Login = Yes if you use SSL Auth, No if you do not.
Enable SSL Connectivity = yes if you are using SSL or LDAPS connections, No if you are not.
Directory Servers (Domain Controllers) = DNS Name or IP Address of your Active Directory Domain Controller
Account Filter = samAccountName or field to search the username to locate the directory profile. For AD, samAccountName should work.
Account Suffix = @yourdomain.com – This is the suffix for you local domain usen in email addressing in the AD for you local network.
Base DN = DC=domainname,DC=com – Note this will vary depending on you local network and complexity of your AD
Bind DN = Blank if you allow Anonymous Binding to your Directory or a username use to pre-bind if you do not.
Bind Password = Blank if you allow Anonymous Binding to your Directory or the password of the user used to pre-bind if you do not.
The remainder of the fields are self explanatory and are not critical to successful authentication.
Now save the changes and log out of the WordPress Admin account.
Next attempt to login to WordPress using an Active Directory User Account.
You should now have Active Directory Authentication enabled and working with WordPress.
Remember, your mileage may vary depending on your specific needs and existing network and Active Directory structure.
Have any other tips, or want to share your experience with AD authentication in WordPress? Leave a comment.
Thanks for this. I got it working with WP 2.6.1 on Apache 2.2.9/Win2003 and our AD. By the way the patch is available for download at http://www.royal.wednet.edu/~ayearout/wpDirAuth-1.2-to-1.3.patch
And if youre on a widnows server then you’ll need to download the open source version of the “patch” program from http://gnuwin32.sourceforge.net/packages/patch.htm