This has probably been discussed earlier but I can’t find a solution to it. We are using ldap authentication and are adding permissions to users via ldap groups. Case sensitivity doesn’t seem to matter for the login but for assigning the user to an ldap group where the role is mapped.
E.g. a user is logging in with username1, all permissions are set correctly. If the user logs in with Username1, no permissions are set. I was expecting that either case doesn’t matter or access would be denied when the user logs in with Username1.
In Configuration > Authentication everything looks fine, we can list ldap users, groups and corresponding memberships.
the issue you’ve linked does not apply to your issue. Case sensitive logins were a bug introduced with v2.8 but were then fixed with v2.8.1.
I’ve just checked the code again, and all places of interest here (logins, memberships, roles) process the username case insensitive.
Have you maybe multiple backends and for all or some of them domains configured? Could there be a Username1 in another backend (e.g. database)? Or a domain mis-match?
Thanks a lot for looking into this. I think I’ve found the issue. LDAP authentication is successful because because the dns are case insensitive. But the filters aren’t. Now, the groups for a user with wrong case are not found.
2021-01-11T16:57:24+01:00 - DEBUG - Issuing LDAP search. Use 'ldapsearch -P 3 -H "ldaps://ldap.example.com:636" -D "uid=icinga2user,cn=systems,dc=example,dc=com" -W -b "cn=accounts,dc=example,dc=com" -s "sub" -z 0 -l 0 -a "never" "(&(objectClass=groupOfUniqueNames)(memberUid=Username1))" "cn"' to reproduce.
Now I need to check if we are using an old code base. According to “About” we are running 2.8.2.
In our case we could just set the username to lower case in LdapUserGroupBackend.php or add ignoreCaseIA5Match to groupMemberAttribute. But I’m not sure what implications this can bring with LDAP servers that are case sensitive.
You’re right, it’s also assumed that the server handles filters case insensitive. This is also the case for you, otherwise you couldn’t login, as for the login we need a DN and that’s identified by a search for your username.
So it’s only the group member attribute that’s not case insensitive. I don’t recommend patching the code, because what happens with a username that actually has an upper case char in it? I’d rather use a different group member attribute or check whether disabling case sensitivity is an option.
Yeah, thought so. But I think I’ve found the answer here. We need to use uniqueMember instead of memberUid. Then it will search for the dn which is case insensitive. We’re going to test this and let you know.