LDAP case sensitivity with ldap_uids

I am setting up my ejabberd install to authenticate off of Active Directory and by and large, things are working well.

The only thing I'm having issues with is getting the web admin users page to populate with all of the users.

My config (sanitized) is:

{auth_method, ldap}.
{ldap_servers, ["ldap.domain.com"]}.
{ldap_encrypt, none}.
{ldap_port, 389}.
{ldap_rootdn, "cn=Jabber Admin,cn=Users,dc=domain,dc=com"}.
{ldap_password, "password"}.
{ldap_base, "ou=orgunit,dc=domain,dc=com"}.
{ldap_uids, [{"mail", "%u@domain.com"}]}.
{ldap_filter, "&(userAccountControl:1.2.840.113556.1.4.803:=512)(!(userAccountControl:1.2.840.113556.1.4.804:=65570))(objectClass=organizationalPerson))"}.

OK, so some of that is kinda crazy. Our AD sAMAccountNames are not the same as the user part of our email address, and I want our JIDs to match our email addresses, so that explains some of the craziness here.

Unfortunately, in AD, not all of the "mail" attributes are entered the same way as far as case is concerned. Some are entered as "first.last@domain.com" and some are entered "first.last@DOMAIN.COM". (Did I mention that I'm not in charge of the AD setup? If I were, I'd just fix this and be done with it. *sigh*)

So, from experimenting with various settings, it seems that ldap_filter is, correctly, not matching case on stuff, but the returned values used in ldap_uids *are* being matched with case sensitivity. So, with the above config, I get the list of users that are in the form "first.last@domain.com", and if I change the above to have:
{ldap_uids, [{"mail", "%u@DOMAIN.COM"}]}.
then I get the other users, the ones in the form "first.last@DOMAIN.COM".

I have tried:
{ldap_uids, [{"mail", "%u@domain.com"},{"mail", "%u@DOMAIN.COM"}].
but still only get the ones with the lowercase "domain.com" in their mail attribute.

This could arguably be called a bug as LDAP is primarily considered case-insensitive, and at least for this config, the host portion of an email address is also case-insensitive, though I understand that string matching may need to be case-sensitive at times.

Is there any solution for me? I'm open to suggestions.
--
Jeff

I've added this to Jira

Syndicate content