Set up Sophos Firewall SATC for Remote Desktop Services

Sophos Authentication for Thin Client, or SATC for short, enables user-based rules for Remote Desktop Services. This is important whenever several users access the network or the internet through the same Windows Remote Desktop Session Host. Classic STAS often sees only the IP address of the terminal server in such cases. SATC, by contrast, supplies Sophos Firewall with user information from the individual RDS sessions.

For standard Windows clients, start with setting up STAS on Sophos Firewall. SATC is not a replacement for STAS in every environment, but the right building block for Remote Desktop Services.

Deployment and planning

When SATC is useful

SATC fits when users do not pass through the firewall directly from their own client, but use applications or browsers on a Remote Desktop Session Host.

Typical scenarios:

• Remote Desktop Services with several simultaneous users
• terminal servers where users need web access or application access
• user-based firewall rules for RDS users
• reporting where more than just the RDS server IP address should be visible
• environments where STAS is insufficient because users share a source IP

SATC is not the right starting point for normal domain clients, VPN users or pure Captive Portal scenarios. In those cases, choose the appropriate authentication model first: STAS, Captive Portal, VPN authentication, RADIUS or Microsoft Entra ID SSO.

On an individual, non-domain-joined endpoint, the Client Authentication Agent can provide deliberate user sign-in. It does not replace SATC on a multi-user host because several sessions share the same source IP.

If a multi-user host only needs to distinguish HTTP and HTTPS through an explicit proxy, Per-Connection AD SSO through the Direct Web Proxy may be sufficient without a SATC agent. As soon as RDP, SMB, or other non-proxy traffic also needs an identity per user session, SATC remains the appropriate design.

Keep STAS and SATC clearly separate

The key difference is the IP mapping.

• One Windows client typically belongs to one user: STAS.
• Many users share the same RDS server IP: SATC.
• Users log in through the browser so that rules apply: Captive Portal.
• Users connect through Remote Access VPN: VPN authentication or Entra ID SSO.
• Traffic passes through technical servers without user context: normal firewall rules without users.

If a terminal server is incorrectly represented through STAS or Clientless User, false expectations quickly arise. A rule appears to be user-based, but the firewall actually sees only a shared server IP. SATC solves exactly this problem, but requires its own configuration on the Windows Server and on the firewall.

If STAS and SATC are used at the same time, the conceptual separation alone is not enough. Citrix XenApp and Windows Server RDS can cause STAS to return incorrect user identity for the same server IP if it is not excluded. Because of this, the IP addresses of the Citrix/RDS servers must be entered in the STAS configuration under Login IP Address/Network Subnet mask Exclusion List and Logoff IP Address/Network Subnet mask Exclusion List. Without this exclusion, STAS can keep delivering its own, conflicting user mapping for exactly the server IPs that are meant to use SATC.

Requirements

Clarify these points before setup:

• Sophos Server Protection can be used on the Remote Desktop Session Host.
• The Windows Server runs as a Remote Desktop Session Host.
• Windows Server 2016 or newer is used.
• Sophos Firewall is reachable.
• Active Directory is connected to Sophos Firewall.
• The required AD groups are imported on the firewall.
• Under Administration > Device access, the RDS server’s zone is allowed in the Clients row.
• The RDS server can reach the firewall IP over UDP 6060; any intervening host or network firewall allows this path.
• Firewall rules can later work with Match known users.
• There is a maintenance window for the registry change and restart of the RDS server.

AD integration should be configured correctly before setting up SATC. If AD is not ready yet, first check connect Active Directory to Sophos Firewall.

Important limits

SATC has a few limits that should be understood before rollout:

