sssd-users February 2025

sssd-users@lists.fedorahosted.org

13 participants
12 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

Issue with SSSD and NSS user/group resolution, sort of
by Lawrence Kearney 10 Mar '25

10 Mar '25

I hope someone can help. I have an odd issue I haven't seen before. I've done a lot of checking under the hood, but I'm stuck. We have hundreds of systems using the v2.9+ of the daemon (AD and LDAP providers). We're deploying a new HPC cluster using Rocky Linux 9 containers (all other systems are RHEL 8/9) as stateless compute nodes. These nodes are ephemeral so we use the LDAP providers. The observed issue is the daemons load and run as expected. The nodes mount NFS file systems but do not resolve file and directory ownerships for LDAP users until I manually run a "getent" or "id" on any user or group. It doesn't even have to be a user or group that owns files. So any type of NSS lookup seems to kick start the process. From there the node is fine. libnfs, libnss, sssd-nfs-idmap, libsss_nss_idmap, etc are all the same on nodes that don't do this. DNS works, there's no difference in daemon configurations from working ones. systemd unit files are identical, etc. I cannot figure out why these nodes need to be poked by NSS to start using NSS. Very peculiar. Any insight would be appreciated, -- lawrence

2 13

Curiosity question about sssd with a Kerberos/LDAP or AD back-end
by Spike White 26 Feb '25

26 Feb '25

