[9.165] Web filtering profiles SSO authentication

Exact same prob here.

Zentyal 3.2 as ADS/LDAP directory server.
UTM ist successfully attached to this dir, DNS-config is' done, all is working.

But when i log in with a default domain user (no admin privileges) on Win8 Pro x64 and start firefox/ie a popup-windows appears. When i typed in the credentials for one time, i can surf all the time, even after a logout/reboot.
On my Vista SP2 x32 Machine, also a domain-client, theres the problem, that the popup-windows appears all the time, with each click i have to re-authorize.

If i switch the profile from transparent-sso to transparent-noauth all is working perfectly.

So what to do? A bug in the beta?
Anyone else with experience on this behaviour?

Thx,

Manuel

A doubt: how does the UTM gets the username from AD ? Never seen an authenticated transparent proxy implementation like this without UTM agents on domain controllers.

The utm joined the ad as a member/client.
The credentials give to the utm allowing it to "browse" the dir for the users/access-rights.

no agent have to be installed on the dc.

But i don't know how the utm gets the information, who is actually logged in in transparent mode (only the source-ip i known), maybe the browser-agents delivering these information when hitting the utm-filters? Maybe a utm-guru can explain here... ? ;-)

Here's a quick run-down on how the AD SSO handshake in Transparent mode works:
 * Browser sends HTTP request, which is transparently intercepted by the UTM
 * UTM redirects the HTTP request to the FQDN of the UTM (port 80)
 * UTM sends a 401 response to challenge for authentication. 
 * Browser replies with a ticket or credentials to complete the handshake
 * UTM caches the authenticated user with the source IP address
 * Browser gets redirected to original site

One caveat here, is that the UTM's hostname must be a fqdn within the local AD domain, so that your browser will consider it to be a site in the local Intranet zone. It will then respond to auth requests from the UTM transparently.

Thanks AlanT for explanation...I have just tested to add UTM's site name (which is FQDN name in my internal domain with DNS record) to the Intranet zone pages in IE and now it works as it should. I will try to investigate where is the problem with browsers - not finding UTM as intranet zone member.

Thanks, Rok

...I found the wpad.mydomain.local (with wpad.dat) was still active from my Sophos WSA testing and after I removed A record for wpad in my DNS everything works fine. The problem is just username/IP cache where UTM is not getting new username if you logoff and logon with different user.

I'll add one more thing to Alan's description.  The following is true for AD SSO in both transparent and standard modes.

When the browser receives a challenge for authentication it should take the OS's currently logged in user's credentials and try them (without any prompting from the user).

If the UTM receives them and cannot use them to authenticate (eg maybe the user is a local login not domain user) then it asks again.  This time the browser (knowing that SSO failed) will do a pop-up asking for credentials.

Some browsers may store the credentials in the password manager, at which point it is up to the browser to decide whether to use the logged in OS user, the stored credentials, or ask the user.  I have seen cases where people are not getting the user they expect or they get different behavior based on browser - this is typically due to saved credentials in their Password Manager.

spjslo - The login is cached for 15 minutes, I think it uses the Authentication Timeout in the WebAdmin settings.

Here's a quick run-down on how the AD SSO handshake in Transparent mode works:
 * Browser sends HTTP request, which is transparently intercepted by the UTM
 * UTM redirects the HTTP request to the FQDN of the UTM (port 80)
 * UTM sends a 401 response to challenge for authentication. 
 * Browser replies with a ticket or credentials to complete the handshake
 * UTM caches the authenticated user with the source IP address
 * Browser gets redirected to original site

One caveat here, is that the UTM's hostname must be a fqdn within the local AD domain, so that your browser will consider it to be a site in the local Intranet zone. It will then respond to auth requests from the UTM transparently.

Thanks for the explanation... but for this kind of approach the browser must support NTLM authentication, correct ?

The bad thing in this kind of implementation is that any other app that´s not a browser usually doesn´t work.....

ps: Sophos really does like to be the "man in the middle" huh? kkkk (kidding)...

Yes, when using AD SSO the application (browser) must support HTTP Authentication, either NTLM or Digest.

If you find an application that do not support this, create an exception (usually defined by the destination it is going to) that skips authentication.  In the new policy model it will choose the first policy that has the flag "Apply this policy to requests that have skipped authentication due to an exception" or will fall do the Base Policy.