sssd-users October 2021

sssd-users@lists.fedorahosted.org

13 participants
14 discussions

Starting SSSD without root
by Tero Saarni 09 Apr '24

09 Apr '24

Hi, I'm trying to run SSSD inside docker container without root user. The container is executed in OpenShift cluster which does not allow running as root inside container. SSSD requires root and checks for this specifically. Is there any workaround for this? I believe the limitation is implemented for security reasons, in order to have most critical parts executed as root and have it drop privileges for other parts but this now completely blocks using SSSD in the above environment. -- Tero

5 20

sssd performance on large domains
by zfnoctis＠gmail.com 03 Feb '22

03 Feb '22

Hi, I'm wondering if there are any plans to improve sssd performance on large active directory domains (100k+ users, 40k+ groups), or if there are settings I am not aware of that can greatly improve performance, specifically for workstation use cases. Currently if I do not set "ignore_group_members = True" in sssd.conf, logins can take upwards of 6 minutes and "sssd_be" will max the CPU for up to 20 minutes after logon, which makes it a non-starter. The reason I want to allow group members to be seen is that I want certain domain groups to be able to perform elevated actions using polkit. If I ignore group members, polkit reports that the group is empty and so no one can elevate in the graphical environment. Ultimately this means that Linux workstations are at a severe disadvantage since they cannot be bound to the domain and have the normal set of access features users and IT expect from macOS or Windows. Distributions used: Ubuntu 16.04 (sssd 1.13.4-1ubuntu1.1), Ubuntu 16.10 (sssd 1.13.4-3) and Fedora 24 (sssd-1.13.4-3.fc24). All exhibit the same problems. I've also tried "ldap_group_nesting_level = 1" without seeing any noticeable improvement with respect to performance. Putting the database on /tmp isn't viable as these are workstations that will reboot semi-frequently, and I don't believe this is an I/O bound performance issue anyways. Thanks for your time.

6 29

kcm, gssproxy and klist
by Winberg Adam 16 Dec '21

16 Dec '21

With KCM and gssproxy we often see a long list of credentials when doing a 'klist': [user.u@lxserv2114 ~]$ klist Ticket cache: KCM:17098:66803 Default principal: user.u@AD Valid starting Expires Service principal 01/01/1970 00:00:00 01/01/1970 00:00:00 Encrypted/Credentials/v1@X-GSSPROXY: 01/01/1970 00:00:00 01/01/1970 00:00:00 Encrypted/Credentials/v1@X-GSSPROXY: 01/01/1970 00:00:00 01/01/1970 00:00:00 Encrypted/Credentials/v1@X-GSSPROXY: 01/01/1970 00:00:00 01/01/1970 00:00:00 Encrypted/Credentials/v1@X-GSSPROXY: 01/01/1970 00:00:00 01/01/1970 00:00:00 Encrypted/Credentials/v1@X-GSSPROXY: 01/01/1970 00:00:00 01/01/1970 00:00:00 Encrypted/Credentials/v1@X-GSSPROXY: 01/01/1970 00:00:00 01/01/1970 00:00:00 Encrypted/Credentials/v1@X-GSSPROXY: and so on... The actual gssproxy credentials at /var/lib/gssproxy/clients/ does not correspond with this output, it only contains what could be expected - a TGT and maybe some service tickets. The ever growing 'klist' list of credentials is a problem, after a while the user can no longer get any new credentials and therefore has no access to its NFS homedir (sec=krb5). I'm guessing it's the 'max_uid_ccaches' option in sssd-kcm that prevents this. What is going on here - have we configured gssproxy/kcm wrong or is this a bug? Regards Adam

3 5

SSSD entry_cache_nowait_percentage/ enum_cache_timeout not working properly?
by Robert Wagensveld 27 Oct '21

27 Oct '21

Hi all, I was hoping you could help me with this, as I am essentially clueless by this point.Even setting debug logging to 8 does not give much information as to what the problem might be. I have chosen to set the enum_cache_timeout to a high value, e.g. 26000 seconds. This because we have a very large environment in terms of AD groups (we use Kerberos over LDAP) and this takes a long time to retrieve all groups. Weird part is, although this helped on some clients, it does not actually reduce login/sudo times on others. I have set the following values in sssd.conf: entry_cache_nowait_percentage = 50 entry_cache_timeout = 60 My reason for this is that defining a value for the nowait percentage automatically update entries in the background. Not sure if I set the percentage rights though. https://linux.die.net/man/5/sssd.conf What is wise to do in this regard? My desired behavior would be that it returns entries from cache even while offline as often as possible, and updates the cache in the background. I don't want users to have to wait for SSSD to iterate through all our insane amounts of groups in the foreground. Thanks in advance!

