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

  • For our multisite environment, the 0.6 version of the ADAI plugin came at just the right time. We are getting ready for a fall launch of our WordPress environment at Princeton, and as soon as I upgraded to 0.6, everything worked like a charm, including SSL.

    We do have a fringe issue. This issue won’t prevent us from using the plugin. This might be too unique of a problem to justify a change to the plugin, but I thought that I would explain the issue we are having to see if a workaround was possible.

    We have an organizational unit within our directory, in which all of the uid values are email addresses. These are part of our guest account system for provisioned users outside of our university. All Princeton users have a normal uid, for example, mdmuzzie (me). An example guest account user might log in as (also me).

    For our normal AD accounts, the uid is the same as the sAMAccountName. For my example guest account, the uid is but the sAMAccountName is guest100000000002032.

    I already added a filter to the wpmu_validate_user_signup function in ms-functions.php to allow the period and the @ sign, so I was able to manually add my test guest user to the system. However, that user cannot authenticate, and gets the debug message “…[2] Authentication failed [3] Storing failed login for “”

    For all users, authentication does not work at all unless I configure ADAI to “Append account suffix to AD usernames before being validated,” using the string “”

    So what I suspect is happening is that the test user is being sent to AD as

    What I think might solve this would be an alternate option to “Prepend account prefix to AD usernames before being validated” (instead of the suffix). Then I could use the string “PRINCETON\”

    In our other systems PRINCETON\ authenticates just fine.

    Does this make sense, or is there a simpler workaround? Are we unique in our use of @ signs in guest usernames?


Viewing 15 replies - 1 through 15 (of 18 total)
  • Plugin Author Curtiss Grymala


    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 “”, 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 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?

    Plugin Author Curtiss Grymala


    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; they would still just login to WordPress using username (the plugin automatically appends the to the username they enter when you have that option enabled).

    If the user’s are having to enter 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 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 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

    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.

    Plugin Author Curtiss Grymala


    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 only. Hopefully that explains my plight better. My apologies for the confusion.

    Plugin Author Curtiss Grymala


    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?

    Plugin Author Curtiss Grymala


    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 (

    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.

    Plugin Author Curtiss Grymala


    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?

    Plugin Author Curtiss Grymala


    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. 🙂

    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 ;{

Viewing 15 replies - 1 through 15 (of 18 total)
  • The topic ‘[Plugin: Active Directory Authentication Integration] Usernames with @ signs’ is closed to new replies.