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.

This article explains when SATC is useful, which limits apply, how to enable SATC through Sophos Server Protection and how to check afterwards whether users appear correctly in Sophos Firewall.

For normal Windows clients, set up STAS on Sophos Firewall is relevant first. SATC is not a replacement for STAS in every environment, but the right building block for Remote Desktop Services.

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 not cleanly sufficient because of the shared 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 authentication model cleanly 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.

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.

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.

The AD connection itself should not be done casually alongside this work. If AD is not yet set up cleanly, first check connect Active Directory to Sophos Firewall.

Important limits

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

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.

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 cleanly 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, document the current settings. If Tamper Protection is active on the server, it must be disabled in a controlled way for the change and then enabled again.

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. 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 consciously documented.

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.

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. Add the RDS server IP:

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

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.

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.

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 fits as the next check path.

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 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 consciously replaced.

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 often only becomes noticeable when user rules suddenly apply too broadly or no longer apply at all.

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