Bug 651028
| Summary: | Cannot find username after a while - LDAP id | ||||||||
|---|---|---|---|---|---|---|---|---|---|
| Product: | [Fedora] Fedora | Reporter: | Paul Ezvan <paul> | ||||||
| Component: | sssd | Assignee: | Stephen Gallagher <sgallagh> | ||||||
| Status: | CLOSED NOTABUG | QA Contact: | Fedora Extras Quality Assurance <extras-qa> | ||||||
| Severity: | high | Docs Contact: | |||||||
| Priority: | low | ||||||||
| Version: | 14 | CC: | jhrozek, sbose, sgallagh, ssorce | ||||||
| Target Milestone: | --- | ||||||||
| Target Release: | --- | ||||||||
| Hardware: | x86_64 | ||||||||
| OS: | Linux | ||||||||
| Whiteboard: | |||||||||
| Fixed In Version: | Doc Type: | Bug Fix | |||||||
| Doc Text: | Story Points: | --- | |||||||
| Clone Of: | Environment: | ||||||||
| Last Closed: | 2010-12-23 18:41:03 UTC | Type: | --- | ||||||
| Regression: | --- | Mount Type: | --- | ||||||
| Documentation: | --- | CRM: | |||||||
| Verified Versions: | Category: | --- | |||||||
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |||||||
| Cloudforms Team: | --- | Target Upstream Version: | |||||||
| Embargoed: | |||||||||
| Attachments: |
|
||||||||
|
Description
Paul Ezvan
2010-11-08 17:10:21 UTC
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. *** |