[SSSD-users] Avoid (&(objectClass=posixAccount)(uid=*)(uidNumber=*)(gidNumber=*))

Stephen Gallagher sgallagh at redhat.com
Mon May 12 18:10:27 UTC 2014


-----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 at redhat.com>
> 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.

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iEYEARECAAYFAlNxDpMACgkQeiVVYja6o6P8ZACeLgGI0eDKyfLHC47c7bEUa2yl
bBEAnj9VsLgbHMHOyxbHUN1oQl3wHXOC
=Fpd5
-----END PGP SIGNATURE-----


More information about the sssd-users mailing list