In our network, we are using the NTLM authentication binded to the AD.
We are able to trace which users going to what website etc..which is great
However, with that setup in place. I found out that we could not do any Microsfot update/Microsoft Security Essentials update.
Even with the windows INTAGRAM program called Pixsta we could not get pictures to load, while having been authenticated via the web browser already
TCP_DENIED/401 0 HEAD http://datawsa01/B0000D0000N0001F0000S0002R0004/http://download.microsoft.com/v9/1/windowsupdate/redir/muv4wuredir.cab?1402180809 - NONE/- - OTHER-NONE-NONE-NONE-NONE-NONE-NONE <-,-,-,"-",-,-,-,-,"-",-,-,-,"-",-,-,"-","-",-,-,-,-,"-","-","-","-","-","-",0.00,0,-,"-","-"> -
TCP_DENIED/307 0 GET http://distilleryimage9.instagram.com/0b9dce80987111e3af360e35a5d477f9_8.jpg - NONE/- - OTHER-NONE-DefaultGroup-NONE-NONE-NONE-NONE <-,-,-,"-",-,-,-,-,"-",-,-,-,"-",-,-,"-","-",-,-,-,-,"-","-","-","-","-","-",0.00,0,-,"-","-"> - 1392711515.566 0 10.100.42.12 TCP_DENIED/307 0 GET http://distilleryimage6.instagram.com/13729128987011e39d120e278e67a242_8.jpg - NONE/- - OTHER-NONE-DefaultGroup-NONE-NONE-NONE-NONE <-,-,-,"-",-,-,-,-,"-",-,-,-,"-",-,-,"-","-",-,-,-,-,"-","-","-","-","-","-",0.00,0,-,"-","-"> -
Im getting TCP_DENIED on the above transaction. What can i do to allow the above traffic
This is the standard authentication process for NTLM with a proxy. You will see a TCP_DENIED/307 which is a redirect for authenticaiton, followed by a TCP_DENIED/401 which is authorization required.
The issue with the Microsoft link is that microsoft updates do not support authentication. This link is to the knowledge base that explains the issue and provides the steps to resolve it on the WSA. http://tools.cisco.com/squish/27385, if you are unable to access the link go to support.ironport.com and click on the IronPort Service and Support page. Click on the literature tab and click on Cisco Email and Web Security Knowledge Base and search for 766.
For the instagram link, it appears that the device is not following the 307 redirect. You will need to make sure the device making that request can resolve the redirect hostname of the WSA (WebGUI > Network > Authentication > edit global settings > redirect hostname). If this is a mobile device (iPad, iPhone, Android phone, etc..) it will not support authentication and you will need to setup an auth exempt identity to match. If you need assistance with the configuration please open a support case and we will be happy to assist.
Customer Support Engineer
Cisco Content Security - Web Security Appliance
Thank you very much for your information. Windows update is NOW working after inserting the relevant microsoft link and exempting it from authentication.
As for the redirect hostname: yes: client machine is able to resolve/ping the WSA hostname (datawsa01)
However, i am having tons of issues with this authentication setup.
As a network administrator, this will be a nightmare, as more & more user will have issues with different sort/type of application/software running on their machine that the WSA will have difficulty bypassing the traffic due to X,Y,Z software not having authentication ability
According to https://supportforums.cisco.com/blog/12176911/updated-access-customer-knowledge-base, the IronPort Knowledge Base was retired and migrated to Cisco Tech Notes.
So for Cisco Tech Notes, go to http://www.cisco.com/web/services/acquisitions/ironport.html#~Literature and under the Technical Documentation section, click Cisco Web Security Appliances.
The issue is that many apps aren't built to do authentication in their use of the http protocol. They hve no mechanism to grab the current logged in user and pass that in response to the challenge. You will find that Outlook will have similar issues.
If you are using IP surrogates, A quick fix is to tell your users to hit any internet page with IE first. They will get authed and stuff will work.
The permanent fix is to deploy a CDA or AD Agent. They scrape the AD logs for log ins and tie user id to ip and can pass that info to WSA,ASA, and ISE.
Sent from Cisco Technical Support Android App
As far as iTunes is concerned you can use the user agent string to match those requests, this article explains how to workaround the issue http://tools.cisco.com/squish/3173B.
Malware bytes application is most likely experiencing the same issue.
As Ken mentioned, this is an issue with the application/site not supporting authentication. CDA will resolve the issue without having to add as many exceptions, as authentication will occur when the user logs into the machine rather than when they make a web request.
Customer Support Engineer
Cisco Content Security - Web Security Appliance
Thanks for the above recommendations.
If i understand correctly: Installing the Context Directory Agent is the only way around this.
We also have the ISE in our environment; which is doing the 802.1x on the switchport side.
Currently our setup is in the way:
If we were to install the CDA:
Does that mean that in order to bring the ISE+WSA together as a single sign on. Both the ISE and WSA needs to integrate with the CDA.
Appreciate any advise
Yes, the only easy way... you could continue chasing user-agents and configing the apps as they come....
I think where they're going with CDA and the fact that Patch 2 can push to ISE is that the plan is for things to be exactly what you're saying:
If you install CDA, it picks up theie user login to AD, and passes that identity info to the WSA.
I'm not sure if you're doing user level policy in ISE, but if you were (eg. I don't care what box they're on, IT people can get to the managment network), CDA could feed that info to ISE instead of what ever otherway you may be doing it know.
I had it backwards... ISE can feed ID info of users that aren't AD users to the CDA... Then the CDA will feed the WSA with user info...
Taken from the CDA patch 2 release notes: ( http://www.cisco.com/c/en/us/td/docs/security/ibf/cda_10/release_notes/cda10_rn.html#wp185334 )
Starting with patch 2, CDA can now receive information from Cisco Identity Services Engine (ISE) and Cisco Secure Access Control Server (ACS) in order to map users that do not directly login into Active Directory. CDA acts as a syslog server, receiving syslog messages from ISE and ACS, and populates the mapping table using network login information derived from ISE and ACS.
CDA supports ISE 1.1.x and 1.2 and ACS 5.3, and 5.4 only.
Client devices, such as the Cisco Adaptive Security Appliance (ASA) and the Cisco IronPort Web Security Appliance (WSA), interact with the Cisco CDA using the RADIUS protocol in order to obtain the latest set of IP-to-user-identity mappings, in any one of the following ways:
•On-Demand—The Cisco CDA can respond to an on-demand query from the client device for a specific mapping.
•Full Download—The Cisco CDA can respond to a request from the client device for the entire set of mappings currently in its cache.
The AD Agent interacts with the following components in a network:
•Active Directory Domain Controller Machines
Integration with ISE/ACS allows consumer devices such as ASA-CX and WSA to make security decisions for a large portion of network endpoints, including those that are not domain members. CDA passes the information to the consumer devices in the same format whether the user/domain information was received from a Windows domain controller event log or through integration with ISE/ACS.