sssd-users August 2021

sssd-users@lists.fedorahosted.org

14 participants
14 discussions

Starting SSSD without root
by Tero Saarni 20 Jan '26

20 Jan '26

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 21

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 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

Trouble-shooting sssd’s ‘Automatic Kerberos Host Keytab Renewal’ with AD back-end….
by Spike White 08 Oct '21

08 Oct '21

Sssd experts, *Short summary: * How can we troubleshoot sssd’s ‘Automatic Kerberos Host Keytab Renewal’ process? We have ~0.4% of our Linux servers dropping off the AD domain monthly. *Longer explanation:* Over the past two years, we have on-boarded sssd as our Linux AD integration component. Largely displacing a former commercial product that did the same. We have about ~20K Linux servers that are sssd-enabled. A mix of RHEL6, RHEL7, RHEL8, Oracle Linux 6, 7 and 8. We have ~7K Linux servers still on the old commercial product. (For certain edge-case scenarios, such as DMZs, the commercial product works better.) Our AD forest is a single AD forest, with 4 regional child domains. All with transitive trust. Sssd auto-discovers parent domain and all 4 child domains, no problem – whenever it’s adcli joined to its regional local domain. Why are I writing this? Because we are researching an ongoing problem reported by L1 server ops. About 70 – 80 sssd-enabled Linux servers / month drop off the domain. Out of our current sssd-enabled population of ~20K server, that’s not horrible. But still it should be better. (Our former commercial product did better.) It’s not limited to one particular OS, OS version, build location or region. We have surveyed; it seems to occur randomly among all OS versions, regions and locations. To be clear, it’s extremely likely that this behavior arising from some subtle misconfiguration on our part – not from any sssd or adcli or Kerberos bug. We have a couple of configuration improvements we’re pursuing. (Kerberos max ticket lifetime mismatch between AD and /etc/krb5.conf file for instance.) We are taking sssd’s default settings for ad_maximum_machine_account_password_age and ad_machine_account_password_renewal_opts. So after 30 days, sssd will attempt daily to renew the host Kerberos keytab file. It should re-attempt daily if not renewed. By company policy, our AD disables any machine accounts that have not renewed their credentials in 40 days. So when we find servers that have dropped off the domain, it’s because they have not renewed their AD machine accounts in 40 days. We have SR’s open with our OS vendors (Redhat and Oracle respectively) for months now. To no great help. (They gave a few suggestions, but none panned out.) We thought we were hitting this bug: https://github.com/SSSD/sssd/issues/4762 But packet captures proved that adcli update is using TCP on RHEL7/8. Thus, this might be a potential problem, but only on RHEL6. (BTW ‘udp_preference_limit = 0’ doesn’t force use of TCP for the kpasswd invocation in RHEL6 – it still uses UDP. Thus, the recommended work-around for this bug doesn’t work.) So that isn’t our underlying problem. We’re at a loss now – as you can see, we’re grasping at straws. How can we troubleshoot sssd’s ‘automatic Kerberos Host keytab renewal’ process? Whenever we inspect a particular server it works. We can’t run all sssd clients at debug level 9; it fills up /var/log filesystem after a few days of that. We’re interested in troubleshooting that one particular sssd process on all clients; not all parts of sssd. Other than a steep learning curve (on our part), obscure situations (like DMZ auto-discovery of AD controllers) and exotic scenarios (like above), we’re quite happy with our 2 yr journey of direct AD integration with sssd. Obviously, the troubleshooting tools on RHEL6 are very minimal. But certainly, overall the quality of sssd on RHEL7/8 is excellent. AD integration has innumerable devils in the details; I’m amazed that sssd performs as well as it does against our multi-domain forest. Spike PS the problem with sssd auto-discovery of AD controllers in DMZs has been fixed in a recent sssd release. The better discovery algorithm was implemented – same one used by Windows clients and commercial products. It’s just that recent sssd version is not on RHEL7 or 8.

8 14

Re: Trouble-shooting sssd’s ‘Automatic Kerberos Host Keytab Renewal’ with AD back-end….
by Patrick Goetz 08 Sep '21

08 Sep '21