• Standalone SATC: No longer supported by Sophos Firewall.
• Deployment: SATC runs through Sophos Server Protection or the Sophos Fusion Server Core Agent.
• Platform: According to Sophos, the current setup with Sophos Server Protection only supports Windows Remote Desktop Services. The older overview still mentions Citrix XenApp in the context of the STAS conflict, and the CLI parameter is still named citrix-ip. Neither is current proof of support for a new Citrix rollout. Confirm an existing Citrix deployment with Sophos Support before making changes and do not build a new deployment from this RDS guide.
• System services: SATC assigns a directory identity only to connections created by user-based processes. Processes started by Windows system services remain without a user identity and require a separate, narrowly scoped machine rule with Match known users turned off. Do not use this rule as a broad fallback for the remaining RDS traffic.
• Server limit: Sophos states up to 192 thin-client servers on the firewall.
• Authentication per server IP: If an RDS server IP is stored on the firewall as a thin client, SATC works as the authentication method for this IP. Other methods such as Clientless User do not apply to this IP.

The last point in particular is important. Do not add production terminal server IPs just for testing without understanding the ruleset and return path. As soon as the IP is treated as a SATC source, expectations for user mapping and rule matching change.

Configuration

Process overview

The technical process consists of five parts:

1. Install Sophos Server Protection on the RDS server.
2. Enable SATC on the RDS server through the registry.
3. Add the RDS server IP in the Device Console of Sophos Firewall.
4. Check AD server, groups and authentication order on the firewall.
5. Validate Device Access, firewall rule and Live Users.

SATC should not only be installed, but also tested. Successful installation on the server does not prove that the firewall will later see the right user in the right rule.

Install Sophos Server Protection

Installation is done through Sophos Fusion (formerly Sophos Central).

Procedure:

1. Sign in to Sophos Fusion.
2. Open Protect Devices.
3. Under Server Protection, download the Windows Server installer.
4. Install the installer on the Remote Desktop Session Host.
5. Check whether the server appears correctly in Sophos Fusion.
6. Define a maintenance window for SATC activation.

SATC is part of the Sophos Fusion Server Core Agent and, according to Sophos, is available with any Server Protection licence. Which installers are actually visible in Sophos Fusion still depends on the available licences. If Sophos Server Protection is already running on the server, also check whether the agent is current and whether Tamper Protection can be disabled in a controlled way and then enabled again.

Enable SATC through the registry

SATC is controlled on the RDS server through registry values under this path:

HKLM\Software\Sophos\Sophos Network Threat Protection\Application

Before making changes, use this read-only command to see which SATC values already exist:

reg query "HKLM\Software\Sophos\Sophos Network Threat Protection\Application"

Caution: Registry changes and the subsequent restart affect all active RDS sessions. Document the current values, use a maintenance window and disable Tamper Protection only in a controlled manner. Re-enable it after the change.

The basic configuration can be set in an administrative command prompt:

reg add "HKLM\Software\Sophos\Sophos Network Threat Protection\Application" /v SendSatcEvents /t REG_DWORD /d 1 /f
reg add "HKLM\Software\Sophos\Sophos Network Threat Protection\Application" /v SatcDestinationAddr /t REG_SZ /d FIREWALL-IP /f
reg add "HKLM\Software\Sophos\Sophos Network Threat Protection\Application" /v SatcDestinationPort /t REG_DWORD /d 6060 /f

Replace FIREWALL-IP with the IPv4 address of Sophos Firewall that is reachable from the RDS server’s zone. Sophos documents UDP 6060 for SATC, so 6060 remains unchanged in the example. Don’t use a public WAN address when the server and firewall communicate through an internal interface.

Avanet recommendation: Connect only one RDS host first and allow UDP 6060 between exactly this host and the firewall. This limits an error to the pilot server before adding further session hosts.

Afterwards:

1. Enable Tamper Protection again.
2. Restart the RDS server.
3. After the restart, check whether the Sophos service is running.
4. Run the read-only reg query command again and verify the configured values.
5. Only then continue with firewall configuration and tests.

Exclude local accounts and destinations

By default, local accounts such as SYSTEM or Administrator can also generate SATC events. This is usually not helpful for user rules and can unnecessarily pollute logs.

SatcExcludedUsers can be used to exclude users. The entries are case-sensitive, so the names must use the spelling that appears on the system.

Example:

reg add "HKLM\Software\Sophos\Sophos Network Threat Protection\Application" /v SatcExcludedUsers /t REG_MULTI_SZ /d "SYSTEM\0administrator" /f

