Is here no one who can help me? Especially the supporters from McAfee...
Or does no one understand my question?
How can i analyse which PC causes the authentication attempts with wrong password?
I am sorry, there is no logging for failed authentication attempts on the Web Gateway.
Can you let us know which user is locked out? Web Gateway usually should create itself a Computer Account within the Domain and use this to communicate with the Domain Controller, and for authenticating requests. Is this account being disabled?
not the MWG computer account is disabled.
A windows user account is beeing locked out coz too many attempts with wrong password.
For example in Acrobat Update a user uses a wrong password and the Update Tool tries permanently to log on at MWG. Then the windows account will be disabled after 20 attempts.
Coz i cannot see from which PC the authentication attempts are started there is no chance to help the user.
For example if i a "bad" user uses wrong credentiels of the boss and this account will be locked out permamently i am not able to analyse on which PC this misconfiguration is done. My boss will not be amused :-(
In windows event log "security" i can only see that the MWG (the Copmuter Account of the MWG is show here) tries to log on the user with wrong password and the user is locked out.
So my question is how can i see in MWG log files which PC causes these failed attempts?
Or how would you start analysing this situation?
thank you, I think I better understand now. Unfortunately it is true that all authentication requests are created by MWG, so this is most likely all you can grab from the Domain Controllers logs. Web Gateway itself does not have a logfile to log failed attempts for native NTLM authentication. The problem with the Access.log is that Usernames only show up once the authentication was successful, therefore they are not helping as well.
The Adobe Updates is know to cause such issues, therefore it is a common practice in support to skip authentication for requests from the Adobe Updater. Of course this does not solve the root cause in this case.
I am afraid but I think the only possibility to detect who is causing by running a packet capture. It is required to find the Client IP address which is sending a GET request which contains an NTLM string for the User Account that is abused. This is not an easy task, but it should be possible to determine the Client IP in this case.
After you have captured some of the HTTP traffic, you can basically display all GET requests where a specific Username has been provided. Ax example filter may be:
tcp.port eq 8080 and ntlmssp.messagetype eq NTLMSSP_AUTH and ntlmssp.auth.username eq "adminsitrator"
It is important that Wireshark knows that the destination Port is HTTP. if you are using a none-default port you can right click any packet which has your proxy port as the destination port and use "Decode as -> Transport -> HTTP" to apply this. After that has been done you can apply the above filters.
I am not sure if that helps, but I do not see a different way to see who is sending the requests.
thanks a lot for your answer.
The way you show in your answer - analysing the traffic with wireshark - sounds good.
There is a workaround to "log" the ip address of a user who failed to authenticate.
Within the authentication rule on the "Events" you can configure an event to send SNMP traps to a snmp server (Corporate NMS) every time a user fails to authenticate. In the trap you can log the user ip, see below
I think it's easier to track the user ip this way.
thanks for your answer. But we are using MWG Version 6. So this solution does not work for our system.
Sorry, I saw it after my answer.
Anyway you should thing about passing to MWG7.1, I thing you can download it for free and you can use the old license as well. So, you need no budget but effort and you got it all.