sssd-users April 2026

sssd-users@lists.fedorahosted.org

8 participants
8 discussions

kscreenlocker fails on the first attempt to unlock with pam_sss error
by Marek Greško 04 May '26

04 May '26

Hello, some time ago the users started to observe strange issue. When they try to unlock the kscreenlocker after switching consoles by Atl+Fx key even the type correct password, it fails and this is found in the logs: kscreenlocker_greet[109438]: pam_sss(kde:auth): received for user username: 4 (Chyba systému), which means system error. I cannot see any other log with more details on this. The second attempt works. It is hard to say when the issue started, because longer time we were thinking users just type wrong password. We are going to elaborate more on this. We are unsure whether the console switching is the necessary condition or only waiting for longer time is sufficient. Apparently when I try to unlock after several minutes, it works on a first attempt. Thanks Marek

1 1

[SSSD] Watch Github for next releases
by Pavel Březina 29 Apr '26

29 Apr '26

Please note that the sssd-2.13.0 was the last release that was announced on sssd-devel, sssd-users and freeipa-users mailing lists. Please, setup GitHub notifications [1] on SSSD/sssd repository [2] to get notified about the next releases. Thank you, Pavel from SSSD team. [1] https://docs.github.com/en/subscriptions-and-notifications/get-started/conf… [2] https://github.com/SSSD/sssd

2 1

[SSSD] Announcing SSSD 2.13.0
by Pavel Březina 29 Apr '26

29 Apr '26

# SSSD 2.13.0 The SSSD team is announcing the release of version 2.13.0 of the System Security Services Daemon. The tarball can be downloaded from: https://github.com/SSSD/sssd/releases/tag/2.13.0 See the full release notes at: https://sssd.io/release-notes/sssd-2.13.0.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.13.0 Release Notes ## Highlights ### General information - Security fix for CVE-2026-6245: out-of-bounds read in PAM passkey responder - During the processing of the `pam_sss_gss` request SSSD will read the SID from the PAC of the Kerberos ticket and might add authentication indicators based on the value of the new option `pam_gssapi_indicators_apply`. The primary use case is to handle SIDs added by Active Directory's Authentication Mechanism Assurance (AMA). - Active Directory's Foreign Security Principals (FSP) are now properly detected and ignored when reading nested group members. The `ldap_ignore_unreadable_references` option is only needed to ignore member objects which are really not accessible. - A number of cache performance optimizations for large deployments. ### New features - Tokens acquired from the IdP are now stored in the domain cache, and are automatically refreshed if the new option `idp_auto_refresh` is enabled. - `idp_type` option allows `entra_idp` url to be specified if user is using a different Microsoft Entra endpoint. - KDE Plasma Login Manager support. ### Configuration changes - New option `avoid_by_id_lookups` to tell the SSSD responders to use a lookup by name instead of by id where possible - New options to customize the OAuth2 prompting behavior: `interactive` and `interactive_prompt`. ### Packaging changes - New `./configure` option `--enable-sensitive-logs` to enable logging of sensitive data (like, for example, IdP tokens). Recommended for debug builds only.

1 0

Help with KCM cache
by Marek Greško 27 Apr '26

27 Apr '26

