Set up STAS on Sophos Firewall

STAS stands for Sophos Transparent Authentication Suite. The feature maps Windows logons from Active Directory to a client IP address so Sophos Firewall can use users and groups in firewall rules without requiring users to sign in again through a browser or portal.

This is still useful in classic Windows domains. At the same time, STAS is not a universal SSO solution. The mapping only works reliably when the firewall sees the real client IP address, the domain controllers write the required logon events and technical accounts are excluded cleanly. RDS, terminal server and Citrix environments usually need a different design, for example SATC.

When STAS makes sense

STAS is best suited to environments with normal Windows clients in an Active Directory domain. Typical goals are:

• firewall rules with AD users or AD groups
• reporting with user context instead of only IP addresses
• transparent user mapping without Captive Portal
• internet rules for internal client networks
• supplementary authentication in environments without an Entra ID SSO design

STAS is less suitable when several users share the same source IP address. This affects Remote Desktop Servers, terminal servers, Citrix servers or systems with NAT between the client and the firewall. In these cases, check early whether Sophos Authentication for Thin Client (SATC) or another authentication model is the better fit.

Video guide

The following Sophos Techvids show the STAS setup visually. The videos were created with SFOS v21, but the basic principle, architecture and most important configuration steps are still helpful. Individual screens may look slightly different in SFOS 22.

How it works

STAS consists of two components:

The typical process:

1. A user signs in on a Windows client.
2. Active Directory writes a matching Security Event.
3. The STA Agent reads this event.
4. The STA Collector receives the user, client IP and domain information.
5. Sophos Firewall updates the Live Users.
6. Firewall rules can evaluate users or groups.

The collector can also check clients through WMI or Registry Read Access. This Workstation Polling helps map an IP address to a user or correct stale entries. Windows Firewall, services, permissions and network paths must be correct for this to work.

Requirements

Clarify these points before installation:

• Sophos Firewall runs in gateway mode.
• Active Directory is already connected to the firewall.
• Domain controllers write the required logon events.
• Windows clients are domain-joined.
• There is no NAT between clients, collector and Sophos Firewall.
• Client Authentication is allowed under Device Access for the relevant zones.
• DNS, time, routing and firewall rules between the systems are correct.
• A service account and password-change process are defined.
• Technical accounts for exclusions are known.

STAS 2.5 and later supports Windows Server 2008 R2, 2012 R2, 2016, 2019, 2022 and 2025 according to the official documentation. New installations should still avoid old server generations. The important point is that STAS can run either directly on a domain controller or, from STAS 2.5 onwards, on a member server. For member-server designs, check event-log access, WMI or Registry access and network paths particularly carefully.

The AD connection itself is described in Connect Active Directory to Sophos Firewall. STAS should not be treated as a replacement for a clean AD server configuration.

If many users and groups have accumulated on the firewall over the years, also keep the Sophos Firewall User-ID limit in mind. This is especially relevant when portal or VPN functions fail only for individual users.

Plan the architecture

In small environments, the agent and collector can run on the same domain controller. This is simple, but not always the best operating model.

The collector creates its own communication and test paths to the firewall, to agents and, depending on the polling method, also to clients. It should therefore not automatically be placed on a domain controller just because the agent already runs there. Sophos itself points out that installing the collector on a domain controller is not always recommended because of the traffic it generates. In production environments, a separate Windows server is often easier to monitor, update and restart if problems occur.

In larger environments, a cleaner design is often:

• STA Agent on every relevant domain controller
• one or two STA Collectors on separate Windows systems
• collector groups per AD domain
• clear Exclusion List for technical accounts
• defined firewall rules and Device Access permissions
• monitoring for services, event logs and Live User mapping

IP visibility is critical. STAS maps users to IP addresses. If a proxy, NAT, terminal server or VPN gateway hides the real client IP, the firewall cannot use the mapping reliably.

Prepare Active Directory

STAS depends heavily on the correct logon events being present in the Security Event Log. Check the following settings on every domain controller on which the STA Agent is used.

Also note the NetBIOS name, FQDN and Search DN of the domain before installation. These values are needed later in the Sophos Firewall and STAS configuration.

Enable Audit account logon events

