[Plugin: Active Directory Authentication Integration] Usernames with @ signs

Michael,
Thanks for the report. I’m definitely willing to add a feature like that to the plugin; but obviously I’ll need help testing it (since I’m not sure if our system will act the same as yours once we add the prefixes).

I’ll try to put together something that can be tested within the next few days, and I’ll update this post to let you know once it’s ready.

Thanks for the quick follow-up.
I would be glad to test anything that you can come up with.

I’m having a related issue although not “exactly” the same. Perhaps it is worth mentioning here. My school district just migrated to AD from OpenDirectory (for integration reasons). The problem I am having is that when I select the option to append a suffix to the username “@mydomain.org”, no one can log in. If I disable that option users can authenticate against AD no problem, but only if they input their userID in the form [email protected]. I prefer their user account to get created just as “username” and have them log in as such. I had no issues when using OpenDirectoy. This is a new WP setup so before I let users start logging in and having their accounts created, I would like to get this working properly. Perhaps there is something that I have overlooked, but This has been a straightforward textbook install. Thoughts?

If you use the “append a suffix” option, that suffix is only used in the database itself (and in the user list). If the user’s username is stored as [email protected]; they would still just login to WordPress using username (the plugin automatically appends the @mydomain.org to the username they enter when you have that option enabled).

If the user’s are having to enter [email protected] in order to login successfully, it sounds like you need to enable the “Append account suffix to AD usernames before being validated?” option and use @mydomain.org as the “AD Account Suffix” rather than (or in addition to) the “WordPress Account Suffix”. Once you do that, they should be able to login using just username, and the plugin will automatically send [email protected] to AD before trying to authenticate them.

In this plugin, the “WordPress Account Suffix” and the “AD Account Suffix” are handled completely separately. As far as I can tell, typical AD usage would require you to use something like @mydomain.local as the AD Account Suffix; but there are no requirements for the WordPress Account Suffix.

The WordPress account suffix option is there as a convenience, to help distinguish between users that were created automatically by the AD plugin and users that were created manually within WordPress.

@michael – I uploaded a new Development Version yesterday that seems to implement the functionality you requested, if you want to test it.

I tested it briefly on our server and it seems to work. It adds a new option “Prepend server name to username before being validated?”. Just make sure that the “Append account suffix to AD usernames before being validated?” is unchecked if you check that new option instead. Then, enter the prefix (PRINCETON\) into the “AD Account Suffix/Prefix” text field instead of using @pu.win.princeton.edu.

I will need to adjust the UI a little bit to prevent both options from being checked at the same time before I release it as stable; but I’ll wait until it’s been tested a bit more before playing with that.

Also, Michael, I’d love to talk to you at some point about what you guys are working on there at Princeton. It would be great to compare notes.

Curtiss – Thanks for the quick reply! The setup that you describe is indeed how I am using it unfortunately. I am not appending a suffix to newly created users. I have left that option turned off. When I turn on “Append account suffix to AD usernames before being validated” and enter the domain suffix information, users can not log in at all not matter what credentials they enter. When I turn that option off they can authenticate using [email protected] only. Hopefully that explains my plight better. My apologies for the confusion.

I just thought of something. What syntax are you using for your AD Username (the one that’s actually used to connect to AD)? I wonder if the suffix is being appended to that and stopping the connection from happening (which, in turn, would stop any user from being able to authenticate against it).

Curtiss. I’m no AD expert so I am learning each day. I’ve been looking for a utility that will let me diagnose in real-time LDAP connections to AD. NOrmal user authentication is just the username without and suffix. If I can find a way to view the LDAP conversation I can see what is going on. Do you have a suggestion?

I’m not aware of any good way to actually watch what’s happening in real-time; but you might be able to diagnose some issues by enabling the debug functions in the plugin. Information on doing that can be found in the last question of the plugin’s FAQ (https://www.ads-software.com/extend/plugins/active-directory-authentication-integration/faq/).

Thanks Curtiss. That did the trick. What was not apparent to me was that when appending the suffix to usernames, that it also appends it to the LDAP “bind user” sting. So my problem was not that the end user was not authenticating, it was that the LDAP lookup was failing because the binding account could not authenticate. I had put the full LDAP user context in the bind string cn=user name,cn=users,dc=mydomain,dc=org in the bind string and it worked great, so I was not suspect of it. Looking at the debug output made it apparent, then looking at the commented instructions on your configuration page made me realize that I violated rule #1, RTFM… Thanks for your help. It’s been a pleasure.

Awesome. Thanks for the update, ppoggione. Glad you got it working.

Please let me know if there are any additional changes or features you’d like to see (either in a new topic in the support forums or on my blog).

I had the exactly same situation as ppoggione.
I’m super happy to find this thread!

By the way, Curtiss, this plugin is awesome. Can I buy you a beer?

Thanks for the positive feedback, CreativeNotice. I’m glad you were able to get the plugin working, and I’m glad you like the plugin.

No need to buy me a beer; just keep helping to spread the word of how awesome and flexible WordPress is. ??

Hi,
please help
i am fresher on wordpress
i develop a site on wordpress but when anyone register on my site he/she get only subscriber account not author account holder, that means only authenticated to comment on submitted articles, not get permission to post articles.
please tell me where i need to change in php coding either wp_login.php page or any other page. what changes are needed.
please help me.

I am running into similar issues to @michael and tested the development version to no avail. If I run the following command via ldapsearch on the command line of the server I get a successful result (genericized of course):

ldapsearch -H ldap://domaincontrollerurl -b 'dc=domain,dc=tld' -D 'DOMAIN\Username' -x -w 'password' '(sAMAccountName=username)'

Could you possibly help with any of the following:

1. A way to see what the syntax of the calls to LDAP / AD are when attempting to login (to help with trial / error debugging of changing settings)
2. If I specify the DOMAIN\username in bind username and save parameters the \ is stripped out. Any way around that?
3. How to flag -x via settings in the dashboard and/or where I might add that in code as a short-term fix until next development version?

Thanks for making such a great plugin – or what appears to be as I can’t yet get it to fully operational to confirm that is the case ;{