Questions [maybe a bug] about SSSD non-anonymous binding working with LDAP

[aaron wang]

Hi all,

I'm configuring SSSD on a system to authenticate users against the LDAP
server.

LDAP server side:
there are basically three options for the anonymous binding flag, 0 for
completely disallow anonymous binding, 1 allows anonymous binding, 2 allows
anonymous bind but allows only search operations on root DSE entry for
anonymous users

SSSD side:
I'm providing the ldap_default_bind_dn and ldap_default_bind_authtok for
the binding.

Tests:
1) if admin changes the anonymous binding flag to "COMPLETELY DISALLOW" or
"ONLY ALLOW DSE", the authentication against LDAP server doesn't work

from the sssd log, the sssd has marked the LDAP server as "working", but
the sssd can't find the user in ldap

2) if admin sets anonymous binding flag to "ALLOW ANONYMOUS BINDING", the
authentication against LDAP server works

The only difference between test 1) and test 2) is the anonymous binding
flag.

I'm expecting that if I provide binding dn and binding password in the
sssd.conf, the server could turn off the anonymous completely or at least
partially. Is there an known issue around this ?

version: sssd-1.9.2

Thanks,
Aaron

[Lukas Slebodnik]

On (12/11/15 13:51), aaron wang wrote:
> Hi all,
>
> I'm configuring SSSD on a system to authenticate users against the LDAP
> server.
>
> LDAP server side:
> there are basically three options for the anonymous binding flag, 0 for
> completely disallow anonymous binding, 1 allows anonymous binding, 2 allows
> anonymous bind but allows only search operations on root DSE entry for
> anonymous users
>
> SSSD side:
> I'm providing the ldap_default_bind_dn and ldap_default_bind_authtok for
> the binding.
>
> Tests:
> if admin changes the anonymous binding flag to "COMPLETELY DISALLOW" or
>
> "ONLY ALLOW DSE", the authentication against LDAP server doesn't work
>
> from the sssd log, the sssd has marked the LDAP server as "working", but
> the sssd can't find the user in ldap
> if admin sets anonymous binding flag to "ALLOW ANONYMOUS BINDING", the
>
> authentication against LDAP server works
>
> The only difference between test 1) and test 2) is the anonymous binding
> flag.
>
> I'm expecting that if I provide binding dn and binding password in the
> sssd.conf, the server could turn off the anonymous completely or at least
> partially. Is there an known issue around this ?
>
> version: sssd-1.9.2

I assume (based on version) you use sssd on el6.4 or el6.5 which are quite old.

Could you test with 1.12.x?

LS

[Sumit Bose]

On Fri, Nov 13, 2015 at 06:51:07AM +0100, Lukas Slebodnik wrote:
> On (12/11/15 13:51), aaron wang wrote:
> > Hi all,
> >
> > I'm configuring SSSD on a system to authenticate users against the LDAP
> > server.
> >
> > LDAP server side:
> > there are basically three options for the anonymous binding flag, 0 for
> > completely disallow anonymous binding, 1 allows anonymous binding, 2 allows
> > anonymous bind but allows only search operations on root DSE entry for
> > anonymous users
> >
> > SSSD side:
> > I'm providing the ldap_default_bind_dn and ldap_default_bind_authtok for
> > the binding.
> >
> > Tests:
> > if admin changes the anonymous binding flag to "COMPLETELY DISALLOW" or
> >
> > "ONLY ALLOW DSE", the authentication against LDAP server doesn't work
> >
> > from the sssd log, the sssd has marked the LDAP server as "working", but
> > the sssd can't find the user in ldap
> > if admin sets anonymous binding flag to "ALLOW ANONYMOUS BINDING", the
> >
> > authentication against LDAP server works
> >
> > The only difference between test 1) and test 2) is the anonymous binding
> > flag.

yes, this is expected, because even for authentication SSSD has to
search for a matching user entry first. This search is done anonymously
in the default configuration.
> > I'm expecting that if I provide binding dn and binding password in the

