ProxySG appliance access logs show 401 TCP_DENIED or 407 TCP_DENIED and no username is logged when NTLM is enabled
search cancel

ProxySG appliance access logs show 401 TCP_DENIED or 407 TCP_DENIED and no username is logged when NTLM is enabled

book

Article ID: 167686

calendar_today

Updated On:

Products

ProxySG Software - SGOS

Issue/Introduction

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.

Resolution

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:

Client --> Proxy GET www.example.com
Client <-- Proxy 407 Proxy Authentication NTLM/BASIC
Client --> Proxy GET www.example.com NTLM SSP NEGOTIATE
Client <-- Proxy 407 Proxy Authentication NTLM SSP CHALLENGE
Client --> Proxy GET www.example.com NTLM SSP AUTH
Client <-- Proxy 200 Okay (data)

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:

Example log:

[16/Mar/2004:12:38:06 +0000] 2 172.16.32.29 TCP_DENIED/407 1101 GET http://www.example.com - NONE/- - none ICAP_NOT_SCANNED

[16/Mar/2004:12:38:06 +0000] 104 172.16.32.29 TCP_DENIED/407 1333 GET http://www.example.com - NONE/- - none ICAP_NOT_SCANNED

[16/Mar/2004:12:38:07 +0000] 528 172.16.32.29 TCP_NC_MISS/200 7300 GET http://www.example.com MSSQLNET\PXG
DIRECT/www.example.com application/octet-stream none ICAP_REPLACED


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

<Exception>
   exception.id=("authentication_redirect_from_virtual_host","authentication_redirect_to_virtual_host","authentication_failed") access_log[main](no)

 ;;Remove access logging failure STOP

For more information, refer to related article 165957.