All,
Users are complaining when they change their passwords in AD, it's taking an excessive amount of time to be reflected on their sssd-integrated Linux servers. Temporarily, they are denied access to their boxes.
These are boxes they log into frequently, so I'm guessing their Posix attributes are read from cache. (Does this include their password)?
I'm setting only these cache settings in the sssd.conf file:
[nss] entry_cache_nowait_percentage = 75 ... [domain/xxx] ... cache_credentials = True
Here's the entry that's being reported (in /var/log/secure). The user reports that he waits 15 - 20 mins after changing his password in AD before attempting to ssh in:
Oct 21 19:50:16 acmappdev01 sshd[9817]: pam_sss(sshd:auth): authentication failure; logname= uid=0 euid=0 tty=ssh ruser= rhost=10.185.116.129 user=gudar1 Oct 21 19:50:16 acmappdev01 sshd[9817]: pam_sss(sshd:auth): received for user gudar1: 6 (Permission denied)
After 20 - 30 mins, the problem goes away without any intervention.
Oct 21 20:15:40 acmappdev01 sshd[11326]: pam_sss(sshd:auth): authentication success; logname= uid=0 euid=0 tty=ssh ruser= rhost=10.185.116.129 user=gudar1 Oct 21 20:15:40 acmappdev01 sshd[11326]: Accepted password for gudar1 from 10.185.116.129 port 49954 ssh2
I realize it can take up to 30 mins for a changed password to fully replicate in AD globally.
But what settings in sssd determine how long passwords are stored in cache?
I see entry_cache_timeout, which has a default of 5400 seconds. (1.5 hrs). Should I set entry_cache_user_timeout to something lower -- say 15 mins?
Spike
On Mon, Oct 21, 2019 at 08:48:48PM -0500, Spike White wrote:
All,
Users are complaining when they change their passwords in AD, it's taking an excessive amount of time to be reflected on their sssd-integrated Linux servers. Temporarily, they are denied access to their boxes.
These are boxes they log into frequently, so I'm guessing their Posix attributes are read from cache. (Does this include their password)?
I'm setting only these cache settings in the sssd.conf file:
[nss] entry_cache_nowait_percentage = 75 ... [domain/xxx] ... cache_credentials = True
Hi,
cached credentials are by default only used for offline authentication (there is cached_auth_timeout but this is dusabled by default, see man sssd.conf for details).
So, as long as SSSD is online SSSD will always try to authenticate against and AD DC. Additionally, SSSD can only add the new password to the cache if there was a successful online authentication with the new password, since it is not possilbe to read password from AD, especially not the clear text ones.
Here's the entry that's being reported (in /var/log/secure). The user reports that he waits 15 - 20 mins after changing his password in AD before attempting to ssh in:
Oct 21 19:50:16 acmappdev01 sshd[9817]: pam_sss(sshd:auth): authentication failure; logname= uid=0 euid=0 tty=ssh ruser= rhost=10.185.116.129 user=gudar1 Oct 21 19:50:16 acmappdev01 sshd[9817]: pam_sss(sshd:auth): received for user gudar1: 6 (Permission denied)
It would be good to see SSSD logs for this case with debug_level=9 in the [pam] and [domain/...] section.
Is the old password still accepted during this time?
Are you using read-only domain controllers (RODC)?
After 20 - 30 mins, the problem goes away without any intervention.
Oct 21 20:15:40 acmappdev01 sshd[11326]: pam_sss(sshd:auth): authentication success; logname= uid=0 euid=0 tty=ssh ruser= rhost=10.185.116.129 user=gudar1 Oct 21 20:15:40 acmappdev01 sshd[11326]: Accepted password for gudar1 from 10.185.116.129 port 49954 ssh2
I realize it can take up to 30 mins for a changed password to fully replicate in AD globally.
Iirc AD DCs can figure out if a password was changed even if the new one is not replicated to the DC yet. For this they can reach out to a dedicated DC in the domain (FSMO or operation master) to check a password which is considered invalid on the DC.
To better understand what is happening the logs might help. Maybe it is just timeout because reaching out to the dedicated DC takes too long? In this case increasing krb5_auth_timeout might help, see man sssd-krb5 for details.
bye, Sumit
But what settings in sssd determine how long passwords are stored in cache?
I see entry_cache_timeout, which has a default of 5400 seconds. (1.5 hrs). Should I set entry_cache_user_timeout to something lower -- say 15 mins?
Spike
sssd-users mailing list -- sssd-users@lists.fedorahosted.org To unsubscribe send an email to sssd-users-leave@lists.fedorahosted.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedorahosted.org/archives/list/sssd-users@lists.fedorahosted.o...
sssd-users@lists.fedorahosted.org