Learn more about these different git repos.
Other Git URLs
Hi,
I have repeated issues with users losing their usernames (only being mapped to their uid / in the terminal it says "i have no name!@host"). It doesn't happen daily, but it is extremely frustrating because they are running scientific pipelines that take a few hours to several days to complete, and as soon as their name is lost, it fails and the pipeline has to start from scratch.
My setup is as follows.
Client: Ubuntu 16.04
Server: Windows AD, with a Windows NFS file server.
What i don't understand is that if a user is successfully able to authenticate, why isn't the account cached, and used for their entire session? How can a name be lost if it is cached. I have the following in my sssd.conf:
[autofs] debug_level=10
[krb5] debug_level=10
[nss] filter_groups = root filter_users = root reconnection_retries = 3 debug_level=10
[pam] reconnection_retries = 3 debug_level=10
[sssd] domains = domain.ca config_file_version = 2 services = nss, pam, ssh, autofs debug_level=10
[domain/domain.ca] ad_domain = domain.ca krb5_realm = DOMAIN.CA realmd_tags = manages-system joined-with-adcli cache_credentials = True id_provider = ad krb5_store_password_if_offline = True default_shell = /bin/bash ldap_id_mapping = True
override_homedir = /NAS/home/%u fallback_homedir = /home/%u access_provider = simple debug_level=10 ignore_group_members=True simple_allow_groups = perform_hpc
I have had this issue for quite awhile, so upon a previous sssd users suggestion, i disabled reverse DNS and it seemed to make this occur less often, but as far as I can tell my DNS is setup properly. I can do a nslookup <host> and get the proper ip address, and vice versa.
nslookup <host>
Any help would be greatly appreciated! i have attacked my sssd_domain log. The user id was lost between 2:14 and 2:17pm
It is embarassing that we didn't reply to this issue sooner. I reviewed the logs from sssd-users again, but I'm afraid I need some help. At one point, the ID conversion fails:
(Fri Oct 20 14:04:27 2017) [sssd[be[domain.ca]]] [be_get_account_info] (0x0200): Got request for [0x1001][FAST BE_REQ_USER][1][idnumber=891461586] (Fri Oct 20 14:04:27 2017) [sssd[be[domain.ca]]] [be_req_set_domain] (0x0400): Changing request domain from [domain.ca] to [domain.ca] (Fri Oct 20 14:04:27 2017) [sssd[be[domain.ca]]] [ad_account_can_shortcut] (0x0080): Mapping ID [891461586] to SID failed: [IDMAP domain not found] (Fri Oct 20 14:04:27 2017) [sssd[be[domain.ca]]] [users_get_send] (0x0080): [891461586] did not match any configured ID mapping domain
Per the reporter, this is the ID that intermittently works for one user. But then I see the same user is happily saved to the domain:
(Fri Oct 20 14:17:04 2017) [sssd[be[domain.ca]]] [sdap_save_user] (0x1000): Mapping user [j_huc] objectSID [S-1-5-21-2025429265-616249376-725345543-2461586] to unix ID
And at least looking at the RID value, it indeed sounds like this is the same ID.
@sbose can you suggest what would be the next thing to look at? The ID range object from the cache maybe?
Metadata Update from @pbrezina: - Issue tagged with: Canditate to close
Thank you for taking time to submit this request for SSSD. Unfortunately this issue was not given priority and the team lacks the capacity to work on it at this time.
Given that we are unable to fulfill this request I am closing the issue as wontfix.
If the issue still persist on recent SSSD you can request re-consideration of this decision by reopening this issue. Please provide additional technical details about its importance to you.
Thank you for understanding.
Metadata Update from @pbrezina: - Issue close_status updated to: wontfix - Issue status updated to: Closed (was: Open)
SSSD is moving from Pagure to Github. This means that new issues and pull requests will be accepted only in SSSD's github repository.
This issue has been cloned to Github and is available here: - https://github.com/SSSD/sssd/issues/4611
If you want to receive further updates on the issue, please navigate to the github issue and click on subscribe button.
subscribe
Thank you for understanding. We apologize for all inconvenience.
Login to comment on this ticket.