sssd-users March 2022

sssd-users@lists.fedorahosted.org

11 participants
8 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

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

sssd 1.16.5 gives no results for other domains in the AD Forest
by Bill Conn 30 Mar '22

30 Mar '22

I'm working on a university's research cluster with nodes that all run CentOS7 and are joined to the school's Active Directory domain. Our domain is part of a statewide forest that contains every state university, and we have used this arrangement to grant cluster access to users from other Universities to our cluster. Recently, a user from outside my Universities domain have said they cannot log in anymore which caused me to look into this issue. I found that if I issue an id command for a user in a different domain in the forest, it gives me the error "no such user". I know that our setup used to work, and after looking into it and trying to replicate the old and new behavior I found out that CentOS7 machines with sssd 1.16.4 can get results from other domains in the forest, but machines with 1.16.5 cannot. Is there some setting that changed between these minor versions that would cause this? Is it possible this is not caused by sssd? I'm testing a node with CentOS 7.9.2009 which doesn't return other domains in the forest and a node with CentOS 7.7.1908 which does return results from other domains.

5 7

tgt-renewal and AD
by Francis Augusto Medeiros-Logeay 21 Mar '22

21 Mar '22

Hi, I currently have some machines that joined a domain on Active Directory, and we were dealing with the challenges of renewing tickets beyond the TGT "renew until" limit. I realised that after version 2.5.0 it is now possible to configure the `tgt_renewal=true`. I changed our configuration to use KCM to store the tickets. To test, I get one-day valid TGT's, and saw that the tickets do not get renewed by themselves, and I wonder if I missed a step when configuring AD and/or the clients. Here's a bit of my configuration: /etc/sssd/sssd.conf: ``` [domain/MYDOMAIN.COM] id_provider = ad auth_provider = ad access_provider = ad autofs_provider = ad chpass_provider = ad ldap_id_mapping = false ldap_user_principal = nosuchattribute # getent on users with more -- results in a lot of noise enumerate = false cache_credentials = true # Setup schema, rfc2307 is for OpenLDAP, rfc2307bis is A/D-close, and ad is A/D #ldap_schema = rfc2307 dns_discovery_domain = mydomain.com krb5_realm = MYDOMAIN.COM # how long including renewals may a ticket be valid for krb5_renewable_lifetime = 1d # time in seconds between checking if a ticket must be renewed krb5_renew_interval = 3600 # template used for placing kerberos tickets by default # krb5_ccname_template = FILE:%d/krb5cc_%U ad_gpo_map_interactive = +gdm-vmwcred #tgt_renewal = true [kcm] tgt_renewal = true tgt_renewal_inherit = MYDOMAIN.COM krb5_renew_interval = 60m debug_level = 10 socket_patch = /var/run/.heim_org.h5l.kcm-socket ``` And /etc/krb5.conf: ``` [libdefaults] default_ccache_name = KCM: kcm_socket = /var/run/.heim_org.h5l.kcm-socket ``` Anything else I should have done? I see that the tickets are stored on KCM, but I don't know why they aren't been renewed. Best, Francis

2 4

AVC alerts for process working in /var/lib/sss
by Brian J. Murrell 21 Mar '22

21 Mar '22

I am getting some SELinux AVC alerts for a given process in a given domain that seems to want to be able to read files in /var/lib/sss/. strace(1)ing the (unprivileged) process it seem to want to do the following: 4024612 openat(AT_FDCWD, "/var/lib/sss/mc/passwd", O_RDONLY|O_CLOEXEC) = -1 EACCES (Permission denied) and 4024612 connect(3, {sa_family=AF_UNIX, sun_path="/var/lib/sss/pipes/nss"}, 110) = -1 EACCES (Permission denied) in /var/lib/sss/ which as you can see SELinux is currently denying. But nothing about the running of the process seems to be a-miss despite these EPERMs Ultimately I am just trying to gauge the potential issues with following the least-privilege principle and setting these to ignore rather than allow. I.e. what might not be functioning correctly (even though they appear to be from all outward appearances) if these EPERMs continue instead of being allowed. Any ideas why this process would be wanting to access those paths and why and what the problem might be with denying it? Cheers, b.

3 7

is the sssd monitor even necessary?
by James Ralston 18 Mar '22

18 Mar '22

For recent versions of sssd, the monitor (the sssd.service) won’t even start unless at least one domain is configured. As sssd.conf(5) notes, all sssd services can be socket-activated when needed. There is no need to list any services in the "services" parameter in [sssd]. So, this leads to a question: if all configured services are configured via systemd to start via socket activation… then what is the monitor actually monitoring? In this configuration, what does it actually do? And is there any reason to even run the monitor at all? If the answer is, “the monitor performs necessary housekeeping functions so it should be running even if all services are socket-activated,” then shouldn’t it be the case that the monitor should run even if no domains are configured?

3 4

LDAP servers(not AD) and nested netgroups
by Don Drake 09 Mar '22

09 Mar '22

Our implementation of netgroups has objects that identify groups of servers, the use the nisnetgrouptriple attribute where users are assigned without domain or server information. i.e. 'nisnetgrouptriple=(,USERID,)', this is called an administrative group. Each server has its own netgroup object that uses the membernisnetgroup attribute to connect the server to an administrative netgroup. i.e. memberNisNetgroup=admngroup. this has worked for us for years. we cann find a way in SSSD to implement this. What am i missing?

2 1

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

sssd-users March 2022