SatcExcludedAddresses can be used to exclude destinations for which no SATC information should be sent to the firewall. This can be useful for local management, update or infrastructure destinations, but should be documented deliberately.

SatcExcludedAddresses is a multi-string value (MULTISTRING / REG_MULTI_SZ). When setting multiple destinations with reg add in Windows Command Prompt, separate entries in the /d data argument with \0, not commas. The maintenance, tamper-protection, verification and rollback steps described above also apply to this change.

Possible formats:

192.0.2.10
192.0.2.10:443
*:443

192.0.2.10 is a documentation address and must be replaced with the actual destination IP. The second entry applies only to port 443 on this destination, whereas *:443 covers this port for every destination. Such a broad exception would effectively remove all HTTPS traffic from SATC mapping and is unsuitable for normal user rules.

Avanet recommendation: Start without exceptions and add one only after a conclusive log finding. Give every exception an owner, purpose, and review date.

If there is noticeable network latency between the RDS server and the firewall, SatcPendDurationMs can also be set. The value determines how long outbound IPv4 TCP connections are held so that user mapping is available in time. If the registry value is absent, SATC uses 100 milliseconds; 0 disables only this connection delay, not SATC. Change the value only for actual latency problems, not as a precaution.

reg add "HKLM\Software\Sophos\Sophos Network Threat Protection\Application" /v SatcPendDurationMs /t REG_DWORD /d 300 /f

300 is an adjustable diagnostic example, not a recommended new default. It increases the delay from the documented default of 100 milliseconds for every affected outbound IPv4 TCP connection. Measure with the same user and destination before and after the change. If it doesn’t help, the following administrative command restores the default by deleting the optional value:

reg delete "HKLM\Software\Sophos\Sophos Network Threat Protection\Application" /v SatcPendDurationMs /f

As with the other registry changes, a restart of the RDS server is required afterwards.

Add the RDS server on the firewall

The firewall must know which servers deliver SATC information. This is done in the Device Console, not in the Advanced Shell.

Procedure:

1. Log in to Sophos Firewall by console or SSH.
2. Open option 4. Device Console.
3. Show existing entries:

system auth thin-client show

4. Add the RDS server IP only if it is not already listed:

system auth thin-client add citrix-ip <RDS-SERVER-IP>

<RDS-SERVER-IP> is replaced with the IP address of the Remote Desktop Session Host.

If several RDS servers are present, add and document each server individually. Afterwards, it should be clear:

• which servers count as SATC sources
• which zone these servers use
• which firewall rules evaluate users from these servers
• who approves changes to the RDS server list

If an incorrect IP address was added, check the list again and then remove it deliberately:

system auth thin-client delete citrix-ip <RDS-SERVER-IP>

The command removes only the thin-client entry on the firewall; registry values and Sophos Server Protection on the RDS server remain in place. Removing a production IP also removes its SATC mapping, so user-based rules may no longer match. Sophos does not document how existing sessions react. Therefore, delete the entry only during a maintenance window and with a prepared rollback path.

Check Active Directory and groups

SATC delivers user information. For the firewall to use this information in rules, the AD connection and groups must be correct.

Check:

1. Open Authentication > Servers.
2. Check the AD server with Test connection.
3. Check group import.
4. Open Authentication > Groups.
5. Search for relevant groups.
6. Open Authentication > Services.
7. Check the AD server in the correct order of the firewall authentication methods.

Only if AD should be queried first: Before changing anything, record the current order and check the intended authentication order and rollback plan; do not indiscriminately reorder production authentication. Under Authentication > Services > Firewall authentication methods, select the relevant AD server, move it to the first position in the list of selected servers and click Apply. If the change has unwanted effects, restore the documented previous order and click Apply.

For AD group assignment, Sophos documents that authentication maps users to their AD groups imported on the firewall; groups are evaluated and updated at every sign-in. Only if none of the user’s AD groups exists on the firewall does the user receive the Default group configured under Authentication > Services > Firewall authentication methods. This fallback does not replace a missing group import.

