Transparent Mode SSO cached credentials

Please show the line from the Web Filtering logfile.  Did you search that log to confirm that this was the first access of the day?

Cheers - Bob

Unfortunately, due to union regulations, data protection laws, corporate policies and whatnot I'm not allowed to turn on logging for HTTP requests, yet alone post those logs on the web. Yes, I could sneaky peeky enable logging or clone the VM and do the tests there, but IMHO it's just not worth the hassle.

Anyways, today I came to the office, disabled Airplane Mode, went to https://www.facebook.com and the request went through without a problem. Definitely the first request of the day for that device. After that, I went to http://www.disney.com and was immediately prompted with the UTM's authentication dialog.

Sorry, but without a log line, there's very little insight that we can provide. There's no law that I've heard of that prevents anyone from posting logs where names and IPs are obfuscated.

My WAG would be that you have configured Web Filtering in Transparent mode, with 'Do not proxy HTTPS traffic in Transparent Mode' and that the HTTPS traffic is going out via a firewall rule created by the Installation Wizard.

Cheers - Bob

My memory is fuzzy on how the latest UTM works (I work on multiple products) but it may be working as intended.

The limitations are:
The UTM cannot perform transparent mode AD SSO in a variety of situations.
- HTTPS
- HTTP with a URL that has a ?parameter
- FTP over HTTP
- The user agent does not include Mozilla, suggesting it is a non-browser request (This is not a limitation, but something we put in to allow for things like Adobe Update running a 1am)

I think what it does is:
- If authentication is required
AND 
- there is a user in the cache
AND
- the cache entry is older than 5 minutes
AND
- this is an HTTPS (etc) request
THEN
- use the expired cache entry

The credentials are cached forever (until overwritten).  If the system requires credentials and the cache less than 300 seconds old, just use the cache.  If the system required credentials and the the cache is greater than 300 seconds, ask for credentials if you can and use the cache if you cannot.

The proof would be in the log line that indicates the user and the authentication method.  I suppose you could do something to prove it was a specific user by giving them a special policy that would uniquely identify them.

Well if the UTM cannot perform transparent mode AD SSO the expected behavior should be to block any traffic, instead of using god knows how old cached credentials. Caching is good for a couple of minutes, but not for hours or days. To me, this is not a feature but a bug.

It works as intended, and is that way for a reason.  Not doing it that way means a lot of updaters and non-browser access stops working.  The alternative could be a very large exception list with dozens of apps and websites in it that an admin would need to maintain.  Or in the case of HTTPS, users would just have to get used to the fact that occasionally they will go to a (HTTPS) website and get "Page cannot be loaded" until they go to a different website (HTTP) first.  Or worse, they go to HTTPS facebook and continuously browse there but every 5 minutes it stops working until they go to an HTTP site.

Other authentication mechanism have different restrictions.  If you use the authentication Agent then you won't have this problem because authentication is no longer tied to the restrictions of the HTTP standard and how well app developers have implemented it.  If you have many users on a single computer, or have non AD devices, than using the Browser login page may be a good option for you.

It sounds like you are working for a company with unusual restrictions - no logging for example.  While being super secure and private are important considerations, please understand that your requirements are different from the majority of UTM users.  There are always trade-offs with security.  Increasing security also means increasing cost, decreasing convenience, different levels of surveillance.  For many places, more security means more tracking (think US gov't) and for you it means less.

We do our best to find a balance that works for most people.  We use out own products.  I hope that it works for you.  And if it doesn't please raise a feature request through feature.astaro.org or contact Sophos support.  Priority of features is based on customer demand.

more security means more tracking (think US gov't)

Oooohhhh, NSA is watching you now, Michael.  ;P

I wrote a somewhat longish reply but chose to delete it anyways as I think this is the wrong place for it.

That being said, you have to realize that your sales reps are actively pushing the UTM as a full-fledged enterprise-ready TMG replacement. No offense meant, but it's far from that. I can, off the top of my head, tell you at least five bugs (features as you might call them) that render your product unfit for enterprise use (The OWA sign-out bug, just to mention the most serious one, see 1 and 2. We've opened a support case for that one and haven't heard from you guys in weeks.)
I know what I'm talking about as we've bought a 150 user VM license to evaluate the UTM as a TMG replacement in one of our departments before deciding on a product for campus wide deployment.

Back to the topic, I realize that the cached credentials thing is meant as a convenience feature. Anyways, NOC / security admins should be free to choose whether they want to use such a feature or not. We have a simple policy for unauthenticated access: We do not allow it. That means, just because a smart device was able to successfully authenticate yesterday, it shouldn't be granted unauthenticated access to HTTPS resources today. It doesn't matter if that's inconvenient to the end user or not.