Description of problem: I am currently using LDAP id with sssd. After a while the system cannot get my user name. For exemple : $ id uid=1063 gid=100(users) for another user : $ id bruno uid=1008(bruno) gid=100(users) $ whoami whoami: cannot find name for user ID 1063 /var/log/secure : Nov 8 17:43:37 hera su: pam_succeed_if(su-l:account): error retrieving information about user 1063 Nov 8 17:43:37 hera su: pam_succeed_if(su-l:session): error retrieving information about user 1063 Nov 8 17:43:37 hera su: pam_unix(su-l:session): session opened for user root by paul(uid=1063) Nov 8 17:43:37 hera su: pam_xauth(su-l:session): error determining invoking user's name Nov 8 18:00:23 hera login: pam_unix(login:session): session opened for user root by LOGIN(uid=0) Nov 8 18:00:23 hera login: ROOT LOGIN ON tty2 Nov 8 18:01:17 hera sudo: 1063 : unknown uid: 1063 ; TTY=pts/1 ; PWD=unknown ; COMMAND=tail Version-Release number of selected component (if applicable): sssd 1.4.0-2.fc14 openldap-clients 2.4.23-2.fc14 How reproducible: - each time after a while Steps to Reproduce: 1. Configure sssd to use LDAP for id 2. Stay logged with one user session a while Actual results: id cannot get username So ssh, gnome-screensaver, and many more are broken.
Created attachment 458820 [details] sssd config
Could you modify your sssd.conf to set debug_level = 6 in the [domains/default] section, then restart sssd. Then next time you see the issue, could you attach /var/log/sssd/sssd_default.log I suspect your username is being purged from the cache for some reason, which it shouldn't be. Also, please yum install ldb-tools and send the output of: ldbsearch -H /var/lib/sss/db/cache_default.ldb uid=1063 Please do this once while it's valid, and again after it fails. I want to see the differences.
Created attachment 459451 [details] sssd log
ldbsearch return nothing with uid=1063, I used uidNumber=1063. Before : ldbsearch -H /var/lib/sss/db/cache_default.ldb uidNumber=1063 # record 1 dn: name=paul,cn=users,cn=default,cn=sysdb createTimestamp: 1289389172 gidNumber: 100 homeDirectory: /home/paul loginShell: /bin/zsh name: paul objectClass: user uidNumber: 1063 originalDN: uid=paul,ou=People,dc=clubnix,dc=org originalModifyTimestamp: 20090202163446Z shadowMin: 0 shadowMax: 99999 shadowWarning: 7 shadowInactive: -1 shadowExpire: -1 shadowFlag: 0 lastUpdate: 1289389172 dataExpireTimestamp: 1289394572 initgrExpireTimestamp: 1289394572 memberof: name=storage,cn=groups,cn=default,cn=sysdb memberof: name=optical,cn=groups,cn=default,cn=sysdb memberof: name=adm,cn=groups,cn=default,cn=sysdb memberof: name=cdrom,cn=groups,cn=default,cn=sysdb memberof: name=boinc,cn=groups,cn=default,cn=sysdb memberof: name=games,cn=groups,cn=default,cn=sysdb memberof: name=plugdev,cn=groups,cn=default,cn=sysdb memberof: name=audio,cn=groups,cn=default,cn=sysdb memberof: name=video,cn=groups,cn=default,cn=sysdb memberof: name=pulse-access,cn=groups,cn=default,cn=sysdb distinguishedName: name=paul,cn=users,cn=default,cn=sysdb # returned 1 records # 1 entries # 0 referrals after : # record 1 dn: name=paul,cn=users,cn=default,cn=sysdb createTimestamp: 1289389172 gidNumber: 100 homeDirectory: /home/paul loginShell: /bin/zsh name: paul objectClass: user uidNumber: 1063 originalDN: uid=paul,ou=People,dc=clubnix,dc=org originalModifyTimestamp: 20090202163446Z shadowMin: 0 shadowMax: 99999 shadowWarning: 7 shadowInactive: -1 shadowExpire: -1 shadowFlag: 0 lastUpdate: 1289389172 dataExpireTimestamp: 1289394572 initgrExpireTimestamp: 1289394572 memberof: name=storage,cn=groups,cn=default,cn=sysdb memberof: name=optical,cn=groups,cn=default,cn=sysdb memberof: name=adm,cn=groups,cn=default,cn=sysdb memberof: name=cdrom,cn=groups,cn=default,cn=sysdb memberof: name=boinc,cn=groups,cn=default,cn=sysdb memberof: name=games,cn=groups,cn=default,cn=sysdb memberof: name=plugdev,cn=groups,cn=default,cn=sysdb memberof: name=audio,cn=groups,cn=default,cn=sysdb memberof: name=video,cn=groups,cn=default,cn=sysdb memberof: name=pulse-access,cn=groups,cn=default,cn=sysdb distinguishedName: name=paul,cn=users,cn=default,cn=sysdb # returned 1 records # 1 entries # 0 referrals
(Wed Nov 10 14:59:33 2010) [sssd[be[default]]] [be_get_account_info] (4): Got request for [4097][1][idnumber=1063] (Wed Nov 10 14:59:33 2010) [sssd[be[default]]] [sdap_get_generic_send] (6): calling ldap_search_ext with [(&(uidNumber=1063)(objectclass=posixAccount))][dc=clubnix,dc=org]. (Wed Nov 10 14:59:33 2010) [sssd[be[default]]] [sdap_get_generic_done] (6): Search result: Success(0), (null) (Wed Nov 10 14:59:33 2010) [sssd[be[default]]] [sdap_get_users_process] (6): Search for users, returned 3 results. (Wed Nov 10 14:59:33 2010) [sssd[be[default]]] [sdap_save_user] (6): Storing info for user paul (Wed Nov 10 14:59:33 2010) [sssd[be[default]]] [sdap_save_user] (6): Storing info for user antirux (Wed Nov 10 14:59:33 2010) [sssd[be[default]]] [sdap_save_user] (6): Storing info for user aristotv You have three different users in LDAP that each have the UID 1063. This is not a supportable configuration, because if we look up the UID, we have no idea which one of those users it's intended to map to. Right now, we're throwing an internal error when we look up in the cache and discover that there is more than one entry with that UID for this domain. I've opened https://fedorahosted.org/sssd/ticket/675 upstream to make this less ambiguous. We shouldn't be storing multiple entries with the same UID. However, be aware that once this is fixed, only the first user to log in with that UID will be allowed access. It is much better to fix your LDAP configuration.
Thanks for the catch, indeed the LDAP was broken.
*** Bug 651026 has been marked as a duplicate of this bug. ***