Re: loss of id / i have no name!

[sssd-bot]

Cloned from Pagure issue: https://pagure.io/SSSD/sssd/issue/3587

• Created at 2017-11-27 18:56:26 by tbeaudry
• Closed at 2020-03-24 14:03:14 as wontfix
• Assigned to nobody

---

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
#use_fully_qualified_names = 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.

Any help would be greatly appreciated! i have attacked my sssd_domain log. The user id was lost between 2:14 and 2:17pm

Comments

---

Comment from jhrozek at 2018-01-22 20:18:15

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?

---

Comment from pbrezina at 2020-03-13 15:14:35

Metadata Update from @pbrezina:

• Issue tagged with: Canditate to close

---

Comment from pbrezina at 2020-03-24 14:03:13

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.

---

Comment from pbrezina at 2020-03-24 14:03:15

Metadata Update from @pbrezina:

• Issue close_status updated to: wontfix
• Issue status updated to: Closed (was: Open)