[SSSD] slow logins via ssh

Dmitri Pal dpal at redhat.com
Fri Sep 23 01:20:40 UTC 2011


On 09/22/2011 08:02 PM, GOLLSCHEWSKY, Tim wrote:
> Hi all.
>
> I work in an organisation with a relatively large LDAP (active) directory.
>
> When we ssh into a server running SSSD it seems to enumerate all the groups in the "ldap_group_search_base" which takes a very long time.  Sometimes it can take up to 30 seconds for the Password: prompt to appear to the ssh client, which feels like ages when you are logging into Linux machines all day.
>
> I've been running debug on the sssd process and I can see it searching and populating all the groups when a person tries to log in.  It calls "ldap_search_ext" over and over again until all the groups (and users inside those groups) have been discovered.  Once it's done this and has all the info in the cache, logging back in again is quick.  But if I don't login for a day or so and try to login again, it downloads all the group information once again and I have the 30 second wait.
>
> The bit I don't understand is:  It does this even when I have "Enumerate" set to False.  Isn't Enumerate = False supposed to stop it from downloading all the group memberships?
>
> http://docs.redhat.com/docs/en-US/Red_Hat_Enterprise_Linux/6/html/Deployment_Guide/chap-SSSD_User_Guide-Configuring_Domains.html
>
> Note I'm using an "ldap_filter" on just one group to control access to the box.  So really for the initial login process it only needs to see the users that exist in one group.  The only time I would expect it to look at other groups is when somebody types the "groups" command for example or does an "ls" in a directory.
>

This is not how it works. It does the resolution of the user and all his
membership once user logs in. We do it once at the login as we do not
know what  applications and user would do. You know that you never call
"groups" and want to offload the performance hit to it but we do not.
This is why we can't have partial information. There were some
performance issue like that that we noticed and tried to address
recently. What version are you running and on what OS? Some of the
recent 1.6 fixes might help.

Also you might extend the cache timeouts significantly but then the
changes made centrally would also be propagated with significant latency.
I also wonder if winbind would be faster... Have you ever tried winbind?
It will be interesting to compare its performance and sssd in your setup
as we are bringing it as a back end to sssd soon.

If you can provide sanitized logs and info about how your data is
structured (how many groups, nesting, etc) we would be able to see if
this problem is something we already know about or something different.

>   access_provider = ldap
>   ldap_access_filter = memberOf=cn=jbsrd,ou=xxx,ou=Right Groups,ou=Groups,dc=xxx,dc=xxx,dc=xxx
>
> I'm just wondering if anybody else is using sssd in a large company or university with a large LDAP directory and wondered how they got around this issue.
>
> Best regards,
>
> Tim Gollschewsky.
>
> This e-mail is sent by Suncorp Group Limited ABN 66 145 290 124 or one of its related entities "Suncorp".
> Suncorp may be contacted at Level 18, 36 Wickham Terrace, Brisbane or on 13 11 55 or at suncorp.com.au.
> The content of this e-mail is the view of the sender or stated author and does not necessarily reflect the view of Suncorp. The content, including attachments, is a confidential communication between Suncorp and the intended recipient. If you are not the intended recipient, any use, interference with, disclosure or copying of this e-mail, including attachments, is unauthorised and expressly prohibited. If you have received this e-mail in error please contact the sender immediately and delete the e-mail and any attachments from your system.
> _______________________________________________
> sssd-devel mailing list
> sssd-devel at lists.fedorahosted.org
> https://fedorahosted.org/mailman/listinfo/sssd-devel


-- 
Thank you,
Dmitri Pal

Sr. Engineering Manager IPA project,
Red Hat Inc.


-------------------------------
Looking to carve out IT costs?
www.redhat.com/carveoutcosts/






More information about the sssd-devel mailing list