Examine and resolve username and related case sensitity issues

Just committed the suggested fix. Thanks.

This change introduced unwanted behaviour:

- Logging in with username "user1" works if the CN of the user is cn=user1,dc=foo,dc=bar
- Because of the strtolower, "UsER1" also works to login
- However, since _ldapgroups_detect_groups does NOT change things to lowercase, the LDAP groups get only mapped for users with the exact case match

Result:

- User 1 logs in with "user1" and has every LDAP group-related permission as expected
- User 1 logs in with "User1" and has no permissions other than "authenticated"!
- If the user logged in with a wrong-case username first, this user has to be actively deleted from the Drupal admin pages before the proper group-related rights are restored with a fresh login with the proper case

This can be solved by:

1) removing the forced removing of case since it produces unwanted behaviour. If ActiveDirectory really needs this to work, it might be worth making it an option.
2) making the LDAP group membership comparison also case insensitive, via something like this:

130         $entries = $_ldapgroups_ldap->search(
              $branch, 
              $ldapgroups_entries_attribute .'='. strtolower($user->name), 
              array($ldapgroups_entries_attribute));

In our environment, we chose for option #1 because this makes the most sense. Most other systems relying on this LDAP authentication are case sensitive, so it only causes confusion to allow deviations for some platforms.

After reviewing once more the issues we are seeing that are caused by this "fix", I guess it should be reopened, rather than setting it to "needs work". It introduces explicitly unwanted and incorrect behaviour.

I tried to research this to find something definitive, but did not find anything.

A possible suggestion would be to add a UI checkbox option and add some switching code in the group detection to be case sensitive on the user ID or not.

If there would come such a checkbox in a later release, it'd have to toggle both the login and group case sensitivity; it doesn't really matter *if* the system uses a strict case or not, as long as both routines are doing it the same way (which isn't the case at the moment). Such an option would be nice though; it'd solve this obscure bug once and for all. It's most strange that the original change ever went through; it may have made life for Active Directory users a bit easier, but it broke other (properly case sensitive) directory services. :-)

Bump... any news on whether or not this will be fixed in the next release of 6.x or 7.x?

My thought is that if I was making a change, I would elect to not change the case of user input data unless there is a good reason for it. Is this a convention to lowercase userIDs in Drupal before checking them against the saved password during authentication? I would be happy to test option #1, don't change the case and let those chips fall where they may.

I believe drupal core is inconsistent on this. I don't think it lets you have two different usernames with only case differences, but I think the username is stored in mixed case.

Drupal 7 handles user name with inconsistent case sensitivity. See #1398830: LDAP Authentication: Login case sensitive.

Doing some research on this... and am pretty sure that the existing code and modern LDAP servers (e.g. ones that follow the 2006 RFCs) will not have problems unless some really strange schema or group structures are being used. Here's my analysis / testing results around this.

Re: Drupal 6 user name case handling.

Drupal is not inconsistent with the default use of user name case. The user module's register process and authentication process both create queries that are case insensitive. So, the core behavior of Drupal is to be case insensitive on user names but to store the case as entered.

In addition the core user_load function wraps the values in LOWER() SQL functions. So having two users entries in the table with only different case names is a security nightmare since you can't be sure which one the DB ordered up first.

LDAP_Integration should follow Drupal's core rules and I think it does assuming the 2006 standards and common attributes used to define. Here's why:

The filter lookup for finding ldap entry from the user name entered will most likely be case insensitive base on the common attributes used for user names. E.g. cn, uid, and sAMAcountName are defined by the standards to be case insensitive. (NOTE: I seem to remember that uid MIGHT have been case sensitive in the past). Unfortunately, this might break if someone is using an odd or homegrown attribute that does not allow this... in this case users will have to enter names with the correct case.

Authentication checks are done using the dn found with via the search and password - No case issues here since this is direct from the ldap server.

New user names in the current code are assigned using the value of the user name attribute. The user entered name is only used as a last resort if for some reason the value is not returned. This should never happen unless something is really borked up. So, the Drupal rules of keep the name case is followed here... and this will always match the LDAP attribute regardless of the attribute's matching rules.

Re: Group assignment problems

This one is trickier... because LDAP's equality is based on the attributes... and in the case of dn's... the attribute rules for the components.. e.g. cn=Foo Bar, ou=People, o=My Corp, dc=mycorp, dc=com has to follow the equality rules for cn, ou, o, and dc in comparing each part.

However, the current ldapgroups code, first uses "group entry attributes (e.g. uniqueMember)" = $user->ldap_dn as a filter. This should match regardless of the subcomponent matching rules since that value is direct from the LDAP server and untouched. So, group members defined by dn should work... unless they are being defined in some odd relative way.

Only if that fails does $user->name come into play... but by this time, the user name will be defined as exactly the same as the user attribute is in the LDAP database. This should match any group attribute values... even if they are case sensitive... unless the LDAP directory is doing something odd.

Problem duplication

In addition to looking at just looking at this, I've tried to reproduce this using the current dev code and can't get it to fail. Of course, this could be due to LDAP server differences and different attributes, etc. But give the dissertation above, I strongly doubt it.

I'm marking this closed (Works as designed). If you are still seeing problems with the latest dev code, please re-open with specific details about your LDAP server type/version and the settings you are using.

If your group attributes are not using full dn's (i.e. something other than member or uniqueMember), first make sure that your user names in the Drupal table match case with the user name attribute values. Users created with older code may not and this may be the problem.

thanks for the writeup. We are setting up an ldap server just for testing ldap modules. It will run on unix and be openldap I suppose with a variety of hostnames depending on how the ldap is implemented. eg. openldap.ldap.pixotech.com, novell.ldap.pixotech.com. They will run be read only and have the same ldiffs/fake data as the unit test in ldap 7. Hopefully they will be useful for testing some of this implementation specific stuff.

If anyone has a windows sandbox or production server that can run a simple Active Directory implemented to Microsoft specs more or less that would also be helpful in this effort.

FYI - I have to live in a WAMP world... (IT limits OS support, sigh... but they are the ones who get called after hours and need to be able to fix it quickly).

So, my testing is done against Apache's Directory Server (OpenLDAP Java based alternative) and our R/O ActiveDirectory production server.

Most of the heavy testing is done against Apache DS since I can setup/test the condition better but if it can be tested against AD I try.