Replay Behavior setting

One thing we have not yet considered is what behavior should occur when a two-factor authentication attempt is a non-allowed replay. In old installations, AuthLite will force the authentication to fail right at the DC, and return an error message. This behavior was only the default for historical reasons, however it is unlikely to be the way you want to keep it.

There are many situations where credentials are stored and sent repeatedly by well-meaning client software. Each time you authenticate to a new NTLM resource, the credentials you entered at login-time are being sent AGAIN to the server. For one-factor passwords this is a detail you never need to think about, but with one-time credentials it can be a problem. If several stale credential attempts are made in a short interval, the account could get locked out even though the user hasn't done anything wrong.

So here is where we come to the Replay Behavior configuration. You can tell AuthLite that when a two-factor authentication is rejected as a replay, to discard the OTP and try again as if it was a simple one-factor logon instead. This allows services that don't need 2-factor security to tolerate seeing stale 2-factor credentials, and treat them as if they were just normal one-factor password-only logons.

This is the new default for recent installations. It effectively puts off the decision about whether to block the logon until later. If there's a group policy blocking a 1-factor Tag group, or the authentication is coming from a Forced 2-factor Computer, or on a Forced 2-Factor Process, then it will be blocked. But if all those things are false, then you are effectively saying that for this server/process/resource you don't need two-factor authentication, and the 1-factor logon will be allowed.

Some customers mistakenly set this setting to “Fail” because they believe it's the only way that 2-factor will ever be enforced. But really it just makes the authentication fail so soon that most of the more nuanced enforcement mechanisms will never be reached. It's a sledgehammer setting that is almost never appropriate for a modern installation.

This setting does not decrease security, and all your two-factor policies and security settings will still apply the same way; it is simply a new feature designed to make life easier to authenticate to non-secure services, and prevent accidental lockouts.