Set up Sophos Firewall SATC for Remote Desktop Services

Sophos Authentication for Thin Client, or SATC for short, helps with user rules on 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.

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.
• Client Authentication is allowed under Device Access for the zone of the RDS server.
• 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 Central Server Core Agent.
• Platform: SATC with Sophos Server Protection is intended for Windows Remote Desktop Services. Sophos also names Citrix XenApp as a supported scenario with limitations; this is also reflected in the citrix-ip parameter name in the CLI command.
• 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 Central.

Procedure:

1. Sign in to Sophos Central.
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 Central.
6. Define a maintenance window for SATC activation.

Which installers are visible depends on the available Sophos licences. If Sophos Server Protection is already running on the server, still 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

FIREWALL-IP is replaced with the IP address of the Sophos Firewall to which the RDS server should send the SATC information. The default port is 6060.

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.

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.

Possible formats:

192.0.2.10
192.0.2.10:443
*:443

Exceptions should be kept narrow. If overly broad destinations are excluded, the firewall will later see less user context than expected.

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

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.

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 Client Authentication from the server zone, Client Authentication must be allowed for this zone.

Path:

Administration > Device access

Enable the RDS server zone under Client Authentication. 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 from the server zone.
3. Set Source zone and Destination zone appropriately.
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.

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 the IP address of the RDS server and the session mapping.
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.

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.

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.
• RDS server IP was added on the firewall with system auth thin-client add citrix-ip.
• The zone of the RDS server allows Client Authentication 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. Sophos confirms issue NC-178903 for upgrades to SFOS 22.0 GA and fixes it in SFOS 22.0 MR2 Build 546. 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.
• Client Authentication is allowed for the correct zone under Device Access.
• 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