sssd-users January 2022

sssd-users@lists.fedorahosted.org

13 participants
12 discussions

SSSD.Service not starting
by Manjot Singh 12 Feb '25

12 Feb '25

● sssd.service - System Security Services Daemon Loaded: loaded (/lib/systemd/system/sssd.service; enabled; vendor preset: enabled) Active: failed (Result: exit-code) since Wed 2020-01-29 14:12:32 EST; 9s ago Process: 23217 ExecStart=/usr/sbin/sssd -i ${DEBUG_LOGGER} (code=exited, status=4) Main PID: 23217 (code=exited, status=4) Jan 29 14:12:32 pop-os systemd[1]: sssd.service: Service RestartSec=100ms expired, scheduling restart. Jan 29 14:12:32 pop-os systemd[1]: sssd.service: Scheduled restart job, restart counter is at 5. Jan 29 14:12:32 pop-os systemd[1]: Stopped System Security Services Daemon. Jan 29 14:12:32 pop-os systemd[1]: sssd.service: Start request repeated too quickly. Jan 29 14:12:32 pop-os systemd[1]: sssd.service: Failed with result 'exit-code'. Jan 29 14:12:32 pop-os systemd[1]: Failed to start System Security Services Daemon.

3 2

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

id_overide issue | 03111823
by Abhijit Roy 27 Jan '22

27 Jan '22

Cus is using id override for user(bjsadmin(a)munimadrid.es). The user has its uid overrided to 16792947 After restart of sssd id bjsadmin(a)munimadrid.es shows 'no such user'. Workaround: Performing a gid-override for bjsadmin(a)munimadrid.es resolves the issue The versions details: Machine RHEL 8.0 where it works -> sssd-2.2.0-19.el8_1.1.x86_64 Machine RHEL 8.0 where it does not work --> sssd-2.3.0-9.el8.x86_64/sssd-2.2.3-20.el8.x86_64/sssd-2.5.2-2.el8_5.1.x86_64 RHEL 8.5 and sssd-2.5.2-2.el8_5.1.x86_64, it does not work. We need to add gid-override for bjsadmin(a)munimadrid.es It works on all RHEL 7 machines. Did we change anything from in terms of override from sssd-2.2.0-19.el8_1.1.x86_64 to sssd-2.3.0-9.el8.x86_64/sssd-2.2.3-20.el8.x86_64 Thank you, *Abhijit Roy* He/Him/His Technical Support Engineer Red Hat Insights - Predict Risk. Get Guidance. Improve Security. <https://www.redhat.com/en/technologies/management/insights> Red Hat Enterprise Linux 8. Any Cloud. Any Workload. One OS. <https://www.redhat.com/en/enterprise-linux-8> <https://red.ht/sig>

1 0

PAM troubleshooting
by Rob Crittenden 26 Jan '22

26 Jan '22

