sssd-users January 2024

sssd-users@lists.fedorahosted.org

10 participants
14 discussions

Offline auth with id provider files auth provider krb5
by Techie 21 May '24

21 May '24

Hi Trying to use cached creds with local users in the passwd file authenticating via kerberos. I have id_provider set to files and auth_provider set to krb5(AD DC). Online authentication works fine however when I disconnect the network authentication fails. The computer is not joined to a domain, I am only leveraging the domain/realm for authentication purposes Relevant entries [pam] offline_credentials_expiration = 7 [domain] cache_credentials=true account_cache_expiration=8 id_provider=files auth_provider=krb5 krb5_server=srva.example.com krb5_kpasswd=srva.example.com krb5_realm=EXAMPLE.COM dns_discovery_domain=EXAMPLE.COM krb5_store_password_if_offline=true Is this a supported configuration for offline logins with cached credentials? Thanks

2 5

Starting SSSD without root
by Tero Saarni 09 Apr '24

09 Apr '24

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 20

Internal credentials cache error while getting initial credentials
by Albert Szostkiewicz 21 Feb '24

21 Feb '24

Hey, Need some help here, I am unable to log-in. when trying to use kinit on my user, I am getting an error: kinit: Failed to store credentials: Internal credentials cache error while getting initial credentials sssd runs. log shows: Oct 13 20:32:59 user.mydomain.com krb5_child[4846]: Internal credentials cache error sssd_kcm.log states: * (2023-10-13 21:17:43): [kcm] [local_db_check_peruid_number_of_secrets] (0x0040): [CID#8708] Cannot store any more secrets for this client (basedn cn=1907400001,cn=persistent,cn=kcm) as the maximum allowed limit (66) has been reached ********************** BACKTRACE DUMP ENDS HERE ********************************* (2023-10-13 21:17:43): [kcm] [sss_sec_update] (0x0040): [CID#8708] local_db_check_number_of_secrets failed [1432158289]: The maximum number of stored secrets has been reached (2023-10-13 21:17:43): [kcm] [sec_update] (0x0040): [CID#8708] Cannot write the secret [1432158289]: The maximum number of stored secrets has been reached ********************** PREVIOUS MESSAGE WAS TRIGGERED BY THE FOLLOWING BACKTRACE: * (2023-10-13 21:17:43): [kcm] [sss_sec_update] (0x0040): [CID#8708] local_db_check_number_of_secrets failed [1432158289]: The maximum number of stored secrets has been reached * (2023-10-13 21:17:43): [kcm] [sec_update] (0x0040): [CID#8708] Cannot write the secret [1432158289]: The maximum number of stored secrets has been reached ********************** BACKTRACE DUMP ENDS HERE ********************************* (2023-10-13 21:17:43): [kcm] [kcm_ccdb_mod_done] (0x0040): [CID#8708] Failed to create ccache [1432158289]: The maximum number of stored secrets has been reached (2023-10-13 21:17:43): [kcm] [kcm_op_set_kdc_offset_mod_done] (0x0040): [CID#8708] Cannot modify ccache [1432158289]: The maximum number of stored secrets has been reached ********************** PREVIOUS MESSAGE WAS TRIGGERED BY THE FOLLOWING BACKTRACE: * (2023-10-13 21:17:43): [kcm] [kcm_ccdb_mod_done] (0x0040): [CID#8708] Failed to create ccache [1432158289]: The maximum number of stored secrets has been reached * (2023-10-13 21:17:43): [kcm] [kcm_op_set_kdc_offset_mod_done] (0x0040): [CID#8708] Cannot modify ccache [1432158289]: The maximum number of stored secrets has been reached ********************** BACKTRACE DUMP ENDS HERE ********************************* (2023-10-13 21:17:43): [kcm] [kcm_cmd_done] (0x0040): [CID#8708] op receive function failed [1432158289]: The maximum number of stored secrets has been reached (2023-10-13 21:17:43): [kcm] [kcm_cmd_request_done] (0x0040): [CID#8708] KCM operation failed [1432158289]: The maximum number of stored secrets has been reached ********************** PREVIOUS MESSAGE WAS TRIGGERED BY THE FOLLOWING BACKTRACE: * (2023-10-13 21:17:43): [kcm] [kcm_cmd_done] (0x0040): [CID#8708] op receive function failed [1432158289]: The maximum number of stored secrets has been reached * (2023-10-13 21:17:43): [kcm] [kcm_cmd_request_done] (0x0040): [CID#8708] KCM operation failed [1432158289]: The maximum number of stored secrets has been reached ********************** BACKTRACE DUMP ENDS HERE ********************************* KRB5_TRACE=/dev/stderr ipa --debug ping ipa: DEBUG: importing plugin module ipaclient.plugins.trust ipa: DEBUG: importing plugin module ipaclient.plugins.user ipa: DEBUG: importing plugin module ipaclient.plugins.vault ipa: DEBUG: trying https://workstation.mydomain.com/ipa/json ipa: DEBUG: Created connection context.rpcclient_140066561958480 ipa: DEBUG: raw: ping(version='2.252') ipa: DEBUG: ping(version='2.252') ipa: DEBUG: [try 1]: Forwarding 'ping/1' to json server 'https://workstation.mydomain.com/ipa/json' ipa: DEBUG: New HTTP connection (workstation.mydomain.com) ipa: DEBUG: HTTP connection destroyed (workstation.mydomain.com) Traceback (most recent call last): File "/usr/lib/python3.11/site-packages/ipalib/rpc.py", line 644, in get_auth_info response = self._sec_context.step() ^^^^^^^^^^^^^^^^^^^^^^^^ File "/usr/lib/python3.11/site-packages/decorator.py", line 232, in fun return caller(func, *(extras + args), **kw) ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ File "/usr/lib64/python3.11/site-packages/gssapi/_utils.py", line 165, in check_last_err return func(self, *args, **kwargs) ^^^^^^^^^^^^^^^^^^^^^^^^^^^ File "/usr/lib/python3.11/site-packages/decorator.py", line 232, in fun return caller(func, *(extras + args), **kw) ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ File "/usr/lib64/python3.11/site-packages/gssapi/_utils.py", line 131, in catch_and_return_token return func(self, *args, **kwargs) ^^^^^^^^^^^^^^^^^^^^^^^^^^^ File "/usr/lib64/python3.11/site-packages/gssapi/sec_contexts.py", line 584, in step return self._initiator_step(token=token) ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ File "/usr/lib64/python3.11/site-packages/gssapi/sec_contexts.py", line 606, in _initiator_step res = rsec_contexts.init_sec_context(self._target_name, self._creds, ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ File "gssapi/raw/sec_contexts.pyx", line 188, in gssapi.raw.sec_contexts.init_sec_context gssapi.raw.exceptions.MissingCredentialsError: Major (458752): No credentials were supplied, or the credentials were unavailable or inaccessible, Minor (2529639053): No Kerberos credentials available (default cache: KCM:) During the handling of the above exception, another exception occurred: Traceback (most recent call last): File "/usr/lib/python3.11/site-packages/ipalib/rpc.py", line 697, in single_request self.get_auth_info() File "/usr/lib/python3.11/site-packages/ipalib/rpc.py", line 646, in get_auth_info self._handle_exception(e, service=service) File "/usr/lib/python3.11/site-packages/ipalib/rpc.py", line 603, in _handle_exception raise errors.CCacheError() ipalib.errors.CCacheError: did not receive Kerberos credentials ipa: DEBUG: Destroyed connection context.rpcclient_140066561958480 ipa: ERROR: did not receive Kerberos credentials I appreciate if anyone have some ideas. Thank you!

3 4

Integrate DMZ clients (sssd) to Active Directory through proxy
by Horváth Szabolcs 02 Feb '24

02 Feb '24

Hi, I'd like to integrate our servers sitting in DMZ to Active Directory (domain controllers are located inside), without direct network connection between the parties. The security policy says we have to use some kind of intermediate party (e.g. layer7 proxy). A few years ago I had a project where the clients and the proxy server were all RHEL7, and the solution was slapd as an ldap proxy and pam_ldap+nslcd on client side (https://wiki.samba.org/index.php/OpenLDAP_as_proxy_to_AD) Time has passed, we have no longer have RHEL7s, RHEL/SUSE no longer have openldap-servers package (although slapd in back in EPEL9) and we don't have nslcd+pam_ldap on SLES15 anymore. It looks like everyone prefers 389 directory server project. RedHat has an excellent article about the problem: https://www.redhat.com/en/blog/identity-management-systems-dmz Basically my options are: 1. local authentication (that's the starting point from which we want to move on) 2. connect directly to AD (there are no working layer7 proxy solutions as far as I know, so we rejected this option) 3. expose read only AD replicas in DMZ (so-called roDCs or 389-ds -> very complex solution, I don't want go in this direction) 4. separate AD/IdM domain in DMZ (see above, it does not reduce complexity) 5. kdcproxy - https://github.com/latchset/kdcproxy On the client side, I would stick to sssd (SLES 15 and RHEL8+, very limited number of older versions). The proxy side, I tested two solutions, none of them really work: 1. slapd (from EPEL9) as an LDAPS proxy between the clients and AD. sssd (I tested 2.5.2) detects the presence of the proxy and fails: --- id_provider = ldap ldap_uri = ldaps://ldapproxy.test.local ldap_search_base = OU=TESTLAB,DC=test,DC=local ldap_schema = AD [...] auth_provider = ldap --- * (2024-01-28 20:08:27): [be[test.local]] [sdap_process_result] (0x2000): Trace: sh[0x55bb0dca1b10], connected[1], ops[0x55bb0dd0c900], ldap[0x55bb0dbd53e0] * (2024-01-28 20:08:27): [be[test.local]] [sdap_process_message] (0x4000): Message type: [LDAP_RES_SEARCH_ENTRY] * (2024-01-28 20:08:27): [be[test.local]] [sdap_parse_entry] (0x1000): OriginalDN: []. * (2024-01-28 20:08:27): [be[test.local]] [sdap_parse_range] (0x2000): No sub-attributes for [objectClass] * (2024-01-28 20:08:27): [be[test.local]] [sdap_parse_range] (0x2000): No sub-attributes for [namingContexts] * (2024-01-28 20:08:27): [be[test.local]] [sdap_parse_range] (0x2000): No sub-attributes for [supportedControl] * (2024-01-28 20:08:27): [be[test.local]] [sdap_parse_range] (0x2000): No sub-attributes for [supportedExtension] * (2024-01-28 20:08:27): [be[test.local]] [sdap_parse_range] (0x2000): No sub-attributes for [supportedFeatures] * (2024-01-28 20:08:27): [be[test.local]] [sdap_parse_range] (0x2000): No sub-attributes for [supportedLDAPVersion] * (2024-01-28 20:08:27): [be[test.local]] [sdap_process_result] (0x2000): Trace: sh[0x55bb0dca1b10], connected[1], ops[0x55bb0dd0c900], ldap[0x55bb0dbd53e0] * (2024-01-28 20:08:27): [be[test.local]] [sdap_process_message] (0x4000): Message type: [LDAP_RES_SEARCH_RESULT] * (2024-01-28 20:08:27): [be[test.local]] [sdap_get_generic_op_finished] (0x0400): Search result: Success(0), no errmsg set * (2024-01-28 20:08:27): [be[test.local]] [sdap_op_destructor] (0x2000): Operation 1 finished * (2024-01-28 20:08:27): [be[test.local]] [sdap_get_rootdse_done] (0x2000): Got rootdse * (2024-01-28 20:08:27): [be[test.local]] [sdap_get_rootdse_done] (0x2000): Skipping auto-detection of match rule * (2024-01-28 20:08:27): [be[test.local]] [sdap_get_server_opts_from_rootdse] (0x0020): ldap_rootdse_last_usn configured but not found in rootdse! ********************** BACKTRACE DUMP ENDS HERE ********************************* Basically we don't have so much information in rootDSE which sssd depends on: # ldapsearch -h 127.0.0.1 -D "CN=_svc_ldapquery,OU=Users,OU=TESTLAB,DC=test,DC=local" -b '' -s base '(objectclass=*)' # dn: objectClass: top objectClass: OpenLDAProotDSE # search result search: 2 result: 0 Success # numResponses: 2 # numEntries: 1 2. kdcproxy as a kerberos proxy: https://github.com/latchset/kdcproxy The main problem is sssd can utilize krb5 for access_provider and access_provider, but it needs separate id_provider, usually id_provider=ldap, and it comes to my previous problem, I couldn't proxy ldap protocol. Do you have any suggestions for this problem that I haven't considered? Thanks! Szabolcs

3 2

Undocumented ldap_sasl_authid feature causing sssd to succeed?
by Spike White 31 Jan '24

31 Jan '24

All, We’re auditing for successful & healthy AD join of our 32K+ servers. Our check is basically this: AUTHID=$(grep ldap_sasl_authid /etc/sssd/sssd.conf | awk '{print $3}') [[ $AUTHID != host/* ]] && AUTHID=host/$AUTHID kinit -k $AUTHID i.e., kinit with the same service principal that sssd uses (prepending the "host/" prefix if not already existing). We’ve identified about 200 “failing” servers, but upon closer inspection only about 30 of them are really failing. The other 170 are failing the above naïve check, but sssd is properly working. Here’s an example: Server ddlplhdc4036.us.company.com has ldap_sasl_authid = ddlplhdc4034.us.company.com(a)AMER.COMPANY.COM <.us.dell.com(a)AMER.DELL.COM> but in /etc/krb5.keytab file ii has: host/ddlplhdc4036.us.company.com(a)AMER.COMPANY.COM <host/ddlplhdc4036.us.dell.com(a)AMER.DELL.COM> If you look at the sssd-ldap man page, it states: ldap_sasl_authid (string) Specify the SASL authorization id to use. When GSSAPI/GSS-SPNEGO are used, this represents the Kerberos principal used for authentication to the directory. This option can either contain the full principal (for example host/ myhost(a)EXAMPLE.COM) or just the principal name (for example host/myhost). By default, the value is not set and the following principals are used: hostname@REALM netbiosname$@REALM host/hostname@REALM *$@REALM host/*@REALM host/* If none of them are found, the first principal in keytab is returned. Default: host/hostname@REALM If we have ldap_sasl_authid defined in /etc/sssd/sssd.conf file and it fails, does it try those other permutations above? I'm guessing so, based on these 170 servers that are allegedly failing, but sssd is truly succeeding. Spike White

2 3

Weird issue with "Couldn't invalidate user" - SSSD-AD
by Kodiak Firesmith 31 Jan '24

31 Jan '24

Hello, I've begun to see the oddest thing within our AD environment on Linux clients (Ubuntu 20, 22). During logins I see "groups: cannot find name for group ID". Then during various operations (eg when installing a package that has scripts that create local users, such as postgresql) I see a few of the same userIDs listed as terminal output like this: Couldn't invalidate user jim.bob(a)domain.college.edu Couldn't invalidate user sally.sue(a)domain.college.edu Couldn't invalidate user joe.nobody(a)domain.college.edu Reading through what little comes up in Google for 'Couldn't invalidate user' + sssd, I found old bugs about not being able to invalidate groups in the sss_cache. That got me far enough to have a repeatable action to force this output: # sss_cache -UG Couldn't invalidate user jim.bob(a)domain.college.edu Couldn't invalidate user sally.sue(a)domain.college.edu Couldn't invalidate user joe.nobody(a)domain.college.edu I've tried ramping up debugging on my AD domain entry in sssd.conf to 9 but I'm not seeing anything that jumps out. Any ideas? Thanks!

2 3

SSSD LDAP provider fails to fetch nested groups (groups member of groups)
by Finn Fysj 22 Jan '24

22 Jan '24

I'm experiencing problems on my RHEL 9 instance when looking up members of group using getent group <GROUP NAME>. I can only get users which has direct access to a group, and no the "user groups" part of the group. My sssd.conf: [domain/<DOMAIN>] id_provider = ldap auth_provider = ldap chpass_provider = ldap sudo_provider = ldap ldap_uri = ldaps:/ipa.example.com ldap_schema = rfc2307bis ldap_search_base = dc=example,dc=com ldap_sudo_search_base = ou=sudoers,dc=example,dc=com ldap_user_search_base = cn=users,cn=accounts,dc=example,dc=com ldap_group_search_base = cn=groups,cn=accounts,dc=example,dc=com [sssd] services = nss, pam, sudo domains = default [nss] homedir_substring = /home [pam] [sudo]

3 10

sssd_nss writing 25 MiB to /var/lib/sss/mc every time it starts up
by D M 19 Jan '24

19 Jan '24

Hi folks! I'm chasing down some interesting behavior on our Ubuntu 20.04 VMs. We're running sssd 2.3.3. The people who run the underlying disks for our VM hosts have been complaining about a spike in disk write latency every 10min. After investigation, I figured out the issue. By default, every 10 mins Debian systems run a cronjob, which kicks off a script called debian-sa1. By default, this script is basically a no-op. It doesn't write to disk. But running this cronjob (which runs as root by default) causes sssd_nss to get started up (on Ubuntu, it's socket activated, as you probably well know). When sssd_nss starts up, it writes the memory-mapped cache in /var/lib/sss/mc/. For us, it writes about 25 MiB of data. (Is that a lot?) By default, sssd_nss has a 5-minute timeout, so, if nothing else looks up any user info, sssd_nss shuts down. So, basically, every 10 mins, sssd_nss wakes up and writes 25 MiB. Across many thousands of VMs, this adds up to a lot of writes! Oh RHEL, seems like sssd_nss runs continuously, not socket-activated. I am thinking of just doing the same on Ubuntu. This will keep the memory-mapped cache active all the time, which is fine. It'll prevent all those disk writes. However, I wanted to see if you had any other suggestions. Thanks!

3 3

SSSD LDAP provider fails to fetch nested groups (groups member of groups)
by Finn Fysj 18 Jan '24

18 Jan '24

1 0

[SSSD] Announcing SSSD 2.9.4
by Pavel Březina 12 Jan '24

12 Jan '24

# SSSD 2.9.4 The SSSD team is announcing the release of version 2.9.4 of the System Security Services Daemon. The tarball can be downloaded from: https://github.com/SSSD/sssd/releases/tag/2.9.4 See the full release notes at: https://sssd.io/release-notes/sssd-2.9.4.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.9.4 Release Notes ## Highlights ### Important fixes * Fixes a crash when PAM passkey processing incorrectly handles non-passkey data. * A workaround was implemented to handle gracefully misbehaving applications that destroy internal state of SSSD client librarires. A particular example of such application is described in https://github.com/TigerVNC/tigervnc/issues/1709. * An error when rotating KCM's logs was fixed. When KCM's logs were rotated by logrotate, KCM would still use the old file (renamed sssd_kcm.log.1). Only after KCM was restarted (either manually or automatically) the new log file would be used. This problem is now solved and KCM uses the new file immediately. * Fixed group membership handling when members are coming from different forest domains and using ldap token groups is prohibited. * Files provider was erroneously taking into consideration `local_auth_policy` config option, thus breaking smartcard authentication of local user in setups that didn't explicitly specify this option. This is now fixed.

1 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

sssd-users January 2024