Policy Deny when a user logs in or comes back after a period of time away from their PC when running new versions of OS.
search cancel

Policy Deny when a user logs in or comes back after a period of time away from their PC when running new versions of OS.


Article ID: 166779


Updated On:


ProxySG Software - SGOS


The following two statements are starting to be seen more with customer who have recently upgraded their desktops to the latest MS OS like Vista / Windows 7  and Windows 2008 Servers.

  • A user logins to their PC for the 1st time in the morning and when they access the internet they are presented with a "Policy Deny"
  • When a user leaves their PC for a period of time and return to be presented with a "Policy Deny"

The deployment of the ProxySG / Internet can vary so there is no one design causing the problem.

So what is causing this.

The way IWA authentication works is that the ProxySG and the PC talk to each other asking for details to verify who the user is. In these challenges the PC will supply the Domain / Username / Workstation.  For authentication to work the PC and SG will use the DOMAIN\USERNAME to pass to the Active Directory to validate. This is not exclusive to Blue Coat system but to all Proxies or any application that requires authentication.

What we are starting to see is when the PC access the internet and the ProxySG requests authentication the PC does not send the Username if the following is true

  • The application accessing the internet is a Service on the PC
  • The PC is at the Login Prompt

So what we see in the 3rd Authentication request is the PC does not send the User Name but the Host Name with a $ at the end.


No.     Time                       Source                Destination           Protocol Info                                                           
     17 2010-06-24 15:31:56.055999              HTTP     GET http://www.someinternetlink.com/ HTTP/1.1 , NTLMSSP_AUTH, User: DOMAIN\PCNAME-PC$

Hypertext Transfer Protocol
    GET http://www.someinternetlink.com// HTTP/1.1\r\n
    Cache-Control: no-cache\r\n
    Pragma: no-cache\r\n
    Accept-Encoding: deflate\r\n
    User-Agent: Application Name\r\n     < ------ indicates the source application of the request
    Proxy-Connection: Keep-Alive\r\n
    Host: internettest.fiberlink.com\r\n
    [truncated] Proxy-Authorization: NTLM abcabcabcabcabc...........
            NTLMSSP identifier: NTLMSSP
            NTLM Message Type: NTLMSSP_AUTH (0x00000003)
            Lan Manager Response: 000000000000000000000000000000000000000000000000
            NTLM Response: 7F92B867E3861D18AA4AFEE9E22AB2610101000000000000...
            Domain name: DOMAIN
            User name: PCNAME-PC$  <-- Username is expected to be here but the PC will user the Host Name and add a $
            Host name: PCNAME-PC
            Session Key: Empty
            Flags: 0xa2888205
    Cookie: BCSI-CS0BBC0803=2\r\n


So now the ProxySG has the been given DOMAIN\PCNAME-PC$  which is still a valid request, the ProxySG sends this to the BCAAA agent for validation.

On the BCAAA server we see the following two differences.

2010/05/11 16:33:18.960 [3216] Recv: WaitForMultipleEvents 0x3b5310=0x174
2010/05/11 16:33:18.960 [1000] Basic authentication for: domain='' user='anonymous'
2010/05/11 16:33:18.976 [1000] LogonUser ret 0x0 hLogin 0x0 last error 0x52e
2010/05/11 16:33:18.976 [1000] Unicode user name (hex) is: 4c 4f 43 41 4c 5c 61 6e 6f 6e 79 6d 6f 75 73
2010/05/11 16:33:18.976 [1000] UTF-8 user name (hex) is:LOCAL\anonymous (LOCAL\anonymous)
2010/05/11 16:33:18.976 [1000] JoinInfo: result=0x0(0), join_status=3, domain=DOMAIN

2010/05/11 16:33:18.976 [1000] EnumerateTrusts: status=0x0(0) count=1
2010/05/11 16:33:18.976 [1000] [0] netbios ADROOT dns adroot.local
2010/05/11 16:33:18.976 [1000] User is not in trusted domain
2010/05/11 16:33:18.976 [1000] RESP2: ctxKey=0x0 ts=0 result=0x8004011A
2010/05/11 16:33:18.976 [1000] RESP:_PayLoadType=5 _PayLoadLen=284 outBufLen=12128 AuthCtxBufLen=0
2010/05/11 16:33:18.976 [1000] Finished processing request

2010/03/22 19:27:52.542 [3196] NTLM authentication
2010/03/22 19:27:52.542 [3196] hContext=0x22f3d8:22f4d700025eff0
2010/03/22 19:27:52.542 [3196] Convert_to_netbios
2010/03/22 19:27:52.542 [3196] Calling convert_name 0 3
2010/03/22 19:27:52.542 [3196] convert_name "NT AUTHORITY\ANONYMOUS LOGON"  3 3
2010/03/22 19:27:52.542 [3196] Converted NT AUTHORITY\ANONYMOUS LOGON to NT AUTHORITY\ANONYMOUS LOGON (0)
2010/03/22 19:27:52.542 [3196] Allocated name: result=0x00000000,  name=0x2599B4 'NT AUTHORITY\ANONYMOUS LOGON'
2010/03/22 19:27:52.542 [3196] Unicode user name (hex) is: 4e 54 20 41 55 54 48 4f 52 49 54 59 5c 61 6e 6f 6e 79 6d 6f 75 73 20 6c 6f 67 6f 6e
2010/03/22 19:27:52.542 [3196] UTF-8 user name (hex) is:NT AUTHORITY\anonymous logon (NT AUTHORITY\anonymous logon)
2010/03/22 19:27:52.542 [3196] Performing NTLM Group-of-Interest Auth for: 'NT AUTHORITY\anonymous logon'
2010/03/22 19:27:52.542 [3196] SSPICheckGroupsOfInterestIwa: lpUserName='NT AUTHORITY\anonymous logon' phContext=0x22F4D700025EFF02010/03/22 19:27:52.542 [3196] MutexName='_' GroupName='DOMAIN\GROUP'

So if the AD Server is Windows 2003 the request is denied where as now with Windows 2008 we are given the NT AUTHORITY\ANONYMOUS LOGON.

As this is a valid request the ProxySG uses this to perform a POLICY check which is then Denied.

If the ProxySG is also using "Surrogate Credentials" then this Username is cached against the IP Address of the Client PC for xx minutes (depending on the set value : default 900 secs)

So how do we get around this.

One thing in the above Packet Capture is the "User-Agent: Application Name" this tells us what sort of application is sending the request. This can range from MS Updates to AV/Malware Updates.

So adding a simple rule of identifying these User-Agents and setting the Authentication to "Do Not Authenticate".


To troubleshoot this you could do the following.....

  1. Find a PC that you know has problems and get the IP Address.
  2. Create a Filter on the Blue Coat Proxy just on this IP Address
  3. Start the Packet Capture and leave this running for a while.
  4. Once you see that you have capture traffic, stop the PCAP and download to a local PC.
  5. Using a Packet Capture Reader (e.g Wireshark) load up the file and filter on the following "http.request or http.response"
  6. Examine the Request packets and look for the User-Agent (just like the one above)


Sample Policy Code :

      condition=UserAgents authenticate(no) 
      condition=UserAgents Allow      or     Deny  (depending on what you want todo)

;; Description:
define condition __CondList1UserAgents


end condition __CondList1UserAgents

define condition UserAgents


end condition UserAgents