Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

LDAP auth not working correctly when LDAP alias is found first #1853

Open
shartge opened this issue Jun 12, 2024 · 2 comments · May be fixed by #1892
Open

LDAP auth not working correctly when LDAP alias is found first #1853

shartge opened this issue Jun 12, 2024 · 2 comments · May be fixed by #1892

Comments

@shartge
Copy link

shartge commented Jun 12, 2024

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.

Additional information

auth.conf looks like this:

ldap
        regexp                          .+\.(xxx|yyy|zzz)\.de
        host                            ldap.xxx.de:636
        timeout                         20
        suffix                          dc=xxx-yyy,dc=de
        bind_dn                         uid=sympa,ou=its-sysuser,dc=xxx-yyy,dc=de
        bind_password                   VERYSECRET
        get_dn_by_uid_filter            (uid=[sender])
        get_dn_by_email_filter          (|(mail=[sender])(gifb-mailaddress=[sender]))
        email_attribute                 mail
        scope                           sub
        use_tls                         ldaps
        ssl_version                     tlsv1_2

I tried setting

DEREF ALWAYS

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() call ldap_authentication() in line 257 of WWW/Auth.pm to look like this:


    my $mesg = $db->do_operation(
        'search',
        base    => $ldap->{'suffix'},
        filter  => $filter,
        deref   => 'always',
        scope   => $ldap->{'scope'},
        timeout => $ldap->{'timeout'}
    );

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.

@ikedas
Copy link
Member

ikedas commented Sep 8, 2024

Hi @shartge ,
Could you please apply this patch and check if the bug has been fixed?

@ikedas ikedas added enhancement and removed bug labels Sep 8, 2024
@shartge
Copy link
Author

shartge commented Sep 8, 2024

Hi @ikedas ,

I will try the patch as soon as I return to the office in about a week.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging a pull request may close this issue.

2 participants