[SSSD-users] Inefficient ldap query...I think (sssd 1.11.2/CentOS 7)

Nordgren, Bryce L -FS bnordgren at fs.fed.us
Tue Sep 9 16:57:30 UTC 2014


> Are you sure it would help in your environment? Did you check that
> searching with:
>     (&(uidNumber=10008)(objectClass=posixAccount))
> is faster than:
>
> (&(uidNumber=10008)(objectclass=posixAccount)(uid=*)(&(uidNumber=*)(
> !(uidNumber=0))))

Yup. Checked before I posted. Actually, the critical difference was the inclusion of the (uid=*) term.

So: (&(uidNumber=10008)(objectClass=posixAccount)) is faster than (&(uidNumber=10008)(objectclass=posixAccount)(uid=*)).

Note: Including the uid term doesn't just make it slower, it alternates between "size limit exceeded" and "time limit exceeded" errors because the proxy server was fetching all the entries from the AD backend. In the interim, some fiddling with openldap's translucent_local and translucent_remote has provoked some query scheduling changes, apparently. Uid was in both the local and remote lists. Removing "uid" from both lists seems to have eliminated the size limit exceeded error.

In essence, the nature of the problem in my environment was:

1] forward lookups (getpwnam) would work
2] reverse lookups (getpwuid) would fail unless a forward lookup had cached that particular user
3] ls -l / getfacl did a lot of reverse lookups on un-cached ids, leading to sequential lookup failures by timeout/sizelimit exceeded


> Please note I'm not dismissing the optimization, I'm just a bit surprised that
> this would make any difference..

It makes a difference when not all the attributes are in the same ldap server, and a proxy server has to divide up your query filter into local and remote components. I don't believe this will turn out to be specific to openldap, and it will be sensitive to the amount of control users have over how specific attributes are scheduled. FreeIPA is steaming full speed ahead into this situation via views.

> As per why we construct the filter like this..we first take a base filter. Here is
> a simple pseudocode:
> ...
> This way, even when searching a POSIX user by name, we make sure this
> user has an ID.

I think that makes sense if sssd is designed to never be used in a proxied environment (where some user attributes may be modified in the local environment and others are inherited from a remote identity source). Such environments may be "custom" to the point where people may require better control over the base query. Of course, granting this control means one extra term condition when processing the results:
   "if len(results)==1 and (myResultAttr in results[0].attrs): # lookup successful"

For the moment, this issue has been solved by stumbling onto different configuration in the proxy server. I still think it would be good to allow users to control the base filter, just in case they have an oddball environment and they still expect sssd to retrieve user information. :)

Bryce






This electronic message contains information generated by the USDA solely for the intended recipients. Any unauthorized interception of this message or the use or disclosure of the information it contains may violate the law and subject the violator to civil or criminal penalties. If you believe you have received this message in error, please notify the sender and delete the email immediately.


More information about the sssd-users mailing list