here are the status codes from auth debug log, locked out is #3:
0 No Failure - Authentication was fine
1 Unexpected Credentials - Authentication was out of expected order (applies to NTLM)
2 Unknown User - User doesnt exist in directory.
3 Wrong Password - Bad password, can apply in other situations, see https://community.mcafee.com/t5/Web-Gateway/Two-Issues-Access-Denied-Log-Wrong-Password-Message/m-p/...
Actual Problem = Authentication.FailureReason
4 No Credentials - No credentials were sent (ignore if authentication hasnt failed -- NTLM)
5 No Server Available - Directory server MWG attempted to contact was not reachable.
6 Proxy Timeout - MWG was communicating with a resource and it took too long to get an answer.
7 Server Timeout - ?
8 Communication Error - Server that MWG was communicating with shut down the connection.
I'm probably missing the obvious here. Am I looking for Failure ID: 3 or Authentication failed: 3? Or something else? When I search the Auth.Debug.log files for Failure ID: 3 I am getting 32,000 hits but, if I am reading the logs correctly, these are failures to authenticate workstations (with a Failure Status: 1).
Hope you are doing well.
The user account has been automatically locked say because too many invalid logon attempts or password change attempts have been requested.
In case authentication fails MWG fills the property Authentication.FailureReason.ID. ID "3" is wrong password.
Say account name configured in windows domain membership is mwgappl,The account name you create on MWG is used, when MWG sends Authentication request to AD servers, so for all requests you will see mwgappl which is the computer name/account name configured on MWG when you configure windows domain membership.
It is the AD server which is locking out the user which may be say due to invalid user credentials being sent.
Please refer below link for more information on this:-
It is not web gateway which is locking the user out, it is the DC server which is doing it may be due to invalid credentials for a configured no of times.
MWG only forwards the users credentials what it receives from client to AD server for verification.
The bad password log file contains the authentication failure events which shows the URL and user name information. You can use this log file for further investigation.
Was my reply helpful?
If you find this post useful, Please give it a Kudos! Also, Please don't forget to select "Accept as a solution" if this reply resolves your query!
Please check in Web Gateway logs (access.log) the IP addresses for affected account name.
In our case it was a remote server session, which was not logged out. User changed password in AD from different computer, but those remote session tried to access Web Gateway with old password and was locking an account.
Gathering the IP address of all workstations where user was logged in, helped to identify which workstations was the problem.
If you have configured the Bad Password log on the gateways, you do not have to turn on authentication troubleshooting. The badpassword.log files will show only events that are returning error code 3 so you will only see authentication issues where accounts are locked out. It really helps in tracking down the IP address of the workstation with the bad creds.
Now, what I am testing and hope works, is having these logs offloaded to CSR so the helpdesk can track it down themselves.