On 09/09/2014 12:57 PM, Nordgren, Bryce L -FS wrote:
> 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. :)
OK. Do we have a ticket to expose the filter and allow user to override
it or parts of it?
If not please file.
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.
_______________________________________________
sssd-users mailing list
sssd-users(a)lists.fedorahosted.org
https://lists.fedorahosted.org/mailman/listinfo/sssd-users
--
Thank you,
Dmitri Pal
Sr. Engineering Manager IdM portfolio
Red Hat, Inc.