I'm trying to get a multi-threaded PAM app working to log in users using the 'login' service to generate client load: https://github.com/freeipa/freeipa-perftest/blob/master/src/pamtest.c The load is generated by running multiple client VMs and on each client running the pam tester with multiple threads. It works about 99% of the time and I'm struggling to find out why it occasionally fails with: Authentication failure (7) The environment is IPA with pre-created users all set with the same known LDAP and Kerberos password. The password is not marked as expired. The journal is reporting a different PAM error: Jan 24 16:11:57 client003.ipa.test pamtest[4285]: pam_sss(login:auth): authentication failure; logname= uid=0 euid=0 tty= ruser= rhost= user=user19client003.ipa.test Jan 24 16:11:57 client003.ipa.test pamtest[4285]: pam_sss(login:auth): received for user user19client003.ipa.test: 6 (Permission denied) Jan 24 16:11:59 client003.ipa.test pamtest[4285]: pam_unix(login:session): session opened for user user19client003.ipa.test(uid=1751200171) by (uid=0) Jan 24 16:14:01 client003.ipa.test pamtest[4285]: pam_unix(login:session): session closed for user user19client003.ipa.test The sssd pam log reports: * (2022-01-24 16:11:50): [pam] [pam_cmd_authenticate] (0x0100): entering pam_cmd_authenticate * (2022-01-24 16:11:50): [pam] [sss_domain_get_state] (0x1000): Domain ipa.test is Active [ short snip of parse_name ] * (2022-01-24 16:11:50): [pam] [pd_set_primary_name] (0x0400): User's primary name is user19client003.ipa.test(a)ipa.test * (2022-01-24 16:11:50): [pam] [pam_initgr_check_timeout] (0x2000): User [user19client003.ipa.test] found in PAM cache. * (2022-01-24 16:11:50): [pam] [pam_dp_send_req] (0x0100): Sending request [CID #2] with the following data: * (2022-01-24 16:11:50): [pam] [pam_print_data] (0x0100): [CID #2] command: SSS_PAM_AUTHENTICATE * (2022-01-24 16:11:50): [pam] [pam_print_data] (0x0100): [CID #2] domain: ipa.test * (2022-01-24 16:11:50): [pam] [pam_print_data] (0x0100): [CID #2] user: user19client003.ipa.test(a)ipa.test * (2022-01-24 16:11:50): [pam] [pam_print_data] (0x0100): [CID #2] service: login * (2022-01-24 16:11:50): [pam] [pam_print_data] (0x0100): [CID #2] tty: not set * (2022-01-24 16:11:50): [pam] [pam_print_data] (0x0100): [CID #2] ruser: not set * (2022-01-24 16:11:50): [pam] [pam_print_data] (0x0100): [CID #2] rhost: not set * (2022-01-24 16:11:50): [pam] [pam_print_data] (0x0100): [CID #2] authtok type: 1 (Password) * (2022-01-24 16:11:50): [pam] [pam_print_data] (0x0100): [CID #2] newauthtok type: 0 (No authentication token available) * (2022-01-24 16:11:50): [pam] [pam_print_data] (0x0100): [CID #2] priv: 1 * (2022-01-24 16:11:50): [pam] [pam_print_data] (0x0100): [CID #2] cli_pid: 4285 * (2022-01-24 16:11:50): [pam] [pam_print_data] (0x0100): [CID #2] logon name: user19client003.ipa.test * (2022-01-24 16:11:50): [pam] [pam_print_data] (0x0100): [CID #2] flags: 2 * (2022-01-24 16:11:50): [pam] [pam_dom_forwarder] (0x0100): pam_dp_send_req returned 0 * (2022-01-24 16:11:53): [pam] [pam_initgr_cache_remove] (0x2000): [user20client003.ipa.test] removed from PAM initgroup cache * (2022-01-24 16:11:55): [pam] [pam_initgr_cache_remove] (0x2000): [user19client003.ipa.test] removed from PAM initgroup cache * (2022-01-24 16:11:57): [pam] [sbus_dispatch] (0x4000): Dispatching. * (2022-01-24 16:11:57): [pam] [pam_dp_send_req_done] (0x0200): received: [6 (Permission denied)][ipa.test][CID #2] * (2022-01-24 16:11:57): [pam] [pam_reply] (0x4000): pam_reply initially called with result [6]: Permission denied. this result might be changed during processing I just can't tell what the permission denied means. Permission to do what? I can provide fuller logs if needed. I suspect it may be a timeout as there is a several second delay in some of the processing. There is nothing wrong with this particular user. I can manually re-run the tool and it will pass 100% but the server is under significantly less stress. Hoping for suggestions on where to start looking. thanks rob

4 4

[ding-libs] Announcing ding-libs 0.6.2
by Alexey Tikhonov 25 Jan '22

25 Jan '22

# ding-libs 0.6.2 The SSSD team announces a minor maintenance update of ding-libs - version 0.6.2 The tarball can be downloaded from: https://github.com/SSSD/ding-libs/releases/tag/0.6.2 Tickets fixed: - https://pagure.io/SSSD/ding-libs/issue/3182 - https://github.com/SSSD/ding-libs/issues/5 - https://github.com/SSSD/ding-libs/issues/7 - https://github.com/SSSD/ding-libs/issues/8 - https://github.com/SSSD/ding-libs/issues/9

1 0

[SSSD] Announcing SSSD 2.6.3
by Pavel Březina 25 Jan '22

25 Jan '22

# SSSD 2.6.3 The SSSD team is proud to announce the release of version 2.6.3 of the System Security Services Daemon. The tarball can be downloaded from: https://github.com/SSSD/sssd/releases/tag/2.6.3 See the full release notes at: https://sssd.io/release-notes/sssd-2.6.3.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 ### Important fixes * A regression introduced in sssd-2.6.2 in the IPA provider that prevented users from login was fixed. Access control always denied access because the selinux_child returned an unexpected reply. * A critical regression that prevented authentication of users via AD and IPA providers was fixed. LDAP port was reused for Kerberos communication and this provider would send incomprehensible information to this port. * When authenticating AD users, backtrace was triggered even though everything was working correctly. This was caused by a search in the global catalog. Servers from the global catalog are filtered out of the list before writing the KDC info file. With this fix, SSSD does not attempt to write to the KDC info file when performing a GC lookup.

