#3900 after upgrade, my session forgets who I am frequently
Closed: duplicate 5 years ago Opened 5 years ago by lschiere.

Per https://bugs.launchpad.net/ubuntu/+source/sssd/+bug/1807246

I configured sssd on an Ubuntu 16.04 LTS system, and it worked just fine. In fact, using the same sssd.conf file (which is managed by puppet) on un-upgraded system continues to work fine.

However, after upgrading to ubuntu 18.04.1 LTS, I find that the system is continuously forgetting who I am. After a few commands, or a few minutes (I'm not sure exactly how many, but around 3-5 minutes) if I try to run sudo or whoami, it says that I am an unknown user. for example,

whoami
whoami: cannot find name for user ID 2000: Unknown error 1432158300

if I run the id command on my username, it returns the correct results, and whoami/sudo/other restricted commands will work again for a short time before forgetting who I am again.

In the sssd_nss.log file, I see the lookup against the @local domain, but I do not see a related lookup in the ldap domain either in that log file or in the log file specific to the ldap domain.

[domain/schierer]
debug_level = 6
id_provider = ldap
enumerate = true
auth_provider = ldap
ldap_schema = rfc2307bis
ldap_uri = ldap://censor001.<domain>
ldap_search_base = ou=schierer,dc=....
ldap_tls_reqcert = allow
cache_credentials = true
use_fully_qualified_names = true

luke@schierer@talemludum001:~$
```

I'll try manipulating other cache timeouts, but I think it important to note that this config works on the 16.x LTS.

I changed enum_cache_timeout to 600 and set entry_cache_timeout = 200 in the [domain/schierer] section of the above sssd.conf file. Despite that, it still starts stating I am unknown around 320 seconds ( I have 316 seconds worth of successful "whoami ; sleep 10s" loop iterations, I know it took a couple of seconds to type that loop up and hit enter from when I initially ran the id command.)


odd, it seems to have dropped some of the text I included.

I have verified there is no overlap in UIDs.

it apparently forgets around 5 minutes:

luke@schierer@talemludum001:~$ !id
id luke@schierer
uid=2000(luke@schierer) gid=100(users) groups=100(users),2(bin),200,3(sys),10(uucp),60(games),4(adm),50(staff),27(sudo),40(src),37(operator),6(disk),110(uuidd),1(daemon),102(systemd-network),24(cdrom),29(audio)
luke@schierer@talemludum001:~$ for i in `seq 1 1000`; do date; whoami; sleep 10s; done
Fri Dec  7 07:52:19 EST 2018
luke@schierer
Fri Dec  7 07:52:29 EST 2018
luke@schierer
Fri Dec  7 07:52:39 EST 2018
luke@schierer
Fri Dec  7 07:52:49 EST 2018
luke@schierer
Fri Dec  7 07:52:59 EST 2018
luke@schierer
Fri Dec  7 07:53:09 EST 2018
luke@schierer
Fri Dec  7 07:53:19 EST 2018
luke@schierer
Fri Dec  7 07:53:29 EST 2018
luke@schierer
Fri Dec  7 07:53:39 EST 2018
luke@schierer
Fri Dec  7 07:53:49 EST 2018
luke@schierer
Fri Dec  7 07:53:59 EST 2018
luke@schierer
Fri Dec  7 07:54:09 EST 2018
luke@schierer
Fri Dec  7 07:54:19 EST 2018
luke@schierer
Fri Dec  7 07:54:29 EST 2018
luke@schierer
Fri Dec  7 07:54:39 EST 2018
luke@schierer
Fri Dec  7 07:54:49 EST 2018
luke@schierer
Fri Dec  7 07:54:59 EST 2018
luke@schierer
Fri Dec  7 07:55:09 EST 2018
luke@schierer
Fri Dec  7 07:55:19 EST 2018
luke@schierer
Fri Dec  7 07:55:29 EST 2018
luke@schierer
Fri Dec  7 07:55:39 EST 2018
luke@schierer
Fri Dec  7 07:55:49 EST 2018
luke@schierer
Fri Dec  7 07:55:59 EST 2018
luke@schierer
Fri Dec  7 07:56:09 EST 2018
luke@schierer
Fri Dec  7 07:56:19 EST 2018
luke@schierer
Fri Dec  7 07:56:29 EST 2018
luke@schierer
Fri Dec  7 07:56:39 EST 2018
luke@schierer
Fri Dec  7 07:56:49 EST 2018
luke@schierer
Fri Dec  7 07:56:59 EST 2018
luke@schierer
Fri Dec  7 07:57:09 EST 2018
whoami: cannot find name for user ID 2000: Unknown error 1432158300
Fri Dec  7 07:57:19 EST 2018
whoami: cannot find name for user ID 2000: Unknown error 1432158300
^C
luke@schierer@talemludum001:~$ 

a redacted sssd.conf (for domain names and such)

luke@schierer@talemludum001:~$ sudo cat /etc/sssd/sssd.conf
# Managed by Puppet.

[sssd]
services = nss, pam, sudo
domains = local, bramlet, ciziunas, schierer

[nss]
debug_level = 6
enum_cache_timeout = 300

[domain/local]
id_provider = local
enumerate = true
max_id = 1000

[domain/bramlet]
id_provider = ldap
enumerate = true
auth_provider = ldap
ldap_schema = rfc2307bis
ldap_uri = ldap://censor001.<domain>
ldap_search_base = ou=bramlet,dc=....
ldap_tls_reqcert = allow
cache_credentials = true
use_fully_qualified_names = true

[domain/ciziunas]
id_provider = ldap
enumerate = true
auth_provider = ldap
ldap_schema = rfc2307bis
ldap_uri = ldap://censor001.<domain>
ldap_search_base = ou=ciziunas,....
ldap_tls_reqcert = allow
cache_credentials = true
use_fully_qualified_names = true

[domain/schierer]
debug_level = 6
id_provider = ldap
enumerate = true
auth_provider = ldap
ldap_schema = rfc2307bis
ldap_uri = ldap://censor001.<domain>
ldap_search_base = ou=schierer,dc=....
ldap_tls_reqcert = allow
cache_credentials = true
use_fully_qualified_names = true

luke@schierer@talemludum001:~$ 

I'll try manipulating other cache timeouts, but I think it important to note that this config works on the 16.x LTS.

Can you try dropping the local domain or at least the min_id from the local domain for a test?

There was a bug in one of the recent releases where if requested ID was outside of a domain range, other domains were not even tried.

But since you didn't include which sssd versions you are running, I don't know if you would be hit by that. And I don't know what ubuntu versions carry which upstream versions. The bug I'm thinking is #3728 fixed in 1.16.2

Sorry, I assumed you'd know what versions ubuntu had.

1.16.1-1ubuntu1 is bad.
1.13.4-1ubuntu1.12 is good

Then I guess it's upstream #3728. I would suggest to either ask Ubuntu to backport the fix or remove the id limits as a temporary workaround.

I'm going to close this ticket, please reopen if either does not help.

Metadata Update from @jhrozek:
- Issue close_status updated to: duplicate
- Issue status updated to: Closed (was: Open)

5 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/4885

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