Hello, had anybody successfully configured kcm cache in sssd? If yes, what is the correct way? I found some partial resources which did not lead me to a working solution. I use Fedora 43. I have configured: /etc/krb5.conf.d/kcm_default_ccache [libdefaults] default_ccache_name = KCM: This configuration is still using files. I configured /etc/sssd/sssd.conf: krb5_ccname_template = KCM:%U and commented out: #krb5_ccachedir = /tmp #krb5_ccname_template = FILE:%d/krb5cc_%U_XXXXXX But files still have been used. I found out the variable KRB5CCNAME still contains FILE:/tmp/krb5cc_..... with the original template. I found in some forums workaround by setting the filter in /etc/sssd/sssd.conf [pam] pam_response_filter = ENV:KRB5CCNAME This started partially working. When I logged in with user with UID 1000000 and run klist, I have seen all the tickets in KCM:1000000, but the file in /tmp still have been created, which looked weird for me. Then I used AI to help me with this, since I was not able to find any more resources. She told me to alter /etc/sssd/sssd.conf: [sssd] services = nss, pam change to: [sssd] services = nss, pam, kcm This lead to failure to start the sssd, so I reverted the last change and rebooted and I was thinking I have a partially working setup and planned to leave it like this for a while. But unfortunately after the reboot user with UID 1000001 came and logged in. Nothing was working for him. When I asked him to run klist, tickets were not there and there was some error message about KCM:1000001. I do not remember for sure, but I think it was KCM:1000001 not found. I had to revert all the changes immediately to the original state with using files. Can anybody help me to firstly analyze what happened and why it was working for user 1000000 and not for user 1000001 (I do not know whether the test the AI told me to do started the problem for all the users) and secondly how to configure it right way to use KCM instead of files without the workaround with the pam filter for KRB5CCNAME environment variable? Thanks Marek

3 11

Memory leak in sssd_be
by Orion Poplawski 24 Apr '26

24 Apr '26

I'm seeing an issue on (only one machine so far) EL9 with sssd_be going crazy and growing massively in size, e.g.: PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND 198203 root 20 0 137.4g 137.0g 22224 R 74.5 54.6 95:19.55 sssd_be the log is spewing (~80/sec): (2026-04-21 16:11:57): [be[nwra.com]] [sysdb_set_entry_attr] (0x0200): [RID#531993] Entry [name=orion_hbac(a)nwra.com,cn=groups,cn=nwra.com,cn=sysdb] has set [ts_cache] attrs. (2026-04-21 16:11:57): [be[nwra.com]] [sysdb_set_entry_attr] (0x0200): [RID#531994] Entry [name=orion_hbac(a)nwra.com,cn=groups,cn=nwra.com,cn=sysdb] has set [ts_cache] attrs. (2026-04-21 16:11:57): [be[nwra.com]] [sysdb_set_entry_attr] (0x0200): [RID#531995] Entry [name=orion_hbac(a)nwra.com,cn=groups,cn=nwra.com,cn=sysdb] has set [ts_cache] attrs. Seems to happen every few days or so. sssd-2.9.7-4.el9_7.1.x86_64 What's the next step to figure this out? -- Orion Poplawski he/him/his - surely the least important thing about me Manager of IT Systems 720-772-5637 NWRA, Boulder Office FAX: 303-415-9702 3380 Mitchell Lane orion(a)nwra.com Boulder, CO 80301 https://www.nwra.com/

3 7

Fw: Re: Help with KCM cache
by Marek Greško 15 Apr '26

15 Apr '26