So i think you just want: kinit -R -k $HOSTNAME$ On 8/30/21 11:28 AM, Mote, Todd wrote: > I wrote that from memory. What's needed is the shortname and a $, but thinking more about it now, that's needed at the end of the shortname not the beginning. > > -----Original Message----- > From: Patrick Goetz <pgoetz(a)math.utexas.edu> > Sent: Monday, August 30, 2021 11:25 AM > To: sssd-users(a)lists.fedorahosted.org > Subject: [SSSD-users]Re: Trouble-shooting sssd’s ‘Automatic Kerberos Host Keytab Renewal’ with AD back-end…. > > Todd, > > On 8/27/21 9:41 AM, Mote, Todd wrote: >> We ultimately decided to deploy a cron job with the install that ran periodically (less than the renewal period) to keep the keytab fresh (kinit -R -k $($hostname -s)). We haven't had computers falling off the domain since we implemented that. >> > > Are you sure about this syntax? Adding a -s flag in $( ) containing a bash variable doesn't do anything. > > _______________________________________________ > sssd-users mailing list -- sssd-users(a)lists.fedorahosted.org To unsubscribe send an email to sssd-users-leave(a)lists.fedorahosted.org > Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ > List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines > List Archives: https://lists.fedorahosted.org/archives/list/sssd-users@lists.fedorahosted.… > Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure >>> This message is from an external sender. Learn more about why this << >>> matters at https://links.utexas.edu/rtyclf. << > _______________________________________________ > sssd-users mailing list -- sssd-users(a)lists.fedorahosted.org > To unsubscribe send an email to sssd-users-leave(a)lists.fedorahosted.org > Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ > List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines > List Archives: https://lists.fedorahosted.org/archives/list/sssd-users@lists.fedorahosted.… > Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure >>> This message is from an external sender. Learn more about why this << >>> matters at https://links.utexas.edu/rtyclf. <<

5 16

Re: Trouble-shooting sssd’s ‘Automatic Kerberos Host Keytab Renewal’ with AD back-end….
by Patrick Goetz 30 Aug '21

30 Aug '21

Todd, On 8/27/21 9:41 AM, Mote, Todd wrote: > We ultimately decided to deploy a cron job with the install that ran periodically (less than the renewal period) to keep the keytab fresh (kinit -R -k $($hostname -s)). We haven't had computers falling off the domain since we implemented that. > Are you sure about this syntax? Adding a -s flag in $( ) containing a bash variable doesn't do anything.

2 1

Re: Trouble-shooting sssd’s ‘Automatic Kerberos Host Keytab Renewal’ with AD back-end….
by Spike White 30 Aug '21

30 Aug '21