Open Local Security Policy on the domain controller, for example with secpol.msc.

Then open:

Security Settings > Local Policies > Audit Policy

Open Audit account logon events.

Enable Success and Failure and save the change.

Prepare the STAS account

The STAS service should run with a documented account. In simple test environments, an administrator account is often used. For production environments, a dedicated STAS account is better if the required permissions are set and tested cleanly.

Depending on the design, the account must be able to:

• start the service
• read relevant event logs
• access clients through WMI or Registry Read Access
• survive planned password changes
• be clearly identifiable in monitoring and documentation

The account does not necessarily have to be a Domain Admin. On the domain controller, the relevant group and file permissions are important. In practice, check:

• membership in Domain Users
• membership in Event Log Readers
• read and write permissions on C:\Program Files (x86)\Sophos\Sophos Transparent Authentication Suite\
• if WMI polling is used, suitable permissions on endpoints, for example Remote Desktop Users, Distributed COM Users and WMI permissions on Root\CIMV2 with Execute Methods and Remote Enable

In larger environments, these endpoint permissions are easier to distribute through Group Policy. If Workstation Polling is not used, avoid unnecessarily broad rights.

If the service runs with its own account, that account needs Log on as a service.

Path in Local Security Policy:

Security Settings > Local Policies > User Rights Assignment

Then add the account.

Check ports and services

The required connections must be possible between Sophos Firewall, STA Collector, STA Agent, domain controller and clients. The basic ports are:

Additional ports depend on the enabled methods:

If Windows Firewall is active on clients or servers, restrict the rules tightly to the collector. Example template for WMI:

New-NetFirewallRule -DisplayName "Sophos STAS Collector WMI" -Direction Inbound -RemoteAddress 10.10.10.10 -Action Allow -Profile Domain

This command is only a template. In production, the source IP, destination ports, profiles and Group Policy settings must match the chosen polling method.

Add Active Directory on the firewall

Before STAS is enabled, Sophos Firewall must know the Active Directory server.

In WebAdmin:

Authentication > Servers

Add an Active Directory server or check the existing configuration.

The individual fields are explained in Connect Active Directory to Sophos Firewall. NetBIOS domain, domain name, search base and group resolution are especially important for STAS.

Download and install STAS

The STAS installation file is provided through Sophos Firewall.

In WebAdmin:

Authentication > Client downloads

Under Single Sign-on, select Sophos Transparent Authentication Suite (STAS).

Start the downloaded STAS.exe as administrator on the intended Windows system.

Typical installation variants:

If there are multiple domain controllers, an STA Agent is usually needed on every relevant domain controller. One collector can collect information from several agents.

Configure STAS

After installation, configure the STA Suite. The most important areas are General, STA Agent, STA Collector and Exclusion List.

General

In the General tab, check the service account, domain details, NetBIOS name and FQDN.

If the domain values are wrong here, the installation may look healthy later, but users or groups will not be mapped correctly. The NetBIOS name must be entered in STAS in uppercase.

STA Agent

In the STA Agent tab, these points are decisive:

• STA Agent Mode: For local event-log detection, EVENTLOG is the typical starting point.
• Specify the networks to be monitored: Enter the client networks in which STAS should detect users.
• Domain Controller IP: Only set this if the agent is not running directly on the domain controller. If the SSO Suite is installed on a domain controller, this field normally remains empty.
• Collector List: Enter the IP addresses of the collector systems.

Choose the monitored networks deliberately. Server networks, management networks or networks without normal user workstations otherwise create unnecessary errors or false expectations.

STA Collector

In the STA Collector tab, the Sophos Firewall is added and client polling is planned.

Important points:

• Sophos Appliance: Enter the IP address of the Sophos Firewall.
• Workstation Polling Method: Choose WMI or Registry Read Access consciously.
• Enable Logoff Detection: Only enable this if ping and timeouts suit the client network.
• Dead entry timeout: Test the value against the STAS version and operating model.

For HA clusters, use the reachable internal firewall address that matches the STAS traffic. Separate peer administration addresses are usually not the right destination for this.

Exclusion List

The Exclusion List prevents technical accounts from overwriting normal user mappings. This is one of the most important STAS operating areas.

Typical entries:

• service accounts for backup, monitoring, software deployment or endpoint tools
• administration and installation accounts
• accounts that sign in to many clients in the background
• servers or systems where no workstation users are expected

Without an Exclusion List, a real user can disappear from Live Users because a service account is detected on the same client shortly afterwards. This later looks like a firewall-rule issue even though the cause is the authentication mapping.

Collector groups and redundancy

One collector is often enough for small environments. In larger environments, plan collector groups deliberately.

Proven rules:

• Use a suitable collector group per AD domain.
• Plan at least two collectors if user-based rules are critical.
• Configure STA Agents with all intended collectors.
• Test firewall and collectors in both directions.
• Do not place collectors on systems that are restarted frequently.

An STA Agent can serve multiple collectors. An STA Collector can also serve multiple Sophos Firewalls. Even so, document the mapping; otherwise troubleshooting becomes unnecessarily difficult later.

On the firewall, a collector is entered with Collector IP, Collector port and Collector group. A maximum of five collectors is possible per collector group. The order in the group matters: the first collector is primary, the others act as backups. Collectors in the same domain belong in the same collector group. Use separate collector groups for subdomains or separate AD domains.

Enable STAS on Sophos Firewall

When agent, collector, AD and network are prepared, enable STAS on the firewall.

In WebAdmin:

Authentication > STAS

Enable STAS and enter the collector or collector group.

If the setup works, users appear on the dashboard and in the Live Users area.

If no users appear there, check AD events, agent, collector, Device Access and ports first. Firewall rules are the next step, not the first one.

Important STAS options on the firewall

Under Authentication > STAS, there are several options that should be set consciously.

• STAS quarantine: For incoming traffic, the firewall asks the collector for the user and destination IP mapping. Without a match, traffic is dropped. This is useful for strict user-based rules, but unstable STAS detection can then look like a network problem.
• Identity probe time-out: How long the firewall waits for the collector response. The default is 120 seconds. Do not increase this blindly; first check why the collector does not respond, or responds too late.
• Restrict client traffic during identity probe: With Yes, traffic can be blocked during identity probing until the firewall receives a response from STAS. With No, traffic is forwarded during probing. The factory default is Yes, so long-running unchanged STAS installations can also be affected. Check this before SFOS 22 upgrades because it is relevant to a documented STAS upgrade and operational issue in SFOS 22.0 MR1.
• Enable user inactivity: Removes inactive users from Live Users. This helps keep Live Users clean, but must match clients, polling and timeout behaviour.
• Inactivity timer: Minutes until inactive users are signed out. The default is 3. Values that are too short can cause confusing sign-outs on quiet clients.
• Data transfer threshold: Minimum data volume in bytes for a user to be considered active. The default is 100. Low thresholds are usually more practical for office clients than very aggressive values.

Create a firewall rule with user identity

Once STAS reliably detects users, firewall rules can use users or groups from Active Directory.

Important:

• Test the rule with a real test group.
• Enable Log firewall traffic if the rule needs to be analysed later.
• Check rule position.
• Avoid fallback rules that hide authentication errors.
• Check Live Users and Log Viewer together.

For rule analysis, see Test a firewall rule with Log Viewer, Policy Test and Packet Capture.

Validate after setup

A green service status is not enough. After setup, test the whole chain.

Practical flow:

1. Sign in with a test user on a domain client.
2. Check the Security Event on the domain controller.
3. Check STA Agent status.
4. Check STA Collector status and detected users.
5. Check Live Users on Sophos Firewall.
6. Test a user-based firewall rule with logging.
7. Test logoff or user switching.
8. Check technical accounts against the Exclusion List.

In STAS itself, use Advanced > Show live users to check which users the collector currently knows. On the firewall, the matching place is Current activities > Live users. Both views should make sense at the same time during testing.

If STAS controls business-critical rules, repeat this test after Windows updates, domain-controller changes, firewall upgrades and password changes of the service account.

Tests, logs and backup

STAS provides several local test tools. These are often faster than only looking at the firewall Log Viewer.

