SSP+AD : How to flush local password cache on windows workstations?

[necarnot]

Hello,

We're happily running SSP here with mostly windows user hosts and some few Linux hosts [1], plugged in a microsoft active directory.
This all is working fine.
But...
According to what we've witnessed, and according to our readings, the following situation is happening, and seems not only related to SSP, but also to a broader audience :

When on promise, a user is logged in her windows account and session. She uses SSP and changes her password. This change is directly effective in active directory. But the local cached credential in her host is not changed.
The local cache will never be synced until an authentication challenge occurs between the user's host and the AD, which can mostly occur in two common ways : logging and re-logging her session, or locking and unlocking her screen. Both ways are triggering an auth challenge, AND forcing a local cache flush.

Doing no such challenge leads to a local password kept unchanged forever (though a offline default limit of 10 login attempts exist).

Reading along the internet resources, this issue is not specific to SSP, as other similar products are facing the same issue. People who are managing this situation tend to advice their users to lock+unlock their screen right after having reset their password.
One can easily forecast 4 users out of 5 will forget this step, so poor advice.

Why is all this an issue, may you ask?
Well, this case is an issue when the way to connect to a network depends on the correct synchronisation of the password known by the directory and the one used by the user host :

• VPN
• Radius
• you name it...

So how do you deal with the urge to sync the local credential as soon as the directory password has changed?

[1] These Linux hosts are using sssd, which seems to manage caching and credentials refresh in a correct way.

[davidcoutadeur]

Hello @necarnot

Syncing the local credential is quite specific to windows, and out of the action scope of self-service-password.

Locking screen and logging again seem to be bad solutions. The best would be to have a system implemented at Windows side to trigger the credential flush, callable by the browser or any other mean (API ?)

As far as I know, there is no such system. If you find out a way to trigger this credential sync, we could maybe implement it in self-service-password, but for now I don't see any solution.

Regards