HI! I'm seeing searches like this sent by sssd to the LDAP server: (&(objectClass=posixAccount)(uid=*)(uidNumber=*)(gidNumber=*)) Likely this is because some of the server admins set in sssd.conf: enumerate = true While it's debatable to disable enumeration I wonder how one can avoid that sssd uses the filter above. Since all three attributes are mandantory in objectClass posixAccount anyway it would be sufficient to do a user numeration search just with filter (objectClass=posixAccount) because there cannot be an entry without any of these attributes. I'm asking because it turned out that the LDAP server's processing of (&(objectClass=posixAccount)(uid=*)(uidNumber=*)(gidNumber=*)) is two times slower than just (objectClass=posixAccount).

Sorry, but I don't agree. The objectclass is cofigurable in sssd.conf and especially in AD deployments it might be quite common to only have some users configured with POSIX attributes and not the others. The enumeration based on objectclass only would download the whole lot and then fail while saving the users..

Sorry, but I don't agree. The objectclass is cofigurable in sssd.conf and especially in AD deployments it might be quite common to only have some users configured with POSIX attributes and not the others. The enumeration based on objectclass only would download the whole lot and then fail while saving the users..

On Sat, May 10, 2014 at 9:07 PM, Simo Sorce <simo(a)redhat.com&gt; wrote: > On Sat, 2014-05-10 at 16:27 +0200, Michael Ströder wrote: >> HI! >> >> I'm seeing searches like this sent by sssd to the LDAP server: >> >> (&(objectClass=posixAccount)(uid=*)(uidNumber=*)(gidNumber=*)) >> >> Likely this is because some of the server admins set in sssd.conf: >> >> enumerate = true >> >> While it's debatable to disable enumeration I wonder how one can avoid that >> sssd uses the filter above. >> >> Since all three attributes are mandantory in objectClass posixAccount anyway >> it would be sufficient to do a user numeration search just with filter >> (objectClass=posixAccount) because there cannot be an entry without any of >> these attributes. >> >> I'm asking because it turned out that the LDAP server's processing of >> (&(objectClass=posixAccount)(uid=*)(uidNumber=*)(gidNumber=*)) is two times >> slower than just (objectClass=posixAccount). > > Please open a ticket, it is a reasonable optimization we should make > available to all users. > > Simo. > > -- > Simo Sorce * Red Hat, Inc * New York > > _______________________________________________ > sssd-users mailing list > sssd-users(a)lists.fedorahosted.org > https://lists.fedorahosted.org/mailman/listinfo/sssd-users _______________________________________________ sssd-users mailing list sssd-users(a)lists.fedorahosted.org https://lists.fedorahosted.org/mailman/listinfo/sssd-users

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 05/10/2014 03:13 PM, Jakub Hrozek wrote: > Sorry, but I don't agree. The objectclass is cofigurable in > sssd.conf and especially in AD deployments it might be quite common > to only have some users configured with POSIX attributes and not > the others. The enumeration based on objectclass only would > download the whole lot and then fail while saving the users.. > > On Sat, May 10, 2014 at 9:07 PM, Simo Sorce <simo(a)redhat.com&gt; > wrote: >> On Sat, 2014-05-10 at 16:27 +0200, Michael Ströder wrote: >>> HI! >>> >>> I'm seeing searches like this sent by sssd to the LDAP server: >>> >>> (&(objectClass=posixAccount)(uid=*)(uidNumber=*)(gidNumber=*)) >>> >>> Likely this is because some of the server admins set in >>> sssd.conf: >>> >>> enumerate = true >>> >>> While it's debatable to disable enumeration I wonder how one >>> can avoid that sssd uses the filter above. >>> >>> Since all three attributes are mandantory in objectClass >>> posixAccount anyway it would be sufficient to do a user >>> numeration search just with filter (objectClass=posixAccount) >>> because there cannot be an entry without any of these >>> attributes. >>> >>> I'm asking because it turned out that the LDAP server's >>> processing of >>> (&(objectClass=posixAccount)(uid=*)(uidNumber=*)(gidNumber=*)) >>> is two times slower than just (objectClass=posixAccount). >> >> Please open a ticket, it is a reasonable optimization we should >> make available to all users. I'd be in favor of adding an optimization option (off by default) for doing a pure-objectClass search, but I certainly wouldn't want this to be the general case. Part of the reason that this is the default right now is because SSSD has encountered LDAP servers in the past that do not conform to the standard, and not just ActiveDirectory. (People had custom LDAP servers not using posixAccount at all, but that had other attributes that more-or-less accomplished the same thing)

I'd certainly argue that known environments like the IPA provider[1] could be fine with this optimization on by default. Otherwise, I think it would be okay to have an 'ldap_fully_rfc_compliant = True' option that drops the extra uid, uidNumber and gidNumber checks on both explicit and enumerated lookups. Down the road, we might also consider doing an internal check that if objectClass == posixAccount we also make this optimization, but I seem to recall that at least one LDAP server (Domino?) didn't implement posixAccount according to RFC2307, so that might end up as a regression. [1] Regarding FreeIPA's non-POSIX groups: I assume it removes objectClass: posixGroup? I haven't played much with that code.