3 4

Group cache entry of removed member in be
by Thomas HUMMEL 22 Oct '21

22 Oct '21

Hello, sssd-2.3.0 on RHEL/CentOS 8.3, I'm trying to figure out how refreshing a user cache entry could impact (or not) a group entry this user is or has been a member of in the backend I'm using sssd-2.3.0 on RHEL/CentOS 8.3 with auth_provider = ldap ldap_schema = AD access_provider = ldap id_provider = ldap authselect provides the following setup of nsswitch: passwd: sss files systemd group: sss files systemd Initial experience on *some* hosts using the same sssd config: a user <user> which has been for some time (greater than any sssd timeout) removed from group <group> in the AD backend still appeared as a member when running getent group <group> "refreshing" this user with getent passwd <user> would fix the issue I don't quite get the reasoning behind this behavior. Does the link between the 2 actions lies in the ghost/unghost mechanism ? I did not manage to reproduce it. The tests I made on another similar host raised some more questions though: a) I was able to verify the expected behavior of entry_cache_group_timeout (or entry_cache_timeout for that matter): after 1h30m getent group <group> would get the group entry from the backend. Before that result were fed by the cache and could not be consistent with the backend b) I'm having trouble understanding how sss_cache -u or -g works as, using ldbsearch -H <cache_ldb_file> I can see the dataExpireTimestamp set to 1 but after what I thought would be a refresh (getent passwd or group), I still see this value : is this because sssd RAM cache is not sync'ed ? Finally, do you confirm that the setting of ldap_purge_cache_timeout should not change how the membership of a user in a group is return ? Thanks for you help -- Thomas HUMMEL

3 3

Ubuntu 20.04 server joined to child AD domain unable to auth users from parent domain
by Joseph Agored 19 Oct '21

19 Oct '21

I have an Ubuntu 20.04 server that I have successfully joined to my domain using realm, US.EXAMPLE.COM. The way our AD is structured is that all machines are joined to the child domain for their region and all users are setup in the parent domain, EXAMPLE.COM. With full trust, etc, of course. I can successfully look up users in the US.EXAMPLE.COM domain with id or getent passwd, but cannot look up any users in the parent EXAMPLE.COM domain. I can successfully kinit to the parent domain. I have tried adding capaths to the krb5.conf as well as adding the parent domain to the sssd.conf file like this: [domain/EXAMPLE.com] inherit_from = US.EXAMPLE.com id_provider = ad debug_level = 7 krb5_validate = False The closest I seem to get is an error message saying the server isn't found in the parent domain's Kerberous DB. Client 'host/SERVER01(a)US.EXAMPLE.COM' not found in Kerberos database Surely there is a way to use the existing trust to let the machine joined to the child domain authenticate users from the parent domain? I have done this successfully in this domain before with a RedHat server using FQDN, but I am trying to get away from RedHat and move to Ubuntu and the same configuration tricks were unable to let the Ubuntu server lookup or authenticate users from the parent domain even with FQDNs.

1 0

Timing sensitive issue on `testing pam_acct_mgmt` which is also seen on SSH logins
by Aitor Pazos 18 Oct '21

18 Oct '21

