I am seeing extreme slowness for all users, when they first login and when they first use sudo. They may be related, but I'm currently focusing on the sudo-slowness, because it is easier to repeat, and because the user's name is hard-coded in the sudoers file. I can reproduce the problem using:
$ sudo sss_cache --groups && time sudo echo hello && time sudo echo hello Thu Dec 5 11:56:38 PM UTC 2024 hello
real 5m3.852s user 0m0.007s sys 0m0.022s hello
real 0m0.030s user 0m0.007s sys 0m0.010s
I don't understand why this should take so long, since the user's name is hard-coded in sudoers. I expect an immediate response, similar to what I see after results are cached for subsequent sudo usage.
$ grep -v -P '(^#|^$)' /etc/sudoers Defaults env_reset Defaults mail_badpass Defaults secure_path="/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/snap/bin" Defaults use_pty root ALL=(ALL:ALL) ALL %admin ALL=(ALL) ALL %sudo ALL=(ALL) NOPASSWD: ALL myuser ALL=(ALL) NOPASSWD: ALL
I primarily need sssd/ldap for user authentication against an Active Directory server. I would like to report the user's group memberships, if requested (i.e., `id`), but I don't need that information cached, unless explicitly asked.
Sudo access should be granted solely from /etc/sudoers. I don't want sssd to have any part in determining sudo restrictions.
My /etc/nsswitch.conf file is:
$ grep -v -P '(^#|^$)' /etc/nsswitch.conf passwd: files systemd sss group: files systemd sss shadow: files sss gshadow: files sudoers: files hosts: files mdns4_minimal [NOTFOUND=return] dns networks: files protocols: db files services: db files sss ethers: db files rpc: db files netgroup: nis sss automount: sss
I have tried to impose timeouts to prevent these long sudo executions, but clearly, I'm missing something.
My /etc/sss/ssd.conf file is:
$ grep -v -P '(^#|^$)' /etc/sssd/sssd.conf [sssd] domains = corp.mycompany.com config_file_version = 2 debug_level = 1 override_space = _ [nss] enum_cache_timeout = 1 entry_cache_nowait_percentage = 75 filter_groups = root, admin, sudo filter_users = root reconnection_retries = 3 entry_cache_timeout = 300 entry_cache_nowait_percentage = 75 [pam]
[domain/corp.mycompany.com] ldap_search_timeout = 3 ldap_network_timeout = 3 ldap_enumeration_search_timeout = 3 entry_cache_timeout = 600 entry_cache_nowait_percentage = 75 entry_cache_user_timeout = 5400 entry_cache_group_timeout = 5400 entry_cache_netgroup_timeout = 5400 ldap_sudo_full_refresh_interval = 0 ldap_sudo_smart_refresh_interval = 21600 ldap_sudo_use_host_filter = true ldap_sudo_include_netgroups = false ldap_sudo_include_regexp = false ldap_referrals = False enumerate = False cache_credentials = true override_shell = /bin/bash override_homedir = /home/%u id_provider = ldap access_provider = ldap auth_provider = ldap chpass_provider = ldap ldap_uri = ldaps://adldap.mycompany.com ldap_service_port = 636 ldap_search_base = dc=corp,dc=mycompany,dc=com ldap_tls_reqcert = allow ldap_id_use_start_tls = true ldap_id_mapping = true ldap_schema = ad ldap_user_search_base = ou=Accounts,dc=corp,dc=mycompany,dc=com ldap_group_search_base = dc=corp,dc=mycompany,dc=com ldap_user_object_class = user ldap_user_name = sAMAccountName ldap_user_fullname = displayName ldap_user_home_directory = unixHomeDirectory ldap_user_principal = userPrincipalName ldap_group_object_class = group ldap_group_name = cn ldap_access_order = expire ldap_account_expire_policy = ad ldap_default_bind_dn = cn=bindusername,ou=Service Accounts,ou=Accounts,dc=corp,dc=mycompany,dc=com ldap_default_authtok_type = password ldap_default_authtok = binduserpassword
What am I missing? How can I speed up sudo access?
Thanks in advance for any help you can provide. :)
(BTW, if you see anything else that I'm configuring sub-optimally, feel free to chime in.)
Hi,
what is the output of `groups $user`?
If the list is large then try ``` ignore_group_members = true subdomain_inherit = ignore_group_members ``` on the domain section of your sssd.conf
On Fri, Dec 6, 2024 at 1:14 AM Ice Man via sssd-users < sssd-users@lists.fedorahosted.org> wrote:
I am seeing extreme slowness for all users, when they first login and when they first use sudo. They may be related, but I'm currently focusing on the sudo-slowness, because it is easier to repeat, and because the user's name is hard-coded in the sudoers file. I can reproduce the problem using:
$ sudo sss_cache --groups && time sudo echo hello && time sudo echo
hello Thu Dec 5 11:56:38 PM UTC 2024 hello
real 5m3.852s user 0m0.007s sys 0m0.022s hello real 0m0.030s user 0m0.007s sys 0m0.010s
I don't understand why this should take so long, since the user's name is hard-coded in sudoers. I expect an immediate response, similar to what I see after results are cached for subsequent sudo usage.
$ grep -v -P '(^#|^$)' /etc/sudoers Defaults env_reset Defaults mail_badpass Defaults
secure_path="/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/snap/bin" Defaults use_pty root ALL=(ALL:ALL) ALL %admin ALL=(ALL) ALL %sudo ALL=(ALL) NOPASSWD: ALL myuser ALL=(ALL) NOPASSWD: ALL
I primarily need sssd/ldap for user authentication against an Active Directory server. I would like to report the user's group memberships, if requested (i.e., `id`), but I don't need that information cached, unless explicitly asked.
Sudo access should be granted solely from /etc/sudoers. I don't want sssd to have any part in determining sudo restrictions.
My /etc/nsswitch.conf file is:
$ grep -v -P '(^#|^$)' /etc/nsswitch.conf passwd: files systemd sss group: files systemd sss shadow: files sss gshadow: files sudoers: files hosts: files mdns4_minimal [NOTFOUND=return] dns networks: files protocols: db files services: db files sss ethers: db files rpc: db files netgroup: nis sss automount: sss
I have tried to impose timeouts to prevent these long sudo executions, but clearly, I'm missing something.
My /etc/sss/ssd.conf file is:
$ grep -v -P '(^#|^$)' /etc/sssd/sssd.conf [sssd] domains = corp.mycompany.com config_file_version = 2 debug_level = 1 override_space = _ [nss] enum_cache_timeout = 1 entry_cache_nowait_percentage = 75 filter_groups = root, admin, sudo filter_users = root reconnection_retries = 3 entry_cache_timeout = 300 entry_cache_nowait_percentage = 75 [pam] [domain/corp.mycompany.com] ldap_search_timeout = 3 ldap_network_timeout = 3 ldap_enumeration_search_timeout = 3 entry_cache_timeout = 600 entry_cache_nowait_percentage = 75 entry_cache_user_timeout = 5400 entry_cache_group_timeout = 5400 entry_cache_netgroup_timeout = 5400 ldap_sudo_full_refresh_interval = 0 ldap_sudo_smart_refresh_interval = 21600 ldap_sudo_use_host_filter = true ldap_sudo_include_netgroups = false ldap_sudo_include_regexp = false ldap_referrals = False enumerate = False cache_credentials = true override_shell = /bin/bash override_homedir = /home/%u id_provider = ldap access_provider = ldap auth_provider = ldap chpass_provider = ldap ldap_uri = ldaps://adldap.mycompany.com ldap_service_port = 636 ldap_search_base = dc=corp,dc=mycompany,dc=com ldap_tls_reqcert = allow ldap_id_use_start_tls = true ldap_id_mapping = true ldap_schema = ad ldap_user_search_base = ou=Accounts,dc=corp,dc=mycompany,dc=com ldap_group_search_base = dc=corp,dc=mycompany,dc=com ldap_user_object_class = user ldap_user_name = sAMAccountName ldap_user_fullname = displayName ldap_user_home_directory = unixHomeDirectory ldap_user_principal = userPrincipalName ldap_group_object_class = group ldap_group_name = cn ldap_access_order = expire ldap_account_expire_policy = ad ldap_default_bind_dn = cn=bindusername,ou=Service
Accounts,ou=Accounts,dc=corp,dc=mycompany,dc=com ldap_default_authtok_type = password ldap_default_authtok = binduserpassword
What am I missing? How can I speed up sudo access?
Thanks in advance for any help you can provide. :)
(BTW, if you see anything else that I'm configuring sub-optimally, feel free to chime in.) -- _______________________________________________ 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, report it: https://pagure.io/fedora-infrastructure/new_issue
On Fri, Dec 6, 2024 at 10:31 AM Alexey Tikhonov atikhono@redhat.com wrote:
Hi,
what is the output of `groups $user`?
If the list is large then try
ignore_group_members = true subdomain_inherit = ignore_group_members
on the domain section of your sssd.conf
re:
I would like to report the user's group memberships, if requested (i.e.,
`id`), but I don't need that information cached, unless explicitly asked. -- when your user logs in it is required to resolve his groups membership for proper access control.
On Fri, Dec 6, 2024 at 1:14 AM Ice Man via sssd-users < sssd-users@lists.fedorahosted.org> wrote:
I am seeing extreme slowness for all users, when they first login and when they first use sudo. They may be related, but I'm currently focusing on the sudo-slowness, because it is easier to repeat, and because the user's name is hard-coded in the sudoers file. I can reproduce the problem using:
$ sudo sss_cache --groups && time sudo echo hello && time sudo echo
hello Thu Dec 5 11:56:38 PM UTC 2024 hello
real 5m3.852s user 0m0.007s sys 0m0.022s hello real 0m0.030s user 0m0.007s sys 0m0.010s
I don't understand why this should take so long, since the user's name is hard-coded in sudoers. I expect an immediate response, similar to what I see after results are cached for subsequent sudo usage.
$ grep -v -P '(^#|^$)' /etc/sudoers Defaults env_reset Defaults mail_badpass Defaults
secure_path="/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/snap/bin" Defaults use_pty root ALL=(ALL:ALL) ALL %admin ALL=(ALL) ALL %sudo ALL=(ALL) NOPASSWD: ALL myuser ALL=(ALL) NOPASSWD: ALL
I primarily need sssd/ldap for user authentication against an Active Directory server. I would like to report the user's group memberships, if requested (i.e., `id`), but I don't need that information cached, unless explicitly asked.
Sudo access should be granted solely from /etc/sudoers. I don't want sssd to have any part in determining sudo restrictions.
My /etc/nsswitch.conf file is:
$ grep -v -P '(^#|^$)' /etc/nsswitch.conf passwd: files systemd sss group: files systemd sss shadow: files sss gshadow: files sudoers: files hosts: files mdns4_minimal [NOTFOUND=return] dns networks: files protocols: db files services: db files sss ethers: db files rpc: db files netgroup: nis sss automount: sss
I have tried to impose timeouts to prevent these long sudo executions, but clearly, I'm missing something.
My /etc/sss/ssd.conf file is:
$ grep -v -P '(^#|^$)' /etc/sssd/sssd.conf [sssd] domains = corp.mycompany.com config_file_version = 2 debug_level = 1 override_space = _ [nss] enum_cache_timeout = 1 entry_cache_nowait_percentage = 75 filter_groups = root, admin, sudo filter_users = root reconnection_retries = 3 entry_cache_timeout = 300 entry_cache_nowait_percentage = 75 [pam] [domain/corp.mycompany.com] ldap_search_timeout = 3 ldap_network_timeout = 3 ldap_enumeration_search_timeout = 3 entry_cache_timeout = 600 entry_cache_nowait_percentage = 75 entry_cache_user_timeout = 5400 entry_cache_group_timeout = 5400 entry_cache_netgroup_timeout = 5400 ldap_sudo_full_refresh_interval = 0 ldap_sudo_smart_refresh_interval = 21600 ldap_sudo_use_host_filter = true ldap_sudo_include_netgroups = false ldap_sudo_include_regexp = false ldap_referrals = False enumerate = False cache_credentials = true override_shell = /bin/bash override_homedir = /home/%u id_provider = ldap access_provider = ldap auth_provider = ldap chpass_provider = ldap ldap_uri = ldaps://adldap.mycompany.com ldap_service_port = 636 ldap_search_base = dc=corp,dc=mycompany,dc=com ldap_tls_reqcert = allow ldap_id_use_start_tls = true ldap_id_mapping = true ldap_schema = ad ldap_user_search_base = ou=Accounts,dc=corp,dc=mycompany,dc=com ldap_group_search_base = dc=corp,dc=mycompany,dc=com ldap_user_object_class = user ldap_user_name = sAMAccountName ldap_user_fullname = displayName ldap_user_home_directory = unixHomeDirectory ldap_user_principal = userPrincipalName ldap_group_object_class = group ldap_group_name = cn ldap_access_order = expire ldap_account_expire_policy = ad ldap_default_bind_dn = cn=bindusername,ou=Service
Accounts,ou=Accounts,dc=corp,dc=mycompany,dc=com ldap_default_authtok_type = password ldap_default_authtok = binduserpassword
What am I missing? How can I speed up sudo access?
Thanks in advance for any help you can provide. :)
(BTW, if you see anything else that I'm configuring sub-optimally, feel free to chime in.) -- _______________________________________________ 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, report it: https://pagure.io/fedora-infrastructure/new_issue
That helped my local tests, putting the cold-cache version on part with the warm-cache call.
I checked the number of groups (and its performance) using:
$ sudo sss_cache --groups && sleep 5 && time (printf "%s\n" $(groups $USER) | sort -u | wc -l) && time (printf "%s\n" $(groups $USER) | sort -u | wc -l) 29
real 0m0.620s user 0m0.007s sys 0m0.035s 29
real 0m0.026s user 0m0.012s sys 0m0.012s
Are there any negative consequences of these settings? ... BTW, I was able to reverse all of the timeout settings and still get this performance boost, just by using:
$ git diff /etc/sssd diff --git a/sssd/sssd.conf b/sssd/sssd.conf index ed048b5..7b05e21 100644 --- a/sssd/sssd.conf +++ b/sssd/sssd.conf @@ -9,6 +9,8 @@ override_space = _ [pam]
[domain/corp.mycompany.com] +ignore_group_members = true +subdomain_inherit = ignore_group_members ldap_referrals = False enumerate = False # This allows users to still login when the LDAP server cannot be reached
Thanks so much for the help! :)
Are there any negative consequences of these settings?
`getgrnam()`/`getgrgid()` libc functions (and thus, for example, `getent group $group`) won't return group members.
BTW, I was able to reverse all of the timeout settings
If a network operation doesn't complete within a timeout then it just fails, it doesn't work faster. So reduced timeouts can't give any performance boost.
On Fri, Dec 6, 2024 at 6:01 PM Ice Man via sssd-users < sssd-users@lists.fedorahosted.org> wrote:
That helped my local tests, putting the cold-cache version on part with the warm-cache call.
I checked the number of groups (and its performance) using:
$ sudo sss_cache --groups && sleep 5 && time (printf "%s\n" $(groups
$USER) | sort -u | wc -l) && time (printf "%s\n" $(groups $USER) | sort -u | wc -l) 29
real 0m0.620s user 0m0.007s sys 0m0.035s 29 real 0m0.026s user 0m0.012s sys 0m0.012s
Are there any negative consequences of these settings? ... BTW, I was able to reverse all of the timeout settings and still get this performance boost, just by using:
$ git diff /etc/sssd diff --git a/sssd/sssd.conf b/sssd/sssd.conf index ed048b5..7b05e21 100644 --- a/sssd/sssd.conf +++ b/sssd/sssd.conf @@ -9,6 +9,8 @@ override_space = _ [pam] [domain/corp.mycompany.com] +ignore_group_members = true +subdomain_inherit = ignore_group_members ldap_referrals = False enumerate = False # This allows users to still login when the LDAP server cannot be
reached
Thanks so much for the help! :)
sssd-users@lists.fedorahosted.org