NOTE: Collective has a separate ISA 2006/TMG filter called LockoutGuard, which operates with the built-in web publishing authentication. This article refers to the older 2004 filter FlexAuth feature of the same name.

FlexAuth LockoutGuard works by detecting when a user account is one attempt away from lockout. When that is the case, it instructs FlexAuth not to try the login any more, but simply return the "login failed" message.

In this manner, the account can not ever be locked out through FlexAuth, and the user has (at least) one try to log in via some other means, i.e. local desktop, etc.

It is a system designed to prevent a lockout "denial of service" by a malicious outside party purposefully causing accounts to be locked out remotely.

Note that when LockoutGuard has gone into effect, there is still not a way to log in through FlexAuth of course, until the lockout count is reset by Active Directory. That occurs after the AD timeout period, or upon a successful authentication by the user.

If all that is confusing, just think of it in the following simplified way: LockoutGuard causes a "meta lockout" to occur one attempt before "real lockout" would occur. This provides the following advantages:

  • Brute forcing of accounts is still thwarted, via the same mechanism that normal AD lockouts employ
  • A local login (inside the LAN, or via vpn) on the account is still possible, since the lower LockoutGuard threshold prevents actual lockout from an remote internet-based attacker.

Thus, LockoutGuard does not in any way compromise the security of the AD lockout scheme. However depending what your needs are, it may not be right for your network.

Please note that there is a known issue regarding LockoutGuard and multiple domains. Basically: the lockoutguard will work for the domain your ISA is a member of, (or the domain the LDAP server is a member of), but it will fail to offer additional protection for other domains in the forest. For those other accounts, normal lockout is still possible.