LDAP case-insensitivity leads to duplicate accounts

[shizmob]

First of all, thanks a lot for your work on Davis, it's been very useful so far.

As per X.520, which describes some common attributes as used in LDAP, sometimes attributes used to construct an LDAP DN, like uid (§6.17.1), are case-insensitive.

In my setup, uid is the primary way users are addressed in a DN:

AUTH_METHOD=LDAP
LDAP_DN_PATTERN=uid=%u,ou=people,dc=redacted,dc=com
LDAP_MAIL_ATTRIBUTE=mail

As the username on Davis's side is case-sensitive, this leads to a nasty side-effect: the casing used by the user matters when logging in!

When logging in with the username shiz, the system will not find a user with that name in the database, branch out to LDAP to retrieve the user, and succesfully auto-create the user. So far so good. However, if the user later attempts to log in with the username Shiz, this process will repeat and a duplicate user Shiz will be created, as the LDAP backend matches case-insensitively. This is very confusing for the user as everything appears to be going well, but suddenly their calendars are gone.

I've made an issue instead of directly submitting a pull request, as I can imagine a few different ways forward:

• Add an LDAP configuration toggle to indicate the username is case-insensitive, which would always lower-case the username before doing the database check in LDAPAuth;
• Add an LDAP configuration toggle with the username attribute to read back from LDAP to be used as the database username;
• Make usernames case-insensitive in all of Davis (in my personal opinion the most correct option as they mostly lead to confusion, but this would likely be a backwards-incompatible change so it may be undesirable).

Does any of these options make sense to you, or do you have a better way in mind this problem could be resolved?

[tchapi]

Hi @shizmob and thanks for the report

Very interesting that LDAP has this specific behavior, didn't know it.

Although 3. seems interesting, casefolding to make this possible would require quite a bit of though, and, as you say, would not be backward-compatible.

I'd be in favour of 2., ie getting the actual answer of the LDAP server and use that as the database username. This abstracts the actual case change to the LDAP server itself, not to Davis, while making it mostly transparent for the end user.