ldap group doesn't work

[sles]

Hello!

I wrote almost the same mail to sasl mail list, but , I guess, it is good to fix in 12.04...

This bug exists in 2.1.26 , and in 2.1.25 which is in 12.04

Problem is that after user is authentificated with ldap bind , ldap
connection for checking user in group ( lak_group_member function )
is made with this user's bind, not bind parameters from config file.
User can not ( and have not in our case- I don't know why , but this is
not real problem ) have access to ldap groups.
And so, authentication is always fail.

I added unbind and anonymous bind ( enough in our case):

/var/local/files/sasl/cyrus-sasl-2.1.26/saslauthd# diff -ur lak.c.orig
lak.c
--- lak.c.orig 2013-06-07 09:15:20.098788278 +0400
+++ lak.c 2013-06-07 09:22:31.504774185 +0400
@@ -1342,6 +1342,10 @@
         if (rc != LAK_OK)
             goto done;

+ lak_unbind (lak );
+ rc = lak_bind(lak, "");
+
+
         rc = ldap_search_st(lak->ld, group_search_base,
lak->conf->group_scope, group_filter, (char **) group_attrs, 0,
&(lak->conf->timeout), &res);
         switch (rc) {
             case LDAP_SUCCESS:

but, it is obvoius that rebind should be done with credintials from
config, but this is over my head :-(

Could you, please, fix this bug correctly?

Thank you!

[sles (slesru)]

btw, more correct patch, which revert back bind from config in lak_auth_bind

 diff -ur lak.c.orig lak.c
--- lak.c.orig 2013-06-07 09:15:20.098788278 +0400
+++ lak.c 2013-06-08 10:17:07.548233104 +0400
@@ -1448,8 +1448,25 @@
     if ( rc == LAK_OK &&
         (ISSET(lak->conf->group_dn) ||
          ISSET(lak->conf->group_filter)) )
- rc = lak_group_member(lak, user, service, realm, dn->value);
+ {
+ /* restore config bind */
+ lak_unbind(lak);
+ rc = lak_user(
+ lak->conf->bind_dn,
+ lak->conf->id,
+ lak->conf->authz_id,
+ lak->conf->mech,
+ lak->conf->realm,
+ lak->conf->password,
+ &lu);
+ if (rc != LAK_OK)
+ goto done;
+ rc = lak_bind(lak, lu);
+ if (rc != LAK_OK)
+ goto done;

+ rc = lak_group_member(lak, user, service, realm, dn->value);
+ }
 done:;
     if (lu)
         lak_user_free(lu);

don't sure it is correct from leaking some resources though

anyway it works

[sles (slesru)]

Hello!

Still have this bug on 16.04.
Have to use my old patch, because there is the same bug...
Why???!!!
:-(

[Joshua Powers (powersj)]

Thank you for taking the time to report this bug and helping to make Ubuntu
better. Sorry this got dropped over the years.

This bug is present in Debian as well and Ubuntu currently does not make any
changes to the Debian package. Therefore, this bug would be best fixed
directly in Debian, and then Ubuntu will pick up the fix automatically.

Would you mind filing a bug with Debian please?

[sles (slesru)]

Hello!

I created pull request in cyrus sasl repository
https://github.com/cyrusimap/cyrus-sasl/pull/428

If you don't patch debian packages, then why debian should do this,
let cyrus developers fix it ;-)

[Andreas Hasenack (ahasenack)]

User filed upstream bug at https://github.com/cyrusimap/cyrus-sasl/issues/427

[Andreas Hasenack (ahasenack)]

Can you share your saslauthd configuration, and portions of your DIT showing how the users and groups are organised?

At first glance, it feels correct to be using the user's DN to check for group membership. I would certainly expect to be able to tell which groups I belong to without having to resort to some sort of third party or even administrator credentials.

[Andreas Hasenack (ahasenack)]

For some reason bug expiration isn't working for this bug. Given that there were no updates for over two months, I'm marking it as invalid.

Feel free to reopen it if you have more information about the problem.

Thanks!

[sles (slesru)]

Why invalid?
Please get into ubuntu current code :-)
https://github.com/cyrusimap/cyrus-sasl/pull/428

[Christian Ehrhardt  (paelzer)]

Thanks sles for driving that upstream!

FYI - Merged 19 hours ago so not in any release (yet).

Now we are back to Josh's comment #3 to file it in Debian to sync to Artful from there.
If you do open a report the please mention it here so we can link it up to get auto-notified once it is accepted.
It is preferred that the reporter (and in this case also patch author) does that bug opening, please let us know if you are unable to do so that we can help.
From there we need to consider SRUing [1] it into released Ubuntu versions

[1]: https://wiki.ubuntu.com/StableReleaseUpdates

[Andreas Hasenack (ahasenack)]

Hi @sles,

I marked this bug as invalid because there was no answer to my question in comment #6 for close to two months, and launchpad wouldn't set this bug to expired. Also when I checked, upstream hadn't commented on your github issue.

I still don't understand fully why the original behaviour is incorrect, but I will take my issue with upstream, since them merging it is a good indication that I'm wrong.

[sles (slesru)]

Hello!

I'm not Debian user, so I don't think this is good idea to open bug report for product I don't use.
And I don't see any reasons why Ubuntu can't provide support for it's packages and have to rely on Debian :-(

Anyway, fix will be in next release, so it will work out of box in 20.04 :-D

Thank you!

[sles (slesru)]

About comment 6- in my opinion this highly depends on your implementation and policy.
I work for not so large company, I'd say small - just about 4200 employers-, so our policy can be wrong - it says not show users their rights, i.e. intruder needs to try ;-)
From another point of view- ldap connection credentials are supplied in config, so application have to use them, not others.
Your point of view is right too- as I said this depends on your policy.
Thank you!