Source conflict at first sign-in: The SATC setup description states that users are automatically assigned to the default group on their first firewall sign-in, whereas the AD group description gives a conditional fallback. Whether this refers to a SATC-specific initial state is unresolved. Do not assume either universal default-group assignment or a special SATC group priority.

Before production rollout: Verify the imported groups under Authentication > Groups and the actual configured Default group and its inherited settings under Authentication > Services. Have a test user sign in again, check their effective group assignment under Authentication > Users, and use RDS test traffic in Log Viewer to verify the intended rule match and both allowed and blocked access. If the fallback is intended to be used, also test it with a test account whose AD groups are not present on the firewall, without deleting production groups. Default-group membership alone does not prove the intended rule match. If assignment is unexpected, stop the rollout and clarify it with Sophos Support; do not broaden user groups or rules as a workaround.

If users appear in the Live Users area but rules do not apply, the cause is often not SATC itself, but group import, default group, rule criterion or rule position.

Set Device Access and firewall rule

For the firewall to accept SATC messages from the server zone, the local service Clients must be allowed for this zone. SFOS 22 documents UDP 6060 for it; Clients also covers STAS and the Client Authentication Agent on its own port.

Path:

Administration > Device access

Enable the RDS server zone in the Clients row. Do not blindly open WAN or a broad insecure zone. Device Access controls local firewall services and is part of management hardening.

The actual traffic then needs a firewall rule.

Typical sequence:

1. Open Rules and policies > Firewall rules.
2. Create a suitable rule for traffic from the RDS server or server zone. As an adaptable example, rule RDS-Web-Users can initially allow only the required HTTPS service from host object RDSH-01 in LAN to WAN.
3. Adapt Source zones, Source networks and devices, Destination zones, and Services to your topology. RDSH-01, LAN, WAN, and HTTPS are examples, not product requirements.
4. Enable Match known users.
5. Select the required AD users or AD groups.
6. Enable logging so that the test can be traced later.
7. Save the rule.
8. Generate test traffic from an RDS session.

Avanet recommendation: Make the pilot rule narrower than the later production rule and place it immediately above a documented block rule. Expand services or user groups only after a successful test with two different RDS users.

Logging is important for later troubleshooting. If a user rule is created without logging, it is harder to see whether SATC, group matching, rule order or another path is the problem.

Validation and operations

Validate after setup

After configuration, do not only check whether a user has internet access. The decisive point is whether the firewall sees the right user and matches the right rule.

Practical test:

1. Log in a user to an RDS session.
2. Generate defined test traffic, for example an allowed HTTPS connection.
3. In Sophos Firewall, open Current activities > Live users.
4. Check whether the user appears with Client type Thin client.
5. Check that the RDS server IP address appears with a unique session ID for each user.
6. Open Log Viewer.
7. Filter by Source IP of the RDS server, user and rule.
8. Check whether the expected user-based rule applies.

Repeat the test with a second user and the same destination connection. Success means more than both connections being allowed: Live users must show two identities with the same RDS server IP but different session IDs, and Log Viewer must show the correct user for each. Also test a documented system service if you created a separate machine rule for it; this traffic must not be incorrectly attributed to a signed-in user.

For deeper analysis in the Advanced Shell, firewall_rule.log is relevant for rule matching and access_server.log for authentication and authorization. Log Viewer remains the faster first check.

If traffic does not behave as expected, test a firewall rule with Log Viewer, Policy Test and Packet Capture also helps. If users are visible but groups or individual users do not match, Sophos Firewall rule does not match is the next useful troubleshooting path.

Operations and documentation

SATC should be operated like a production authentication component, not like a one-off registry hack.

Document:

• RDS servers and IP addresses
• firewall IP and SATC port used
• registry values set
• excluded users and destinations
• affected firewall rules
• AD groups and owner
• test user and expected rule match
• maintenance window and restart time

After updates to Sophos Server Protection, Windows Server, Sophos Firewall or AD, SATC should be checked deliberately with a test user. Authentication issues often become apparent only when user rules suddenly apply too broadly or no longer apply at all.

Roll back in a maintenance window

