How to get user 'logged in' to ironport web filter without launching IE

[keithsauer507]

We have an issue with some employees who use third party programs that traverse the Internet.  These programs are 100% allowed by the organization as they are required for day to day business.  Some programs go over the Internet to communicate for certain reasons, such as a live chat help support, or ordering products, etc..

The problem is that some of these users log in and never even touch Internet Explorer for awhile.  They will go on and start working right away.  Well if they don't try to access an Internet site via IE, then the Ironport does not 'log them in', and they are known as unauthenticated.  Of course this doesn't happen with everyone.  There's nothing wrong with people coming in a little early and checking the local news online.

We were thinking up if it's possible to have each user 'touch' the ironport web filter in some way during a logon script, unbeknown to the end user, so that they are 'signed in' and whatever Internet connected application they launch has access through to the Internet.  Right now they need to at least launch IE and go to some site (say Google or MSN) and via NTLM credentials transparently passed through IE7, 8 or 9, they can simply close the page and go about their business.  Note: they MUST go to an external site.... not an internally hosted one (such as our Intranet, time clock or HR self service pages).

So is there any commands we can put in via kix or bat or something that will say "Hey Ironport, %username% just logged in at 10.x.x.x".  Then maybe to make it more advanced, a logoff script that says "Hey Ironport, %username% just logged OFF of 10.x.x.x".  This way when our hourly timeout happens, they aren't immediately booted from their Internet applications (if they don't keep an IE window open that is).

Right now our ASA Firewall uses WCCP to forward port 80 to the ironport web filter.  The Ironport is a transparent proxy.

Thanks!

[edadios]

Don't you want to do ASA Auth proxy instead? It seems like you just want to know that someone used a pc to go to internet, and also when they finished.

http://www.cisco.com/en/US/customer/docs/security/asa/asa82/configuration/guide/access_fwaaa.html#wp1043431

This will help you monitor and you can also show start stop if doing accounting.

If this is what you actualy needed, the firewall forum will be able to help you further, if you have further queries.

I hope this helps.

Regards,

Eric

[keithsauer507]

So it looks like you are moving the authentication from the Ironport S160 to the ASA5500 series firewall?

I guess we are looking at something simpler, like a way to 'touch' the internet and pass NTLM credentials, because then the Ironport knows who the user is.

If the user does not 'touch' the internet with IE, and say they use some other program that does not pass NTLM credentials (say Firefox or live chat program, or an ftp program, etc...) They are likely to be blocked, because the Ironport doesn't know who they are.

Your link seems to lead to a complicated setup for something that seems so simple.  I'm not sure how that relates to an Ironport S160.. it seems to focus on the ASA5500. Also we want it to be completely 100% transparent to the end user.

This is how it worked with a Barracuda web filter appliance...

A DCAgent program sat on each domain controller. As users logged in or out of the domain, this agent passed this current activity to the Barracuda web filter appliance.

The Barracuda appliance knew exactly who was logged in because of this little program on the domain controller(s) that kept it updated. Based on this, policies could be assigned based on Active Directory group memberships. ie) HR and Marketing can access Facebook, while others cannot.

I guess I'm looking for similar functionality with the Ironport S160. If there's any way the domain controller, or even the client PC can say "Hey Ironport, %username% is logged on here at %ip_address%". That way the Ironport would know who they are, and there would be no unnecessary authentication boxes (besides the user logging into the windows domain). They could use internet connected apps that do not pass NTLM authentication. I guess the client PC or the domain controller would also have to tell the IronPort when they signed off, just so we don't have to deal with authentication timeouts. This way, say they are in our internet chat help program... after an hour, it will cut out and disconnect them - because the IronPort forgets who they are (unless they are actively using the internet with IE).

So for now, we just use the bypass option for the affected internet services.  The default browser is IE, so the reality is that we are not suffering any tremendous inconvienence.  It's just that we want to ensure we have the best robust solution, and we can handle these types of situations with programs other than IE accessing internet resources.

[Justin Westover]

I have the exactly the same problem in my environment. Most of our users are using firefox though for their web browser and as you know, firefox does not natively support NTLM auth. You have to go into the about:config and set it. I also need some way for the ironport to authenticate a user without the user opening Internet explorer to do so. A script would make since but a client that actually sits on the users computer makes more since to me. We use the Anyconnect 3.0 client as it is with the NAM module which uses single sign on auth and communicates with our Cisco ACS server to deliver VLAN and DACL assignment. A very lighweight client that passes the authentication when a user logs into his/her computer for the day to ironport would be a perfect solution for this issue. Cisco would just need to develop something but in the interm, I would be satisifed with a script or something at least.

[tidavids]

This auth issue is somewhat common to transparent deployments.  If you were deploying via PAC, WPAD, explicit browser settings, etc - most applications successfully pass authentication to a proxy server like the WSA.

To answer questions in reverse order, there are open source tools availabe that can help push Firefox settings in a similar fashion as GPO (most use a login script mechanism to push the required about:config settings).

However, for the issue stated - how to make the WSA aware of auth without forcing a browser session; your options are somewhat limited currently.  The first recommendation would be to set auth surrogate to IP Address and match the timter to the DHCP lease timer.  In this case, once the WSA has auth information, it will just cache it for the remainder of that IP's life at the host.

However, we still need to get auth.  You could force some type of web request from the client when they login (thinking of a scripted wget).  You could also set the WSA to bypass authentication for certain sites.  You mentioned they were needed for their job...if they all fall into a specific category, application type, or agent type - a policy could be written to key off that attribute and bypass auth for that traffic.

[anewscript]

Also an isue on Ubuntu 14.04 when using apt-get

these are usually running over 80 & 443 so are shoved through Ironport.

even though Firefox works, apt-get returns a 401 auth required,

Hoping someone has seen this and has a fix for it

[snormoyle]

We were having those issues with asyncOS 7.1.0 and google earth 6. So we kept adding URL's to the "dest no auth" policy.  This was getting to be cumbersome because of all the exemptions that needed.

during a packet capture noticed that you see GoogleEarth and Google Earth in the user-agent string.  So we created an identity policy for no authentication for those user-agent strings and tied it to a no auth policy.

to date we have no more issues with google earth.

you may be able to do the same thing. with these applications.

[mudolisans]

İs there any news on this problem? We are having exactly same problem. We tried to increase TTL value. But issue is still happening. 

[Ken Stieers]

the current solution is to deploy a Context Directory Agent (CDA).  Its a vm that you point at your domain controllers.  It scrapes the security log for logins and passes who logged in from which IP to the WSA. (the old version was the ADAgent)

[mudolisans]

We had already deployed CDA. But we didn't add all of our domain controllers. So after add last one , its look like problem resolved since last 10 hours. Thank you! 

[stopper17]

hello guys,

We have the same problem(auth popup window appears on random users) and we do have CDA communicating with the AD logs(CDA mappings are correct). Mostly on Firefox and rarely on IE/Chrome the users have the problem but still we havent resovled it. Is there any suggestion or idea we could try???

S170 - AsyncOS 8.5.3