sssd-users December 2024

sssd-users@lists.fedorahosted.org

4 participants
4 discussions

[SSSD] Announcing SSSD 2.10.1
by Pavel Březina 10 Dec '24

10 Dec '24

# SSSD 2.10.1 The SSSD team is announcing the release of version 2.10.1 of the System Security Services Daemon. The tarball can be downloaded from: https://github.com/SSSD/sssd/releases/tag/2.10.1 See the full release notes at: https://sssd.io/release-notes/sssd-2.10.1.html RPM packages will be made available for Fedora shortly. ## Feedback Please provide comments, bugs and other feedback via the sssd-devel or sssd-users mailing lists: https://lists.fedorahosted.org/mailman/listinfo/sssd-devel https://lists.fedorahosted.org/mailman/listinfo/sssd-users # SSSD 2.10.1 Release Notes ## Highlights ### General information * `krb5-child-test` was removed. Corresponding tests under 'src/tests/system/' are aimed to provide a comprehensive test coverage of 'krb5_child' functionality. * SSSD doesn't create anymore missing path components of DIR:/FILE: ccache types while acquiring user's TGT. The parent directory of requested ccache directory must exist and the user trying to log in must have 'rwx' access to this directory. This matches behavior of 'kinit'. * The DoT (DNS over TLS) for dynamic DNS updates is supported now. It requires new version of `nsupdate` from BIND 9.19+. * The option default_domain_suffix is deprecated. Consider using the more flexible domain_resolution_order instead. ### Packaging changes * **Important note for downstream maintainers.** A set of capabilities required by privileged binaries was further reduced to: ``` krb5_child cap_dac_read_search,cap_setgid,cap_setuid=p ldap_child cap_dac_read_search=p selinux_child cap_setgid,cap_setuid=p sssd_pam cap_dac_read_search=p ``` Keep in mind that even with a limited set of fine grained capabilities, usual precautions still should be taken while packaging binaries with file capabilities: it's very important to make sure that those are executable only by root/sssd service user. For this reason upstream spec file packages it as: ``` -rwxr-x---. 1 root sssd ``` Failing to do so (i.e. allowing non-privileged users to execute those binaries) can impose systems installing the package to a security risk. * Support of deprecated 'ad_allow_remote_domain_local_groups' sssd.conf option isn't built by default. It can be enabled using '--with-allow-remote-domain-local-groups' ./configure option. ### Configuration changes * `ad_allow_remote_domain_local_groups` option is deprecated and will be removed in future releases. * the `dyndns_server` option is extended so it can be in form of URI (dns+tls://1.2.3.4:853#servername). New set of options `dyndns_dot_cacert`, `dyndns_dot_cert` and `dyndns_dot_key` allows to configure DNS-over-TLS communication. * Added `exop_force` value for configuration option `ldap_pwmodify_mode`. This can be used to force a password change even if no grace logins are left. Depending on the configuration of the LDAP server it might be expected that the password change will fail.

1 0

slow login and first sudo usage when user is hard coded in /etc/sudo/sudoers file
by Ice Man 06 Dec '24

06 Dec '24

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.)

2 4

Slowness with freeipa and sudorules involving large hostgroups
by Richard Doerwaldt 06 Dec '24

06 Dec '24

I've configured sudo to use the ipa backend basically using the config ipa-client-install generated for me and it's mostly working. However, when I configure sudo rules in FreeIPA with hostgroups containing a large amount of hosts, and I attempt to run sudo with an emptied sssd cache I get delays as sssd looks up the hosts in those netgroups, sometimes leading to timeouts when these lookups exceed ldap_search_timeout. I don't think looking up the hosts the netgroups should be required to evaluate the sudo rules. Configuring ignore_group_members=True unfortunately doesn't seem to help me here. Is there any way I can avoid sssd looking up these large netgroups?

4 4

[SSSD] Announcing SSSD 2.9.6
by Pavel Březina 05 Dec '24

05 Dec '24

# SSSD 2.9.6 The SSSD team is announcing the release of version 2.9.6 of the System Security Services Daemon. The tarball can be downloaded from: https://github.com/SSSD/sssd/releases/tag/2.9.6 Note that this is the latest release of 2.9.x LTM branch. See the full release notes at: https://sssd.io/release-notes/sssd-2.9.6.html RPM packages will be made available for Fedora shortly. ## Feedback Please provide comments, bugs and other feedback via the sssd-devel or sssd-users mailing lists: https://lists.fedorahosted.org/mailman/listinfo/sssd-devel https://lists.fedorahosted.org/mailman/listinfo/sssd-users # SSSD 2.9.6 Release Notes ## Highlights ### General information * The DoT for dynamic DNS updates is supported now. It requires new version of `nsupdate` from BIND 9.19+. * The option `default_domain_suffix` is deprecated. Consider using the more flexible `domain_resolution_order` instead. ### Important fixes * When the `DP_OPT_DYNDNS_REFRESH_OFFSET` enumerator was created, the associated `struct dp_option` was not. Because these structures are part of an array and the enumerator is used as the index, the wrong structure would be accessed when trying to use this index. This problem was fixed by creating the missing structure. ### Configuration changes * The `dyndns_server` option is extended so it can be in form of URI (`dns+tls://1.2.3.4:853#servername`). New set of options `dyndns_dot_cacert`, `dyndns_dot_cert` and `dyndns_dot_key` allows to configure DNS-over-TLS communication. * Added `exop_force` value for configuration option `ldap_pwmodify_mode`. This can be used to force a password change even if no grace logins are left. Depending on the configuration of the LDAP server it might be expected that the password change will fail.

1 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

sssd-users December 2024