I am currently working on implementing NTLM authentication using a Cisco Cache Engine 560 within our organization. In addition to this stand alone caching device, I am also utilizing SmartFilter for URL filtering policies. I have been successful in configuration NTLM authentication (using our Windows 2003 domain) and have enabled HTTP transparent proxy using WCCP2.
When I started to do my testing, I immediately noticed that the browser displayed a pop-up asking for the user ID and password for this site. Because I want this to be transparent, it seems that after opening a TAC case, the only way to do this is to enable the "User Authentication > Logon > Automatic logon with current username and password" within Internet Explorer 7 in the Internet Zone security settings.
My concern is that with this option enabled, it seems possible that a malicious site could also prompt for HTTP authentication, in which my browser would automatically pass the cached Windows domain credentials which are the domain username and password onward. With this information, said site could use it to attempt to access external (webmail) or internal (VPN, remote access, etc.). Is my thinking correct?
I broke down 4 scenarios below that I have considered.
1) No NTLM Authentication - SmartFilter policies are applied based on source IP addresses. PROS: Secure / CONS: Difficult to manage, DHCP addressing allows for anonymity for most web browsing.
2) Proxy with NTLM - Users NTLM authenticate to a proxy server transparently because the proxy server is in the Intranet zone. IE7 is setup to only passed credentials to other hosts in Intranet zones. PROS: Secure, user based authorization, no additional IE7 settings required, no credentials passed to Internet / CONS: Hardcoded Proxy settings cause problems with mobile / remote users.
3) Transparent WCCP2 with NTLM (Automatic Login turned on) - Users NTLM authenticate transparently to the Cache engine. PROS: No pop-up box, user based authorization / CONS: Domain credentials could be passed to external sites on the Internet.
4) Transparent WCCP2 with NTLM (Automatic Login turned off) - Users authenticate via Basic HTTP authentication method. PROS: user based authorization, no additional IE7 settings required CONS: Credentials are sent Clear Text from browser to cache engine
I was also wondering if there may be some way to have the HTTP header re-written (from the cache engine) so that it shows the authentication request is coming from it and not the Internet, and I could add this host to the Intranet sites list in IE7.
I would like to know how other people, using Cisco equipment, are performing authentication securely. Please feel free to correct me and my thinking, quash my security fears, or share how your organization is doing it.
Options 3 and 4 seem to be the best here. You are right about your concerns in regards to your users credentials being forwarded out to the Internet by the browser if Automatic logon with current username and password is configured. You need to think what is better for your users, transparent authentication or the possibility of having their credentials on the Internet.
In regards to your question about how to configure the authentication header so it shows your company's name, here is the command you need to use on the CE: http authentication realm xxxx.
I hope this helps. Thanks!
Thanks for the response. with the http authentication realm command, do you know if I could then add an exclusion in IE7 for sending to credentials based on this hostname so I would only send NTLM ID and hash to the internal site?
I've never seen that being possible. I'll do some research to see if there is a way to restrict this matter. Thanks!
Do you know if it is possible to block internet bound NTLM requests at the firewall or perimeter router (using NBAR or ports)? Because the Cache Engine is internal, NTLM requests from it would be allowed, but if we blocked NTLM requests (from the internal network to the Internet), I think this may work. I am just not sure what the actual process is. Does the client attempt to connect to a server, and then the server responds with info in the HTTP packet that says "Hey, send me NTLM information to authenticate" and then the client sends on the information?
Regarding the question you asked on May 15th, on IE, what you can do is to configure the browser to automatically log in with current username and password on Intranet and make the browser to ask for credentails when going to the Internet. Now, you would depend on the browser to be able to tell the difference, so I don't know how effective that would be.
In regards to the question you've posted on May 16th, I don't know if it is possible to block NTLM requests using NBAR or ports, due that the NTLM requests go under the same already established HTTP connection ( so the TCP port is the same for the whole session ), so you would need an application capable of identify an NTLM request and block it. I don't know if smartfilter has this capability. Thanks!
NBAR is a function of IOS in a router. I found info on NTLM at the following link (http://davenport.sourceforge.net/ntlm.html#ntlmHttpAuthentication) and am thinking that I can write a NBAR rule that looks for the following inbound request in HTTP and then drop the packet.
The server responds with a 401 status, indicating that the client must authenticate. "NTLM" is presented as a supported authentication mechanism via the "WWW-Authenticate" header. Typically, the server closes the connection at this time:
HTTP/1.1 401 Unauthorized
If the client never receives a response from the server, I am assuming that it will think that the connection timed out stall the session.
If you can look for the 401 request and block it on the router; as you correctly said, the client ( browser ) would never send the client's credentials out to the Internet.
The drawback of this matter is that some web sites that require authentication ( for example CCO ) would be blocked as well; but if you can live with that, then you've found a solution for your problem. Thanks!
I am working on a NBAR filter to only block NTLM authentication requests specifically. I should have more informaiton later this week and I will post a resolution if it works.