cached_auth_timeout not honored for AD users authenticated via trust with FreeIPA #4933

sssd-bot · 2020-05-02T13:56:16Z

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

Created at 2019-02-18 11:29:39 by plumbeo
Closed at 2019-03-26 22:13:05 as Fixed
Assigned to jhrozek
Associated bugzillas
- https://bugzilla.redhat.com/show_bug.cgi?id=1685581

We set up a trust between the FreeIPA server and our AD, and we can correctly authenticate both AD users and FreeIPA users on the clients, but when we enabled cached_auth_timeout on the clients we noticed that the setting is not being honored for AD users, while it's working as expected for users defined in FreeIPA.

$ ssh freeipa-user@test76
Password: 
Last login: Fri Feb 15 16:53:28 2019 from 172.22.9.28
[freeipa-user@test74 ~]$ exit
logout
Connection to test74 closed.
$ ssh freeipa-user@test74
Password: 
Authenticated with cached credentials.
Last login: Mon Feb 18 10:00:42 2019 from 172.22.9.28

$ ssh ad-user@test74
Password: 
Last login: Fri Feb 15 16:54:22 2019 from 172.22.9.28
[ad-user@test74 ~]$ exit
logout
Connection to test74 closed.
$ ssh ad-user@test74
Password: 
Last login: Mon Feb 18 09:59:40 2019 from 172.22.9.28

But if we force the backed offline by blocking traffic directed to the FreeIPA server on the client firewall:

$ ssh ad-user@test74
Password: 
Authenticated with cached credentials.
Last login: Mon Feb 18 11:12:21 2019 from 172.22.9.28
[ad-user@test74 ~]$

This is our sssd.conf:

sssd.conf:

[domain/freeipa.example.com]
cached_auth_timeout = 3600
cache_credentials = True
krb5_store_password_if_offline = True
krb5_auth_timeout = 60
ipa_domain = freeipa.example.com
id_provider = ipa
auth_provider = ipa
access_provider = ipa
ipa_hostname = test74.freeipa.example.com
chpass_provider = ipa
dyndns_update = True
ipa_server = srv, freeipa-master.freeipa.example.come
dyndns_iface = enp0s3
ldap_tls_cacert = /etc/ipa/ca.crt
[sssd]
services = nss, sudo, pam, ssh

domains = freeipa.example.com
[nss]
homedir_substring = /home

[pam]
pam_verbosity = 2
[sudo]

[autofs]

[ssh]

[pac]

[ifp]

[secrets]

[session_recording]

We're running FreeIPA 4.6.4 on CentOS 7.6.1810 on our FreeIPA server and SSSD 1.16.2 on our clients (both Ubuntu and CentOS):

server:

libipa_hbac-1.16.2-13.el7.x86_64
sssd-krb5-common-1.16.2-13.el7.x86_64
python2-ipaserver-4.6.4-10.el7.centos.noarch
sssd-ldap-1.16.2-13.el7.x86_64
ipa-client-4.6.4-10.el7.centos.x86_64
python-iniparse-0.4-9.el7.noarch
sssd-common-pac-1.16.2-13.el7.x86_64
sssd-proxy-1.16.2-13.el7.x86_64
ipa-server-trust-ad-4.6.4-10.el7.centos.x86_64
sssd-tools-1.16.2-13.el7.x86_64
python2-ipaclient-4.6.4-10.el7.centos.noarch
ipa-server-common-4.6.4-10.el7.centos.noarch
sssd-dbus-1.16.2-13.el7.x86_64
python-ipaddress-1.0.16-2.el7.noarch
ipa-server-4.6.4-10.el7.centos.x86_64
python-libipa_hbac-1.16.2-13.el7.x86_64
python2-ipalib-4.6.4-10.el7.centos.noarch
sssd-ipa-1.16.2-13.el7.x86_64
ipa-client-common-4.6.4-10.el7.centos.noarch
sssd-common-1.16.2-13.el7.x86_64
sssd-ad-1.16.2-13.el7.x86_64
sssd-1.16.2-13.el7.x86_64
ipa-server-dns-4.6.4-10.el7.centos.noarch
ipa-common-4.6.4-10.el7.centos.noarch
python-sssdconfig-1.16.2-13.el7.noarch
sssd-client-1.16.2-13.el7.x86_64
sssd-krb5-1.16.2-13.el7.x86_64

clients:

sssd-common-pac-1.16.2-13.el7_6.5.x86_64
sssd-ldap-1.16.2-13.el7_6.5.x86_64
sssd-client-1.16.2-13.el7_6.5.x86_64
python2-ipalib-4.6.4-10.el7.centos.2.noarch
sssd-krb5-common-1.16.2-13.el7_6.5.x86_64
sssd-ipa-1.16.2-13.el7_6.5.x86_64
sssd-krb5-1.16.2-13.el7_6.5.x86_64
sssd-proxy-1.16.2-13.el7_6.5.x86_64
ipa-client-4.6.4-10.el7.centos.2.x86_64
python-iniparse-0.4-9.el7.noarch
ipa-common-4.6.4-10.el7.centos.2.noarch
ipa-client-common-4.6.4-10.el7.centos.2.noarch
python-sssdconfig-1.16.2-13.el7_6.5.noarch
python-libipa_hbac-1.16.2-13.el7_6.5.x86_64
sssd-common-1.16.2-13.el7_6.5.x86_64
sssd-ad-1.16.2-13.el7_6.5.x86_64
sssd-1.16.2-13.el7_6.5.x86_64
python-ipaddress-1.0.16-2.el7.noarch
libipa_hbac-1.16.2-13.el7_6.5.x86_64

Comments

Comment from jhrozek at 2019-02-21 12:50:13

Does it help to create a subsection for your trusted AD domain and add the parameter there?

[domain/freeipa.example.com/ad.example.com]
cached_auth_timeout = 3600

?

Comment from plumbeo at 2019-02-21 13:38:36

Does it help to create a subsection for your trusted AD domain and add the parameter there?
[domain/freeipa.example.com/ad.example.com]
cached_auth_timeout = 3600
?

It didn't. I added both cached_auth_timeout and cache_credentials in a subsection but there was no difference.

Another thing that I noticed is that sssctl user-show behaves differently for FreeIPA users and AD users:

# sssctl user-show freeipa-user
Name: freeipa-user
Cache entry creation date: 02/21/19 13:27:26
Cache entry last update time: 02/21/19 13:27:35
Cache entry expiration time: 02/21/19 14:57:35
Initgroups expiration time: 02/21/19 14:57:35
Cached in InfoPipe: No
# sssctl user-show freeipa-user@freeipa.example.com
Name: freeipa-user
Cache entry creation date: 02/21/19 13:27:26
Cache entry last update time: 02/21/19 13:27:35
Cache entry expiration time: 02/21/19 14:57:35
Initgroups expiration time: 02/21/19 14:57:35
Cached in InfoPipe: No

But:

# sssctl user-show ad-user
User ad-user is not present in cache.
# sssctl user-show ad-user@ad.example.com
Name: ad-user
Cache entry creation date: 02/21/19 13:21:17
Cache entry last update time: 02/21/19 13:28:24
Cache entry expiration time: 02/21/19 14:58:24
Initgroups expiration time: 02/21/19 14:58:24
Cached in InfoPipe: No

I don't know if it's important, for what it's worth caching doesn't seem to work even if I login using username+ad domain name, ie: ssh 'ad-user@ad.example.com'@test76.

Comment from jhrozek at 2019-03-01 21:21:21

You are right that this is a bug. Sorry about the delay.

Comment from jhrozek at 2019-03-01 21:21:34