sssd-users July 2022

sssd-users@lists.fedorahosted.org

7 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

Re: [Freeipa-users] who killed SSSD - ?
by Rob Crittenden 21 Jul '22

21 Jul '22

cc'ing the sssd users list. rob lejeczek via FreeIPA-users wrote: > Hi guys. > > One of the masters started recently to find SSSD dead and says the > killer is the WATCHDOG - but I'm not sure about that. > From sssd.log: > ... > ********************** BACKTRACE DUMP ENDS HERE > ********************************* > > (2022-07-21 7:11:01): [sssd] [svc_child_info] (0x0020): Child [991] > ('pac':'pac') was terminated by own WATCHDOG > * ... skipping repetitive backtrace ... > (2022-07-21 7:11:14): [sssd] [svc_child_info] (0x0020): Child [984] > ('abba.xx.priv.yy':'%BE_abba.xx.priv.yy') was terminated by own WATCHDOG > * ... skipping repetitive backtrace ... > (2022-07-21 7:11:14): [sssd] [svc_child_info] (0x0040): Child [9744] > ('nss':'nss') exited with code [3] > ********************** PREVIOUS MESSAGE WAS TRIGGERED BY THE FOLLOWING > BACKTRACE: > * (2022-07-21 7:11:14): [sssd] [sbus_dispatch_reconnect] (0x0400): > Connection lost. Terminating active requests. > * (2022-07-21 7:11:14): [sssd] [sbus_dispatch_reconnect] (0x4000): > Remote client terminated the connection. Releasing data... > * (2022-07-21 7:11:14): [sssd] [sbus_connection_free] (0x4000): > Connection 0x5576314d9180 will be freed during next loop! > * (2022-07-21 7:11:14): [sssd] [mt_svc_restart] (0x0400): > Scheduling service abba.xx.priv.yy for restart 1 > * (2022-07-21 7:11:14): [sssd] [get_provider_config] (0x0100): > Formed command '/usr/libexec/sssd/sssd_be --domain abba.xx.priv.yy --uid > 0 --gid 0 --logger=files' for provider '%BE_abba.xx.priv.yy' > * (2022-07-21 7:11:14): [sssd] [start_service] (0x0100): Queueing > service abba.xx.priv.yy for startup > * (2022-07-21 7:11:14): [sssd] [mt_svc_exit_handler] (0x1000): > SIGCHLD handler of service nss called > * (2022-07-21 7:11:14): [sssd] [svc_child_info] (0x0040): Child > [9744] ('nss':'nss') exited with code [3] > ********************** BACKTRACE DUMP ENDS HERE > ********************************* > > (2022-07-21 7:11:14): [sssd] [svc_child_info] (0x0040): Child [9758] > ('pac':'pac') exited with code [3] > * ... skipping repetitive backtrace ... > (2022-07-21 7:11:16): [sssd] [svc_child_info] (0x0040): Child [9876] > ('nss':'nss') exited with code [3] > * ... skipping repetitive backtrace ... > (2022-07-21 7:11:16): [sssd] [svc_child_info] (0x0040): Child [9877] > ('pac':'pac') exited with code [3] > * ... skipping repetitive backtrace ... > (2022-07-21 7:11:20): [sssd] [svc_child_info] (0x0040): Child [9903] > ('nss':'nss') exited with code [3] > * ... skipping repetitive backtrace ... > (2022-07-21 7:11:20): [sssd] [monitor_restart_service] (0x0010): > Process [nss], definitely stopped! > (2022-07-21 7:11:20): [sssd] [monitor_quit] (0x3f7c0): Returned with: 1 > (2022-07-21 7:11:20): [sssd] [monitor_quit] (0x3f7c0): Terminating > [pac][9904] > (2022-07-21 7:11:21): [sssd] [monitor_quit] (0x3f7c0): Child [pac] > terminated with a signal > (2022-07-21 7:11:21): [sssd] [monitor_quit] (0x3f7c0): Terminating > [abba.xx.priv.yy][9875] > (2022-07-21 7:11:21): [sssd] [monitor_quit] (0x3f7c0): Child > [abba.xx.priv.yy] exited gracefully > (2022-07-21 7:11:21): [sssd] [monitor_quit] (0x3f7c0): Terminating > [sudo][990] > (2022-07-21 7:11:21): [sssd] [monitor_quit] (0x3f7c0): Child [sudo] > exited gracefully > (2022-07-21 7:11:21): [sssd] [monitor_quit] (0x3f7c0): Terminating > [ssh][989] > (2022-07-21 7:11:21): [sssd] [monitor_quit] (0x3f7c0): Child [ssh] > exited gracefully > (2022-07-21 7:11:21): [sssd] [monitor_quit] (0x3f7c0): Terminating > [ifp][988] > (2022-07-21 7:11:21): [sssd] [monitor_quit] (0x3f7c0): Child [ifp] > exited gracefully > (2022-07-21 7:11:21): [sssd] [monitor_quit] (0x3f7c0): Terminating > [pam][987] > (2022-07-21 7:11:21): [sssd] [monitor_quit] (0x3f7c0): Child [pam] > exited gracefully > (2022-07-21 7:11:21): [sssd] [monitor_quit] (0x3f7c0): Terminating > [implicit_files][983] > (2022-07-21 7:11:21): [sssd] [monitor_quit] (0x3f7c0): Child > [implicit_files] exited gracefully > > This "death" happens randomly, well, to me at least. Can be just after > reboot or several hours of uptime. > There is more in log files from /var/log/sssd but before I clutter > emails with more logs snippets I was hoping some expert can share some > thoughts. > > many thanks, L. > _______________________________________________ > FreeIPA-users mailing list -- freeipa-users(a)lists.fedorahosted.org > To unsubscribe send an email to freeipa-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/freeipa-users@lists.fedorahost… > > Do not reply to spam on the list, report it: > https://pagure.io/fedora-infrastructure

