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.
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
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 184.108.40.206 220.127.116.11 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
User-Agent: Application Name\r\n < ------ indicates the source application of the request
[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
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  Recv: WaitForMultipleEvents 0x3b5310=0x174
2010/05/11 16:33:18.960  Basic authentication for: domain='' user='anonymous'
2010/05/11 16:33:18.976  LogonUser ret 0x0 hLogin 0x0 last error 0x52e
2010/05/11 16:33:18.976  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  UTF-8 user name (hex) is:LOCAL\anonymous (LOCAL\anonymous)
2010/05/11 16:33:18.976  JoinInfo: result=0x0(0), join_status=3, domain=DOMAIN
2010/05/11 16:33:18.976  EnumerateTrusts: status=0x0(0) count=1
2010/05/11 16:33:18.976   netbios ADROOT dns adroot.local
2010/05/11 16:33:18.976  User is not in trusted domain
2010/05/11 16:33:18.976  RESP2: ctxKey=0x0 ts=0 result=0x8004011A
2010/05/11 16:33:18.976  RESP:_PayLoadType=5 _PayLoadLen=284 outBufLen=12128 AuthCtxBufLen=0
2010/05/11 16:33:18.976  Finished processing request
2010/03/22 19:27:52.542  NTLM authentication
2010/03/22 19:27:52.542  hContext=0x22f3d8:22f4d700025eff0
2010/03/22 19:27:52.542  Convert_to_netbios
2010/03/22 19:27:52.542  Calling convert_name 0 3
2010/03/22 19:27:52.542  convert_name "NT AUTHORITY\ANONYMOUS LOGON" 3 3
2010/03/22 19:27:52.542  Converted NT AUTHORITY\ANONYMOUS LOGON to NT AUTHORITY\ANONYMOUS LOGON (0)
2010/03/22 19:27:52.542  Allocated name: result=0x00000000, name=0x2599B4 'NT AUTHORITY\ANONYMOUS LOGON'
2010/03/22 19:27:52.542  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  UTF-8 user name (hex) is:NT AUTHORITY\anonymous logon (NT AUTHORITY\anonymous logon)
2010/03/22 19:27:52.542  Performing NTLM Group-of-Interest Auth for: 'NT AUTHORITY\anonymous logon'
2010/03/22 19:27:52.542  SSPICheckGroupsOfInterestIwa: lpUserName='NT AUTHORITY\anonymous logon' phContext=0x22F4D700025EFF02010/03/22 19:27:52.542  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.....
Sample Policy Code :
condition=UserAgents Allow or Deny (depending on what you want todo)
define condition __CondList1UserAgents
end condition __CondList1UserAgents
define condition UserAgents
end condition UserAgents