Sophos STAS authentication, (Sophos Transparent Authentication Suite) is a collection of tools that provides a method of authentication that was introduced in UTM 9.4. This authentication mechanism has been lacking from the UTM, compared with some of its contemporary NGFW / UTM competitors. Sophos UTM now supports more authentication mechanisms than most others.
Sophos STAS authentication works by monitoring of the domain controller's event to correlate authenticated users with their associated IP addresses. The Sophos UTM then knows the identity of the user, and can apply access based on the user.
Sophos STAS Authentication works like this:
In theory, this is every domain controller in your environment. In practice, this is each domain controller that would service client authentication requests.
In a large environment with multiple AD sites, you would probably only require the STA Agents on sites associated with your end user subnets.
The STA Agent is either installed on a domain controller (EventLog mode) or another server (NetApi mode). In a small environment such as our lab, you can deploy the STAS Agent and STAS Collector roles on the domain controller itself.
Because there is no Agent required on the client, it is called agent-less authentication. "Domain controller monitoring Agent and no client agent" is way more accurate, but a bit too wordy for sales pitches.
In this step-by-step guide, I will go through deploying Sophos STAS in a simple test lab environment that you would probably want to duplicate before deploying this into your production environment.
The lab contains:
The following is performed on the domain controller(s) in your environments. Or each STAS Agent server.
Ensure port 5566 is allowed, by adding a firewall rule with the following PowerShell command:
New-NetFirewallRule –Display "STAS Agent" -Direction Outbound –RemotePort 5566 –Protocol TCP –Action Allow
Next, you need to grant the account with Run as a Service rights. To do this:
You are now ready to install the Sophos STAS Agent:
Download Sophos STAS from https://www.sophos.com/en-us/support/utm-downloads.aspx
Run the installer, and accept all the defaults.
At the Type of Setup Screen page, select STA Agent. (If you are installing the collector and agent on the same machine select the SSO Suite option). Click Next.
Specify the account that is to be used. It must have administrative permissions on the server.
From the start menu Launch Sophos Transparent Authentication Suite.
In the General tab complete the information for the Monitored Domains.
In the STA Agent tab specify the network subnets to be monitored.
Specify the IP address of the device that will be the STA collector:
Once this has been completed, start the Agent service from the General tab.
The following needs to be completed on all of the devices that will act as collectors.
Use the two PowerShell commands to set up the required firewall rules.
New-NetFirewallRule –Display "STAS Agent Inbound" -Direction Inbound –LocalPort 5566 –Protocol TCP –Action Allow
New-NetFirewallRule –Display "STAS Collector" -Direction Outbound –RemotePort 6677 –Protocol UDP –Action Allow
Next up you need to grant the account Run as a Service rights.
You are now ready to install and configure the STA Collector:
NOTE: If this is installed on the domain controller it is effectively a domain admin service account.
* You would want to adjust the logout settings accordingly once you have established that everything is working as expected.
As mentioned earlier, the whole process works based on the domain controller logging the log in and log out events. The following settings ensure that these events are actually logged on the domain controller.
This procedure must be configured on all the of "Monitored Domain Controllers", or domain controllers on which the STA Agent is installed.
The UTM will take the user information it receives from the STA collector and check it against Active Directory for Group Membership.
Add your domain controller(s) as Authentication Servers:
Next up we will configure the UTM to use STAS:
The following only needs to be configured if you want to validate the logged in user. This portion is not required, but I would suggest you configure it if possible.
There are two methods that can be used. WMI verification or Registry Read.
Both methods require the associated services to be running on the client, so set them to Auto Start, and start them.
For Registry Read
Since these are sensitive services you would also need to explicitly allow the communications through the Windows firewall.
I found the only reliable way to enable this was to set a broad inbound rule from the STA Collector with the following PowerShell command
New-Netfirewall –DisplayName "STAT Collector" -Direction inbound –RemoteAddress 192.168.2.10
Now we are ready to check that everything is working as expected.
From the Start menu, open the Sophos Transparent Application Suite, and select the Advanced tab.
Use the troubleshooting section to test each function:
If you have a successful test on all items that apply you are ready to start some real world testing. You may already have some detected live users, you can see these by clicking the Show Live Users button. You can check here to verify if the UTM is receiving what it should be.
You should now be able to log onto a domain-joined device and the user information should make its way through to the UTM. On a domain-joined windows machine, log off and then back on again. Just locking and unlocking will not work.
Next up we can check if those users are successfully sent to the UTM. You can see who is identified by checking the UTM management console:
You can also check the User Authentication Daemon log (aua.log), and look for entries that contain caller="stas".
As we all know, security directly opposes convenience. That extra security gate you need to unlock is an inconvenience but it is worth it if the extra security means you get to keep your stuff. With STAS you would have noticed that the UTM does not actually authenticate the user, instead it trusts the domain controller to identify the user. Based on that identification the UTM then authorizes the access.
STAS is generally effective and efficient for some environments, but it (and similar transparent authentication methods from any other vendor) can be easily defeated.
A really simple scenario:
A user logs on to their workstation, and is identified and logged as an online user by the UTM. An action is required by the operating system the require UAC and someone with administrative access needs to allow the action. Once the action is completed the admin goes away and the user keeps on working. What happens in the background is that the administrator has completed a successful authentication on the client IP address. As far as AD and STAS are concerned, the IP now belongs to the administrator. The user the lock their workstation and unlocks it for the next few days. After all, why log off or reboot the machine. For the entire duration before an actual log on event happens, all traffic from that IP would be reported as the administrator, and not the user.
Another scenario where this does not work is when you have a terminal server environment such as Citrix or RDS. Multiple users log on to the same IP address. The latest logged on user would be the only one that shows up on the UTM. The same condition exists when user switching is enabled on a Windows Client OS.
If client devices go through a NAT before they reach the UTM the client will not be identified as the client NAT IP and the AD log IP would be different.
If a user authenticates against a service like a website, the user's identity will then move to be the web server's IP address and no longer the client's. Exclusions would have to be set for instances like this.
One handy feature of STAS is that it enables you to create firewall rules pertaining to users in the form of User Network objects. This means that the rule will apply to which ever IP addresses is associated to that user.
The problem is it's hard to see if it's actually working.
Since STAS is only one of many methods for identifying the user to the UTM, STAS itself does not impact how the username is represented in the logs. One thing it will assist with though is allowing the username to show up even if no authentication is requested. Normally, if a web profile does not require authentication, and the username is unknown, the IP would be used. However, with STAS the user might be populated independently of the Web Protection authentication requirements.
User Network firewall rules are another matter. The only way to verify that the above three rules were working, was to connect from those three network locations and watch the packetfilter.log to see which rule was rejecting the traffic. Of course, it worked. But unless you are looking for the rule number, the username or network object never shows up in the log.
We have seen that Sophos STAS authentication is a very convenient way to identify users, but it is identification only. Since the identification method is easily confused, it is really not suitable for a dynamic, high-security deployment.
The great news, however, is that the UTM platforms support numerous authentication methods that actually authenticates users. These include Agent, AD SSO and Browsers that make use of Kerberos to properly identify, authenticate and authorize access.
Download our FREE 30-day trial, or schedule a demo and we'll show you how it works.
How to Enable Dark Mode in Fortinet FortiGate (FortiOS 7.0)
Sophos XG - How to Block Searches and URLs with Specific Keywords