On Mon, Oct 21, 2019 at 08:48:48PM -0500, Spike White wrote:
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:
entry_cache_nowait_percentage = 75
cache_credentials = True
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: pam_sss(sshd:auth): authentication
failure; logname= uid=0 euid=0 tty=ssh ruser= rhost=10.185.116.129
Oct 21 19:50:16 acmappdev01 sshd: 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: pam_sss(sshd:auth): authentication
success; logname= uid=0 euid=0 tty=ssh ruser= rhost=10.185.116.129
Oct 21 20:15:40 acmappdev01 sshd: 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
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
sssd-users mailing list -- sssd-users(a)lists.fedorahosted.org
To unsubscribe send an email to sssd-users-leave(a)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