You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
In our DIT we employ LDAP aliases to put user object in different branches.
Login via LDAP using the UID works fine for 98% of the users but for those users where the LDAP alias is found before the full user object, authentication fails, because Sympa tries to bind to the LDAP alias and not the user object.
Version
6.2.72
Installation method
Installed from source
Expected behavior
Any user can login with their username.
Actual behavior
Users with a very specific order of LDAP objects and LDAP aliases can't login.
Steps to reproduce
Create an LDAP tree with an LDAP alias pointing to a user object and make sure the alias is found before the user object.
For example:
uid=foobar,ou=a,ou=base
objectClass: top
objectClass: alias
objectClass: extensibleObject
aliasedObjectName: uid=foobar,ou=b,ou=base
uid: foobar
uid=foobar,ou=b,ou=base
objectClass: account
objectClass: simpleSecurityObject
objectClass: top
userPassword: foobar
uid: foobar
In this case trying to login as "foobar" will fail, because Sympa finds the Alias first and then tries to bind to uid=foobar,ou=a,ou=base.
If dereferening is switched on (which you usally want in 99% of cases), then the LDAP server will always return the real user object and the login works correctly.
In our DIT we employ LDAP aliases to put user object in different branches.
Login via LDAP using the UID works fine for 98% of the users but for those users where the LDAP alias is found before the full user object, authentication fails, because Sympa tries to bind to the LDAP alias and not the user object.
Version
6.2.72
Installation method
Installed from source
Expected behavior
Any user can login with their username.
Actual behavior
Users with a very specific order of LDAP objects and LDAP aliases can't login.
Steps to reproduce
Create an LDAP tree with an LDAP alias pointing to a user object and make sure the alias is found before the user object.
For example:
In this case trying to login as "foobar" will fail, because Sympa finds the Alias first and then tries to bind to
uid=foobar,ou=a,ou=base
.If dereferening is switched on (which you usally want in 99% of cases), then the LDAP server will always return the real user object and the login works correctly.
Additional information
auth.conf looks like this:
I tried setting
via /etc/ldap/ldap.conf, because that usually works, but not in this case.
As a quick'n'dirty workaround I changed the
$db->do_operation()
callldap_authentication()
in line 257 ofWWW/Auth.pm
to look like this:and this made this work, in a very hackish way, obviously.
This should be made configurable via auth.conf, just like the other parameters are.
The text was updated successfully, but these errors were encountered: