sssd-users January 2025

sssd-users@lists.fedorahosted.org

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

4 3

[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

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

/var/lib/sss/pubconf/kpasswdinfo.$DOMAIN missing
by Brian J. Murrell 31 Jan '25

31 Jan '25

I am trying to start the krenew user service from the kstart package but it's failing due to krenew failing. Using strace to see what is going on with it I ends as such: openat(AT_FDCWD, "/var/lib/sss/pubconf/kdcinfo.EXAMPLE.COM", O_RDONLY) = 3 read(3, "[redacted]\n[fd31:aeb1:48"..., 4096) = 77 read(3, "", 4019) = 0 close(3) = 0 openat(AT_FDCWD, "/var/lib/sss/pubconf/kpasswdinfo.EXAMPLE.COM", O_RDONLY) = -1 ENOENT (No such file or directory) write(2, "krenew: ", 8krenew: ) = 8 write(2, "error renewing credentials: KDC "..., 62error renewing credentials: KDC can't fulfill requested option) = 62 write(2, "\n", 1 ) = 1 exit_group(1) = ? +++ exited with 1 +++ It seems to very clearly want that /var/lib/sss/pubconf/kpasswdinfo.EXAMPLE.COM file to exist, but it does not. Thoughts? Cheers, b.

1 0

Is there anything more effective than sss_cache -E?
by Johnnie W Adams 22 Jan '25

22 Jan '25

Hi, folks, I am trying to force reloads against LDAP and failing terribly with sss_cache -E. I keep getting the same long, long, long out-of-date information. Is there anything more thorough than sss_cache -E to clear it out? Thanks, John A -- John Adams Senior Linux/Middleware Administrator | Information Technology Services +1-501-916-3010 | jxadams(a)ualr.edu | http://ualr.edu/itservices *UA Little Rock* Reminder: IT Services will never ask for your password over the phone or in an email. Always be suspicious of requests for personal information that come via email, even from known contacts. For more information or to report suspicious email, visit IT Security <http://ualr.edu/itservices/security/>.

6 5

looking for the bitmap debug levels of ldap_library_debug_level....
by Spike White 17 Jan '25

17 Jan '25

Sssd experts, Our AD team is complaining that their AD controllers in our more densely-populated datacenters are getting overloaded. (up to 5K concurrent LDAP connections per AD DC). They find that 90% of the LDAP queries come from Linux servers -- which is surprising as Linux servers are < 50% of the resident population. We had previously found a coding bug in a vendor’s cron job that was generating a lot of unnecessary LDAP queries. That cybersecurity monitoring software was on every Linux server, so it led to a thundering herd problem when the cron job would kick off on every Linux server. That thundering herd problem has been remediated, but we suspect something similar occurring now. We’d like to see what LDAP queries are being executed by several random Linux servers, but we’ve had negative experiences leaving sssd debug_level = 9 on for several days. (Fills up the /var/log filesystem after a few days). I read in the sssd-ldap man page: ldap_library_debug_level (integer) Switches on libldap debugging with the given level. The libldap debug messages will be written independent of the general debug_level. OpenLDAP uses a bitmap to enable debugging for specific components, -1 will enable full debug output. Default: 0 (libldap debugging disabled) This seems to be exactly what we want! We want to see what LDAP queries are being executed without all the other massive logging that arises from debug_level 9. However, I cannot find these bitmap values of debug levels for the openldap library. The most I can find is bitmapped debug values for a stand-alone slapd daemon. OpenLDAP debug level - Knowledge Base / Community - Univention Help <https://help.univention.com/t/openldap-debug-level/19301> Where may I find the documentation of the bitmapped debug values that can be set via ldap_library_debug_level? Spike White

4 4

Issue with SSSD and Authentication Using AD Sites
by Rob Gibson 10 Jan '25

10 Jan '25

I am having some extreme difficulty with a setup for work, and I'm hoping that someone on the list can help... My employer has two sites, New York and London (details are being anonymized, but the details are consistent. At each physical location, we have servers which we wish to configure with AD logins against an existing on-prem AD domain, example.com. Each of these locations has two domain controllers which are properly categorized in Active Directory Sites and Services, and the Windows servers will log into their local DCs for their site. This can be confirmed as zero communication is allowed from one site's servers to the opposite's DCs. and you cannot telnet from one side to the other, although AD replication between the two sites is configured correctly. The Linux servers running sssd are Ubuntu 20.04 with sssd 2.2.3. The Windows DCs are Server 2019 running a supported domain functional level. Each Linux server has the IP addresses of their respective local DCs configured as their DNS resolvers. I was unable to use "realm discover" to discover a default domain, but I understand this is because the servers are not using DHCP, so they have no default DNS domain. However, when I "realm discover example.com", I get the expected output, including the "ad" provider statement. I am able to join the domain, and I can see the computer object getting created on the DCs, so it looks like the domain join is working correctly. I can also run "getent passwd <user>@example.com" and get a passwd entry exactly as I would expect it. The next test is to attempt to log in using the AD provider. I have tried using SSH, sudo, and directly running "login" from a 'root' shell. In all three cases, they will work once or twice and then fail over and over again, with the failures taking roughly 90 seconds to time out. Having found nothing obviously wrong but with timeout, I double-checked DNS to make sure all DNS names were available from the DCs, and they were. I also confirmed with our network team that no failures are seen when the login is happening, so it's not traversing and being blocked at the firewall. At nearly my wits end, I decided to do a local packet capture with Wireshark on the Linux server. To my surprise, sssd was trying to connect to the opposite datacenter. A server in New York was trying to connect to London for authentication, and this is not allowed by firewall rules. I see the first packet fail, and then 4 more with a doubling of each duration until it times out completely. I have spent the last couple of days trying various combinations of parameters with no luck. I have added the below settings to "sssd.conf" and restarted sssd: * ad_site = NewYork * ad_server = dc1.example.com, dc2.example.com * ad_enable_dns_sites = false * dns_discovery_domain = NewYork._sites.example.com For each of these, I have added each one to the section for example.com before restarting sssd. Each change has resulted in the same symptoms. What am I missing? What other things can I try to diagnose or resolve the issue? Thanks in advance, Rob

2 1

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

sssd-users January 2025