Changed passwords in AD seem to take a long time to be seen on sssd-integrated servers?

[Spike White]

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