January 2024 - sssd-users - Fedora mailing-lists

filter_users using user id
by Francois Rigault 22 Mar '25

22 Mar '25

Greetings, we run some podman containers that come with their own local users, such as this one: ironic-inspector:x:42461:42461::/var/lib/ironic-inspector:/usr/sbin/nologin when running a top on the server, top tries to resolve the user name for that id and fails, however there is still a BE_REQ_USER request sent: (2022-12-30 22:42:33): [be[MY.DOMAIN.NET]] [dp_get_account_info_send] (0x0200): Got request for [0x1][BE_REQ_USER][idnumber=42461] I would hope to get rid of these requests against the domain. unfortunately in MY.DOMAIN.NET there are uids below and above this number, so I cannot rely on the "min_id" parameter to filter users. I would like to know if it is possible to support using user ids in the [nss] filter_users to prevent those user requests to the domain, or if anyone has any other suggestion. I increased the entry_negative_timeout to reduce the number of queries, but filtering them out entirely would be even better. Thank you!

4 4

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

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

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]

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

Does sssd (on RHEL8 and RHEL9) RPM have an implied dependency on sssd-kcm RPM?
by Spike White 11 Jan '24

11 Jan '24

All, Is there a packaging problem on the latest version of RHEL8 sssd? On several of our RHEL8 servers during the last update cycle, sssd logins start failing. It appears to be when upgrading to version sssd-2.9.1-4.0.1.el8_9.x86_64. Upon deep dive, it turns out the sssd-kcm RPM is missing. The sssd-kcm service fails to start, complaining about missing symbols in /usr/libexec/sssd_kcm file. Sure enough, there is a problem with that file: [root@mftplat1wplp105 ~]# rpm -qf /usr/libexec/sssd/sssd_kcm file /usr/libexec/sssd/sssd_kcm is not owned by any package Once the sssd-kcm RPM is installed, then this looks normal: [root@mftplat1wplp105 ~]# rpm -qf /usr/libexec/sssd/sssd_kcm sssd-kcm-2.9.1-4.0.1.el8_9.x86_64 Then sssd-kcm service will restart fine. and then sssd logins again work fine. Also, it appears that a yum downgrade of sssd seems to work too -- presumably because this downgrade also triggers an install of sssd-kcm RPM. I see that the sssd RPM has no direct explicit RPM dependency on sssd-kcm. But is there some indirect or implied dependency that was missed on this latest packaging for sssd-2.9.1-4.0.1.el8_9.x86_64? We've run sssd for years and never had significant sssd-kcm problems until last month. BTW, another clue that it was KCM is that 'kinit -k' fails with error: # knit -k Cannot update default cache But if you tell it to store creds under /tmp, it works: # export KRB5CCNAME="FILE:/tmp/krb5cc_0" # kinit -k Spike

3 4

Re: sssd losing track of uid after existing kvm
by Alexey Tikhonov 10 Jan '24

10 Jan '24

On Tue, Jan 9, 2024 at 7:34 PM Charles Hedrick <hedrick(a)rutgers.edu> wrote: > > ubuntu 22.04.3, sssd 2.6.3-1ubuntu3.2 > will be doing updates tomorrow to latest 22.04 code > files sss > ipa [we're a highly kerberized site] > > I'll do strace if it happens again. So far it hasn't. I hate intermittent bugs. If you are able to reproduce, then it also makes sense to set 'debug_level=9' in [nss] and [$domain] section of sssd.conf (or use `sssctl debug-level` in runtime) and capture /var/log/sssd/* covering failed attempt. > > ________________________________ > From: Alexey Tikhonov <atikhono(a)redhat.com> > Sent: Tuesday, January 9, 2024 1:15 PM > To: End-user discussions about the System Security Services Daemon <sssd-users(a)lists.fedorahosted.org> > Subject: [SSSD-users] Re: sssd losing track of uid after existing kvm > > Hi, > > On Tue, Jan 9, 2024 at 4:50 PM Charles Hedrick <hedrick(a)rutgers.edu> wrote: > > > > We want to use user-mode kvm for students. I've set up a VM. It uses 9p to mount the user's home directory. After connecting to the VM with "virsh console", and then exiting, sssd on the host (not in the VM, in the main host) loses track of the user's UID. "getent passwd UNAME" works "getent passwd UID" does not, and "whoami" says cannot find name. > > > > It doesn't always happen immediately. It's not quite reproducible. But it's close. > > > > Any idea what's going on? Logging in again will fix it. > > What is: > - platform, SSSD version > - in /etc/nsswitch.conf::passwd > - what id_provider is used in sssd.conf? > > Did you try to run `getnet -s sss passwd ...` under strace? > -- > _______________________________________________ > 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://pagure.io/fedora-infrastructure/new_issue > -- > _______________________________________________ > 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://pagure.io/fedora-infrastructure/new_issue

1 0

Re: sssd losing track of uid after existing kvm
by Alexey Tikhonov 09 Jan '24

09 Jan '24

Hi, On Tue, Jan 9, 2024 at 4:50 PM Charles Hedrick <hedrick(a)rutgers.edu> wrote: > > We want to use user-mode kvm for students. I've set up a VM. It uses 9p to mount the user's home directory. After connecting to the VM with "virsh console", and then exiting, sssd on the host (not in the VM, in the main host) loses track of the user's UID. "getent passwd UNAME" works "getent passwd UID" does not, and "whoami" says cannot find name. > > It doesn't always happen immediately. It's not quite reproducible. But it's close. > > Any idea what's going on? Logging in again will fix it. What is: - platform, SSSD version - in /etc/nsswitch.conf::passwd - what id_provider is used in sssd.conf? Did you try to run `getnet -s sss passwd ...` under strace?

2 1

sssd losing track of uid after existing kvm
by Charles Hedrick 09 Jan '24

09 Jan '24

We want to use user-mode kvm for students. I've set up a VM. It uses 9p to mount the user's home directory. After connecting to the VM with "virsh console", and then exiting, sssd on the host (not in the VM, in the main host) loses track of the user's UID. "getent passwd UNAME" works "getent passwd UID" does not, and "whoami" says cannot find name. It doesn't always happen immediately. It's not quite reproducible. But it's close. Any idea what's going on? Logging in again will fix it.

1 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

sssd-users January 2024