How long does ironport wsa cache ad credentials at a workstation?

[keithsauer507]

Here is an issue.

Say a person logs onto a workstation with limited internet access.  Almost all internet sites are blocked per company policy.  They log off the computer and another individual logs into the workstation.  This individual should have internet access with a different policy.  However the Ironport still thinks the last person is logged in, so they cannot access anything on the internet.

How do you circumvent this issue?

We have an S160 running 7.5.2-304 and we are a Microsoft Windows organization.

Under Security Services > End User Notification, we redirect the blocked notification page to a custom one on another server/ironport/stop.asp.  We had to remove the reauthenticate user button because either it wouldn't always come up anyway, or we would get http 500 server errors.  So how else can I reauthenticate the user?

[Ken Stieers]

You can play with the settings in Network/Authentication (Basic Authentication Token TTL, Surrogate Timeout, Client IP Idle Timeout).  Do you have the CDA deployed? That should get the next login authenticated, but your turnaround time may vary...

[keithsauer507]

I thought we had the CDA deployed.  I will have to search for it.

Surrogate timeout is 3600 seconds.

Client IP Idle timeout is also 3600 seconds.

Cache Size 8192 number of entries.

Basic Authentication token TTL 3600 seconds.

[keithsauer507]

Ok in Network NTLM Authentication realm I did a start test and it did find and verify the shared secret to the server populated for the Active Directory Agent.  It said test successful.  So it should be reading form the AD Agent.

[keithsauer507]

Upon further investigation, we are using AD agent.  I just downloaded the documentation for CDA, CDA and the 4 patches and I am highly interested in this.

What sparks this is Office 2013 users sometimes are prompted for proxy credentials because they haven't been on the internet in the last hour, Ironport for whatever reason cannot authenticate them. So what they have to do is open IE and go to any regular http site, then Office will stop prompting.

I'm hoping CDA will overcome this.

[keithsauer507]

I just finished deploying the CDA as a virtual machine.  Its logging appropriately from all 3 of our domain controllers.

I changed in the WSA the hostname and shared secret to point to CDA.  I did an authentication test and all lookups, dc's and the CDA passed.

However I still have an issue.  I logged onto a test workstation with an AD user that is in our limited internet group.  I attempted to go to youtube and facebook and was correctly blocked with the correct block category listed.

I then logged off this PC and logged on as myself, an IT user who has a lot more relaxed internet.  When trying to go to those pages, I still get a blocked message and the username listed is still the old username that was logged on before.

I went into CDA IP mapping and searched for my name.  Sure enough my user name is in there for that IP address, but for whatever reason the webfilter is not looking at it?  How can we get this working right so Internet access is correct when the user logs on and off and they do not have to ever re-authenticate manually?  The WSA should just know from CDA who is logged on a particular workstation.  

[Ken Stieers]

There is an issue (bug? Weirdness with how MS stuff works) when you RDP to a box and login.

Since the current RDP client actually checks with AD before it lets you connect to the other machine, your local machine shows up as the account you RDP'd with, NOT your account. (because the most recent login from that IP was the account...)

I have this issue when I rdp to servers with service accounts...

Your users, who don't have/use multiple accounts won't see this issue.

[keithsauer507]

I'm not using RDP.  I'm physically logging into a test Dell Optiplex 390 Windows 7 Professional PC, which is joined to our domain.  I log in as the limited user, test in IE 9, then do a log off, and then log on as me.  Physically.  No RDP in this case.

CDA shows the IP address mapping is correct.  Just seems WSA doesn't care to look at it after some kind of "timeout".  Isn't there a way to get the WSA to look at it more often (such as every minute) and if so would there be any downsides to that?

I don't want users prompted for credentials, or things suddenly stop working for them.  The CDA should have all of this information (and at a glance right now it seems to), so when needed the IronPort should look here first, rather than pop up an authentication prompt.

I have yet to test this with a non domain device (iPhone) but on WPA2/Enterprise (authentication with my AD credentials).  Normally iOS devices always would prompt from "webfilter" and you would need to type your AD username and password.  So we created a second SSID and use MDM software to assign its complex key to all iOS devices.  This SSID bypasses our webfilter since it is such a PITA.

[keithsauer507]

I left that workstation logged in and it took 1 whole hour and then I was able to browse to websites I am allowed to access.  

So it takes 1 hour. If I change surrogate timeout to like 3 minutes, would that fix this issue?

[Ken Stieers]

Yes, that should do it... not sure what side effects (auth traffic?) that will have...

[DWalker79]

Did this work for you?  I'm having the same issue in an environment where computers are shared between users with varying access levels.  Among other things, even service accounts such as for running tasks or antivirus are getting cached into the PC for 1 hour, and all of my reporting is now inaccurate.

I also have a CDA in place, and have contemplated changing the Basic Authentication Token, Surrogate, and Client IP idle timeouts.  Did you only need to change 1 timer, and what affect if any did this have on your environment?

[Ken Stieers]

You can tell the CDA to ignore service accounts.

On the Mappings/Filters page, you can add account names to tell it to ignore.
It takes wildcards so stuff like "SCCM*" works...

Ken

[DWalker79]

That is good to know.  I may leave them for now while only changing the surrogate timer.  I like having the statistics for the service accounts that go out to the web.  Some departments need shown just how much traffic their new cloud applications can use in a day.  :)

[keithsauer507]

DWalker79,

Things seem a lot better since we changed the Surrogate timeout from its default 3600 seconds down to 120 seconds.

I did not change anything else.  

In CDA I did have to filter out service accounts, and since then it seems to be working as I would expect.

[DWalker79]

Thank you both for your prompt responses.  This should solve my issues.