sssd-users January 2023

sssd-users@lists.fedorahosted.org

13 participants
9 discussions

filter_users using user id
by Francois Rigault 22 Mar '25

22 Mar '25

Greetings, we run some podman containers that come with their own local users, such as this one: ironic-inspector:x:42461:42461::/var/lib/ironic-inspector:/usr/sbin/nologin when running a top on the server, top tries to resolve the user name for that id and fails, however there is still a BE_REQ_USER request sent: (2022-12-30 22:42:33): [be[MY.DOMAIN.NET]] [dp_get_account_info_send] (0x0200): Got request for [0x1][BE_REQ_USER][idnumber=42461] I would hope to get rid of these requests against the domain. unfortunately in MY.DOMAIN.NET there are uids below and above this number, so I cannot rely on the "min_id" parameter to filter users. I would like to know if it is possible to support using user ids in the [nss] filter_users to prevent those user requests to the domain, or if anyone has any other suggestion. I increased the entry_negative_timeout to reduce the number of queries, but filtering them out entirely would be even better. Thank you!

4 4

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

Only IPv4 addresses in /var/lib/sss/pubconf/kdcinfo.DOMAIN
by Brian J. Murrell 22 Jul '23

22 Jul '23

On my dual-stack network where some machines actually don't have IPv4 connectivity I am finding that whatever is writing IP addresses into /var/lib/sss/pubconf/kdcinfo.DOMAIN is only writing the IPv4 addresses and not the KDC's IPv6 addresses. The result is that such an IPv6 machine cannot reach a KDC until I remove that file. It ends up being recreated at some subsequent point again with only the KDC's IPv4 addresses. Is this a bug or a problem with my configuration? Cheers, b.

2 3

'automount -m' segfaults when using sssd
by Prentice Bisbal 30 Jan '23

30 Jan '23

sssd-users, I'm having an odd problem with autmount, that seems to be specific to using sssd for autofs. The operating system is Springdale Open Enterprise Linux 9.1, which is a rebuild of RHEL maintained by Princeton University, so it should be 100% bug compatible with RHEL (and Rocky). My configuration is using Kerberos for auth, and LDAP directory services. When my nsswitch.conf entry for automount looks like this: automount: sss files Testing the configuration of automount/sssdwith 'automount -m' leads to a segfault: # automount -m autofs dump map information =========================== global options: none configured Mount point: /p source(s): Segmentation fault (core dumped) If I change nsswitch.conf to use files only or use ldap like this: automount: files or this: automount files ldap Everything works as expected. LDAP searches using ldapsearch works just fine, and using getent to get user and group information (which is stored in LDAP) works just fine. I've increased the debugging levels for the relevant SSSD daemons: # egrep '^\[|debug_level' /etc/sssd/sssd.conf [domain/PPPL] debug_level = 8 [sssd] debug_level = 8 [nss] debug_level = 8 [pam] [autofs] debug_level = 8 Looking in the related log files the logs for my default domain show that it is getting information from the LDAP directory, and then it fails saying it can't contact the LDAP server: (2023-01-24 16:01:31): [be[default]] [sysdb_set_entry_attr] (0x0200): [RID#6] Entry [name=/lldap:ou\3Dauto.local\,ou\3Dmounts\,dc\3Dunix\,dc\3Dpppl\,dc\3Dgov,name=auto.master,cn=autofsmaps,cn=custom,cn=default,cn=sysdb] has set [cache] attrs. (2023-01-24 16:01:31): [be[default]] [sysdb_entry_attrs_diff] (0x0400): [RID#6] Entry [name=/pfsldap:ou\3Dauto.pfs\,ou\3Dmounts\,dc\3Dunix\,dc\3Dpppl\,dc\3Dgov,name=auto.master,cn=autofsmaps,cn=custom,cn=default,cn=sysdb] differs, reason: ts_cache doesn't trace this type of entry. (2023-01-24 16:01:31): [be[default]] [sysdb_set_entry_attr] (0x0200): [RID#6] Entry [name=/pfsldap:ou\3Dauto.pfs\,ou\3Dmounts\,dc\3Dunix\,dc\3Dpppl\,dc\3Dgov,name=auto.master,cn=autofsmaps,cn=custom,cn=default,cn=sysdb] has set [cache] attrs. (2023-01-24 16:01:31): [be[default]] [fo_resolve_service_send] (0x0100): [RID#6] Trying to resolve service 'LDAP' (2023-01-24 16:01:31): [be[default]] [get_server_status] (0x1000): [RID#6] Status of server 'host-a.pppl.gov' is 'working' (2023-01-24 16:01:31): [be[default]] [get_port_status] (0x1000): [RID#6] Port status of port 389 for server 'host-a.pppl.gov' is 'not working' Not only do the earlier log file entries show that sssd_bes actually getting data from LDAP before it reports an error, but I can run queries from this machine to our LDAP server with 'ldapsearch', and all the other computers in our environment, which are running CentOS 7 or Rocky 8 using the same configuration files. -- Prentice

