in my original text above I said I use 'auth_provider = simple'.  What I meant to say is 'access_provider = simple'.  

my bad.  

I might also point out that I have tried using 'access_provider = ldap', with an ldap_access_filter set to:
ldap_access_filter = (memberOf:1.2.840.113556.1.4.1941:=CN=engr-lab-acl,OU=UserReqLists,OU=AutoLists,DC=iastate,DC=edu)

This works too, but is no faster than access_provider = simple.  It still takes 30 to 40 seconds to get access.

Finally, I need to mention that after the initial caching is done of the access group in the SSSD cache, subsequent logins are near instantaneous (which is expected) so long as I log in before the cache entry has expired.  Unfortunately, for most users, this means that every time they log in, it takes them 30 to 40 seconds to get logged in.

There might be two things at play. One is that a large group takes a long time to resolve, the other is that during login, we always refresh group memberships from the remote server, bypassing the cache, to make sure access control uses up-to date group information.

The former can be tested quite simply:
for gid in $(id -G $user); do time getent group $gid; done

and check which getgrgid() takes the longest. The ignore_group_members option might come handy.

The latter is something we're going to fix in a later release, to satisfy environments that can tolerate a certain period where stale data might be used and favor speed.

Thanks for the suggestions.

I was never sure what 'ignore_group_members' would do, but I think that is the solution.  If you set "ignore_group_members = true", then group lookups are much much faster in general.  

The only downside is that 'getent group $somegroup' doesn't list the users in the group.  Not a big deal.  In fact, there's an argument to be made that it's better from a security point of view to suppress listing the group members.

So now, instead of taking 30 to 45 seconds to log in, it takes 2 to 3 seconds.  

Much better!!

I would strongly recommend that the man page for sssd.conf be modified to point out that 'ignore_group_members = true' will greatly improve the speed of group lookups in pam_sss and 'id $user', and that it will also suppress listing user members in output from 'getent group $groupname'.

I think we can close this case.

(In reply to John Dickerson from comment #4)
> I would strongly recommend that the man page for sssd.conf be modified to
> point out that 'ignore_group_members = true' will greatly improve the speed
> of group lookups in pam_sss and 'id $user', and that it will also suppress
> listing user members in output from 'getent group $groupname'.

I suppose you are a native speaker. 

We will be very thankful if you could provide text which is better according to you. Contribution in any form is welcomed.

(In reply to John Dickerson from comment #4)
> Thanks for the suggestions.
> 
> I was never sure what 'ignore_group_members' would do, but I think that is
> the solution.  If you set "ignore_group_members = true", then group lookups
> are much much faster in general.  
> 

This option makes all groups appear empty from the point of view of getgrnam(3) or getgrgid(3).

> The only downside is that 'getent group $somegroup' doesn't list the users
> in the group.  Not a big deal.  In fact, there's an argument to be made that
> it's better from a security point of view to suppress listing the group
> members.

Correct! In general, most security mechanisms only care about the other way around, mostly represented by getgrouplist() call, that is, what groups is the user a member of.

> 
> So now, instead of taking 30 to 45 seconds to log in, it takes 2 to 3
> seconds.  
> 
> Much better!!
> 
> I would strongly recommend that the man page for sssd.conf be modified to
> point out that 'ignore_group_members = true' will greatly improve the speed
> of group lookups in pam_sss and 'id $user', and that it will also suppress
> listing user members in output from 'getent group $groupname'.

I agree with Lukas that we'd appreciate clarification of the man page. If you can suggest better wording, I'm sure we can push it upstream.

Since we found a workaround for the performance issue you were seeing, I'm going to close this bugzilla.

Feel free to add any suggestions for the man page here or send them to the  sssd-devel mailing list or even directly to one of the developers.

Thanks for filing the bug!

Here's a suggested change to the man page for sssd.conf:


       ignore_group_members (bool)
           Do not return group members for group lookups.

           If set to TRUE, suppresses the listing of group members in 'getent group $groupname'.  This can also make access provider checks for group membership significantly faster, especially for groups containing many members.  

           Default: FALSE

I slightly reworded the first sentence to also describe what the underlying group calls are. Attached to this bugzilla is a proposed patch, does it look good to you?

Created attachment 967534 [details]
A proposed man page patch.