On Mon, Nov 12, 2018 at 04:25:30PM -0000, Jonathan Gray wrote: > Hello, > > We need help debugging this issue. > > For some servers we're experiencing over 10 second delay logging in with IPA > user. > Since the issue isn't present everywhere we're finding it hard to debug. > > > SSSD config looks like this:: > > [domain/hostname.com] > > cache_credentials = true > krb5_store_password_if_offline = true > ipa_domain = hostname.com > id_provider = ipa > auth_provider = ipa > access_provider = ipa > ldap_tls_cacert = /etc/ipa/ca.crt > ipa_hostname = hostname.com > chpass_provider = ipa > dyndns_update = True > ipa_server = ipa1-hostname, ipa2-hostname > dyndns_iface = eth0 > dns_discovery_domain = hostname.com > debug_level = 9 > > [sssd] > services = nss, sudo, pam, ssh > > domains = hostname.com > [nss] > homedir_substring = /home > > [pam] > > [sudo] > > [autofs] > > [ssh] > > [pac] > > [ifp] > > [secrets] > > [session_recording] > > We're wondering if there's any obvious configurations we could apply above > that would improve SSSD performance
There's no make_sssd_faster=True switch :-), it's hard to give an advise without at least a little understanding of what might be the root cause. In general, login consists of: - retrieving the user information - you can simulate the worst case by running "sss_cache -E; id $username". Above you said that the user is an IPA one, does the user really come from the IPA directory or e.g. IPA-AD trusts? The difference would be that with IPA, the sssd on the clients talks directly to the IPA directory server, with IPA-AD trusts the SSSD on the clients talks to the DS on the IPA servers which ask SSSD on the servers which ask the AD DS. So in the trust case, typically you want to first make sure the servers are fast. If this is the slow piece, then look into the SSSD logs for messages like dp_get_account_info_send (this is the beginning of a lookup) and dp_req_reply_std (this is the end of a lookup). Are there many of these messages or is there a long delay between them? Some time ago we also instrumented the SSSD code with systemtap probes, so maybe it would be easier to run a systemtap script and see what is slow, e.g. http://justin-stephenson.blogspot.com/2017/05/measuring-sssd-performance-with.html - authentication - you can simulate the SSSD authentication /partially/ with kinit. But SSSD also does some extra steps like verifying the TGT comes from the same KDC that issued the keytab. But all in all you can look for messages like dp_pam_handler_send for the pam request beginning and dp_req_done for PAM request end. - authorization - similar to above, dp_pam_handler_send followed by SSS_PAM_ACCT_MGMT marks the beginning of the account control check and dp_req_done marks the account check end - session setup - unless you use FleetCommander to control your desktop systems, SSSD typically does nothing in this step >, and what exactly to look out for in sssd debug logs that would help us with >our investigation. I'd advise to experiment with the lookups, kinit and check the systemtap scripts or check which PAM phase might be slow for you. Also, if you have many groups or especially many large groups, it might be worth a try to suppress group members (ignore_group_members=True) _______________________________________________ sssd-users mailing list -- sssd-users@lists.fedorahosted.org To unsubscribe send an email to sssd-users-le...@lists.fedorahosted.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedorahosted.org/archives/list/sssd-users@lists.fedorahosted.org