All, We notice that when sssd-kcm service is messed up and not running, password auth fails. Interestingly, Kerberos (GSSAPI auth still succeeds. Why? So I know why password auth fails. In /etc/krb5.conf.d/kcm_default_cache, it has: [libdefaults] default_ccache_name = KCM: So in password auth, it is failing on the step of writing the Kerberos credential cache into the credentials store (KCM). I speculate that it’s specifically pam_sss.so in the auth phase that’s failing to do this. You can see this failure on the command line: [admspike_white@austgcore23 ~]$ kinit admspike_white(a)EXAMPLE.COM kinit: Connection refused while getting default ccache I understand why password auth fails. My question is – why does Kerberos (GSSAPI) auth succeed? My guess is that sshd handles GSSAPI auth internally and never calls the PAM stack in the “auth” phase. Only for the “account” and “session” phase. Thus pam_sss.so never gets invoked for the auth phase. Spike

4 4

SSSD Not Restarted After Being Killed By Watchdog
by Mark Jackson 25 Feb '25

25 Feb '25

Hello, I previously opened an issue on GitHub (https://github.com/SSSD/sssd/issues/7838) regarding this, but I feel the mailing list is more active and I may get a response here quicker. I am investigating an ongoing issue. We are working with vendor support also, but we have still not been able to find a solution. SSSD Version: 2.9.4 OS: RHEL 7/8/9 SSSD is connected upstream to a RedHat IdM (FreeIPA) cluster. There seems to be two related issues. 1. SSSD is being killed by watchdog. We think external load from backups is causing this to happen, but it is still unclear for certain. 2. SSSD is not restarted after being killed by Watchdog. When this happens users become unable to login via SSH. We have tried the following to resolve the issue, but we continue to see SSSD get killed by Watchdog without being restarted. - Upgrading SSSD to latest version available to RHEL. - Increasing SSSD timeout. - Adding 'Restart=on-failure' to the SSSD systemd unit. - Looking for selinux alerts and setting selinux to permissive. - Disabling third party security services. - Validating the configs. - Reviewing relevant logs. - As a temporary fix we added a cron job to restart the service, but this does not work reliably. I can collect logs, or configs, at request to further this investigation. I am seeking feedback regarding known issues or ways I may continue to look for root cause. Feedback would be appreciated, thank you in advance.

3 2

SSSD problem one-way trust GSSAPI Error: Unspecified GSS failure. Minor code may provide more information (Server not found in Kerberos database)
by Omnis ludis - games 17 Feb '25

17 Feb '25

Good afternoon, please tell me there is such an infrastructure windows domain and samba domain between them, one-sided external outgoing trust relationships are set up, so that users from the windows domain can freely enter the samba domain, I entered the client into the samba domain and all users from the samba domain can safely pass to this client, but that's not the task of users they do not want to authenticate from the windows domain in any way when I try to log in to a client from the samba domain under them, I get the following error in sssd on the client, GSSAPI Error: Unspecified GSS failure. Minor code may provide more information (Server not found in Kerberos database), do I understand correctly that this works like this, the client accesses the samba domain controller, since there is no given user in samba, the request is redirected to the windows domain controller and that in turn must provide information about this to users from its database kerberos? but for some reason this does not happen, does anyone have at least some information on this error, I have already tried many different scenarios and can not log in as a user in any way, as if samba does not process information correctly, while if you build a two-way trusting relationship, then everything works as it should

2 1

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

[SSSD] Announcing SSSD 2.10.2
by Pavel Březina 08 Feb '25

08 Feb '25

# SSSD 2.10.2 The SSSD team is announcing the release of version 2.10.2 of the System Security Services Daemon. The tarball can be downloaded from: https://github.com/SSSD/sssd/releases/tag/2.10.2 See the full release notes at: https://sssd.io/release-notes/sssd-2.10.2.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.2 Release Notes ## Highlights This release fixes a number of minor issues in the spec and services files, affecting mainly rpm-ostree based systems. ### Important fixes * If the ssh responder is not running, `sss_ssh_knownhosts` will not fail (but it will not return the keys). * A wrong path to a pid file in SSSD logrotate configuration snippet was corrected. * SSSD is now capable of handling multiple services associated with the same port. * `sssd_pam`, being a privileged binary, now clears the environment and doesn't allow configuration of the `PR_SET_DUMPABLE` flag as a precaution.

2 2

Shadows ldap
by Rodrigo Prieto 07 Feb '25

07 Feb '25

Hello, I am trying to configure warnings when a password is about to expire. I added the following in the sssd.conf file: ldap_pwd_policy = shadow pwd_expiration_warning = 7 I create a user with shadow enabled, but when logging in, no warning is displayed. In nslcd, the shadow attributes work fine, but in sssd, I can't get them to work. The ACLs are configured on the OpenLDAP server. Can someone guide me on what I might be doing wrong? Best regards.

2 2

keytabmux
by Troels Arvin 05 Feb '25

05 Feb '25

Hello, SSSD is a great way to maintain server's joined relation to an active directory, for example. In combination with msktutil, one may manage SPNs in an elegant way, forming the basis of single-signe-on into (e.g.) Postgres. However, there doesn't seem to be a good way to maintain derived keytabs from the system's main /etc/krb5.keytab. A use case I have is that I need the 'postgres/' keytab entries from a server's main krb5.keytab to be available for the server's Postgres database as /etc/postgresql-common/krb5.conf with special permissions. (Have I overlooked a good, existing solution for it?) So I've written a little utility to help with this: "keytabmux": https://gitlab.com/troelsarvin/keytabmux The tool may be started by systemd, and it will then keep running, keeping an eye on updates of /etc/krb5.keytab and write new derived keytabs, as needed. Maybe someone here will find it interesting. Let me know, if you have comments. -- Regards, Troels Arvin

3 4

order of entries in /etc/nsswitch.conf file....
by Spike White 05 Feb '25

05 Feb '25

All, In the comments in /etc/nsswitch.conf file, it says: # Notes: # # 'sssd' performs its own 'files'-based caching, so it should generally # come before 'files'. # and then later: # In order of likelihood of use to accelerate lookup. passwd: sss files systemd shadow: files group: sss files systemd However, we have consulted with Redhat Tech Support years ago when we first started implementing sssd and they advised us to put in local providers first, then remote. So we typically do this: passwd: files systemd sss ... group: files systemd sss Which is correct? Spike

3 3

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

sssd-users February 2025