Todd, I confess I don't completely understand your solution. I get that configuration management tools use the passwordlastset attribute with a value that's greater than XX days to cull objects. My Windows server engineering counterparts have a scheduled job that deletes all machine accounts from their Windows OU where passwordlastset attribute > 60 days and server not pingable. (Actually, it moves the machine account to an archival OU and then deletes it from archival OU if a Windows SE hasn't moved it back in 90 days). Also, by policy our AD forest locks all machine accounts where passwordlastset attribute > 40 days. So I get that part. But you said: We ultimately decided to deploy a cron job with the install that ran periodically (less than the renewal period) to keep the keytab fresh (kinit -R -k $($hostname -s)). I get what this is doing. Actually, sssd typically uses the service principal 'host/<fqdn>@<DOMAIN>'. For example: host/ austgcore17.us.example.com(a)AMER.EXAMPLE.COM. So I would do this: kinit -R -k host/austgcore17.us.example.com(a)AMER.EXAMPLE.COM or (even simpler): kinit -R -k since kinit appears to assume this host/ service principal if you don't specify it. What you're doing is refresh the host's Kerberos TGT ticket. Actually, you're doing it for your cron job only -- sssd seems to store its host credential in cache FILE:/var/lib/sss/db/ccache_AMER.EXAMPLE.COM_VgdSdK or some such. So you're renewing your host's TGT ticket. But by default, the max lifetime for a TGT ticket is 24hrs (our AD DCs allow max 10 hrs -- that's pretty std recommendation for AD). And your max renewal lifetime is 7 days by default. After that, you'd have to get a fresh kerberos TGT ticket. So are you completely disabling sssd's automatic machine account password renewal (by setting ad_maximum_machine_account_password_age = 0)? And then you're never changing your machine account passwords ever; your cron job is just refreshing your host's TGT ticket every 9 hrs or so for 7 days? I'm not fully following the explanation of your approach. Also, machine account passwords are related to kerberos keytab entries. For a machine account, a Kerberos keytab entry is the machine account password (encrypted) with other relevant information, such as timestamp, KVNO, service principal name and encryption type. The machine account password stored in AD (with a particular msDS-KeyVersionNumber) must change the corresponding /etc/krb5.keytab entry (with the same KVNO number). That's how this client authenticates to Kerberos (AD) that it's who it claims to be. Spike On Fri, Aug 27, 2021 at 9:41 AM Mote, Todd <moter(a)austin.utexas.edu> wrote: > As a follow on to that, to keep themselves clear of debris, configuration > management tools use the passwordlastset attribute with a value that's > greater than XX days to cull objects as well. We had similar issues when > we first implemented SSSD several years ago too. We ultimately decided to > deploy a cron job with the install that ran periodically (less than the > renewal period) to keep the keytab fresh (kinit -R -k $($hostname -s)). We > haven't had computers falling off the domain since we implemented that. > > Isn’t the issue that the keytab expires and is not renewed in time, then > the computer can't change its password because the domain can't verify the > keytab? Also, aren't machine passwords different from Kerberos keytabs? > Related, because a machine can't change it's password if it can't prove who > it is via Kerberos and the keytab. I just want to make sure those aren't > being conflated. Similarly, a computer can't update it's DNS record in the > domain with out Kerberos, so similarly, if the keytab is not kept fresh, > little domain object maintenance can happen, because Kerberos is stale. > > Computer account password changes are always initiated by clients, not the > domain, even on windows. > > Todd > > -----Original Message----- > From: James Ralston <ralston(a)pobox.com> > Sent: Thursday, August 26, 2021 10:31 PM > To: End-user discussions about the System Security Services Daemon < > sssd-users(a)lists.fedorahosted.org> > Subject: [SSSD-users]Re: Trouble-shooting sssd’s ‘Automatic Kerberos Host > Keytab Renewal’ with AD back-end…. > > On Thu, Aug 26, 2021 at 8:11 PM Christian, Mark <mark.christian(a)intel.com> > wrote: > > [W]hy bother with updating the machine account password? > > For sites that have a lot of machine churn, where machine accounts aren't > reliably purged from AD when the underlying host is decommissioned, > disabling and/or purging machine accounts with old passwords is essentially > a garbage collection activity, to prevent stale machine accounts from > continuing to exist in AD in perpetuity. > > Also, some sites must conform with security guidelines that *require* > frequent changes of machine account passwords: > > > https://www.stigviewer.com/stig/microsoft_windows_server_2016/2021-03-05/fi… > > Granted, that STIG rule applies to Windows machine accounts, not Linux > machine accounts, but disabling any machine account in AD whose password is > older than 30 days is one way to detect any Windows clients that are > nonconforming with the STIG. And in many cases it's easier to apply that > rule globally than on a per-OU basis (to exempt non-Windows machine > accounts). > _______________________________________________ > sssd-users mailing list -- sssd-users(a)lists.fedorahosted.org To > unsubscribe send an email to sssd-users-leave(a)lists.fedorahosted.org > Fedora Code of Conduct: > https://docs.fedoraproject.org/en-US/project/code-of-conduct/ > List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines > List Archives: > https://lists.fedorahosted.org/archives/list/sssd-users@lists.fedorahosted.… > Do not reply to spam on the list, report it: > https://pagure.io/fedora-infrastructure > >> This message is from an external sender. Learn more about why this << > >> matters at https://links.utexas.edu/rtyclf. << > _______________________________________________ > sssd-users mailing list -- sssd-users(a)lists.fedorahosted.org > To unsubscribe send an email to sssd-users-leave(a)lists.fedorahosted.org > Fedora Code of Conduct: > https://docs.fedoraproject.org/en-US/project/code-of-conduct/ > List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines > List Archives: > https://lists.fedorahosted.org/archives/list/sssd-users@lists.fedorahosted.… > Do not reply to spam on the list, report it: > https://pagure.io/fedora-infrastructure >

2 1

ldap client configuration in sssd.conf to query views
by iulian roman 20 Aug '21

20 Aug '21

Hello, I try to configure some old sssd clients to connect to IPA server which does use AD and views. Is there any documentation which points which ldap_* related variables needs to be configured in sssd,conf in order to be able to query the views in IPA server ? Currently I can run ldapsearch -Y GSSAPI -h ipaserver.ipa.example.com -b "cn=legacy_servers,cn=views,cn=accounts,dc=example,dc=com" and it does display all the data, but I want that to be configured automatically at sssd level.

2 2

One slight enhancement to sssctl user-checks...
by Spike White 18 Aug '21

18 Aug '21

All, sssctl user-check is very good. In particular, when you want to see if a particular user is conferred access, you look for the: pam_acct_mgmt: Success or the: pam_acct_mgmt: Permission denied lines. But often, users are members of multiple various groups. It's often difficult to track down which of the particular groups or user entries are actually conferring the access to the user. It would be nice to output on success, which user or group is conferring the login access. I'm not saying it needs to be exhaustive. I.e., no need to parse every group to see which groups. But sssctl at that point in time has determined (based on some rule) that login access is permitted. Just output whatever that matching rule is. If you wanted this additional output only in a verbose mode, that'd be fine. I suppose I could probably turn on debug level on sssd, restart it and grub through all the sssd log files to find which user or group conferred access. But that'd be painful. Usually I construct a list of all AD groups this individual is a member of (often it's 15-20). Then which of these groups are UNIX-enabled in AD. Then of those, which are permitted. Spike

1 0

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

sssd-users August 2021