Sorry, I accidentally replied only to Sumit. Additional question: Is it safe to delete the file, should not it be only invalidated by some command? Thanks Marek Odoslané pomocou bezpečného emailu Proton Mail. ------- Forwarded Message ------- Od: Marek Greško <marek.gresko(a)protonmail.com> Dátum: utorok 14. apríla 2026, 14:39 Predmet: Re: [SSSD-users]Help with KCM cache Komu: Sumit Bose <sbose(a)redhat.com> > The 1000000 is the UID of the user who logs in. > > so after removing /var/lib/sss/db/cache_LDAP.ldb I should no longer get my KRB5CCNAME filled in any more? Or should it be filled in by KCM something after that? > > Thanks > > Marek > > > > > Odoslané pomocou bezpečného emailu Proton Mail. > > utorok 14. apríla 2026, 14:04, Sumit Bose <sbose(a)redhat.com> napísal/a: > > > Am Tue, Apr 14, 2026 at 11:30:10AM +0000 schrieb Marek Greško: > > > Hello, > > > > > > I removed the krb5_ccname_template option at all and rebooted. Now I still have the KRB5CCNAME variable filled in with the /tmp/krb5cc..... and it is still using the file. > > > > > > The krb5_child log relevant entries look like: > > > > > > (2026-04-14 12:53:14): [krb5_child[2688]] [sss_log_process_caps] (0x0100): [RID#707] Starting under ruid=..., > > > euid=..., suid=... : rgid=..., egid=..., sgid=... > > > (2026-04-14 12:53:14): [krb5_child[2688]] [sss_log_process_caps] (0x0100): [RID#707] With following capabiliti > > > es: > > > CAP_DAC_READ_SEARCH: effective = 0 , permitted = *1*, inheritable = 0 , bounding = *1* > > > CAP_SETGID: effective = 0 , permitted = *1*, inheritable = 0 , bounding = *1* > > > CAP_SETUID: effective = 0 , permitted = *1*, inheritable = 0 , bounding = *1* > > > (2026-04-14 12:53:14): [krb5_child[2688]] [unpack_buffer] (0x1000): [RID#707] total buffer size: [107] > > > (2026-04-14 12:53:14): [krb5_child[2688]] [unpack_buffer] (0x0100): [RID#707] cmd [249 (pre-auth)] uid [...] gid [...] validate [false] enterprise principal [false] offline [false] UPN [username(a)EXAMPLE.COM] > > > (2026-04-14 12:53:14): [krb5_child[2688]] [unpack_buffer] (0x0100): [RID#707] ccname: [KCM:] old_ccname: [FILE > > > :/tmp/krb5cc_1000000_asdfgh] keytab: [not set] > > > (2026-04-14 12:53:14): [krb5_child[2688]] [check_keytab_name] (0x0400): [RID#707] Missing krb5_keytab option f > > > or domain, looking for default one > > > (2026-04-14 12:53:14): [krb5_child[2688]] [check_keytab_name] (0x0400): [RID#707] krb5_kt_default_name() retur > > > ned: FILE:/etc/krb5.keytab > > > (2026-04-14 12:53:14): [krb5_child[2688]] [check_keytab_name] (0x0400): [RID#707] krb5_child will default to: > > > /etc/krb5.keytab > > > (2026-04-14 12:53:14): [krb5_child[2688]] [check_use_fast] (0x0100): [RID#707] Not using FAST. > > > (2026-04-14 12:53:14): [krb5_child[2688]] [old_ccache_valid] (0x0400): [RID#707] Saved ccache FILE:/tmp/krb5cc > > > _1000000_asdfgh doesn't exist, ignoring > > > (2026-04-14 12:53:14): [krb5_child[2688]] [k5c_ccache_check] (0x4000): [RID#707] Old ccache is [FILE:/tmp/krb5 > > > cc_1000000_asdfgh] and is active and TGT is not valid. > > > (2026-04-14 12:53:14): [krb5_child[2688]] [k5c_ccache_check] (0x4000): [RID#707] Reusing old ccache [FILE:/tmp > > > /krb5cc_1000000_asdfgh] > > > > Hi, > > > > the important messages are the ones from above and 'is active' means > > that a process running with the UID of the user trying to log in > > (1000000 ?) was found. Is there any service or daemon running under > > this UID which is automatically started after reboot? > > > > The old credential cache name (FILE:/tmp/krb5cc_1000000_asdfgh) is saved > > in SSSD's cache. So in the worst case you can remove the SSSD cache > > /var/lib/sss/db/cache_LDAP.ldb and restart SSSD. You will loose the > > cached password hashes for offline login in this case, if you have > > 'cache_credentials = True' in sssd.conf. > > > > bye, > > Sumit > > > > > > > (2026-04-14 12:53:14): [krb5_child[2688]] [privileged_krb5_setup] (0x0080): [RID#707] Cannot open the PAC resp > > > onder socket > > > > > > The sssd_LDAP.log relevant entries look like: > > > 2026-04-14 12:53:18): [be[LDAP]] [sbus_senders_lookup] (0x2000): Looking for identity of sender [sssd.pam] > > > (2026-04-14 12:53:18): [be[LDAP]] [dp_pam_handler_send] (0x0100): Got request with the following data > > > (2026-04-14 12:53:18): [be[LDAP]] [pam_print_data] (0x0100): command: SSS_PAM_AUTHENTICATE > > > (2026-04-14 12:53:18): [be[LDAP]] [pam_print_data] (0x0100): domain: LDAP > > > (2026-04-14 12:53:18): [be[LDAP]] [pam_print_data] (0x0100): user: username@ldap > > > (2026-04-14 12:53:18): [be[LDAP]] [pam_print_data] (0x0100): service: login > > > (2026-04-14 12:53:18): [be[LDAP]] [pam_print_data] (0x0100): tty: /dev/tty2 > > > (2026-04-14 12:53:18): [be[LDAP]] [pam_print_data] (0x0100): ruser: > > > (2026-04-14 12:53:18): [be[LDAP]] [pam_print_data] (0x0100): rhost: > > > (2026-04-14 12:53:18): [be[LDAP]] [pam_print_data] (0x0100): authtok type: 1 (Password) > > > (2026-04-14 12:53:18): [be[LDAP]] [pam_print_data] (0x0100): newauthtok type: 0 (No authentication token available) > > > (2026-04-14 12:53:18): [be[LDAP]] [pam_print_data] (0x0100): priv: 1 > > > (2026-04-14 12:53:18): [be[LDAP]] [pam_print_data] (0x0100): cli_pid: 2602 > > > (2026-04-14 12:53:18): [be[LDAP]] [pam_print_data] (0x0100): child_pid: 2688 > > > (2026-04-14 12:53:18): [be[LDAP]] [pam_print_data] (0x0100): logon name: not set > > > (2026-04-14 12:53:18): [be[LDAP]] [pam_print_data] (0x0100): flags: 0 > > > (2026-04-14 12:53:18): [be[LDAP]] [dp_attach_req] (0x0400): [RID#708] DP Request [PAM Authenticate #708]: REQ_TRACE: New request. [sssd.pam CID #3] Flags [0000]. > > > (2026-04-14 12:53:18): [be[LDAP]] [dp_attach_req] (0x0400): [RID#708] Number of active DP request: 1 > > > (2026-04-14 12:53:18): [be[LDAP]] [sss_domain_get_state] (0x2000): [RID#708] Domain LDAP is Active > > > (2026-04-14 12:53:18): [be[LDAP]] [krb5_auth_queue_send] (0x1000): [RID#708] Wait queue of user [username@ldap] is empty, running request [0x557c1a0e1ea0] immediately. > > > (2026-04-14 12:53:18): [be[LDAP]] [krb5_setup] (0x4000): [RID#708] No mapping for: username@ldap > > > (2026-04-14 12:53:18): [be[LDAP]] [check_ccache_re] (0x1000): [RID#708] Ccache directory name [KCM:] does not contain illegal patterns. > > > (2026-04-14 12:53:18): [be[LDAP]] [fo_resolve_service_send] (0x0100): [RID#708] Trying to resolve service 'KERBEROS' > > > (2026-04-14 12:53:18): [be[LDAP]] [get_server_status] (0x1000): [RID#708] Status of server 'kerb.example.com' is 'working' > > > (2026-04-14 12:53:18): [be[LDAP]] [get_port_status] (0x1000): [RID#708] Port status of port 0 for server 'kerb.example.com' is 'working' > > > (2026-04-14 12:53:18): [be[LDAP]] [fo_resolve_service_activate_timeout] (0x2000): [RID#708] Resolve timeout [dns_resolver_timeout] set to 6 seconds > > > (2026-04-14 12:53:18): [be[LDAP]] [get_server_status] (0x1000): [RID#708] Status of server 'kerb.example.com' is 'working' > > > (2026-04-14 12:53:18): [be[LDAP]] [be_resolve_server_process] (0x1000): [RID#708] Saving the first resolved server > > > (2026-04-14 12:53:18): [be[LDAP]] [be_resolve_server_process] (0x0200): [RID#708] Found address for server kerb.example.com: [10.0.0.1] TTL 7190 > > > (2026-04-14 12:53:18): [be[LDAP]] [sss_domain_get_state] (0x2000): [RID#708] Domain LDAP is Active > > > (2026-04-14 12:53:18): [be[LDAP]] [create_send_buffer] (0x0400): [RID#708] krb5_keytab not set for domain in sssd.conf > > > (2026-04-14 12:53:18): [be[LDAP]] [_write_pipe_handler] (0x0400): [RID#708] All data has been sent! > > > (2026-04-14 12:53:18): [be[LDAP]] [_read_pipe_handler] (0x4000): [RID#708] Adding [120] bytes of data. > > > (2026-04-14 12:53:18): [be[LDAP]] [_read_pipe_handler] (0x0400): [RID#708] All data received > > > (2026-04-14 12:53:18): [be[LDAP]] [parse_krb5_child_response] (0x1000): [RID#708] child response: status code: 0 (Úspech), msg type: 3 (Env variable to be set with pam_putenv(3)), len: 43 > > > (2026-04-14 12:53:18): [be[LDAP]] [parse_krb5_child_response] (0x1000): [RID#708] child response: status code: 0 (Úspech), msg type: -1073741822 (UPN info), len: 17 > > > (2026-04-14 12:53:18): [be[LDAP]] [parse_krb5_child_response] (0x1000): [RID#708] child response: status code: 0 (Úspech), msg type: -1073741823 (TGT lifetime info), len: 32 > > > (2026-04-14 12:53:18): [be[LDAP]] [parse_krb5_child_response] (0x1000): [RID#708] TGT times are [1776163998][1776163998][1776768794][1776163998]. > > > (2026-04-14 12:53:18): [be[LDAP]] [_be_fo_set_port_status] (0x8000): [RID#708] Setting status: PORT_WORKING. Called from: src/providers/krb5/krb5_auth.c: krb5_auth_done: 1161 > > > (2026-04-14 12:53:18): [be[LDAP]] [fo_set_port_status] (0x0100): [RID#708] Marking port 0 of server 'kerb.example.com' as 'working' > > > (2026-04-14 12:53:18): [be[LDAP]] [set_server_common_status] (0x0100): [RID#708] Marking server 'kerb.example.com' as 'working' > > > (2026-04-14 12:53:18): [be[LDAP]] [krb5_mod_ccname] (0x4000): [RID#708] Save ccname [FILE:/tmp/krb5cc_1000000_asdfgh] for user [username@ldap]. > > > (2026-04-14 12:53:18): [be[LDAP]] [sysdb_set_entry_attr] (0x0200): [RID#708] Entry [name=username@ldap,cn=users,cn=LDAP,cn=sysdb] has set [ts_cache] attrs. > > > (2026-04-14 12:53:18): [be[LDAP]] [sysdb_ldb_msg_difference] (0x2000): [RID#708] Replaced/extended attr [cachedPassword] of entry [name=username@ldap,cn=users,cn=LDAP,cn=sysdb] > > > (2026-04-14 12:53:18): [be[LDAP]] [sysdb_set_entry_attr] (0x0200): [RID#708] Entry [name=username@ldap,cn=users,cn=LDAP,cn=sysdb] has set [cache, ts_cache] attrs. > > > (2026-04-14 12:53:18): [be[LDAP]] [check_wait_queue] (0x1000): [RID#708] Wait queue for user [username@ldap] is empty. > > > (2026-04-14 12:53:18): [be[LDAP]] [krb5_auth_queue_done] (0x1000): [RID#708] krb5_auth_queue request [0x557c1a0e1ea0] done. > > > (2026-04-14 12:53:18): [be[LDAP]] [dp_req_done] (0x0400): [RID#708] DP Request [PAM Authenticate #708]: Request handler finished [0]: Úspech > > > > > > > > > The strange thing is the username@ldap. I expect it is some internal sssd representation as I named the domain section domain/LDAP, is it? > > > > > > Thanks > > > > > > Marek > > > > > > > > > > > > > > > Odoslané pomocou bezpečného emailu Proton Mail. > > > > > > utorok 14. apríla 2026, 12:06, Sumit Bose <sbose(a)redhat.com> napísal/a: > > > > > > > Am Tue, Apr 14, 2026 at 07:52:59AM +0000 schrieb Marek Greško: > > > > > Hello, > > > > > > > > > > I am sure there is no other default_ccache_name in the krb5.conf or /etc/krb5.conf.d/*. > > > > > > > > > > I always tested after reboot, so the user should not be logged in while testing. > > > > > > > > > > When performing debugs you requested what is the required state of the config? > > > > > > > > > > Should I have > > > > > [libdefaults] > > > > > default_ccache_name = KCM: > > > > > in /etc/krb5.conf.d/kcm_default_ccache > > > > > > > > > > and > > > > > > > > > > > > > Hi, > > > > > > > > I would suggest to remove the 'krb5_ccname_template' option as well > > > > since it should not be needed. > > > > > > > > > krb5_ccname_template = KCM:%U > > > > > in sssd.conf, but not the > > > > > #pam_response_filter = ENV:KRB5CCNAME > > > > > > > > > > ??? > > > > > > > > > > Is it working for you? > > > > > > > > yes > > > > > > > > > > > > bye, > > > > Sumit > > > > > > > > > > > > > > Thanks > > > > > > > > > > Marek > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Odoslané pomocou bezpečného emailu Proton Mail. > > > > > > > > > > utorok 14. apríla 2026, 9:28, Sumit Bose <sbose(a)redhat.com> napísal/a: > > > > > > > > > > > Am Tue, Apr 14, 2026 at 05:46:20AM +0000 schrieb Marek Greško via sssd-users: > > > > > > > Hello, > > > > > > > > > > > > > > had anybody successfully configured kcm cache in sssd? If yes, what is the correct way? I found some partial resources which did not lead me to a working solution. > > > > > > > > > > > > > > I use Fedora 43. I have configured: > > > > > > > > > > > > > > /etc/krb5.conf.d/kcm_default_ccache > > > > > > > > > > > > > > [libdefaults] > > > > > > > default_ccache_name = KCM: > > > > > > > > > > > > > > This configuration is still using files. > > > > > > > > > > > > > > I configured /etc/sssd/sssd.conf: > > > > > > > > > > > > Hi, > > > > > > > > > > > > > > > > > > > > krb5_ccname_template = KCM:%U > > > > > > > > > > > > even this should not be needed, SSSD should follow the defaults set in > > > > > > the Kerberos configuration above. However, please check /etc/krb5.conf > > > > > > and the condif snippets from the includedir directories if there is > > > > > > another 'default_ccache_name' line which sets FILE:... > > > > > > > > > > > > > and commented out: > > > > > > > #krb5_ccachedir = /tmp > > > > > > > #krb5_ccname_template = FILE:%d/krb5cc_%U_XXXXXX > > > > > > > > > > > > > > But files still have been used. I found out the variable KRB5CCNAME still contains FILE:/tmp/krb5cc_..... with the original template. > > > > > > > > > > > > > > I found in some forums workaround by setting the filter in /etc/sssd/sssd.conf > > > > > > > > > > > > > > [pam] > > > > > > > pam_response_filter = ENV:KRB5CCNAME > > > > > > > > > > > > SSSD will reuse existing credential caches if there is an active session > > > > > > of the related user. If you are testing while you are still logged in as > > > > > > the user on the desktop or another shell, the old FILE bases credential > > > > > > cache will be refreshed. > > > > > > > > > > > > Please try with a user which is currently not logged into the target > > > > > > system or log out the test user completely from the system and try > > > > > > again. > > > > > > > > > > > > If this does not help you can add 'debug_level = 9' in the [domain/...] > > > > > > section of sssd.conf, re-run the test again and check the domain log and > > > > > > krb5_child.log if you can find a hint why FILE is still be used. Feel > > > > > > free to send the logs here for inspection as well, but be aware that the > > > > > > logs might contain sensitive/confidential information about the user or > > > > > > your environment. > > > > > > > > > > > > HTH > > > > > > > > > > > > bye, > > > > > > Sumit > > > > > > > > > > > > > > > > > > > > This started partially working. > > > > > > > > > > > > > > When I logged in with user with UID 1000000 and run klist, I have seen all the tickets in KCM:1000000, but the file in /tmp still have been created, which looked weird for me. > > > > > > > > > > > > > > Then I used AI to help me with this, since I was not able to find any more resources. She told me to alter /etc/sssd/sssd.conf: > > > > > > > > > > > > > > [sssd] > > > > > > > services = nss, pam > > > > > > > > > > > > > > change to: > > > > > > > > > > > > > > [sssd] > > > > > > > services = nss, pam, kcm > > > > > > > > > > > > > > This lead to failure to start the sssd, so I reverted the last change and rebooted and I was thinking I have a partially working setup and planned to leave it like this for a while. But unfortunately after the reboot user with UID 1000001 came and logged in. Nothing was working for him. When I asked him to run klist, tickets were not there and there was some error message about KCM:1000001. I do not remember for sure, but I think it was KCM:1000001 not found. I had to revert all the changes immediately to the original state with using files. > > > > > > > > > > > > > > Can anybody help me to firstly analyze what happened and why it was working for user 1000000 and not for user 1000001 (I do not know whether the test the AI told me to do started the problem for all the users) and secondly how to configure it right way to use KCM instead of files without the workaround with the pam filter for KRB5CCNAME environment variable? > > > > > > > > > > > > > > Thanks > > > > > > > > > > > > > > Marek > > > > > > > > > > > > > -- > > > > > > > _______________________________________________ > > > > > > > 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, report it: https://forge.fedoraproject.org/infra/tickets/issues/new > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >

1 0

Fw: Re: Re: Help with KCM cache
by Marek Greško 15 Apr '26

15 Apr '26

Sorry, I replied only to Striker accidentally. Marek Odoslané pomocou bezpečného emailu Proton Mail. ------- Forwarded Message ------- Od: Marek Greško <marek.gresko(a)protonmail.com> Dátum: utorok 14. apríla 2026, 14:35 Predmet: Re: [SSSD-users]Re: Help with KCM cache Komu: Striker Leggette <striker(a)terranforge.com> > redacted krb5.conf: > > > includedir /etc/krb5.conf.d/ > > [logging] > default = FILE:/var/log/krb5libs.log > kdc = FILE:/var/log/krb5kdc.log > admin_server = FILE:/var/log/kadmind.log > > [libdefaults] > dns_lookup_realm = false > ticket_lifetime = 7d > renew_lifetime = 14d > forwardable = true > rdns = false > pkinit_anchors = FILE:/etc/pki/tls/certs/ca-bundle.crt > spake_preauth_groups = edwards25519 > dns_canonicalize_hostname = fallback > qualify_shortname = "" > default_realm = EXAMPLE.COM > #default_ccache_name = KEYRING:persistent:%{uid} > #default_tgs_enctypes = aes256-cts-hmac-sha1-96 aes128-cts-hmac-sha1-96 > #default_tkt_enctypes = aes256-cts-hmac-sha1-96 aes128-cts-hmac-sha1-96 > > [realms] > > [domain_realm] > > > > ls /etc/krb5.conf.d/: > crypto-policies dbmodules.conf domain_realm.conf enable_sssd_conf_dir kcm_default_ccache realms.conf > > redacted cat /etc/krb5.conf.d/* including kcm_default_ccache > [libdefaults] > permitted_enctypes = aes256-cts-hmac-sha384-192 aes128-cts-hmac-sha256-128 aes256-cts-hmac-sha1-96 aes128-cts-hmac-sha1-96 camellia256-cts-cmac camellia128-cts-cmac > [dbmodules] > openldap_ldapconf = { > db_library = kldap > ldap_kerberos_container_dn = "cn=..." > ldap_kdc_dn = "cn=..." > ldap_kadmind_dn = "cn=..." > ldap_service_password_file = /var/kerberos/krb5kdc/service.keyfile > ldap_servers = ... > ldap_conns_per_server = 2 > } > > [domain_realm] > .example.com = EXAMPLE.COM > example.com = EXAMPLE.COM > > # This file should normally be installed by your distribution into a > # directory that is included from the Kerberos configuration file (/etc/krb5.conf) > # On Fedora/RHEL/CentOS, this is /etc/krb5.conf.d/ > > includedir /var/lib/sss/pubconf/krb5.include.d/ > # This file should normally be installed by your distribution into a > # directory that is included from the Kerberos configuration file (/etc/krb5.conf) > # On Fedora/RHEL/CentOS, this is /etc/krb5.conf.d/ > # > # To enable the KCM credential cache enable the KCM socket and the service: > # systemctl enable sssd-kcm.socket > # systemctl start sssd-kcm.socket > # > # To disable the KCM credential cache, comment out the following lines. > > [libdefaults] > default_ccache_name = KCM: > [realms] > EXAMPLE.COM = { > kdc = kerb.example.com > admin_server = kerb.example.com > default_domain = example.com > database_module = openldap_ldapconf > } > > > > > > redacted /etc/sssd/sssd.conf: > [sssd] > config_file_version = 2 > services = nss, pam > # SSSD will not start if you do not configure any domains. > # Add new domain configurations as [domain/<NAME>] sections, and > # then add the list of domains (in the order you want them to be > # queried) to the "domains" attribute below and uncomment it. > domains = LDAP > > [nss] > > filter_users = root,ldap,named,avahi,haldaemon,dbus,radvd,tomcat,radiusd,news,mailman,nscd,gdm,polkituser,rtkit,pulse > > [pam] > #pam_response_filter = ENV:KRB5CCNAME > > [domain/LDAP] > id_provider = ldap > access_provider = ldap > auth_provider = krb5 > chpass_provider = krb5 > # ldap_schema can be set to "rfc2307", which stores group member names in the > # "memberuid" attribute, or to "rfc2307bis", which stores group member DNs in > # the "member" attribute. If you do not know this value, ask your LDAP > # administrator. > ldap_schema = rfc2307 > ldap_uri = ... > ldap_search_base = ... > ldap_user_search_base = ... > ldap_group_search_base = ... > ldap_tls_reqcert = demand > ldap_id_use_start_tls = true > ldap_tls_cacert = ... > enumerate = true > cache_credentials = true > ldap_min_id = 500 > ldap_max_id = 3000000 > > ldap_group_member = memberUid > ldap_group_name = cn > > ldap_access_filter = objectclass=person > > krb5_server = kerb.example.com > krb5_realm = EXAMPLE.COM > #krb5_ccachedir = /tmp > #krb5_ccname_template = FILE:%d/krb5cc_%U_XXXXXX > #krb5_ccname_template = KCM:%U > krb5_auth_timeout = 15 > > > > > > Odoslané pomocou bezpečného emailu Proton Mail. > > utorok 14. apríla 2026, 13:46, Striker Leggette <striker(a)terranforge.com> napísal/a: > > > > > > > On 4/14/26 7:30 AM, Marek Greško via sssd-users wrote: > > > Hello, > > > > > > I removed the krb5_ccname_template option at all and rebooted. Now I still have the KRB5CCNAME variable filled in with the /tmp/krb5cc..... and it is still using the file. > > > > Could you show these? > > > > # cat /etc/krb5.conf > > # ls /etc/krb5.conf.d/ > > # cat /etc/krb5.conf.d/kcm_default_ccache > > # cat /etc/sssd/sssd.conf > > > > > The strange thing is the username@ldap. I expect it is some internal sssd representation as I named the domain section domain/LDAP, is it? > > > > Yes, SSSD will use the naming from the [domain/...] section in this way. > > To be safe, it should be set to your Kerberos realm, such as: > > > > [domain/example.com] > >

1 0

pam_systemd sddm failed to get user record no such process
by joe kluthe 08 Apr '26

08 Apr '26

m trying to get SSSD working on EneavourOS to authenticate using my Active Directory domain, it appears that SSSD is not talking to Systemd-userdb, because I can SU the user and login on shell, but starting a KDE session fails,a nd using userdbctl user <domain User> returns user does not exist attempting to login via GUI will freeze the system until ctrl-c is pressed. journalctl shows pam_systemd sddm failed to get user record no such process anyone know how to fix this? i wend around and around with Google's AI search, but it's now going in circles.

2 1

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

sssd-users April 2026