Access logs display entries with 401 TCP_DENIED or 407 TCP_DENIED and no username is logged when NTLM authentication is enabled. There are many access log entries where the usernames that are missing and display as a dash "-" , but the ProxySG appliance is working as expected and users are not complaining of any access or authentication issues.
If you have NTLM authentication enabled, your access log will contain a large number of 401 or 407 TCP_DENIED messages. This is because the standard NTLM sequence to authenticate a user involves a several-stage negotiation process. Starting with NTLM SSP NEGOTIATE, then NTLM SSP CHALLENGE which triggers a 401 or 407 TCP_DENIED message. When you view the access log or perform a policy trace, this sequence looks like two failed attempts to authenticate followed by one successful attempt. If you are logging the username, it will appear as a dash "-" during the NEGOTIATE portion of the transaction, because the authentication is still incomplete and the username is not yet known.
Here is an example of the NTLM SSP negotiate, challenge, and authentication sequence:
The sequence above is what occurs when a client authenticates via NTLM. We see two failed authentication attempts followed by one that is successful. The failed attempts also will not contain a username. This is normal. The third request, which completed the NTLM authentication, the NTLM user shows up in the access log entry. Below is an example access log:
Modifying Logging to Suppress The First Two Log Entries
The following 2 line policy can be added to your existing local policy to suppress 407 responses from the main access log. If you are logging to a log other than main, substitute the name of the other log for main.
Paste the following policy into your local policy.
;;Remove access NTLM failure entries from access logging START