How can I set up Redmine => Active Directory authentication?

First, I'm not an AD admin on site, but my manager has asked me to try to get my personal Redmine installation to integrate with ActiveDirectory in order to test-drive it for a larger-scale rollout.

Our AD server is at host:port ims.example.com:389 and I have a user IMS/me.

Right now, I also have a user me in Redmine using local authentication.

I have created an ActiveDirectory LDAP authentication method in RedMine with the following parameters:

Host: ims.example.com
Port: 389
Base DN: cn=Users,dc=ims,dc=example,dc=com

On-The-Fly User Creation: YES
Login: sAMAccountName
Firstname: givenName
Lastname: sN
Email: mail

Testing this connection works just fine.

I have, however, not successfully authenticated with it.

I've created a backup admin user so that I can get back in to the me account if I break things, and then I've tried changing me to use the ActiveDirectory credentials. However, once I do, nothing works to log in. I have tried all of these login name options:

• me
• IMS/me
• IMS\me

I've used my known Domain password, but no joy.

So, what setting do I have wrong, or what information do I need to acquire in order to make this work?

From serverfault Chris R

• I have no familiarity with Redmine, but it sure looks like you're trying to do an anonymous bind to Active Directory to validate credentials. That's not going to work. Having configured multiple products for LDAP integration with AD, this is a common problem that I've seen.

  Out of the box, AD requires that clients authenticate when binding to the directory to perform queries.

  Have a look at this Redmine wiki posting re: configuring LDAP authentication. They're talking about specifying an account and password for Redmine to use (one that has rights to read the directory-- a plain ol' "Domain User" will do) to bind to the directory.

  Chris R : What form should I put the username in? They don't really explain that in the wiki posting (which was my starting point for this process anyway)

  Chris R : Specifically, I tried `IMS\me` and it didn't seem to work. I can't get any details on _why_ it's failing, either.

  Evan Anderson : I'd specify the bind username in DOMAIN\samAccountName syntax. As far as figuring out *why* it's failing, I'd recommend getting a sniffer (tcpdump, wireshark, built-in Microsoft "Network Monitor", etc) out and bringing that to bear on the problem. There's no quicker way to figure out what's being said on the wire than to look at what's being said on the wire. (It sounds silly, but a lot of people don't ever think to look there...) Then, at least, you can see if the parameters you've specified are being passed as you expect them to be.

  Chris R : Wireshark is turning out to be a godsend here. Thanks for that tip. I've found some issues for it, and I'll be coming through and posting the details shortly.

  Evan Anderson : Seeing what the boxes are saying to each other makes the cause of a lot of problems instantly clear. Glad to hear you got it working!
  From Evan Anderson

• Okay, so here are the specific settings that I needed in order to make this work:

  Host: ims.example.com
  Port: 389
  User: MYDOMAIN\accountName
  Password: *******
  Base DN: dc=mydomain,dc=example,dc=com
  
  On-The-Fly User Creation: YES
  Login: sAMAccountName
  Firstname: givenName
  Lastname: sN
  Email: mail
  

  The trick was removing cn=Users from the Base DN, after which it all sort of came together.

  The other notable thing was the inclusion of a user to read the directory.

  Lastly, the user that logs in uses their user name without domain qualification, and their domain password as usual. Our domain does not require an email address, so there is an additional step where the email address has to be set during user creation, but that's pretty straightforward.

  Evan Anderson : Ahh... I didn't even think about asking you if your user accounts were under the "CN=Users, ..." default container or not.

  Chris R : It would be more useful to know how _I_ could have determined that. I only arrived at this setup through trial and error.
  From Chris R

• Use an ldap browser and visually check the structure... luma on ubuntu works well, ldapper for the mac also.

  Chris R : It didnt't actually work with my LDAP server, but I can see how it'd be useful.
  From Neil