AD SSO operations

Question

Hi, I&rsquo;m struggling to find documentation about how Active Directory SSO operates (as opposed to how to set it up). The kind of questions I have are&hellip; 
 
 Is the initial browser authentication transparent, or does the captive portal appear for login? 
 Once the user is added to the firewall, will further browser authentications be transparent, or will the captive portal appear again? 
 Once a user is authenticated via the browser, does this apply to all firewall rules & logging or just browsing? 
 How long does the user remain authenticated against their IP address? 
 What happens when the user logs out? 
 Does it work over RDP? 
 
 That will do for starters 
 Thanks

carbon15 · Accepted Answer

You don't come across this very often, but I've some experience of it (albeit only once or two and not recently). 
 If you set it up correctly, the browser session is authenticated in the background and the user doesn't see anything. A live user just pops up on the XG. 
 There's a timeout of (by default) six minutes after which the browser authenticates automatically - there's no user input. I see no reason why when there's an authenticated user on that IP that all traffic (firewall, filtering etc) would not apply - it does normally. If the user logs out then there will be a delay whilst the time out occurs and they drop. When a new user logs in and opens a browser I'm pretty sure the old user gets overwritten straight away. Six minutes is the smallest timeout value. 
 If you RDP into something and log in, then yes, I would expect it will work but if there is more than one person on that device you need to setup per connection SSO or things get very messy as users overwrite each other. 
 
 I do recall it can be painful to setup, and any issues are difficult to troubleshoot (all that background stuff is hard to see). 
 
 Regards

Steve Weißflog · Answer

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

Michael Dunn · Answer

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.

AD SSO operations

Top Replies