Jakub Hrozek wrote 2015-09-28 21:56:
I wrote a blog post targeted at performance some time ago:
https://jhrozek.wordpress.com/2015/08/19/performance-tuning-sssd-for-larg...
It is targeted at IPA-AD trust deployments, but some of the general
advices still hold for direct integration as well.
That's a really great article. I wonder how I haven't found it before.
Thank you, many things are more clear now.
> Second is that SSSD does not resolve nested groups by default and
some
> users
> that are should be allowed, are not able to login.
I'm not sure I understand this part. Do you mean that when you log in,
the nested groups are not displayed when you type 'id' ? Or that the
nested groups are not taken into account during the access control
phase?
The former would be wrong and we'd have to debug it, the latter would
be
expected, because the LDAP entry in AD doesn't contain memberof entries
in the entry itself (see below).
Sorry, I mislead you: I can see the groups in output of 'id user'. Both
that user is a direct member, or a member of a nested group.
Although I can't log in with user that is not in group. But I see that
this is a known behaviour, so apparently I have to write extended
ad_filter. (or use GPO access control)
>
> In the output of 'id user' I see these strange groups:
> 704195244(groupname {fcc357ea-83ef-4645-17e9-1967bfe8a77f})
Is this really how you see the group (sans the groupname obfuscation) ?
Yes, I've got about 4 such groups in 60-groups output.
This 'hash' appears when two groups with same name and different ID are
present. Hashes are different too.
It appears only when I enable 'ldap_groups_use_matching_rule_in_chain'
and 'ldap_initgroups_use_matching_rule_in_chain'.
I would first try ignore_group_members. Please note that we're planning
for performance enhancements in 1.14..
I've set it and it gave some boost, thank you.