Oh wow, don’t everybody post at once. ;p
(note: I’m stephdau, posted from wrong account…)
I’m willing to help you test out authentication via LDAPs, but I’m brand new to WordPress (downloaded this afternoon). I put wpDirAuth.php in the wp-content/plugins directory and according to the wp-admin/plugins.php page, it’s activated. How do I set it up with the proper information for my LDAPs server?
OK, I figure out that the secret is to deactivate the plugin and then look for the setup menu in options. Do I need to do anything in wp-config.php to enable this?
Hi there,
First, thanks for giving it a shot. 🙂
I haven’t had time to write the readme yet, so here it goes:
Installation:
– create as follow [wordpress_root]/wp-content/plugins/wpDirAuth/
– drop wpDirAuth.php in the latter directory.
– go to http://[wordpress_install]/wp-admin/plugins.php and activate the plugin
– go to http://[wordpress_install]/wp-admin/options-general.php where you should now see a menu entitled “Directory Auth.”
– click it and it should take you to the plugin admin screen, most likely located at http://[wordpress_install]/wp-admin/options-general.php?page=wpDirAuth.php
I’ve been debating having the menu under the plugin section instead, but also being new to WP, I’m not sure if there are backward compatibility issues and if having the admin tool in the Options section is better. To be debated. 🙂
In case it comes up, one of the reasons that I’m not using OO on this one is primarily due to the limitations of OO in PHP4, which WP still supports (probably at least for a few more months, until php.net drops their own support of php4 [sched. for around 2008-01-01]).
Let me know how it goes.
I also just launched a plugin hosting request to http://dev.wp-plugins.org/ so we can get access to svn and Trac project management tools there.
Thanks for the information. I misunderstood the plugins form, I thought that it was showing me the state of the plugin “Activate”, when it was really showing me a command button. I got the plugin activated. The login window is slightly different (but doesn’t have the text that I keyed into the “branding” section of the plugin setup.) It also recycles almost immediately and doesn’t let me log in. The is a new hyperlink at the bottom of the page “please access the encrypted version of this page” which seems to have a zero refresh: <meta http-equiv="refresh" content="0;url=" /><p>Please access the <a href="">encrypted version</a> of this page.</p></form></div></html> but no url is in the link. I tried to change the page to use https:// but I get the same constant reload. https is set up on the web server and works just fine. Is there some other plugin or configuration setting that I missed?
I was able to get a little farther by disabling the “Require SSL Login” settings in the wordpress settings section of the plugin options of wpDirAuth. I now get the proper text label in the login box. I haven’t gotten a successful login through the LDAPs yet, but that could be a problem with our setup and I’ll check into it.
I evaluated a similar plugin: admin-ssl that does a https for logins and the admin pages. This plugin works OK for the SSL logins on my web server.
I believe that I figured out the problem with the login credentials failing. With our LDAP, in order to bind with a password, the ldap_bind “userid” (i.e second argument) needs to be the full dn, not just the userid. What I think needs to happen is to do an anonymous bind, use it to search for and return the dn, then use the dn as the second argument in the ldap_bind call with the password.
Are you by any chance using OpenLDAP?
I wonder if an update to the ldap_bind call similar to the one linked to below would help:
http://ashay.org/?page_id=133#comment-558
I’ll see if it works in AD.
I glanced at the post. I am using OpenLDAP (on Linux). The problem is for our LDAP is that the DNs are not the same for all users. We also have an “l=” parameter (location??) that will differ depending on the user. Mine is l=US others have l=GB, etc. The users wouldn’t necessarily know about this parameter. I wrote a simple php routine to test out ldaps and I couldn’t bind with password without the l=US in my DN. I’ll do some more experimenting tomorrow when I get into work.
The snag I’m hitting with implementing the solution you suggested is that on my side, my dir server won’t let me search without binding… The old chicken and egg thing. 🙂
Soooo, what I did was to try and couple both approaches.
Since there was already an anonymous bind being performed in the connection pool loop, I’m trying an anonymous search on success, trying to retrieve the targeted user’s full dn.
If the profile is located, user binding is performed with the full dn, or we try the sent username instead.
See lines 363-368 in the updated version available in SVN.
Is that solving it for you?
On another note, could you post details about your setup?
OS, dir server type, ldap configs with “Blah Corp” instead of your company’s info where it matters, etc?
PS: I’m in Montreal, and can only devote time to this in the evening, hence my posting timeframe. 🙂
Oh, hadn’t refreshed the page before posting my last comment and I missed your added info.
The code I added will only really help if the username we search for anonymously matches the unique identifier defined in the account filter. This actually translates to sentUsername + accountSuffix if setup in the wpDirAuth prefs [optional].
Here’s an example which might help you with part involving locating the user’s profile, whether for dn pre-mapping (added code), or binding:
In what I’ve seen in other php/ldap related code, people seem to default the field on which we try to locate the profile with to samAccountName (hence the default in wpDirAuth), which seems to be assumed to be the same value as the username used to bind with.
In my context, the samAccount is in one form, but the username used to bind (first.last@myDomaincontroller, not full dn) with simple auth actually matches a field named userPrincipalName.
So in my setup, I expect users to enter first.last@myDomainController, leave the Account Suffix pref empty (since we have multiple ones), and set my Account Filter to userPrincipalName.
As an aside, I’m realizing that I need to make sure the added code didn’t open a hole if the anonymous search returns more than one entry, since we ultimately default to entry[0] when returning to wp_login.
SVN Rev. #308
Added extra security check to make sure only one account is returned during the profile search in wpDirAuth_auth, before returning to wp_login. Better safe than sorry.
SVN Rev. #309
Extra error checking and handling tweaks + cleaned up error messages format for easier future localization.