Hi all, Let me introduce the symptoms that triggered this investigation. First, versions: - OS: Ubuntu 20.04 - SSSD: 2.2.3-3ubuntu0.7 - Platform: x86_64 Some weeks after starting using a new region/provider we noticed some intermittent issue impacting SSH logins (ie: clients got `Connection closed by UNKNOWN port 65535` on `ssh ...`). When looking into it, I was able to reproduce it somewhat reliably. It happens after some time of inactivity for that user, but if I constantly issue commands (ie: `watch sssctl user-checks <user>` or `watch ssh <host> whoami` from a client) the issue wont trigger. If I stopped trying out those commands and tried again ~30 minutes later, it would fail. With these symptoms I had these possibilities in mind: some caching issue, some authentication expiring, connections pools issues... I enabled detailed logging and compared logs from a successful request and a failed one and I found what seems to be the source of the error from sssd logs perspective, but still can't make much sense of it. Log extracted from sssd_<domain>.log: ``` (Wed Oct 13 19:40:52 2021) [be[<domain>]] [ipa_hbac_rule_info_next] (0x0400): Sending request for next search base: [cn=hbac,dc=ipa,dc=corp,<dc <domain>>][2][(&(objectclass=ipaHBACRule)(ipaenabledflag=TRUE)(accessRuleType=allow)(|(hostCategory=all)(...)))] (Wed Oct 13 19:40:52 2021) [be[<domain>]] [sdap_print_server] (0x2000): Searching <ip10.1.10.102:389 (Wed Oct 13 19:40:52 2021) [be[<domain>]] [sdap_get_generic_ext_step] (0x0400): calling ldap_search_ext with [(&(objectclass=ipaHBACRule)(ipaenabledflag=TRUE)(accessRuleType=allow)(|(hostCategory=all)(...)][cn=hbac,dc=ipa,dc=corp,<dc <domain>>]. (Wed Oct 13 19:40:52 2021) [be[<domain>]] [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [objectclass] (Wed Oct 13 19:40:52 2021) [be[<domain>]] [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [cn] (Wed Oct 13 19:40:52 2021) [be[<domain>]] [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [ipauniqueid] (Wed Oct 13 19:40:52 2021) [be[<domain>]] [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [ipaenabledflag] (Wed Oct 13 19:40:52 2021) [be[<domain>]] [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [accessRuleType] (Wed Oct 13 19:40:52 2021) [be[<domain>]] [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [memberUser] (Wed Oct 13 19:40:52 2021) [be[<domain>]] [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [userCategory] (Wed Oct 13 19:40:52 2021) [be[<domain>]] [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [memberService] (Wed Oct 13 19:40:52 2021) [be[<domain>]] [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [serviceCategory] (Wed Oct 13 19:40:52 2021) [be[<domain>]] [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [sourceHost] (Wed Oct 13 19:40:52 2021) [be[<domain>]] [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [sourceHostCategory] (Wed Oct 13 19:40:52 2021) [be[<domain>]] [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [externalHost] (Wed Oct 13 19:40:52 2021) [be[<domain>]] [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [memberHost] (Wed Oct 13 19:40:52 2021) [be[<domain>]] [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [hostCategory] (Wed Oct 13 19:40:52 2021) [be[<domain>]] [sdap_get_generic_ext_step] (0x2000): ldap_search_ext called, msgid = 18 (Wed Oct 13 19:40:52 2021) [be[<domain>]] [sdap_op_add] (0x2000): New operation 18 timeout 60 (Wed Oct 13 19:40:52 2021) [be[<domain>]] [sdap_process_result] (0x2000): Trace: sh[0x55d349f96d00], connected[1], ops[0x55d349ff16e0], ldap[0x55d34a10cba0] (Wed Oct 13 19:40:52 2021) [be[<domain>]] [sdap_process_result] (0x2000): Trace: end of ldap_result list (Wed Oct 13 19:41:52 2021) [be[<domain>]] [sdap_op_timeout] (0x1000): Issuing timeout for 18 (Wed Oct 13 19:41:52 2021) [be[<domain>]] [sdap_op_destructor] (0x1000): Abandoning operation 18 (Wed Oct 13 19:41:52 2021) [be[<domain>]] [generic_ext_search_handler] (0x0040): sdap_get_generic_ext_recv failed [110]: Connection timed out (Wed Oct 13 19:41:52 2021) [be[<domain>]] [ipa_hbac_rule_info_done] (0x0080): Could not retrieve HBAC rules (Wed Oct 13 19:41:52 2021) [be[<domain>]] [ipa_pam_access_handler_done] (0x0020): Unable to fetch HBAC rules [110]: Connection timed out (Wed Oct 13 19:41:52 2021) [be[<domain>]] [dp_req_done] (0x0400): DP Request [PAM Account #21]: Request handler finished [0]: Success ``` I tried using `ldap_enumeration_search_timeout = 180` which updated the timeout in (`[sdap_op_add] (0x2000): New operation 18 timeout 60 `) but same result (`enumerate` and `subdomain_enumerate` config options are left to their defaults, `false` and `none` respectively). I looked at the IPA servers LDAP logs and saw now related requests regarding `ipaHBACRules` so I assume the request didn't even left the server. I tried tweaking some other caching options like `cached_auth_timeout` and `pam_id_timeout` without any impact. Also tried clearing up the caches with `sss_cache -E` or `systemctl stop sssd && rm /var/lib/sss/db/* && systemctl start sssd` and nothing changed. This is the error returned by `sssctl user-checks` when it fails: ``` $ sudo sssctl user-checks <user> user: <user> action: acct service: system-auth SSSD nss user lookup result: - user name: <user> - user id: <uid> - group id: <gid> - gecos: <name> - home directory: /home/<user> - shell: /bin/bash InfoPipe operation failed. Check that SSSD is running and the InfoPipe responder is enabled. Make sure 'ifp' is listed in the 'services' option in sssd.conf.InfoPipe User lookup with [<user>] failed. testing pam_acct_mgmt pam_acct_mgmt: System error PAM Environment: - no env - ``` Any pointer here would be very useful. Thank you! Aitor