2 1

Re: Session Recording with sssd is not working
by Stephen Gallagher 15 Jul '22

15 Jul '22

A better place for this question is the sssd-users list (which I've just CCed). On Fri, Jul 15, 2022 at 7:24 AM Sergio Belkin <sebelk(a)gmail.com> wrote: > > Hi, I've configured sssd to use session recording along with tlog but it's not working. > > I don't use any domain for authentication, all users are local > > This my configuration files: > > **/etc/sssd/sssd.conf** > ``` > [sssd] > domains = files > services = pam, sudo, nss, ssh > > [domain/files] > id_provider = files > ``` > > Is the above configuration correct? > > And **/etc/sssd/conf.d/sssd-session-recording.conf** : > > ``` > [session_recording] > scope=all > exclude_users= > exclude_groups= > ``` > I don't find ny errors: > > ``` > [root@munster ~]# sssctl config-check > Issues identified by validators: 0 > > Messages generated during configuration merging: 0 > > Used configuration snippet files: 1 > /etc/sssd/conf.d/sssd-session-recording.conf > [root@munster ~]# systemctl status sssd > ● sssd.service - System Security Services Daemon > Loaded: loaded (/usr/lib/systemd/system/sssd.service; enabled; vendor preset: enabled) > Active: active (running) since Wed 2022-07-13 23:40:25 -03; 9h ago > Main PID: 971 (sssd) > Tasks: 6 (limit: 38124) > Memory: 55.9M > CPU: 2.409s > CGroup: /system.slice/sssd.service > ├─ 971 /usr/sbin/sssd -i --logger=files > ├─ 1030 /usr/libexec/sssd/sssd_be --domain files --uid 0 --gid 0 --logger=files > ├─ 1035 /usr/libexec/sssd/sssd_pam --uid 0 --gid 0 --logger=files > ├─ 1036 /usr/libexec/sssd/sssd_sudo --uid 0 --gid 0 --logger=files > ├─ 1037 /usr/libexec/sssd/sssd_nss --uid 0 --gid 0 --logger=files > └─ 1038 /usr/libexec/sssd/sssd_ssh --uid 0 --gid 0 --logger=files > > jul 13 23:40:24 munster.belkin.home systemd[1]: Starting sssd.service - System Security Services Daemon... > jul 13 23:40:24 munster.belkin.home sssd[971]: Starting up > jul 13 23:40:24 munster.belkin.home sssd_be[1030]: Starting up > jul 13 23:40:24 munster.belkin.home sssd_ssh[1038]: Starting up > jul 13 23:40:24 munster.belkin.home sssd_pam[1035]: Starting up > jul 13 23:40:24 munster.belkin.home sssd_sudo[1036]: Starting up > jul 13 23:40:24 munster.belkin.home sssd_nss[1037]: Starting up > jul 13 23:40:25 munster.belkin.home systemd[1]: Started sssd.service - System Security Services Daemon. > jul 13 23:40:41 munster.belkin.home sssd_nss[1037]: Enumeration requested but not enabled > ``` > > But recording sessions does not work. > > Relevant packages: > > ``` > sssd-2.7.3-1.fc36.x86_64 > tlog-12-2.fc36.x86_64 > fedora-release-common-36-17.noarch > ``` > > Please could you help me to figure out why session recording is not working? > > Thanks in advance! > > -- > -- > Sergio Belkin > LPIC-2 Certified - http://www.lpi.org > _______________________________________________ > devel mailing list -- devel(a)lists.fedoraproject.org > To unsubscribe send an email to devel-leave(a)lists.fedoraproject.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.fedoraproject.org/archives/list/devel@lists.fedoraproject.org > Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure

3 2

Re: Can SSSD be set up to disallow login if provider not available?
by Alexey Tikhonov 07 Jul '22

07 Jul '22

Hi, On Thu, Jul 7, 2022 at 12:14 PM Fisher, Philip <phil.fisher(a)dxc.com> wrote: > Hi SSSD experts > > I have tried examining various documentation and man pages but I am unable > to determine the answer. Specifically, for security reasons, we require > user on our Linux servers to login via AD credentials only (unless they are > a specific local user). In particular, if the provider is offline/not > available (in this case an AD server/servers) then login should fail. > Sounds like `cache_credentials = false`? (see `man sssd.conf`) > > I thought it would be possible by setting various "cache" parameters but > the documentation suggests that zero (0) is not a useful value. > > So, can this be done? And if so, how? And if I missed some simple thing > in the documentation a reply pointing me to said documentation would be > acceptable :-). > > Thanks. > Phil > > -- > Phil J Fisher > UNIX Technology Consultant > > > > DXC Technology Company -- This message is transmitted to you by or on > behalf of DXC Technology Company or one of its affiliates. It is intended > exclusively for the addressee. The substance of this message, along with > any attachments, may contain proprietary, confidential or privileged > information or information that is otherwise legally exempt from > disclosure. Any unauthorized review, use, disclosure or distribution is > prohibited. If you are not the intended recipient of this message, you are > not authorized to read, print, retain, copy or disseminate any part of this > message. If you have received this message in error, please destroy and > delete all copies and notify the sender by return e-mail. Regardless of > content, this e-mail shall not operate to bind DXC Technology Company or > any of its affiliates to any order or other contract unless pursuant to > explicit written agreement or government initiative expressly permitting > the use of e-mail for such purpose. > _______________________________________________ > 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 >

