I've run into this issue a number of times and it usually ends up being the Credential Manager on the workstation. Clearing that out will usually resolve the issue for the user.
If you wanted to track something like this, I created a log which will look for the generic "bad password" event, see this thread:
Also it is worth noting that the Authentication.FailureID is the same (3) for different type of events (Re: Two Issues: Access Denied Log & Wrong Password Message):
Actual Problem = Authentication.FailureReason
Wrong password = Wrong password
Locked out = Wrong password
Password expired = Wrong password
Not allowed computer = Wrong password
Did this work for you? I saw you liked it. I have posted this information a number of times, but didnt get much feedback.
My apologies, Jon. i assumed I would have been able to mark this as an answer. While your advice did help a lot, it seemed like that particular user account had some issues. Also, when I observe the rule engine trace, I see that there are multiple authentication steps for a web request. I'd take a screenshot but my MWG appliance is currently down for some network reconfiguration. I have only one Authenticate With User Database rule so I'm not sure why I see two authenticate steps. I think that may have contributed to the account lockouts.
That might be a red herring
It is important to understand that NTLM authentication is a three step process, this is what you see in the rule traces.
The steps for MWG to authenticate a user are NEGOTIATE, CHALLENGE, AUTHENTICATE. So whenever you run a ruletrace or tcpdump, you will always see three requests before MWG allows it.
I have examples on this Best Practice:
We had a few users who experienced constant account lockouts when using MWG and NTLM authentication. Using our SIEM tool, we could see that it was the Alkami Network Interface on the end users computer that was locking the account.
We got on the users computer and disabled it and this fixed their issue. (Start - Run - msconfig - uncheck alkami - reboot).