On 09/09/14 09:59, Jakub Hrozek wrote:

On Mon, Sep 08, 2014 at 10:03:10PM +0000, Nordgren, Bryce L -FS wrote:

...

ls -l is very slow, as is "getfacl".

Is there any reason that a call to getpwuid(10008) should produce an ldap query filter like this?:

(&(uidNumber=10008)(objectclass=posixAccount)(uid=*)(&(uidNumber=*)(!(uidNumber=0))))

Clearly, if uidNumber=10008, it is both present and not zero so the last two terms are moot. At best, a smart ldap server will optimize this out and only waste the time it takes to parse the filter. At worst, it goes and performs all three checks independently.

Also, my ldap setup is proxying "uid" defined in two remote ADs and FreeIPA, optionally overriding the uid value locally to resolve conflicts. Adding (uid=*) essentially translates to "send me information on every account in your system, so I can then combine your remote result with the rest of the query", which is causing size limit errors and/or timeouts. (objectClass=posixAccount) would cause the same issues, except none of the entries in AD are posixAccounts. FreeIPA will probably observe exactly the same phenomenon when they implement views.

Is there any way for me to control this ldap query, hopefully knocking it down to (&(uidNumber=10008)(objectClass=posixAccount)), requesting attribute uid?

Thanks, Bryce

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

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

As per why we construct the filter like this..we first take a base filter. Here is a simple pseudocode:

 if using_posix_ids:
     # Base filter makes sure there is a posix attribute
     base_filter = (objectclass=posixAccount)(uid=*)(&(uidNumber=*)(!(uidNumber=0))
 else if id_mapping
     # Base filter makes sure there is a SID to map the ID from
     base_filter = (objectclass=posixAccount)(sid=*)

 if searching_by_name:
     specific_filter = (cn=$key)
 else if searching_by_id:
     specific_filter = (uidNumber=$key)

 filter = AND(base_filter, specific_filter)

This way, even when searching a POSIX user by name, we make sure this user has an ID. _______________________________________________ sssd-users mailing list sssd-users@lists.fedorahosted.org https://lists.fedorahosted.org/mailman/listinfo/sssd-users

Can I jump in here and point out the base filter will never work against a windows AD server, windows AD does not use the posixAccount objectclass directly, it is an auxiliary class of 'User' and as such never appears but its attributes do.

Rowland

On Tue, 9 Sep 2014, Jakub Hrozek wrote:

On Tue, Sep 09, 2014 at 10:58:54AM +0100, Rowland Penny wrote:

...

Can I jump in here and point out the base filter will never work against a windows AD server, windows AD does not use the posixAccount objectclass directly, it is an auxiliary class of 'User' and as such never appears but its attributes do.

Well, we do use different objectclasses for different back ends. For AD we use 'group'.

You're also free to change this with the ldap backend without modifying the filter via:

ldap_group_object_class = group

At least, I /assume/ that's how things are working at my end...

jh

We had this discussion before:

https://lists.fedorahosted.org/pipermail/sssd-users/2014-May/001630.html

With lots of fine-grained ACLs in the LDAP server (like in my setup) each additional assertion attribute type is a performance penalty (without additional benefit in my setup).

Same here. It's probably worthwhile to note that my use of fine grained ACL's is far more intense than I'd prefer because sssd has no mechanism to define cross-domain groups. More precisely, it doesn't have a vocabulary for pointing at a local ldap server which defines groups composed from multiple domains.

I've thought to point sssd at my "merged domain", but I'd lose the ability to do Kerberos authentication (need per-domain spec of Kerberos info). The choice appears to be cross-domain groups, or Kerberos (and NFSv4), but not both.

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.

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@lists.fedorahosted.org https://lists.fedorahosted.org/mailman/listinfo/sssd-users

On 09 Sep 2014, at 23:07, Nordgren, Bryce L -FS bnordgren@fs.fed.us wrote:

...

OK. Do we have a ticket to expose the filter and allow user to override it or parts of it? If not please file.

Didn't see one, so:

https://fedorahosted.org/sssd/ticket/2434

Tried to summarize impacted deployment scenarios, describe the request, and link back to the two distinct email threads where this was brought up.

Thanks, Bryce

Thank you very much.

A patch would be even more appreciated — after your explanation I agree this might be a good idea for some deployments, but frankly our plate is quite full for 1.12.2 already.

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@lists.fedorahosted.org https://lists.fedorahosted.org/mailman/listinfo/sssd-users