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 -- [email protected]
To unsubscribe send an email to [email protected]
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/[email protected]