yes, this will instruct SSSD to bind before doing searches, but ...
> > sssd.conf, the server could turn off the anonymous completely or at least
> > partially. Is there an known issue around this ?

... the DSE lookup will still be done anonymously because afaik (I hope
this didn't change in the meantime) it is said in the RFC that the DSE
should always be accessible. And since the DSE contains information
about supported authentication type it makes sense to read it before
doing a bind.

Nevertheless a failure during the DSE lookup should not be fatal you
only have to provide e.g. the baseDN of your LDAP tree in sssd.conf
which would otherwise be discovered automatically from the DSE.
> > version: sssd-1.9.2
>
> I assume (based on version) you use sssd on el6.4 or el6.5 which are quite old.
>
> Could you test with 1.12.x?

yes, please use a newer version.

bye,
Sumit
> LS
> _______________________________________________
> sssd-users mailing list
> [e-mail]
> https://lists.fedorahosted.org/mailman/listinfo/sssd-users

[Jakub Hrozek]

On Thu, Nov 12, 2015 at 01:51:14PM -0800, aaron wang wrote:
> Hi all,
>
> I'm configuring SSSD on a system to authenticate users against the LDAP
> server.
>
> LDAP server side:
> there are basically three options for the anonymous binding flag, 0 for
> completely disallow anonymous binding, 1 allows anonymous binding, 2 allows
> anonymous bind but allows only search operations on root DSE entry for
> anonymous users
>
> SSSD side:
> I'm providing the ldap_default_bind_dn and ldap_default_bind_authtok for
> the binding.
>
> Tests:
> if admin changes the anonymous binding flag to "COMPLETELY DISALLOW" or
>
> "ONLY ALLOW DSE", the authentication against LDAP server doesn't work
>
> from the sssd log, the sssd has marked the LDAP server as "working", but
> the sssd can't find the user in ldap
> if admin sets anonymous binding flag to "ALLOW ANONYMOUS BINDING", the
>
> authentication against LDAP server works
>
> The only difference between test 1) and test 2) is the anonymous binding
> flag.
>
> I'm expecting that if I provide binding dn and binding password in the
> sssd.conf, the server could turn off the anonymous completely or at least
> partially. Is there an known issue around this ?

By default the identity lookups are done over unencrypted connection,
anonymously. You can either use bind DN and password or GSSAPI binds.

However, normally you should use rootDSE anonymously readable even if
you restrict the binds to disallow anonymous binds.
> version: sssd-1.9.2

As Lukas said, there were known bugs especially around retrying
authenticated rootDSE search from a failed anonymous search.

[aaron wang]

Hi Lukas, Sumit, Jakub,

Thank you very much for your reply.

I tried to update to sssd-1.12.4. The behavior is same as with sssd-1.9.2.

*I observed following things (with ldap server side disallow anonymous
binding):*

1) *Got rootdse* is printed before* [simple_bind_send] (0x0100):
Executing simple bind as: cn=myadminuser*

2) Server is marked as "working"

3) If I issue "id oneuser" , there will such log
c*alling ldap_search_ext with
[(&(uid=oneuser)(objectclass=posixAccount)(uid=*)(&(uidNumber=*)(!(uidNumber=0))))][dc=mydomain,dc=com].*

4)and at last, *[sdap_get_users_done] (0x0040): Failed to retrieve
users*

*My thoughts:*

ldapsearch -h myhostname -p myportnumber -b "dc=mydomain,dc=com" -D
"cn=myadminuser" -W
'(&(uid=oneuser)(objectclass=posixAccount)(uid=*)(&(uidNumber=*)(!(uidNumber=0))))'

Above ldapsearch can return the user, the "cn=myadminuser" is what I
provided in the sssd.conf as "ldap_default_bind_dn" , -W I provided the
password in the sssd.conf as "ldap_default_authtok".

And I guess the rootDSE is not the key thing here, as rootDSE is retrieved
successfully from the log.

And also, when I issue "id oneuser", SSSD is trying to used the cached
connection(I assume this cached connection is the one cn=myadminuser
started). So it shouldn't treated as anonymous binding, correct ?

