Important note about SSL VPN compatibility for 20.0 MR1 with EoL SFOS versions and UTM9 OS. Learn more in the release notes.
Disclaimer: This information is provided as-is for the benefit of the Community. Please contact Sophos Professional Services if you require assistance with your specific environment.
Table of Contents
This recommended read describes the best practices for STAS.
Sophos Transparent Authentication Suite (STAS) enables users to automatically log into Sophos Firewall when logging in to a Windows AD workstation.
STAS only requires software installation on AD servers; no software is needed on the workstation.
The configuration example provided in the article is quite simple, but it explains how STAS works.
It covers Windows AD GPO and Windows Firewall rules needed for STAS and also provides basic troubleshooting guides.
STAS authenticates users on workstations, not servers.
STAS consists of an agent and a collector.
The agent monitors the AD domain controller for the user login event, which is Windows Event ID 4768, and sends it to the collector UDP port 5566 (#1 and #2 in diagram logon.type2.png)
The collector analyses the logon event and sends it to Sophos firewall UDP port 6060 if a user isn’t an existing STAS live user. (#3, and #4 in diagram logon.type2.png)
Sophos Firewall looks up the username in the AD domain controller to get the group, email address, and more user details. (#5 in diagram logon.type2.png)
Then, the user will be displayed on Sophos Firewall as a live STAS user. (#6 in diagram logon.type2.png)
User detected in such a way is known as STAS logon type 2.
Diagram: logon.type2.png
The collector can also help Sophos Firewall get users logged on to an AD workstation.
For example, Sophos Firewall doesn't have a live user on an AD workstation, but the firewall rule requires user authentication for traffic from the AD workstation. (#1, and #2 in diagram logon.type1.png)
In such a situation, Sophos Firewall sends a query to the collector UDP port 6677, asking for a username on the workstation. (#3 in diagram logon.type1.png)
The collector talks to the workstation via methods defined in the Workstation Polling Method, such as WMI. (#4 in diagram logon.type1.png)
Workstation replies with username in WMI,
then the collector records the live user (#5 in diagram logon.type1.png) and sends it back to Sophos Firewall on UDP port 6060
Sophos Firewall looks up the username in the AD domain controller to get the group, email address, and more user details. (#6 in diagram logon.type1.png)
Then, the user will be displayed on Sophos Firewall as a live STAS user. (#7 in diagram logon.type1.png)
User detected in such a way is known as STAS logon type 1.
Diagram: logon.type1.png
STA Agent and Collector support to change the default communication ports.
UDP port 6060 on Sophos Firewall for STAS can't be changed.
[ Note: Member server is a computer that runs an operating system in the Windows Server family, belongs to a domain, and isn’t a domain controller. ]
For the AD domain with 1 DC, my recommendation is
For the AD domain with 2 DC, my recommendation is:
Sophos Firewall supports 12,288 live users by default.
That can be verified below.
The limitation can be lifted with the Device Console command by using the following command: Make sure your Sophos Firewall is up to sizing.
system auth max-live-users set <8192-32768>
STAS can only detect users on AD domain workstations.
If a workstation isn’t a member of the AD domain, STAS won't be able to detect live users.
In such a scenario, Sophos Client Authentication Agent is the solution. Details of Client Authentication Agent is available at https://support.sophos.com/support/s/article/KB-000038465
Traffic between the AD workstation, STA Agent/Collector, and Sophos Firewall must be routed/switched, not NATed, because an original IP address is needed for STAS to work.
The STAS application requires a GUI to work. Windows Server core edition does not have a GUI environment installed by default, so STAS won't work on it.
Kevin Kuphal has provided a workaround:
You can run STAS on a member server and point it at a Windows Core domain controller and it’ll work just fine.
You can find AD NetBIOS Name, FQDN, and Search DN as described below.
In this example, FQDN is tao.xg, and NetBIOS name is TAOXG
Search DN is required when we configure the authentication server on the Sophos Firewall.
To find out Search DN, run the command dsquery user in Windows CMD, as shown below.
C:\Users\Administrator>dsquery user
"CN=Administrator,CN=Users,DC=tao,DC=xg"
"CN=Guest,CN=Users,DC=tao,DC=xg"
"CN=krbtgt,CN=Users,DC=tao,DC=xg"
"CN=One User,OU=ABP Users,DC=tao,DC=xg"
"CN=Two User,CN=Users,DC=tao,DC=xg"
"CN=AD Admin,CN=Users,DC=tao,DC=xg"
"CN=User Super,CN=Users,DC=tao,DC=xg"
C:\Users\Administrator>
Search DN for "Two User" is "CN=Users,DC=tao,DC=xg"
Search DN for "One User" is "OU=ABP Users,DC=tao,DC=xg"
Later, we’ll configure search DN "DC=tao,DC=xg" in the authentication server on Sophos Firewall.
Log on to Sophos Firewall webadmin, go to Administration > Device access, and enable "Client Authentication" on the zone where the STA Collector and user workstation are located. In this example, it’s the LAN zone.
We need to configure Windows AD DC as an authentication server on Sophos Firewall so that Sophos Firewall can fetch the group and other information of STAS's live users from AD DC.
Sophos Firewall Online help: Configure Active Directory authentication
Log on to the Sophos Firewall webadmin, go to Authentication > Servers, and click the "Add" button.
Configure the authentication server below
-Server Type: Active Directory
-Server Name: any name for the AD DC
-Server IP: IP address of the AD DC
-Connection security: SSL/TLS, by default
-Port: 636, default TCP port for LDAP service on SSL/TLS
[ Note: To enable SSL on Windows LDAP service, you need to generate a CA on AD DC, reboot DC, DC would automatically assign the CA to LDAP service, and accept LDAP traffic on TCP port 636. Details in the section "10. Appendix > a) Enable SSL on Windows LDAP service ]
-NetBIOS Domain: TAOXG, as discovered
-ADS username: an AD user with AD administrator privilege
-Password: password of ADS username
-Display Name Attribute: leave it blank. If you need to use another AD attribute for Name, refer to Microsoft KBA docs.microsoft.com/.../attributes-all
-Email Address Attribute: mail, by default. If you need to use other AD attributes for email, refer to Microsoft KBA docs.microsoft.com/.../attributes-all
-Domain Name: tao.xg, as discovered.
-Search Queries: "DC=tao,DC=xg" as discovered above.
Once the configuration is completed, click "Test connection" to ensure the Sophos Firewall can communicate with AD DC via LDAP.
This step is optional; however, it’s recommended that you import AD user groups to simplify user management on the Sophos Firewall.
Those AD user groups need to be imported into the Sophos Firewall to apply firewall rules on specific AD user groups.
Go to Authentication > Server, and click the "Import" icon next to an AD server, as shown below.
Set Base DN to "DC=tao,DC=xg"
Check the desired groups.
Set common policies for those Groups. Normally, we leave it as is by default during the initial setup.
Click on Next to import the group.
Go to Authentication > Groups and verify the AD group has been imported, as shown below.
Go to the Sophos Firewall web admin> Authentication > Services, and choose the Windows AD DC as the first server for "Firewall Authentication Methods", as shown below.
Go to Sophos Firewall webadmin > Authentication > STAS, turn on "Enable Sophos Transparent Authentication Suite", and then click the "Activate STAS" button, as shown below
Change default settings,
Note:
The next step is to add the STAS server.
Click the "Add new collector button" and add the IP address of the STAS server. In this example, it’s 192.168.20.9
Collector Port can be checked on STAS Suite> General tab > Listening to the Sophos appliance on Port, as shown below.
Make sure the Firewall rule on the AD workstation allows incoming WMI.
Check WMI-In
Action: Allow the connection
Once the group policy is updated, you can continue to the next step, which is to verify that the audit policy settings were applied correctly.
You can also wait for the group policy to be updated per the Windows schedule.
C:\WINDOWS\system32>auditpol.exe /get /category:"Logon/Logoff"
System audit policy
Category/Subcategory Setting
Logon/Logoff
Logon Success and Failure
Logoff No Auditing
Account Lockout No Auditing
IPsec Main Mode No Auditing
IPsec Quick Mode No Auditing
IPsec Extended Mode No Auditing
Special Logon No Auditing
Other Logon/Logoff Events No Auditing
Network Policy Server No Auditing
User / Device Claims No Auditing
Group Membership No Auditing
C:\WINDOWS\system32>auditpol.exe /get /category:"Account Logon"
System audit policy
Category/Subcategory Setting
Account Logon
Kerberos Service Ticket Operations No Auditing
Other Account Logon Events No Auditing
Kerberos Authentication Service Success and Failure
Credential Validation No Auditing
C:\WINDOWS\system32>
Event ID 4768 is for user login.
If AD DC doesn't generate event ID 4768 in Windows Event Viewer, the STA Agent cannot detect any user logon activity.
Once event ID 4768 is generated, the STA Agent forwards that information to the STA Collector UDP port 5566.
Please check Windows Event Viewer to ensure that Event ID 4768 is generated when a user logs on to a workstation.
The following screenshot shows user1 logged on to AD domain tao.xg from workstation 192.168.20.19.
Sophos KBA for STAS https://support.sophos.com/support/s/article/KB-000035732
The latest STAS can be downloaded from Sophos Firewall webadmin > Authentication > Client downloads, as below
In this example, STA Agent was installed on a Windows AD DC 192.168.20.5. STA Collector was installed on a member server, 192.168.20.9.
Install STAS by right-clicking on the installation file > 'Run as administrator' to prevent any potential permission issue on Windows.
For STA Agent, choose "STA Agent."
For STA Collector, choose "STA Collector"
Enter Windows AD administrator credentials, as shown below. The account is needed to
It isn’t necessary to be an administrator, but it must be a member of group Domain Admins.
Open STAS on domain controller 192.168.20.5.
1) In the "General" tab, put in the NETBIOS name of the AD domain, together with the Fully Qualified Domain Name
And then click the Start button to start the agent
2) Wait for the Current Status of STA Agent to be "Start."
If the STA agent can't be started, double-check the Administrator Credentials, NetBIOS Name, and Fully Qualified Domain Name.
3) Go to the "STA Agent" tab and specify the subnet to which all Windows AD users belong, as shown below.
"STA Agent Mode": EVENTLOG is recommended.
"Domain Controller IP" is only needed when STA Agent is installed on a member server. It must be blank if STA Agent is installed on an AD DC. Otherwise, the STA Agent can't read local Windows Event logs.
“Monitor Networks”: 192.168.20.0/24 for the example
"Collector List": In the example, it is 192.168.20.9
"Domain Controller Polling" is configurable if STA Agent Mode is set to NETAPI. In the example, I set STA Agent Mode to be EVENTLOG. Therefore, no need to configure the option.
Remember to click "OK" to save the configuration on the STA agent.
Open STAS on member server 192.168.20.9.
In the "General" tab, put NetBIOS Name and Fully Qualified Domain Name of AD domain.
Go to the "STA Collector" tab,
Go to "Exclusion List",
1) In the "Login User Exclusion List," we put in any background service accounts, for example, trendupd, trendupd2, OktaService, and more, depending on the software installed on the workstation.
That prevents STAS live users from logging off when a background service account logs in to start background tasks.
Note:
- "Login User Exclusion List" only supports "username", and doesn't support "username@domain.com", nor "domain\username".
- The username in the "Login User Exclusion List" is case insensitive.
2) In "Login IP Address/Network Exclusion List", add IP addresses of any server, for example, Citrix terminal server, Microsoft RDS server, DNS server, or web server, to prevent frequent user logon/logoff.
The reason is that STAS authenticates users on workstations, not servers.
In the example, I put the IP addresses of the DNS server and web server into the Login IP Address Exclusion List.
The following is recommended in case STAS troubleshooting is needed.
STAS log files, stas.log, and stas.log1 are located on the Windows server installed with STAS in the directory of C:\Program Files (x86)\Sophos\Sophos Transparent Authentication Suite by default.
stas.log and stas.log1 gets rotated at every 25 MB (or as defined by Log File Size).
Remember to click "OK" to save the configuration.
We have completed the configuration of STA Collector.
Click "Start" to start the STAS service.
Once STAS and Sophos Firewall establish communication, the IP address of the Sophos Firewall is displayed on the "General" tab, as below.
Sometimes, the STAS service might fail to be started, with the error "Failed: Cannot start service: STAS". Please refer to section "8. Troubleshooting > g) STAS service did not start due to a logon failure" for a solution.
Note:
SSH to Sophos Firewall as admin, and go to 5. Device Management > 3. Advanced Shell, and run the following command
grep "CTA LIVE Received from\|sending CTA_IS_ACTIVE" /log/access_server.log | tail
SFVUNL_SO01_SFOS 18.0.4 MR-4# grep "CTA LIVE Received from\|sending CTA_IS_ACTIVE" /log/access_server.log | tail
DEBUG Feb 08 16:00:36.719168 [access_server]: process_cta_live: CTA LIVE Received from 192.168.20.5
DEBUG Feb 08 16:01:06.733092 [access_server]: process_cta_live: CTA LIVE Received from 192.168.20.5
DEBUG Feb 08 16:01:36.748435 [access_server]: process_cta_live: CTA LIVE Received from 192.168.20.5
DEBUG Feb 08 16:02:06.753870 [access_server]: process_cta_live: CTA LIVE Received from 192.168.20.5
DEBUG Feb 08 16:02:36.754746 [access_server]: process_cta_live: CTA LIVE Received from 192.168.20.5
DEBUG Feb 08 16:03:06.770399 [access_server]: process_cta_live: CTA LIVE Received from 192.168.20.5
DEBUG Feb 08 16:03:36.784307 [access_server]: process_cta_live: CTA LIVE Received from 192.168.20.5
DEBUG Feb 08 16:04:06.799499 [access_server]: process_cta_live: CTA LIVE Received from 192.168.20.5
MESSAGE Feb 09 11:01:29.423157 [access_server]: process_cta_live: sending CTA_IS_ACTIVE 192.168.20.5
MESSAGE Feb 09 11:08:30.094186 [access_server]: process_cta_live: sending CTA_IS_ACTIVE 192.168.20.5
SFVUNL_SO01_SFOS 18.0.4 MR-4#
If STA Collector and STA Agent are installed on different servers,
If STA Collector and STA Agent are installed on the same Windows server, create Windows Firewall rules on the Windows server to allow
Ports needed by STAS are described in section "1. How STAS works > d) Summary of ports."
Windows Firewall rules are applied to the network profile (Domain, Private, Public). Make sure the above Windows Firewall rules are applied to the correct network profile.
To ensure that STAS works without problems, the STA Collector must communicate with all workstations via the workstation poll method.
In the configuration, we configured STA Collector to use WMI as a workstation polling method.
We need to verify that the STA Collector can communicate with any AD workstation via WMI:
It should be successful. Otherwise, check the Windows GPO configuration for WMI in section "5. Configure Windows AD GPO > b) Allow inbound WMI on AD computers."
To troubleshoot wmi issue, refer to
user1 re-logged on AD workstation 192.168.20.19 after STAS was set up
On STA collector, open STAS, go to Advanced > Show Live Users, there was the live user.
On Sophos Firewall webadmin, Current Activity > Live Users also showed the live user
Create a firewall rule to allow users in the IT group to access internet
Now, 192.168.20.19 can access internet
Sophos Firewall webadmin > Current activities > Live connections > Live connections for Username shows the live connection of user1@tao.xg
Firewall rule traffic stats also confirmed traffic from 192.168.20.19 was generated by the user in the IT group and hit the firewall rule.
When the STA Collector can't communicate with Sophos Firewall, the STAS "General" tab doesn't show the Sophos Firewall IP address.
Make sure
In case STA Collector doesn't detect any live user
Make sure
If Sophos Firewall doesn't show any live users, but STAS shows live users, make sure
STAS can detect live users on AD workstations. However, it removes live users after a while.
Make sure
Firewall webadmin GUI > Current Activity > Live Users show some STAS live users, but not all. Some STAS live users are missed on Sophos Firewall.
Make sure
Please also check if Sophos Firewall reaches the STAS server via the static route. Details in section "9. Known issues".
If STAS service fails to start with "Fatal Error: The service didn’t start due to a logon failure.", make sure the account for STAS is a member of AD group "Domain Admins".
You can update the account for STAS in the "General" tab, as below.
If it doesn't fix the issue, try the following:
1) Go to Windows Service and find "Sophos Transparent Authentication Suite". Right-click on it, and click "Properties."
2) Go to the "Log On" tab and enter the AD Domain admin account and password again.
3) Go back to STAS, click the "Start" button, and now STAS should Start.
a) Dead entry timeout: must be 0 otherwise, STAS stops working (applies to STAS v2.5.1.0 and earlier)
b) When Sophos Firewall reaches the STAS server via a static route, Sophos Firewall can't communicate with the STAS server after reboot/boot-up.
Symptom: Sophos Firewall doesn't send packets to STAS server UDP port 6677 to actively query live users on workstations. Sophos Firewall can only passively receive live user information from the STAS server.
Workaround: Manually restart authentication service after firewall reboot/boot-up.
- in Advanced Shell, please run the command "service access_server:restart -ds nosync", or
- in webadmin GUI, go to "System service" > "Services", and then Restart the "Authentication" service, as below
[ Note: This bug (NC-84910) will be fixed in Sophos Firewall OS v18.5 MR5. ]
Note: If you need technical support to enable SSL on Windows LDAP service, seek help from Microsoft.
In Server Manager, Add Roles and Features
Select "Role-based or feature-based installation."
Add the role of "Active Directory Certificate Services."
Click "Next" install "Certificate Authority."
Install
Once the installation is complete, in Server Manager, click on "Notifications" > Post-deployment Configuration > Configure Active Directory Certificate Services.
In "AD CS Configuration", click Next to continue.
Choose "Enterprise CA"
Choose "Root CA"
"Create a new private key."
Key length: at least 2048
Hash algorithm: SHA256 or higher, don't choose SHA1/MD5...
Input essential information for the CA
Click "Configure" to generate root CA.
Now, restart the DC, and Windows automatically enables SSL on the LDAP service.