Using Flush on Change

One configuration setting, flush on change, may be useful for organizations that only care about user-account locking. Many ESMs will lock a user account after a certain number of failed attempts to sign on. If a user does sign on successfully after a failed attempt (but not so many attempts that the account is locked), then the count of failed attempts is reset to zero. For this to work with caching, the ESM must see the successful Verify request, which means it must not be retrieved from the cache.

The "flush on change" setting tells ESF to discard a cached Verify request if it sees a Verify request with a different result for the same user. For example, assuming Verify caching and flush-on-change are enabled:

• Bob signs on to his account. The request is sent to the ESM, and the result is cached.
• Bob signs off, then signs on again. The cache is used to validate this attempt.
• Bob signs off, then tries to sign on again, but mistypes his password. This doesn't match the cached request, so it's sent to the ESM. The ESM returns a "denied" result, and sets Bob's failed sign-on attempt count to 1.
• The flush-on-change setting sees this is a Verify request for Bob, but with a different result, so it removes the old successful Verify entry from the cache.
• Bob tries again, and types his password correctly this time. Since his previous attempt flushed his successful Verify from the cache, this request also goes to the ESM. The ESM returns an "allow" result and sets his failed count back to 0.

If flush-on-change had not been enabled, the final successful Verify would have been processed using the cache, and Bob's failed-attempt count would still be 1. If Bob repeated this pattern a few times, he'd be locked out, even though he'd signed on successfully between each failed attempt.