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

Question

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!

Answer 1

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.