2 3

[SSSD] Announcing SSSD 2.5.2
by Pavel Březina 14 Oct '21

14 Oct '21

# SSSD 2.6.0 The SSSD team is proud to announce the release of version 2.6.0 of the System Security Services Daemon. The tarball can be downloaded from: https://github.com/SSSD/sssd/releases/tag/2.6.0 See the full release notes at: https://sssd.io/release-notes/sssd-2.6.0.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 ## Highlights ### General information * Support of legacy json format for ccaches was dropped * Support of long time deprecated `secrets` responder was dropped. * Support of long time deprecated `local` provider was dropped. * This release drops support of `--with-unicode-lib` configure option. `libunistring` will be used unconditionally for Unicode processing. * This release removes pcre1 support. pcre2 is used unconditionally. * p11_child does not stop at the first empty slot when searching for tokens * A flaw was found in SSSD, where the sssctl command was vulnerable to shell command injection via the logs-fetch and cache-expire subcommands. This flaw allows an attacker to trick the root user into running a specially crafted sssctl command, such as via sudo, to gain root access. The highest threat from this vulnerability is to confidentiality, integrity, as well as system availability. This patch fixes a flaw by replacing `system()` with `execvp()`. ### New features * Basic support of user's 'subuid and subgid ranges' for IPA provider and corresponding plugin for shadow-utils were introduced. Limitations: - single subid interval pair (subuid+subgid) per user - idviews aren't supported - only forward lookup (user -> subid ranges) Take a note, this is MVP of experimental feature. Significant changes might be required later, after initial feedback. Corresponding support in shadow-utils was merged upstream, but since there is no upstream release available yet, SSSD feature isn't built by default. Build can be enabled with `--with-subid` configure option. Plugin's install path can be configured with `--with-subid-lib-path=` (`${libdir}` by default) ### Important fixes * KCM now replace the old credential with new one when storing an updated credential that is however already present in the ccache to avoid unnecessary growth of the ccache. * Improve mpg search filter to be more reliable with id-overrides and the new auto_private_groups options. * Even if the forest root is disabled for lookups all required internal data is initialized to be able to refresh the list of trusted domains in the forest from a DC of the forest root. * ccache files are created with the right ownership during offline Smartcard authentication * AD ping is now sent over `ldap` if `cldap` support is not available during build. This helps to build SSSD on distributions without `cldap` support in `libldap`. * CVE-2021-3621 ### Configuration changes * New IPA provider's option `ipa_subid_ranges_search_base` allows configuration of search base for user's subid ranges. Default: `cn=subids,%basedn`

1 1

[SSSD] Announcing SSSD 2.6.0
by Pavel Březina 14 Oct '21

14 Oct '21

1 0

feasible to use sssd in mostly offline mode?
by James Ralston 12 Oct '21

12 Oct '21

For our on-site Linux machines, we use the sssd-ad provider to both map users/groups from Active Directory, and to authenticate users via Kerberos. It works fantastically well, to the point where we have absolutely no desire to go back to maintaining local users/groups in /etc/passwd and /etc/group (respectively). We are contemplating offering remote Linux laptops to our users. But our InfoSec team is adamant that our AD DCs must not be reachable from the Internet at large. So unless the owner of the laptop logs in to the laptop locally and then connects to our VPN, the laptop will have no access to Active Directory, and therefore sssd will be in offline mode. We are wondering whether it would be feasible to set the various sssd caches to have long values (e.g. 180 days) so that as long as the user fires up the laptop and connects to the VPN once every 180 days, they will still be able to login (using their cached password) and getpwnam/getpwuid/getgrnam/getgrgid will still work for their uids/gids (because sssd will return the values it cached from the last time it was able to reach the AD DCs). It’s not clear to us how we would implement this. We could adjust various timeouts; e.g., from: entry_cache_timeout = 5400 cache_credentials = FALSE To: entry_cache_timeout = 7776000 cache_credentials = TRUE …but I don’t think this is going to do what we want. We only want sssd to keep entries in the cache for 90 days when it is offline. If sssd comes back online (because the user connected to the VPN and thus AD is reachable again), we want AD to refresh any cached entries that are older than 90 minutes. So, what we really want is an option for sssd that essentially says, “You are frequently going to be operating in offline mode, so only kick things out of the cache when you are in online mode, because otherwise there’s a good chance that the user won’t be able to login to fire up the VPN so that you can switch to online mode.” Has anyone attempted running sssd in a mostly-offline environment like this? If so, how well does it work, and what settings are you using? Thanks!

2 1

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

sssd-users October 2021