1755: LDAP does not appear to support multiple login names for the same account (common with Mac OS X Server)

emai*****@gmai***** (Google Code) (Is this you? Claim this profile.)
Aug. 30, 2010 
What version are you running?
1.0.9

What's the URL of the page containing the problem?
http://private/codereviews/

What steps will reproduce the problem?
1. Set up a Mac OS X Server as an Open Directory Master (it uses OpenLDAP I believe).
2. Set up Review Board on another server.
3. Configure Review Board to authenticate via LDAP with the following settings.
LDAP Server: ldap://macosxserver.domain.com 
LDAP Base DN: cn=users, dc=domain,dc=com 
E-Mail Domain: 
E-Mail LDAP Attribute: mail 
Use TLS for authentication: unchecked 
User Mask: (uid=%s) 
Anonymous User Mask: 
Anonymous User Password: 

4. Log in using the "long name" of the user (i.e. "John Doe" instead of "jdoe").  This is the cn LDAP attribute I believe, but Mac OS X maps that to uid as well I think.
5. Log in using the "short name" (i.e. "jdoe").  This is the uid LDAP attribute I believe.

What is the expected output? What do you see instead?
I expected both 4 and 5 to log me into the same user (because they are the same user on Mac OS X Server).  Instead, Review Board treats these as separate users, and makes separate user entries etc. for them.

What operating system are you using? What browser?
Mac OS X 10.6.4 and Mac OS X Server 10.6.4.  Safari 5.0.1.

Please provide any additional information below.
I tried changing the User Mask to "(|(uid=%s)(cn=%s))", but I was no longer able to log in at all after that.

I tried editing reviewboard/accounts/backends.py like this.
1. Edit the LDAPBackend.get_or_create_user function (method?  my Python vernacular is poor...).
2. Change the line "user = User.objects.get(username=username)" to "user = User.objects.get(username__iexact=username)".
3. Delete reviewboard/accounts/backends.pyc.
4. Restart the web service (which is Apache 2 on Mac OS X Server I believe).
There was no change when I did these steps.
david
#1 david 
While the LDAP server may authenticate against it, Review Board uses "username". What do you suggest we look up other than the username?

This sounds to me like a bizarre behavior of the LDAP server, and not something which seems at all standard.
  • +WontFix
#2 emai*****@gmai***** (Google Code) (Is this you? Claim this profile.) 
Sorry for the super late response, somehow the bug slipped in under my radar.  I'm suggesting that after you authenticate a user, you request the user's distinguished name back from the LDAP server because it may be different from the user ID you used to authenticate.  It's how Mac OS X has worked for quite awhile, and it's what my users expect.  I don't think this is unusual in Active Directory environments either, though it's probably less standard in the Linux world.  You would want to do something like this basically.

$ ldapsearch -LLL -h macosxserver.domain.com -b "cn=users,dc=domain,dc=com" -x "(uid=John Doe)" dn
dn: uid=jdoe,cn=users,dc=domain,dc=com
#3 emai*****@gmai***** (Google Code) (Is this you? Claim this profile.) 
Sorry for the super late response, somehow the bug slipped in under my radar.  I'm suggesting that after you authenticate a user, you request the user's distinguished name back from the LDAP server because it may be different from the user ID you used to authenticate.  It's how Mac OS X has worked for quite awhile, and it's what my users expect.  I don't think this is unusual in Active Directory environments either, though it's probably less standard in the Linux world.  You would want to do something like this basically.

$ ldapsearch -LLL -h macosxserver.domain.com -b "cn=users,dc=domain,dc=com" -x "(uid=John Doe)" dn
dn: uid=jdoe,cn=users,dc=domain,dc=com
#4 emai*****@gmai***** (Google Code) (Is this you? Claim this profile.) 
Sorry for the super late response, somehow the bug slipped in under my radar.  I'm suggesting that after you authenticate a user, you request the user's distinguished name back from the LDAP server because it may be different from the user ID you used to authenticate.  It's how Mac OS X has worked for quite awhile, and it's what my users expect.  I don't think this is unusual in Active Directory environments either, though it's probably less standard in the Linux world.  You would want to do something like this basically.

$ ldapsearch -LLL -h macosxserver.domain.com -b "cn=users,dc=domain,dc=com" -x "(uid=John Doe)" dn
dn: uid=jdoe,cn=users,dc=domain,dc=com