• Test firewall connection: Advanced > Troubleshooting > Test Connectivity > Sophos checks whether agent or collector can reach the firewall.
• Test STA Agent: Advanced > Troubleshooting > Test Connectivity > STAS Agent checks whether the collector can reach an agent.
• Test STA Collector: Advanced > Troubleshooting > Test Connectivity > STAS Collector checks whether an agent can reach a collector.
• WMI Verification: Advanced > Troubleshooting > STAS Polling Utilities > WMI Verification tests Workstation Polling via WMI against a client IP.
• Registry Read Verification: Advanced > Troubleshooting > STAS Polling Utilities > Registry Read Verification tests Workstation Polling via Registry Read Access against a client IP.

The STAS log is visible directly in the STAS application under Advanced > View Log. The log file is also located on the Windows system at:

C:\Program Files (x86)\Sophos\Sophos Transparent Authentication Suite\stas.log

Before larger changes, back up the STAS configuration in the STAS application under Advanced > Backup / Restore > Backup Now. The backup is created as a file in the format STAS_ConfigBackup_DD_MM_YYYY_THH_MM_SS.bkp. To restore, select the .bkp file under Backup / Restore and apply it with Upload and Restore.

Check STAS before SFOS 22 MR1

STAS is one of the functions that should be checked deliberately before a major upgrade. The current known-issues list includes an issue around SFOS 22.0 MR1, STAS and the Restrict client traffic during identity probe option. If this option is set to Yes, it can prevent an upgrade to SFOS 22.0 MR1 or lead to repeated Identity Probes after the upgrade and therefore temporary traffic interruptions. Because Yes is the default value, do not assume that only deliberately hardened special configurations are affected.

For administrators, the important point is that this is not a normal STAS setup problem. An environment may have worked for years and still be affected during the upgrade because a previously accepted setting becomes critical in combination with SFOS 22.0 MR1. STAS should therefore be included in the SFOS 22 upgrade check.

Before upgrading to SFOS 22.0 MR1 or later, check:

• Is STAS active at all?
• Are user-based rules used in production?
• Is Restrict client traffic during identity probe enabled?
• Are there already messages about repeated Identity Probes or unexplained short traffic interruptions?
• Is there a test user with which STAS can be checked deliberately after the upgrade?

If the affected option is active, do not assess it for the first time during the firmware maintenance window. A short separate test beforehand is better: document the change, sign in a test user, check Live Users, test the user-based rule and check Log Viewer. If STAS controls security-critical rules, also clarify whether a temporary fallback rule is needed so users are not blocked unexpectedly.

For the upgrade path to SFOS 22.0 MR1, the pragmatic rule is: if STAS is active and Restrict client traffic during identity probe is set to Yes, set the option to No before the upgrade and then validate with real test users. If this change cannot be tested beforehand, postponing the upgrade is often cleaner than a risky maintenance window. On already affected SFOS 22.0 MR1 systems, No is also the documented mitigation until a corrected release is available.

After the upgrade, check specifically:

1. Check STAS status under Authentication > STAS.
2. Check Live Users with a fresh domain login.
3. Test the user-based firewall rule with logging.
4. Check in Log Viewer whether the username is visible and not only the IP address.
5. Watch for repeated Identity Probe effects or short interruptions.

If the upgrade is blocked by a STAS message, or if reproducible interruptions occur after the upgrade, prepare a Sophos Support case. Useful evidence includes a screenshot of the upgrade message, current STAS configuration, firmware version, affected user rule and a short test sequence.

Troubleshooting

No users in Live Users

First check whether the domain controller writes matching Security Events. Then check STA Agent, STA Collector, ports and Device Access.

Typical causes:

• Audit Policy not active
• STA Agent is not running or reads the wrong domain controller
• collector is not reachable
• UDP 6060 or 6677 is blocked
• Client Authentication is not allowed in Device Access
• NAT hides the real client IP

User is mapped incorrectly

Exclusions, Workstation Polling or technical accounts are often involved. Check whether service accounts, monitoring accounts or installation accounts overwrite the same client.

User disappears too quickly

Check Logoff Detection, Dead Entry Timeout, client reachability and polling method. If clients do not respond to ping, WMI or Registry access, entries can disappear unexpectedly or remain stale.

DCOM errors or STAS queries the wrong networks