1 0

Heads up. Moving 'ding-libs' to github. (Date to be defined)
by Alexey Tikhonov 20 Jan '22

20 Jan '22

Hello, as a follow up to the complete SSSD migration to github [1], we decided to continue with the consolidation effort and to make the same step with the 'ding-libs' project that currently uses both Pagure [2] and Github [3]. This is only a heads up. Precise date isn't set yet. But as a first step: we will no longer accept new bug reports at Pagure and we will kindly ask you to use Github instead. Thank you, Alexey. [1] https://lists.fedoraproject.org/archives/list/sssd-users@lists.fedorahosted… [2] https://pagure.io/SSSD/ding-libs [3] https://github.com/SSSD/ding-libs

1 1

kvon in keytab is getting out of sync
by Sebastian Grebe 20 Jan '22

20 Jan '22

Hello, we are getting report from users where they suddenly can‘t authenticate to their Linux computers anymore. These computers are joint to ore MS Domain using adcli und sssd. Checking the log reveals that the kerberos tickets stored in /etc/krb5.keytab do not have the expected KVON. At the moment we can’t tell what’s causing the issue. It happens only sporadically. I’m under the impression only computer without permanent network connection (Laptops) are affected. The log shows: Jan 11 09:30:52 lc015564 systemd[1]: Starting System Security Services Daemon... Jan 11 09:30:52 lc015564 sssd[1376]: Starting up Jan 11 09:30:52 lc015564 sssd_be[1609]: Starting up Jan 11 09:30:52 lc015564 sssd_ifp[1633]: Starting up Jan 11 09:30:52 lc015564 systemd[1]: Started System Security Services Daemon. Jan 11 09:30:55 lc015564 sssd_be[1609]: Backend is offline Jan 11 09:49:32 lc015564 sssd_be[1609]: Backend is online Jan 11 09:49:41 lc015564 krb5_child[6111]: Cannot find key for LC015564$(a)WAGO.LOCAL kvno 11 in keytab Jan 11 09:49:41 lc015564 krb5_child[6111]: Cannot find key for LC015564$(a)WAGO.LOCAL kvno 11 in keytab Jan 11 09:49:49 lc015564 adcli[6102]: GSSAPI client step 1 Jan 11 09:49:49 lc015564 adcli[6102]: GSSAPI client step 1 Jan 11 09:49:50 lc015564 adcli[6102]: GSSAPI client step 1 Jan 11 10:00:57 lc015564 krb5_child[6838]: Cannot find key for LC015564$(a)WAGO.LOCAL kvno 11 in keytab Jan 11 10:00:57 lc015564 krb5_child[6838]: Cannot find key for LC015564$(a)WAGO.LOCAL kvno 11 in keytab And klist -k shows: Keytab name: FILE:/etc/krb5.keytab KVNO Principal ---- -------------------------------------------------------------------------- 10 LC015564$(a)WAGO.LOCAL 10 LC015564$(a)WAGO.LOCAL 10 LC015564$(a)WAGO.LOCAL 10 host/LC015564(a)WAGO.LOCAL 10 host/LC015564(a)WAGO.LOCAL 10 host/LC015564(a)WAGO.LOCAL 10 host/lc015564.wago.local(a)WAGO.LOCAL 10 host/lc015564.wago.local(a)WAGO.LOCAL 10 host/lc015564.wago.local(a)WAGO.LOCAL 10 RestrictedKrbHost/LC015564(a)WAGO.LOCAL 10 RestrictedKrbHost/LC015564(a)WAGO.LOCAL 10 RestrictedKrbHost/LC015564(a)WAGO.LOCAL 10 RestrictedKrbHost/lc015564.wago.local(a)WAGO.LOCAL 10 RestrictedKrbHost/lc015564.wago.local(a)WAGO.LOCAL 10 RestrictedKrbHost/lc015564.wago.local(a)WAGO.LOCAL 9 LC015564$(a)WAGO.LOCAL 9 LC015564$(a)WAGO.LOCAL 9 LC015564$(a)WAGO.LOCAL 9 host/LC015564(a)WAGO.LOCAL 9 host/LC015564(a)WAGO.LOCAL 9 host/LC015564(a)WAGO.LOCAL 9 host/lc015564.wago.local(a)WAGO.LOCAL 9 host/lc015564.wago.local(a)WAGO.LOCAL 9 host/lc015564.wago.local(a)WAGO.LOCAL 9 RestrictedKrbHost/LC015564(a)WAGO.LOCAL 9 RestrictedKrbHost/LC015564(a)WAGO.LOCAL 9 RestrictedKrbHost/LC015564(a)WAGO.LOCAL 9 RestrictedKrbHost/lc015564.wago.local(a)WAGO.LOCAL 9 RestrictedKrbHost/lc015564.wago.local(a)WAGO.LOCAL 9 RestrictedKrbHost/lc015564.wago.local(a)WAGO.LOCAL This is a our sssd.conf (it's from o different computer): [sssd] domains = wago.local config_file_version = 2 services = ifp [domain/wago.local] default_shell = /bin/bash fallback_homedir = /home/%d/%u cache_credentials = true krb5_store_password_if_offline = true krb5_realm = WAGO.LOCAL krb5_ccname_template = /tmp/krb5cc_%U realmd_tags = manages-system joined-with-adcli id_provider = ad access_provider = ad ad_domain = wago.local ad_enabled_domains = wago.local ad_hostname = lc017547.wago.local use_fully_qualified_names = false ldap_id_mapping = true ldap_user_gecos = displayName ldap_use_tokengroups = false ldap_search_base = dc=wago,dc=local?subtree? ldap_user_search_base = ou=User,ou=Minden,ou=Germany,dc=wago,dc=local?subtree??ou=User,ou=Administration,dc=wago,dc=local?onelevel?(&(objectClass=user)(cn=a2*))?ou=Service,dc=wago,dc=local?subtree? ldap_group_search_base = cn=Users,dc=wago,dc=local?onelevel?(&(objectClass=group)(cn=Domain Users))?ou=Groups,ou=Minden,ou=Germany,dc=wago,dc=local?onelevel?(&(objectClass=group)(cn=&01-PC-Support)) ldap_netgroup_search_base = cn=Users,dc=wago,dc=local?onelevel? ignore_group_members = true enumerate = false dyndns_update = true dyndns_refresh_interval = 7200 dyndns_update_ptr = true dyndns_server = 10.1.100.2 case_sensitive = Preserving [nss] filter_users = root filter_groups = root [pam] offline_credentials_expiration = 0 offline_failed_login_attempts = 3 offline_failed_login_delay = 5 And the krb5.conf: [libdefaults] ticket_lifetime = 240:00:00 renew_lifetime = 240:00:00 clock_skew = 300 renewable = true default_ccache_name = FILE:/tmp/krb5cc_%{uid} default_realm = WAGO.LOCAL kdc_timesync = 1 ccache_type = 4 forwardable = true proxiable = true udp_preference_limit = 1 noaddresses = true fcc-mit-ticketflags = true [realms] WAGO.LOCAL = { admin_server = 10.1.101.200 admin_server = 10.1.100.1 admin_server = 10.1.100.253 admin_server = 10.1.100.2 } [domain_realm] .wago.local = WAGO.LOCAL wago.local = WAGO.LOCAL [login] krb4_convert = true krb4_get_tickets = false To solve the issue we delete the computer from the domain, delete the krb5.keytab and rejoin them.

4 5

sssd-1.16.5-10.0.1.el7_9.11.x86_64 is under-discovering AD domains
by Spike White 18 Jan '22

18 Jan '22

sssd experts, This sssd version (released Tue 23 Nov 2021) is under-discovering AD domains. A similar sssd bug occurred last July, where sssd over-discovered AD domains (AD domains for which there was not a legal trust relationship with this AD domain.) Now, it appears that sssd is under-discovering AD domains (not discovering AD domains which have a valid trust relationship with this AD domain). Ultimately, an sssd developer on this sssd mailing list (Sumit Rose) resolved the July bug of AD domain over-discovery. Hopefully, someone will recognize this new AD domain under-discovery bug. We have opened RedHat support case #03124778 for this new AD domain under-discovery bug. But to be frank, such complicated sssd bugs don’t get resolved by RHEL L1 customer support. (RHEL customer support is great, but not for complicated sssd bugs.) For now, we have pulled sssd-*-1.16.5-10.0.1.el7_9.11.x86_64 RPMs out of our Jan OS patching cycle. Spike

2 3

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

sssd-users January 2022