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

Jakub Hrozek jhrozek at redhat.com
Tue May 13 07:30:36 UTC 2014


On Mon, May 12, 2014 at 02:10:27PM -0400, Stephen Gallagher wrote:
> -----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)

OK, I filed:
https://fedorahosted.org/sssd/ticket/2332

> 
> 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.

Right, it appears that IPA's non-POSIX group have:
    objectClass: top
    objectClass: ipaobject
    objectClass: groupofnames
    objectClass: ipausergroup
    objectClass: nestedgroup

With other LDAP servers I've seen groupOfNames used commonly for
non-POSIX groups.


More information about the sssd-users mailing list