AD SSO operations

Thanks for your helpful and detailed reply. It suggests that the flaw is not in Kerberos SSO but the documentation, which would be a shame for all those struggling with it. We have a straight forward environment, and I have followed the setup carefully, but can get nothing but the captive portal.

AD SSO using Kerberos or NTLM is fairly common for our customers.
Like a lot of configuration it can be complex when setting up, depending on your environment, but once working it is solid.
Kerberos has more requirements to set up that NTLM but is worth it.
AD SSO works better if you are doing HTTPS decryption, so that it can authenticate HTTPS requests in addition to HTTP.
AD SSO works slightly better if you also use direct proxy rather than transparent. This is because the HTTP specification for authentication works slightly better for authenticating against proxies.
AD SSO is not compatible with other authentications. You cannot use AD SSO for some things and Heartbeat or STAS for others.

The SSO part (Single Sign On) means that if the computer is logged in with an AD user, that AD user is used to authenticate silently with the XG with no prompting. If the user is not from AD (local login) or for example is a phone then most browsers will follow the redirect to a captive portal page they can enter in username and password.

Assuming AD SSO and not Captive Portal:

When there is no user logged in to Windows (for example system things like Windows Update) the "user" that the computer sends may be the computername. This can cause problems depending on your configuration. I recommend that you have firewall rules that allow "computer users" to have limited access. Some customers seem to have more problems with computers as users than other customers.

The authentication applies to all connections from that IP address, not just web browsing.

The authentication is performed periodically (after four minutes since the last authentication, the next web request is authenticated). If a windows user logs off and someone else logs in (or Fast User Switching) it can take up to four minutes for the Sophos Firewall to see the change. If you are not doing HTTPS decryption then it is "the next HTTP request after four minutes" which for some customers might mean that it is 15+ minutes between the reauthentication sees the new user.

Users are "logged off" automatically if there is no network activity in a certain timeframe. Do not change these settings (I regret that they are visible in the UI). In practical terms, if the computer disconnects from the wifi or go into sleep mode then it will be idle and the logoff will occur. Most computers stay logged in overnight.

The user is logged on to an IP address. If you RDP into a remote computer and that computer logs in and does stuff, it is that remote computer's ip and user that is logged in.

If you have multiple users on the same IP address (virtual desktops, citrix server) then you must use a mode called "Multi User Hosts". That will authenticate every web request and not associate the user with the IP. Non-web requests will never have a user.

Will try support. Thanks again for your help.

As far as I know there are only KB-articles/How-to with WMI setup - support told us the other way and we just tried...

Would be nice if there would be a better documentation...

Great, that sounds hopeful - we just use single user RDP sessions. Is there documentation for the setup needed for registry polling? Everything seems to assume WMI.

Yes we already changed the polling method - this solves issues if a user do RDP to another internal server...(local auth gets lost) but this did not change anything with userbased RDP session auth for terminal servers...(You will need an extra firewall rule without user auth for terminalservers). We did not have any issues with the exclusion list so far (this may depend on the customer infrastructure) - if you need an exclusion for users (without auth) you should do that with an IP-based extra firewall rule before the main rule...

regards

Hi Steve, thanks for sharing your experiences. Not very encouraging... I've seen a post saying you can work around the STAS RDP issue if you forgo using WMI polling for log-off detection and use Registry Read Access instead. Is this something you're aware of? My other main concern about STAS is the need to maintain the exclusion list. Do you know if it's possible to explicitly include the required users instead?

As far as we can say with the experience of a lot of customer projects: AD SSO with browser authentication is a pain on XGS (a desaster compared to UTM)! We had always support cases and there were always other root causes and issues and never a satisfied solution with support...We wasted hours here! It never works 100% for all users all the time. If you need Authentication with SFOS you have to use STAS, InterceptX-Client or captive portal. There could also be some issues with STAS but you can change some settings there and this works. BUT: For RDP/Terminalservers a session userauth is generally NOT possible!

regards

I was avoiding STAS as there seems too many opportunities for it to stop working one morning e.g. forgetting to add exceptions for new services or MS patches throwing a spanner in the works on the DCs. Also we use a lot of RDP which isn't supported.

99% of our installations use STAS, the only time I've used Kerbs SSO is in conjunction with Mac devices in recent years - I guess other peoples milage may vary.

In olden days of the UTM it was all NTLM which tended to work ok, but if you have an issue there's a lot hidden in the background (PC direct to AD etc) which is painful to troubleshoot. Plus it's only when the user fires up their browser they are authenticated - with STAS it's the whole device as soon as they log in, which we find more preferrable.

Regards