2 6

Install/upgrade sssd 2.7.0 and above not wrking
by shay cohen 23 Jan '23

23 Jan '23

Hi, I am trying to install SSSD by downloading the tar file. ( os ubuntu 22.04 LTS) Download form this link: https://github.com/SSSD/sssd/releases/tag/2.7.0 After running the "./configure" I go an error error: tdb header files are not installed Anyone has experience with upgrade/install of sssd?? Thanks, Shay

4 3

LDAP/Yubikey PIV authentication problems
by Bill McGrory 13 Jan '23

13 Jan '23

Hello, I am looking for clues on how to debug a problem with my configuration for using LDAP and Yubikey PIV authentication. I have successfully gotten my sssd config to recognize my ldap server, and can authenticate and log in to a user from there. I also am prompted to enter my smartcard. my p11_chiuld.log correctly logs the presence of my key, and the certs offered up for authentication. However, If I configure my pam common-auth so that I only use pam_sss for auth, and comment out pam_unix, I get 3 failed logging attempts, but It never asks me for a pin. I have debug_level set to 10 for all the different sections, but I in looking at the logs I can't see any particular error that stands out. I feel like the last relevant sssd_pam.log entries are Fri Jan 13 08:33:48 2023) [pam] [cache_req_create_and_add_result] (0x0400): CR #5: Found 1 entries in domain closed.aerosoftinc.com (Fri Jan 13 08:33:48 2023) [pam] [cache_req_done] (0x0400): CR #5: Finished: Success (Fri Jan 13 08:33:48 2023) [pam] [pd_set_primary_name] (0x0400): User's primary name is mcgrory(a)closed.aerosoftinc.com (Fri Jan 13 08:33:48 2023) [pam] [pam_initgr_cache_set] (0x2000): [mcgrory] added to PAM initgroup cache (Fri Jan 13 08:33:48 2023) [pam] [pam_dp_send_req] (0x0100): Sending request with the following data: (Fri Jan 13 08:33:48 2023) [pam] [pam_print_data] (0x0100): command: SSS_PAM_AUTHENTICATE (Fri Jan 13 08:33:48 2023) [pam] [pam_print_data] (0x0100): domain: closed.aerosoftinc.com (Fri Jan 13 08:33:48 2023) [pam] [pam_print_data] (0x0100): user: mcgrory(a)closed.aerosoftinc.com (Fri Jan 13 08:33:48 2023) [pam] [pam_print_data] (0x0100): service: sudo (Fri Jan 13 08:33:48 2023) [pam] [pam_print_data] (0x0100): tty: /dev/pts/1 (Fri Jan 13 08:33:48 2023) [pam] [pam_print_data] (0x0100): ruser: mcgrory (Fri Jan 13 08:33:48 2023) [pam] [pam_print_data] (0x0100): rhost: not set (Fri Jan 13 08:33:48 2023) [pam] [pam_print_data] (0x0100): authtok type: 0 (Fri Jan 13 08:33:48 2023) [pam] [pam_print_data] (0x0100): newauthtok type: 0 (Fri Jan 13 08:33:48 2023) [pam] [pam_print_data] (0x0100): priv: 0 (Fri Jan 13 08:33:48 2023) [pam] [pam_print_data] (0x0100): cli_pid: 109539 (Fri Jan 13 08:33:48 2023) [pam] [pam_print_data] (0x0100): logon name: mcgrory (Fri Jan 13 08:33:48 2023) [pam] [pam_print_data] (0x0100): flags: 513 (Fri Jan 13 08:33:48 2023) [pam] [pam_dom_forwarder] (0x0100): pam_dp_send_req returned 0 (Fri Jan 13 08:33:48 2023) [pam] [sbus_dispatch] (0x4000): Dispatching. (Fri Jan 13 08:33:48 2023) [pam] [pam_dp_send_req_done] (0x0200): received: [7 (Authentication failure)][closed.aerosoftinc.com] this is from sssd_closed.aerosoftinc.com.log (Fri Jan 13 08:33:48 2023) [be[closed.aerosoftinc.com]] [pam_print_data] (0x0100): command: SSS_PAM_AUTHENTICATE (Fri Jan 13 08:33:48 2023) [be[closed.aerosoftinc.com]] [pam_print_data] (0x0100): domain: closed.aerosoftinc.com (Fri Jan 13 08:33:48 2023) [be[closed.aerosoftinc.com]] [pam_print_data] (0x0100): user: mcgrory(a)closed.aerosoftinc.com (Fri Jan 13 08:33:48 2023) [be[closed.aerosoftinc.com]] [pam_print_data] (0x0100): service: sudo (Fri Jan 13 08:33:48 2023) [be[closed.aerosoftinc.com]] [pam_print_data] (0x0100): tty: /dev/pts/1 (Fri Jan 13 08:33:48 2023) [be[closed.aerosoftinc.com]] [pam_print_data] (0x0100): ruser: mcgrory (Fri Jan 13 08:33:48 2023) [be[closed.aerosoftinc.com]] [pam_print_data] (0x0100): rhost: (Fri Jan 13 08:33:48 2023) [be[closed.aerosoftinc.com]] [pam_print_data] (0x0100): authtok type: 0 (Fri Jan 13 08:33:48 2023) [be[closed.aerosoftinc.com]] [pam_print_data] (0x0100): newauthtok type: 0 (Fri Jan 13 08:33:48 2023) [be[closed.aerosoftinc.com]] [pam_print_data] (0x0100): priv: 0 (Fri Jan 13 08:33:48 2023) [be[closed.aerosoftinc.com]] [pam_print_data] (0x0100): cli_pid: 109539 (Fri Jan 13 08:33:48 2023) [be[closed.aerosoftinc.com]] [pam_print_data] (0x0100): logon name: not set (Fri Jan 13 08:33:48 2023) [be[closed.aerosoftinc.com]] [pam_print_data] (0x0100): flags: 0 (Fri Jan 13 08:33:48 2023) [be[closed.aerosoftinc.com]] [dp_attach_req] (0x0400): DP Request [PAM Authenticate #10]: New request. Flags [0000]. (Fri Jan 13 08:33:48 2023) [be[closed.aerosoftinc.com]] [dp_attach_req] (0x0400): Number of active DP request: 1 (Fri Jan 13 08:33:48 2023) [be[closed.aerosoftinc.com]] [sss_domain_get_state] (0x1000): Domain closed.aerosoftinc.com is Active (Fri Jan 13 08:33:48 2023) [be[closed.aerosoftinc.com]] [dp_req_done] (0x0400): DP Request [PAM Authenticate #10]: Request handler finished [0]: Success (Fri Jan 13 08:33:48 2023) [be[closed.aerosoftinc.com]] [_dp_req_recv] (0x0400): DP Request [PAM Authenticate #10]: Receiving request data. (Fri Jan 13 08:33:48 2023) [be[closed.aerosoftinc.com]] [dp_req_destructor] (0x0400): DP Request [PAM Authenticate #10]: Request removed. (Fri Jan 13 08:33:48 2023) [be[closed.aerosoftinc.com]] [dp_req_destructor] (0x0400): Number of active DP request: 0 (Fri Jan 13 08:33:48 2023) [be[closed.aerosoftinc.com]] [dp_method_enabled] (0x0400): Target selinux is not configured (Fri Jan 13 08:33:48 2023) [be[closed.aerosoftinc.com]] [sbus_issue_request_done] (0x0400): sssd.dataprovider.pamHandler: Success (Fri Jan 13 08:33:48 2023) [be[closed.aerosoftinc.com]] [sbus_dispatch] (0x4000): Dispatching. I see no evidence in that log of failure, but I'm not sure what I'm looking for? my sssd.conf file is as follows [sssd] domains = closed.aerosoftinc.com debug_level = 10 [pam] pam_cert_auth = true pam_verbosity = 3 pam_cert_db_path = /etc/sssd/pki/aerosoft_ca.pem debug_level = 10 [domain/closed.aerosoftinc.com] debug_level = 10 id_provider = ldap selinux_provider = none auth_provider = ldap ldap_uri = ldaps://backup.closed.aerosoftinc.com cache_credentials = false ldap_search_base = dc=closed,dc=aerosoftinc,dc=com [certmap/closed.aerosoftinc.com/main] matchrule = <ISSUER>^CN=AeroSoft CA 2,O=AeroSoft Inc,L=Blacksburg,ST=Virginia,C=US$ maprule = (gecos={subject_dn}) domains = closed.aerosoftinc.com

2 2

Ensure to start a systemd service after users are available
by Ronald Wimmer 12 Jan '23

12 Jan '23

Hi, We have got a systemd service unit file that uses a user that comes from FreeIPA. However, the user is not available when the service tries to start. Adding after=sssd.service nss-user-lookup.target seems not to be sufficient. What's the right way to go? Cheers, Ronald

1 0

Does sssd support direct integration to AzureAD?
by Spike White 09 Jan '23

09 Jan '23

All, Our org uses sssd for direct integration to our corp AD forest, which has the std MS schema extension (RFC 2307bis IIRC). Currently, we have some Windows builds running in the Azure cloud, integrated via AzureAD. I'm not a Windows engineer, so I don't know the details of this Windows-based user authentication. Other than it works. Does sssd support direct integration to AzureAD? I read this with great interest: https://research.redhat.com/blog/engineering_project/integrate-sssd-with-az… So if sssd supports this, any sssd config changes required for AzureAD? Spike

3 4

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

sssd-users January 2023