Sophos documents that SendSatcEvents enables SATC only when the value exists and is non-zero, and that the thin-client entry displaces other authentication methods for this server IP. This provides a planned return path, but it doesn’t automatically restore the previous identity method.

1. First record the registry query, the output of system auth thin-client show, affected rules, and the previous authentication model.
2. Sign out active RDS sessions during the maintenance window, turn off Tamper Protection in a controlled manner, and disable SendSatcEvents in an administrative command prompt:

reg add "HKLM\Software\Sophos\Sophos Network Threat Protection\Application" /v SendSatcEvents /t REG_DWORD /d 0 /f

3. Re-enable Tamper Protection and restart the RDS server.
4. In the Device Console, verify the entry with system auth thin-client show, then delete it deliberately:

system auth thin-client delete citrix-ip <RDS-SERVER-IP>

5. Restore the previously documented rule and authentication model and validate it with a test user. Don’t enable a Clientless User or broad machine rule as a replacement without testing it.

Avanet recommendation: Don’t delete all registry values before identifying the cause. A value of 0 preserves the destination address and exclusion lists for controlled reactivation; a registry export also preserves the exact starting state.

Troubleshooting

No thin-client user visible

Check:

• RDS server was restarted after the registry change.
• SendSatcEvents is set and not 0.
• SatcDestinationAddr points to the correct firewall IP.
• SatcDestinationPort matches the expected port.
• Network path from the RDS server to the firewall is open for UDP 6060.
• RDS server IP was added on the firewall with system auth thin-client add citrix-ip.
• The RDS server’s zone is allowed in the Clients row under Device Access.

User remains unauthenticated because of a source-port conflict

Proxy or security software on the RDS server can change a connection’s source port. The firewall then detects a port mismatch and treats the traffic as unauthenticated. Do not confuse this source port with SatcDestinationPort: the registry value specifies the destination port for SATC messages, which is 6060 by default. Test such software in a controlled manner or configure it appropriately for the SATC path; do not disable protection features indiscriminately.

User appears, but rule does not match

Check:

• user or group is imported on the firewall.
• rule uses Match known users.
• the correct AD group is selected in the rule.
• rule position is suitable.
• there is no earlier rule that matches the same traffic without user context.
• Log Viewer shows the same user, the same Source IP and the same service.

Local accounts appear in logs

Check SatcExcludedUsers and add technical accounts. Common candidates are local administrators, services and system accounts. However, the list should not become so broad that real users are accidentally excluded.

Individual destinations get no user context

Check SatcExcludedAddresses. If a destination or port has been excluded, SATC does not send authentication information for it to the firewall. This can be intentional, but can easily cause confusion with user rules.

After adding the server IP, an old Clientless User no longer applies

This is expected. If the RDS server IP has been added on the firewall as a thin-client server, SATC should be the authentication model for this IP. Old workarounds with Clientless Users should be removed or replaced deliberately.

No internet access after upgrading to SFOS 22.0 GA

If the user appears as a Thin client but has had no internet access since the upgrade, first record the firmware version and rule match and collect firewall_rule.log and access_server.log. The official SFOS 22.0 release notes list NC-178903 under SFOS 22.0 MR2 Build 546 as a fixed issue affecting upgrades to SFOS 22.0 GA. Sophos does not provide a unique log signature or a separate workaround. See the SFOS 22.0 MR2 overview for release context.

Checklist

• RDS scenario really fits SATC and not normal STAS.
• Sophos Server Protection is installed on the Remote Desktop Session Host.
• Windows Server version and RDS role have been checked.
• Tamper Protection was disabled only in a controlled way and then enabled again.
• SendSatcEvents, SatcDestinationAddr and SatcDestinationPort are set.
• RDS server was restarted.
• RDS server IP was added in the Device Console on the firewall.
• AD server and AD groups have been checked on the firewall.
• Clients is allowed for the correct zone under Device Access and UDP 6060 is reachable.
• firewall rule uses Match known users and has logging enabled.
• user appears under Current activities > Live users with Client type Thin client.
• Log Viewer shows the expected user and the expected rule.

FAQ