If Windows Event Viewer shows DCOM errors such as Event ID 10009 or 10028 after STAS installation, the firewall rule is not automatically the cause. The collector often tries to check clients through WMI or Registry Read Access that aren’t reachable or don’t belong to the monitored networks.

In this case, narrow the monitored networks in STAS:

1. In the STAS application, open the STA Collector tab.
2. Under Sophos appliances, select the affected Sophos Firewall and click Edit.
3. Turn on Enable subnet based filter.
4. Enter only the networks that should really be monitored.
5. In the STA Agent tab, check the same client networks under Specify the networks to be monitored.
6. Apply the changes and restart STAS.

This reduces unnecessary WMI queries and prevents users from unsuitable networks from appearing as LogonType: 1. After the change, check stas.log, Windows Event Viewer and Current activities > Live users together.

Firewall rule does not match

Do not look only at the rule. Check:

• Is the user visible under Live Users?
• Is the correct AD group detected?
• Does an earlier firewall rule match?
• Is logging enabled on the rule?
• Does Log Viewer see the user or only the IP address?

Transition period for unauthenticated traffic

For transition phases, the firewall allows unauthenticated traffic for a short period by default. This value can be checked or changed through the Device Console:

system auth cta unauth-traffic drop-period

Do not change this setting blindly. First clarify whether the issue is really the transition period or an incorrect STAS mapping.

If the firewall sees traffic from an IP address for which STAS does not yet know a user, this IP is first checked in learning mode. During this phase, traffic can be dropped. If the collector does not respond, the firewall treats the IP as unauthenticated for a certain period. For devices outside the domain, do not expect STAS to cover them automatically and cleanly. Clientless Users or separate rules may be more appropriate for such systems.

STAS over VPN

STAS can also be used in an IPsec VPN scenario when users at a remote site authenticate against a domain controller at the main site. This should only be planned deliberately because routing, source IP, STAS monitored networks and firewall zones must match.

Requirements for this design:

• IPsec connection is active and stable.
• Branch traffic is routed through the tunnel.
• STAS and Active Directory are configured correctly at the main site.
• The branch network is entered in STAS as a monitored network.
• The branch firewall is configured as a Sophos Appliance in the STA Collector configuration.
• Client Authentication is allowed for the VPN zone in Device Access.

On the firewall at the main site, add the remote network for STAS through the Device Console. Example:

system auth cta vpnzonenetwork add source-network 172.50.50.0 netmask 255.255.255.0

Replace the example with the real branch network. In many environments, it is still simpler and more robust to use STAS only for local client networks and design remote sites separately.

STAS, SATC and Remote Desktop Servers

Classic STAS works well when one client IP usually belongs to one user. On Remote Desktop Servers, terminal servers or Citrix systems, however, several users share the same IP address. Classic STAS cannot distinguish these sessions cleanly per user.

In such environments, check Sophos Authentication for Thin Client (SATC). SATC is not a simple checkbox in STAS, but its own design topic:

• Which servers are affected?
• Which users work through these servers?
• Which firewall rules really need to be user-based?
• Is there mixed traffic from server services and user sessions?
• How will the behaviour be tested and documented?

If terminal servers are only used rarely, it may be better to segment these connections differently or use separate rules without user identity. The decisive point is that authentication must match the real network architecture.

Operational checklist

Before installation:

• AD server works on Sophos Firewall.
• Client networks and domain controllers are documented.
• No NAT hides client IP addresses.
• Service account and permissions are defined.
• Audit Policy is active on relevant domain controllers.
• Exclusion List is prepared.

After installation:

• Agent and collector are running.
• Ports between agent, collector, firewall and clients are open.
• Live Users show the test user.
• User-based firewall rule matches in Log Viewer.
• Logoff, user switching and technical accounts were tested.
• Collector redundancy is documented if required.

In operation:

• Monitor the service account.
• Maintain the Exclusion List regularly.
• Align Windows Firewall and GPO changes with STAS.
• Regularly align subnet-based filters and monitored networks with the real client structure.
• Test STAS after firewall and domain-controller upgrades.
• Before SFOS 22.0 MR1 or later, check Restrict client traffic during identity probe.
• Do not improvise with STAS for RDS/Citrix; check SATC or another design instead.

FAQ