Any thoughts on these? Let me know if you need extra information.

Thanks,
Aaron

On Fri, Nov 13, 2015 at 12:50 AM, Jakub Hrozek  wrote:
> On Thu, Nov 12, 2015 at 01:51:14PM -0800, aaron wang wrote:
> > Hi all,
> >
> > I'm configuring SSSD on a system to authenticate users against the LDAP
> > server.
> >
> > LDAP server side:
> > there are basically three options for the anonymous binding flag, 0 for
> > completely disallow anonymous binding, 1 allows anonymous binding, 2
>
> allows
> > anonymous bind but allows only search operations on root DSE entry for
> > anonymous users
> >
> > SSSD side:
> > I'm providing the ldap_default_bind_dn and ldap_default_bind_authtok for
> > the binding.
> >
> > Tests:
> > if admin changes the anonymous binding flag to "COMPLETELY DISALLOW"
>
> or
> > "ONLY ALLOW DSE", the authentication against LDAP server doesn't work
> >
> > from the sssd log, the sssd has marked the LDAP server as "working", but
> > the sssd can't find the user in ldap
> > if admin sets anonymous binding flag to "ALLOW ANONYMOUS BINDING", the
> >
> > authentication against LDAP server works
> >
> > The only difference between test 1) and test 2) is the anonymous binding
> > flag.
> >
> > I'm expecting that if I provide binding dn and binding password in the
> > sssd.conf, the server could turn off the anonymous completely or at least
> > partially. Is there an known issue around this ?
>
> By default the identity lookups are done over unencrypted connection,
> anonymously. You can either use bind DN and password or GSSAPI binds.
>
> However, normally you should use rootDSE anonymously readable even if
> you restrict the binds to disallow anonymous binds.
> > version: sssd-1.9.2
>
> As Lukas said, there were known bugs especially around retrying
> authenticated rootDSE search from a failed anonymous search.
> _______________________________________________
> sssd-users mailing list
> [e-mail]
> https://lists.fedorahosted.org/mailman/listinfo/sssd-users

[Jakub Hrozek]

On Fri, Nov 13, 2015 at 03:36:03PM -0800, aaron wang wrote:
> Hi Lukas, Sumit, Jakub,
>
> Thank you very much for your reply.
>
> I tried to update to sssd-1.12.4. The behavior is same as with sssd-1.9.2.
>
> *I observed following things (with ldap server side disallow anonymous
> binding):*
> 1) *Got rootdse* is printed before* [simple_bind_send] (0x0100):
>
> Executing simple bind as: cn=myadminuser*

We try to retrieve rootDSE anonymously first and only if that fails,
retry even the rootdse with the bind method from the config.
> 2) Server is marked as "working"
>
>  3) If I issue "id oneuser" , there will such log
>
> c*alling ldap_search_ext with
> [(&(uid=oneuser)(objectclass=posixAccount)(uid=*)(&(uidNumber=*)(!(uidNumber=0))))][dc=mydomain,dc=com].*
>   4)and at last, *[sdap_get_users_done] (0x0040): Failed to retrieve
>
> users*
>
> *My thoughts:*
>
> ldapsearch -h myhostname -p myportnumber -b "dc=mydomain,dc=com" -D
> "cn=myadminuser" -W
> '(&(uid=oneuser)(objectclass=posixAccount)(uid=*)(&(uidNumber=*)(!(uidNumber=0))))'
>
> Above ldapsearch can return the user, the "cn=myadminuser" is what I
> provided in the sssd.conf as "ldap_default_bind_dn" , -W I provided the
> password in the sssd.conf as "ldap_default_authtok".
>
> And I guess the rootDSE is not the key thing here, as rootDSE is retrieved
> successfully from the log.
>
> And also, when I issue "id oneuser", SSSD is trying to used the cached
> connection(I assume this cached connection is the one cn=myadminuser
> started). So it shouldn't treated as anonymous binding, correct ?

correct
> Any thoughts on these? Let me know if you need extra information.

Full logs would be best. Please also look into the server logs if
you have access.