sssd-users July 2025

sssd-users@lists.fedorahosted.org

9 participants
5 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] Announcing SSSD 2.11.1
by Pavel Březina 31 Jul '25

31 Jul '25

# SSSD 2.11.1 The SSSD team is announcing the release of version 2.11.1 of the System Security Services Daemon. The tarball can be downloaded from: https://github.com/SSSD/sssd/releases/tag/2.11.1 See the full release notes at: https://sssd.io/release-notes/sssd-2.11.1.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.11.1 Release Notes This is a minor bugfix update. ## Fixed Issues * [#7921](https://github.com/SSSD/sssd/issues/7921) - AD user in external group is not cleared when expiring the cache * [#7968](https://github.com/SSSD/sssd/issues/7968) - cache_credentials = true not working in sssd master * [#8005](https://github.com/SSSD/sssd/issues/8005) - Socket activation doesn't work for 'sssd_pam'

1 0

SSSD with rfc2307bis causes thousands of concurrent LDAP queries, triggering OpenLDAP flow control
by Christopher Paul 24 Jul '25

24 Jul '25

Hello sssd-users, I'm experiencing severe performance degradation with SSSD when using ldap_schema=rfc2307bis. User lookups with "id" can take several seconds, and I believe that I have identified the root cause. ## Symptoms: - SSSD logs: "LDAP operation ... seems slow, took more than 80% of timeout" - OpenLDAP logs: "deferring operation: pending operations" - Simple "id username" commands taking 5-10+ seconds (when not cached) ## Root Cause: When looking up a single user, SSSD appears to be sending individual LDAP queries for EVERY member of EVERY group the user belongs to. This results in thousands of near-simultaneous asynchronous LDAP searches. OpenLDAP's conn_max_pending/conn_max_pending_auth parameters are correctly throttling these requests, causing the perceived slowness. ## Environment: - SSSD version: 2.9.6 - OpenLDAP version: 2.5.20 ## Questions: 1. Why does SSSD need to resolve all group members when looking up a single user? This should be unnecessary to id a single user. 2. Can SSSD be configured to return just the group names/GIDs for a user lookup without also fetching full details of every member in those groups? 3. Could SSSD batch these queries or use more efficient LDAP operations? I've attached my sssd.conf. The key setting is ldap_schema=rfc2307bis. This behavior effectively makes rfc2307bis unusable in environments with large groups. Any guidance would be appreciated. Many thanks, -- Chris Paul | Rex Consulting |https://www.rexconsulting.net

6 16

multi prompt changed to single prompt
by seojeong kim 15 Jul '25

15 Jul '25

2FA user, multi prompt changes to single prompt at the 4th try all the time. Is this flow intended by FreIPA + SSSD ? or can it be configurable at client side by changing something in /etc/sssd/sssd,conf ? I expect first/second factor for prompt at the 4th attempt as well. (seojeong)(a)xx.yyy.xx.yyy) First Factor: (seojeong)(a)xx.yyy.xx.yyy) Second Factor: (seojeong)(a)xx.yyy.xx.yyy) First Factor: (seojeong)(a)xx.yyy.xx.yyy) Second Factor: (seojeong)(a)xx.yyy.xx.yyy) First Factor: (seojeong)(a)xx.yyy.xx.yyy) Second Factor: seojeong(a)xx.yyy.xx.yyy's password:

2 1

Computer Accounts in simple_allow_groups
by Yehuda Katz 07 Jul '25

07 Jul '25

We are using SSSD to connect RHEL systems to Microsoft Active Directory. Access is granted to groups using the `simple_allow_groups` option and those groups are also used to allow sudo access. Some of these groups have members that are the computer accounts for other computers in the domain. Should that be considered a security risk? For example, could someone with root access on one system recover the computer account information and use that computer account to log in to a different system?

3 2

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

sssd-users July 2025