#3587 Re: loss of id / i have no name!
Closed: wontfix 4 years ago by pbrezina. Opened 6 years ago by tbeaudry.

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


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

4 years ago

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)

4 years ago

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.

Thank you for understanding. We apologize for all inconvenience.

Login to comment on this ticket.

Metadata