3 2

Can SSSD be set up to disallow login if provider not available?
by Fisher, Philip 07 Jul '22

07 Jul '22

Hi SSSD experts I have tried examining various documentation and man pages but I am unable to determine the answer. Specifically, for security reasons, we require user on our Linux servers to login via AD credentials only (unless they are a specific local user). In particular, if the provider is offline/not available (in this case an AD server/servers) then login should fail. I thought it would be possible by setting various "cache" parameters but the documentation suggests that zero (0) is not a useful value. So, can this be done? And if so, how? And if I missed some simple thing in the documentation a reply pointing me to said documentation would be acceptable :-). Thanks. Phil -- Phil J Fisher UNIX Technology Consultant DXC Technology Company -- This message is transmitted to you by or on behalf of DXC Technology Company or one of its affiliates. It is intended exclusively for the addressee. The substance of this message, along with any attachments, may contain proprietary, confidential or privileged information or information that is otherwise legally exempt from disclosure. Any unauthorized review, use, disclosure or distribution is prohibited. If you are not the intended recipient of this message, you are not authorized to read, print, retain, copy or disseminate any part of this message. If you have received this message in error, please destroy and delete all copies and notify the sender by return e-mail. Regardless of content, this e-mail shall not operate to bind DXC Technology Company or any of its affiliates to any order or other contract unless pursuant to explicit written agreement or government initiative expressly permitting the use of e-mail for such purpose.

1 0

[SSSD] Announcing SSSD 2.7.3
by Pavel Březina 04 Jul '22

04 Jul '22

# SSSD 2.7.3 The SSSD team is announcing the release of version 2.7.2 of the System Security Services Daemon. The tarball can be downloaded from: https://github.com/SSSD/sssd/releases/tag/2.7.3 See the full release notes at: https://sssd.io/release-notes/sssd-2.7.3.html *This is a hot fix release* which fixes a serious regression that prevented IPA users to log in. This fix is already included in Fedora packages. ## 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 ## Highlights ### General information * All SSSD client libraries (nss, pam, etc) won't serialize requests anymore by default, i.e. requests from multiple threads can be executed in parallel. Old behavior (serialization) can be enabled by setting environment variable "SSS_LOCKFREE" to "NO".

1 0

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

sssd-users July 2022