Hi all,
We've been using SSSD for a while successfully in our Kerberos over LDAP enterprise environment. However, our SSSD online query time, especially over VPN, is very poor, usually each login request or sudo requests takes about 1 minute. There does not seem to be a way around it, not even forcing SSSD to use the cache for a while even when online again. entry_cache_timeout does not help. Is there anything I'm missing? Some configuration options I do not know about yet?
[sssd] config_file_version = 2 services = nss, pam, ifp domains = company.nl debug_level = 9 [nss] entry_cache_nowait_percentage = 5 filter_groups = root filter_users = root debug_level = 9 [pam] offline_failed_login_attempts = 3 offline_failed_login_delay = 30 debug_level = 9 [domain/company.nl] debug_level = 9 id_provider = ldap ignore_group_members = true auth_provider = krb5 chpass_provider = krb5 access_provider = permit cache_credentials = true min_id = 1000 entry_cache_timeout = 28800 krb5_realm = COMPANY.NL krb5_canonicalize = false krb5_renewable_lifetime = 24h krb5_renew_interval = 6h krb5_server = dc03.company.nl krb5_store_password_if_offline = true krb5_ccname_template = FILE:%d/krb5cc_%U ldap_uri = ldap://dc03.company.nl ldap_search_base = DC=Company,DC=nl ldap_user_search_base = OU=CompanyCompany,DC=nl ldap_group_search_base = OU=Company,DC=Company,DC=nl?? ldap_referrals = false enumerate = false ldap_force_upper_case_realm = true ldap_schema = rfc2307bis ldap_id_use_start_tls = false ldap_tls_reqcert = demand ldap_tls_cacert = /etc/ssl/certs/ca-certificates.crt ldap_sasl_canonicalize = true ldap_sasl_mech = GSSAPI ldap_user_object_class = user ldap_user_name = sAMAccountName ldap_user_uid_number = uidNumber ldap_user_gid_number = gidNumber ldap_user_gecos = gecos ldap_user_shell = loginShell ldap_user_home_directory = unixHomeDirectory ldap_user_principal = nonExistingAttribute ldap_group_object_class = group ldap_group_name = cn ldap_group_gid_number = gidNumber ldap_group_member = member
Am Tue, Nov 30, 2021 at 02:24:34PM -0000 schrieb Robert Wagensveld:
Hi all,
We've been using SSSD for a while successfully in our Kerberos over LDAP enterprise environment. However, our SSSD online query time, especially over VPN, is very poor, usually each login request or sudo requests takes about 1 minute. There does not seem to be a way around it, not even forcing SSSD to use the cache for a while even when online again. entry_cache_timeout does not help. Is there anything I'm missing? Some configuration options I do not know about yet?
Hi,
until recently SSSD unconditionally updated the group-memberships of the user during authentication. With recent versions of SSSD there is the new option pam_initgroups_scheme and SSSD does not update the group-memberships if the related user is already logged in. This should already help for sudo. To speed up the login as well if the user is not already logged in you can set 'pam_initgroups_scheme = never' and SSSD will used cached data as long as the cached data is valid.
HTH
bye, Sumit
[sssd] config_file_version = 2 services = nss, pam, ifp domains = company.nl debug_level = 9 [nss] entry_cache_nowait_percentage = 5 filter_groups = root filter_users = root debug_level = 9 [pam] offline_failed_login_attempts = 3 offline_failed_login_delay = 30 debug_level = 9 [domain/company.nl] debug_level = 9 id_provider = ldap ignore_group_members = true auth_provider = krb5 chpass_provider = krb5 access_provider = permit cache_credentials = true min_id = 1000 entry_cache_timeout = 28800 krb5_realm = COMPANY.NL krb5_canonicalize = false krb5_renewable_lifetime = 24h krb5_renew_interval = 6h krb5_server = dc03.company.nl krb5_store_password_if_offline = true krb5_ccname_template = FILE:%d/krb5cc_%U ldap_uri = ldap://dc03.company.nl ldap_search_base = DC=Company,DC=nl ldap_user_search_base = OU=CompanyCompany,DC=nl ldap_group_search_base = OU=Company,DC=Company,DC=nl?? ldap_referrals = false enumerate = false ldap_force_upper_case_realm = true ldap_schema = rfc2307bis ldap_id_use_start_tls = false ldap_tls_reqcert = demand ldap_tls_cacert = /etc/ssl/certs/ca-certificates.crt ldap_sasl_canonicalize = true ldap_sasl_mech = GSSAPI ldap_user_object_class = user ldap_user_name = sAMAccountName ldap_user_uid_number = uidNumber ldap_user_gid_number = gidNumber ldap_user_gecos = gecos ldap_user_shell = loginShell ldap_user_home_directory = unixHomeDirectory ldap_user_principal = nonExistingAttribute ldap_group_object_class = group ldap_group_name = cn ldap_group_gid_number = gidNumber ldap_group_member = member _______________________________________________ sssd-users mailing list -- sssd-users@lists.fedorahosted.org To unsubscribe send an email to sssd-users-leave@lists.fedorahosted.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedorahosted.org/archives/list/sssd-users@lists.fedorahosted.o... Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Sumit,
Good day! I'm curious about your statement "during authentication". I seek clarification. It's when you said:
... until recently SSSD unconditionally updated the group-memberships of the user *during authentication*.
We do a lot of GSSAPI-based ssh logins. That is, we acquire a Kerberos credential up front and then ssh to the Linux server. The ssh client (putty or equiv) passes the kerberos credentials and ssh daemon automatically logs us in. No passwords. It's secure because ssh daemon is verifying the Kerberos identity with KDC (AD controllers).
So effectively, sshd is bypassing the pam "auth" phase for these Kerberized logins. it is doing the "account" and "session" phase for these logins only.
Also, we have set up some sudo privs with "NOPASSWD:" flag like so:
%<priv group> ALL=NOPASSWD: /bin/su
then it appears that sudo is by passing the PAM "auth" phase when these engineers issue "sudo su -l oracle". Again, doing the "account" and "session" phases only.
In these cases, does that mean that sssd is bypassing updating group-memberships?
Spike
On Tue, Nov 30, 2021 at 9:36 AM Sumit Bose sbose@redhat.com wrote:
Am Tue, Nov 30, 2021 at 02:24:34PM -0000 schrieb Robert Wagensveld:
Hi all,
We've been using SSSD for a while successfully in our Kerberos over LDAP enterprise environment. However, our SSSD online query time, especially over VPN, is very poor, usually each login request or sudo requests takes about 1 minute. There does not seem to be a way around it, not even forcing SSSD to use the cache for a while even when online again. entry_cache_timeout does not help. Is there anything I'm missing? Some configuration options I do not know about yet?
Hi,
until recently SSSD unconditionally updated the group-memberships of the user during authentication. With recent versions of SSSD there is the new option pam_initgroups_scheme and SSSD does not update the group-memberships if the related user is already logged in. This should already help for sudo. To speed up the login as well if the user is not already logged in you can set 'pam_initgroups_scheme = never' and SSSD will used cached data as long as the cached data is valid.
HTH
bye, Sumit
[sssd] config_file_version = 2 services = nss, pam, ifp domains = company.nl debug_level = 9 [nss] entry_cache_nowait_percentage = 5 filter_groups = root filter_users = root debug_level = 9 [pam] offline_failed_login_attempts = 3 offline_failed_login_delay = 30 debug_level = 9 [domain/company.nl] debug_level = 9 id_provider = ldap ignore_group_members = true auth_provider = krb5 chpass_provider = krb5 access_provider = permit cache_credentials = true min_id = 1000 entry_cache_timeout = 28800 krb5_realm = COMPANY.NL krb5_canonicalize = false krb5_renewable_lifetime = 24h krb5_renew_interval = 6h krb5_server = dc03.company.nl krb5_store_password_if_offline = true krb5_ccname_template = FILE:%d/krb5cc_%U ldap_uri = ldap://dc03.company.nl ldap_search_base = DC=Company,DC=nl ldap_user_search_base = OU=CompanyCompany,DC=nl ldap_group_search_base = OU=Company,DC=Company,DC=nl?? ldap_referrals = false enumerate = false ldap_force_upper_case_realm = true ldap_schema = rfc2307bis ldap_id_use_start_tls = false ldap_tls_reqcert = demand ldap_tls_cacert = /etc/ssl/certs/ca-certificates.crt ldap_sasl_canonicalize = true ldap_sasl_mech = GSSAPI ldap_user_object_class = user ldap_user_name = sAMAccountName ldap_user_uid_number = uidNumber ldap_user_gid_number = gidNumber ldap_user_gecos = gecos ldap_user_shell = loginShell ldap_user_home_directory = unixHomeDirectory ldap_user_principal = nonExistingAttribute ldap_group_object_class = group ldap_group_name = cn ldap_group_gid_number = gidNumber ldap_group_member = member _______________________________________________ sssd-users mailing list -- sssd-users@lists.fedorahosted.org To unsubscribe send an email to sssd-users-leave@lists.fedorahosted.org Fedora Code of Conduct:
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives:
https://lists.fedorahosted.org/archives/list/sssd-users@lists.fedorahosted.o...
Do not reply to spam on the list, report it:
https://pagure.io/fedora-infrastructure _______________________________________________ sssd-users mailing list -- sssd-users@lists.fedorahosted.org To unsubscribe send an email to sssd-users-leave@lists.fedorahosted.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedorahosted.org/archives/list/sssd-users@lists.fedorahosted.o... Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Am Tue, Nov 30, 2021 at 09:57:24AM -0600 schrieb Spike White:
Sumit,
Good day! I'm curious about your statement "during authentication". I seek clarification. It's when you said:
... until recently SSSD unconditionally updated the group-memberships
of the user *during authentication*.
We do a lot of GSSAPI-based ssh logins. That is, we acquire a Kerberos credential up front and then ssh to the Linux server. The ssh client (putty or equiv) passes the kerberos credentials and ssh daemon automatically logs us in. No passwords. It's secure because ssh daemon is verifying the Kerberos identity with KDC (AD controllers).
So effectively, sshd is bypassing the pam "auth" phase for these Kerberized logins. it is doing the "account" and "session" phase for these logins only.
Also, we have set up some sudo privs with "NOPASSWD:" flag like so:
%<priv group> ALL=NOPASSWD: /bin/su
then it appears that sudo is by passing the PAM "auth" phase when these engineers issue "sudo su -l oracle". Again, doing the "account" and "session" phases only.
In these cases, does that mean that sssd is bypassing updating group-memberships?
Hi,
thanks for asking with *during authentication* I meant any PAM related operation which typically happens at login/authentication time. So 'account' and 'session' phase will trigger an update of the group memberships as well. But SSSD has a cache (option pam_id_timeout) to avoid that the group memberships are updated at every step.
It's a bit tricky to find the right level of technical details. I'm not sure if every reader here knows about PAM and what it does, so I used the vague term 'authentication'.
bye, Sumit
Spike
On Tue, Nov 30, 2021 at 9:36 AM Sumit Bose sbose@redhat.com wrote:
Am Tue, Nov 30, 2021 at 02:24:34PM -0000 schrieb Robert Wagensveld:
Hi all,
We've been using SSSD for a while successfully in our Kerberos over LDAP enterprise environment. However, our SSSD online query time, especially over VPN, is very poor, usually each login request or sudo requests takes about 1 minute. There does not seem to be a way around it, not even forcing SSSD to use the cache for a while even when online again. entry_cache_timeout does not help. Is there anything I'm missing? Some configuration options I do not know about yet?
Hi,
until recently SSSD unconditionally updated the group-memberships of the user during authentication. With recent versions of SSSD there is the new option pam_initgroups_scheme and SSSD does not update the group-memberships if the related user is already logged in. This should already help for sudo. To speed up the login as well if the user is not already logged in you can set 'pam_initgroups_scheme = never' and SSSD will used cached data as long as the cached data is valid.
HTH
bye, Sumit
[sssd] config_file_version = 2 services = nss, pam, ifp domains = company.nl debug_level = 9 [nss] entry_cache_nowait_percentage = 5 filter_groups = root filter_users = root debug_level = 9 [pam] offline_failed_login_attempts = 3 offline_failed_login_delay = 30 debug_level = 9 [domain/company.nl] debug_level = 9 id_provider = ldap ignore_group_members = true auth_provider = krb5 chpass_provider = krb5 access_provider = permit cache_credentials = true min_id = 1000 entry_cache_timeout = 28800 krb5_realm = COMPANY.NL krb5_canonicalize = false krb5_renewable_lifetime = 24h krb5_renew_interval = 6h krb5_server = dc03.company.nl krb5_store_password_if_offline = true krb5_ccname_template = FILE:%d/krb5cc_%U ldap_uri = ldap://dc03.company.nl ldap_search_base = DC=Company,DC=nl ldap_user_search_base = OU=CompanyCompany,DC=nl ldap_group_search_base = OU=Company,DC=Company,DC=nl?? ldap_referrals = false enumerate = false ldap_force_upper_case_realm = true ldap_schema = rfc2307bis ldap_id_use_start_tls = false ldap_tls_reqcert = demand ldap_tls_cacert = /etc/ssl/certs/ca-certificates.crt ldap_sasl_canonicalize = true ldap_sasl_mech = GSSAPI ldap_user_object_class = user ldap_user_name = sAMAccountName ldap_user_uid_number = uidNumber ldap_user_gid_number = gidNumber ldap_user_gecos = gecos ldap_user_shell = loginShell ldap_user_home_directory = unixHomeDirectory ldap_user_principal = nonExistingAttribute ldap_group_object_class = group ldap_group_name = cn ldap_group_gid_number = gidNumber ldap_group_member = member _______________________________________________ sssd-users mailing list -- sssd-users@lists.fedorahosted.org To unsubscribe send an email to sssd-users-leave@lists.fedorahosted.org Fedora Code of Conduct:
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives:
https://lists.fedorahosted.org/archives/list/sssd-users@lists.fedorahosted.o...
Do not reply to spam on the list, report it:
https://pagure.io/fedora-infrastructure _______________________________________________ sssd-users mailing list -- sssd-users@lists.fedorahosted.org To unsubscribe send an email to sssd-users-leave@lists.fedorahosted.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedorahosted.org/archives/list/sssd-users@lists.fedorahosted.o... Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
sssd-users mailing list -- sssd-users@lists.fedorahosted.org To unsubscribe send an email to sssd-users-leave@lists.fedorahosted.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedorahosted.org/archives/list/sssd-users@lists.fedorahosted.o... Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Hi Sumit, setting 'pam_initgroups_scheme = never' indeed helps with not retrieving group memberships during the lock screen. However, the request time is indeed long still, I don't think setting pam_id_timeout to a high value is really smart to do.. Although it helps with speeding up requests as it uses the memory cache more often, it will have he side effect of not loading AD groups? Are there any other negative side effects?
Greetings, Robert
sssd-users@lists.fedorahosted.org