Set up Sophos Firewall Per-Connection AD SSO for multi-user hosts

Several users work on the same Remote Desktop Session Host, but Sophos Firewall sees only one server IP for all connections. Per-Connection AD SSO solves this specific case for web traffic: the Direct Web Proxy authenticates each HTTP and HTTPS connection separately with Kerberos or NTLM.

The feature is not limited to Windows RDS: a multi-user Linux server can also use this connection model, provided its clients support the Direct Web Proxy and Kerberos or NTLM. This example walks through a Windows RDS pilot; the Windows commands and GPO deployment are not instructions for Linux. Hosts outside the Multi-user hosts list retain their previously configured IP-based authentication.

The limitation is as important as the feature. Only connections that the browser or application explicitly sends to the proxy receive a user identity. DNS, RDP, SMB and other non-proxy traffic from the same server IP remain unauthenticated. If these protocols also require user-based control, SATC for Remote Desktop Services is the better choice.

⚠️ As soon as an IP address is entered under Multi-user hosts, it no longer uses other IP-based authentication methods. STAS, Captive Portal, Clientless User and transparent AD SSO no longer apply to this IP. Start by testing with exactly one pilot server and documenting the existing authentication path.

Per-Connection AD SSO in nine steps

1. Decide whether only HTTP and HTTPS sent through an explicit proxy need user-based processing.
2. Check Active Directory, group import, DNS, time and the firewall’s domain join.
3. Prepare a resolvable firewall FQDN and a matching HTTP SPN for Kerberos.
4. Assess scope and security impact first; then enable AD SSO for the required LAN zone under Administration > Device access and select Apply. Separately scope Web proxy access to the pilot host with a targeted ACL exception where supported; an accept exception does not narrow zone permission. If the required zone permission is unacceptable, stop rollout and obtain a supported, scoped design.
5. Create the RDS server as an IP host object with its exact IP address.
6. Enable Per-Connection AD SSO for this host under Authentication > Web authentication.
7. Configure browsers and proxy-capable applications to use the firewall FQDN and port 3128.
8. Place a dedicated, logged host rule before competing user rules and leave Match known users disabled.
9. Test two simultaneous RDS sessions, different web policy results and non-proxy traffic separately.

Per-Connection AD SSO, STAS or SATC?

All three methods provide user context, but solve different problems.

• STAS suits standard Windows clients where a client IP typically belongs to exactly one user. The firewall receives a user-to-IP mapping from Windows logon events.
• Per-Connection AD SSO suits multi-user hosts where only explicitly proxied HTTP and HTTPS connections need to be distinguished. No SATC agent is required on the RDS server, but all applications must reliably use the Direct Web Proxy.
• SATC suits supported Windows RDS systems where other connection types from individual user sessions also need an identity. This requires Sophos Server Protection on the Session Host. The current Sophos instructions do not substantiate a new Citrix rollout; existing Citrix installations should be discussed with Sophos Support before making changes.

Conventional STAS on Sophos Firewall cannot distinguish multiple users behind the same RDS IP. Per-Connection AD SSO and SATC are therefore not more convenient variants of STAS, but separate operating models. SATC also maps only user-based processes; connections generated by system services still need a separate rule without Match known users. If an application does not support an explicit proxy or non-web protocols require user-based rules, stop here and assess SATC.

Example and values to replace

The procedure uses this example:

• Multi-user host: RDS01
• IP address: 10.20.30.40
• Firewall FQDN and proxy destination: fw01.corp.example
• Direct Web Proxy port: 3128
• AD groups: RDS-Web-Standard and RDS-Web-Restricted
• One pilot account per group, with deliberately different web policy results

Replace 10.20.30.40 with the pilot server’s fixed IP address as seen by the firewall. No other systems may also appear behind this address through NAT. fw01.corp.example is a documentation name and must be replaced with the real, internally resolvable firewall FQDN. The host portion should be no more than 15 characters long and in lower case so that the hostname, NetBIOS name, AD computer object and SPN match.

Port 3128 is the default for the Direct Web Proxy. If your environment uses a different listening port, the firewall, PAC file or GPO, browsers and tests must all use the same value. The example groups are only intended to make acceptance testing clear; group names and web policies must match your own permissions structure.

Prepare the prerequisites

Check Active Directory and the domain join

The firewall requires a working Active Directory server, imported groups and a successful domain join. Connect Active Directory to Sophos Firewall explains LDAPS, the search base, group import and the general AD SSO prerequisites.

If the AD server has not yet been configured, select Active Directory under Authentication > Servers > Add. Enter the server name, the reachable DC IP or DC FQDN, NetBIOS domain, AD domain and search base for your environment. For corp.example, the search base is dc=corp,dc=example. Encrypt the connection using SSL/TLS on port 636 or STARTTLS on port 389, and prepare certificate validation as described in the linked AD procedure. Enter the read/join account with the permissions described below, run Test connection and save with Save. Do not replace an existing AD server solely for the pilot or change its credentials without checking them first. If the domain enforces strict LDAP channel binding or LDAP signing, establish compatibility using the AD procedure before rollout; the Sophos AD server help lists a limitation here. Do not disable a domain-wide security requirement to troubleshoot a problem.

During group import, selecting an organisational unit (OU) automatically selects all groups it contains. Attach to all the Groups assigns the selected shared policies to every group imported by the wizard. Before finishing, therefore, check the group list expanded by the OU selection and the scope of these policies; accept only the groups actually needed and the intended policy assignments.

For the pilot, open Import for the AD server under Authentication > Servers > Manage, begin with Start in the Import group wizard and select the appropriate Base DN. For the example domain corp.example, this is dc=corp,dc=example; replace the domain components, not the LDAP syntax. Select RDS-Web-Standard and RDS-Web-Restricted, check the shared policy assignment and the summary, complete the wizard and close it with Close. Then check under Authentication > Groups that both groups are actually present. A successful domain join alone does not import the required policy groups.

An account with read permissions is sufficient for normal LDAP queries. Joining the domain and creating the SPN, however, require a Domain Admin account or an account with properly delegated permissions. The configured account must also allow a later rejoin, because HA, additional AD servers or upgrades can trigger this again. An unrestricted Domain Admin account should not be used permanently for this purpose unless necessary.

Under Authentication > Services > Firewall authentication methods, select the intended AD server and put it in the correct order. If there are multiple servers, the firewall checks them from top to bottom. Test connection on the AD server confirms only credentials and reachability, not subsequent Kerberos or NTLM authentication in the browser.

In the same section, choose the Default group deliberately and save with Apply. If the required AD group has not been imported, a successfully authenticated user may end up in the default group rather than receiving the intended group policy. Users in an OU who are not members of a directory group may appear in the Open group. Where a user belongs to multiple groups, the first matching group may determine the policy; check not only the import, but also the order and actual assignment. For the pilot, therefore, do not use a broadly privileged default group as a substitute for a missing import. At the first new logon, check the actual group assignment under Authentication > Users; a user object does not have to be visible before this logon.

Check the FQDN, DNS, SPN and time

Kerberos works only if clients use the firewall FQDN as the proxy destination. A proxy IP address is not sufficient. These read-only checks are useful on a Windows pilot client:

Resolve-DnsName fw01.corp.example
setspn -Q HTTP/fw01.corp.example
w32tm /query /status

The HTTP SPN, short for Service Principal Name, binds the proxy FQDN to the firewall’s AD computer object. setspn -Q should return exactly one matching assignment. No matches or multiple matches must be resolved before rollout.

The DNS suffix configured in the hostname field is not automatically the AD suffix: when joining the domain, the firewall constructs the AD computer name and SPN from its NetBIOS name and the AD domain. If the DNS domain and AD domain differ, compare the FQDN registered on the AD computer object with the planned proxy destination. The example assumes a matching SPN for fw01.corp.example; simply entering this name under Admin and user settings does not prove that it exists. First establish both DNS and the SPN for the actual proxy destination, then distribute the proxy configuration. Do not create additional SPNs speculatively.

The DNS response must point to the intended firewall. The client, domain controller and firewall also need time settings suitable for Kerberos. These commands do not change anything. Do not adjust the SPN, domain join or time configuration speculatively; first establish evidence of the actual fault.

Identify proxy support and exceptions

Every browser and application whose web traffic needs a user identity must use the explicit proxy and support Kerberos or NTLM; in this Windows RDS example, this is done through integrated Windows authentication. Before rollout, check at least:

• Browsers in every supported RDS session
• Applications with their own HTTP stack
• Windows and software updates
• Services running in the system context rather than a user session
• Destinations listed in the PAC file or proxy bypass list

Traffic that bypasses the proxy remains without a user ID, as expected. Plan a separate, tightly scoped rule without user-based matching for necessary machine connections. A broad Any rule would weaken the security effect of the user and web policies.

Configure Per-Connection AD SSO

1. Prepare the firewall FQDN and AD SSO

Enter the intended firewall FQDN under Administration > Admin and user settings and save with Apply. Then, under Authentication > Web authentication, select Kerberos & NTLM for If Active Directory (AD) SSO is configured and save with Apply again. NTLM is technically supported as a fallback; Kerberos is faster and more secure and should work reliably in the pilot. Since every proxy connection can trigger authentication, also monitor authentication failures, response times and the load on the firewall and AD under representative traffic before a larger rollout. Do not infer a fixed load multiplier or guaranteed user capacity from this.

If endpoints are not configured correctly for Kerberos or the browser does not support Kerberos authentication, NTLMv2 is automatically used as a fallback. Unlike Kerberos, NTLMv2 does not require an FQDN as the proxy destination. However, this compatibility fallback does not guarantee successful authentication: the authentication channels described below must be initialised, and the actual authentication path must be tested with the pilot accounts.

After AD SSO initialisation, these success messages must appear in the Log Viewer under Authentication:

• Kerberos authentication initialized successfully
• NTLM authentication channel established successfully

The firewall offers these methods only when both channels are working. Cannot initialize Kerberos authentication or Cannot establish NTLM authentication channel are signals to stop, not invitations to restart services blindly.

2. Restrict Device Access permissions

Sophos requires AD SSO to be enabled for the required LAN zone under Administration > Device access, followed by Apply, as a prerequisite for Kerberos/NTLM. Assess the zone scope and security impact before enabling it; do not blanket-open LAN without that review. Disabling AD SSO in all zones prevents Kerberos/NTLM, and a host-only AD SSO ACL exception does not replace this prerequisite. Adding an accept exception cannot narrow an existing zone permission. If the required zone permission is unacceptable, stop rollout and obtain a supported, scoped design for the installed build from the ACL owner or Sophos Support. Separately, restrict Web proxy source reachability to the pilot host using a targeted Local service ACL exception rule where supported. An accept exception does not narrow existing zone-wide Web proxy permission; that broad proxy permission must not remain enabled for genuinely host-scoped access. Enable no unnecessary additional zones or services. Device Access and Local Service ACL explains the full setup.

Web proxy access has an important side effect: an allowed host can reach the firewall’s HTTP and HTTPS services through the proxy even if their zone is not permitted in the normal local service matrix. Therefore, test from the pilot host that access to WebAdmin, User Portal and other local destinations is denied where required. If this exposure is unacceptable in your network, do not activate the design in production.

Under Web > General settings, check the actual Web proxy listening port and the allowed destination ports. Change the default 3128 only if the PAC file, GPO and all managed applications can be updated consistently.

3. Create the multi-user host

Create a new host object at this path:

Hosts and services > IP host > Add

Use these values for the example:

1. Name: RDS01
2. IP version: IPv4
3. Type: IP
4. IP address: 10.20.30.40

Save with Save and check that the object contains the exact pilot IP before selecting it in the multi-user list.

Do not enter an entire range or subnet for the first test. Otherwise, many systems may lose their existing IP-based authentication at once. Once each host has passed individual acceptance testing, multiple approved hosts can be brought together in a host group in a controlled manner.

4. Enable Per-Connection AD SSO

Go to this section:

Authentication > Web authentication > Authentication settings for direct web proxy

Then:

1. Enable Use per-connection AD SSO authentication for multi-user hosts.
2. Under Multi-user hosts, use Add new item to add the RDS01 object.
3. Save with Apply.

From this point onwards, STAS, Captive Portal, Clientless User and transparent AD SSO are no longer available for 10.20.30.40. Make the change during a maintenance window and do not use an existing RDS session as the only test.

Optional API mapping for automation

If you want to automate this GUI step, the API reference for SFOS 22.0 and 23.0 documents the entity DirectWebProxyAuthentication. It maps to the switch and multi-user list as follows. Add the operation wrapper and other required fields to construct an executable request.

• DirectWebProxyAuthentication > PerConnectionAuth corresponds to the on/off switch for Per-Connection AD SSO. The parameter is documented as an optional SCALAR and allows only Enable or Disable. The slash notation in the reference example indicates alternatives, not a third permitted value.
• DirectWebProxyAuthentication > MultiUserHosts > Host describes the list of multi-user host names: in this example, the name of the previously created host object RDS01, not its IP address. Host is optional and documented as an ARRAY with data type STRING. Multiple values are allowed, and the reference states that duplicate values are ignored. The reference specifies a maximum of 1500 characters, but does not explain whether this limit applies to each value or to the entire list.

The Default columns are blank: this establishes neither a documented default value nor what happens when fields are omitted. The operation section also does not describe whether a submitted list adds to or replaces existing entries, or how entries are removed. Therefore, do not interpret either omission or an empty list as a safe rollback method; the specific update and removal behaviour must be established for the build in use before automation.

The status table contains 200 and 500. These reference values confirm neither the actual HTTP transport status nor successful user and policy processing. The message fields reference JavaScript; the operation section provided does not supply literal response messages.

The prerequisites above and the tightly scoped single-host pilot still apply to any subsequent authorised API change. Before making the change, securely save the actual settings and have an independent management access path available. Afterwards, read back the switch setting and the complete multi-user list from the exact firewall changed, and compare them with the intended state; then carry out the positive and negative proxy, user, policy, non-proxy and local service tests described below. An accepted configuration response does not replace this acceptance testing. For rollback, restore the saved previous state without inferring any undocumented API deletion syntax from it.

5. Deploy the Direct Web Proxy

Set the browser or system proxy through a GPO, PAC file or managed application to this value:

fw01.corp.example:3128

For Kerberos, you must use exactly the FQDN that matches the SPN. An IP address as the proxy destination, an unresolvable short name or a different alias often leads to NTLM fallback or a credentials prompt. Keep bypass entries deliberately limited and document them, because every bypassed connection receives no per-connection identity.

The general listener, PAC, rule and rollback configuration is described in Set up the Direct Web Proxy with a PAC file. This article adds only multi-user authentication to that setup.

6. Position a dedicated firewall rule

Under Rules and policies > Firewall rules, create a dedicated, clearly named outbound rule for RDS01. It must precede rules that match the same host using Match known users.

For this IPv4 example, select IPv4 > Add firewall rule > New firewall rule. Set Rule name to, for example, RDS01_DirectProxy_Outbound and Action to Accept. You can choose any name; it should identify the host and purpose. Check its position before competing user rules against the full rule list, not merely its name.

The secure baseline:

• Source zones: the actual RDS zone, for example LAN
• Source networks and devices: only RDS01
• Destination zones: WAN
• Destination networks: only the required destinations, or deliberately Any
• Services: HTTP, HTTPS and a custom TCP service for 3128 or the actual configured proxy listening port; use Any only deliberately. Selecting only the listening port is not a complete service selection for the Direct Web Proxy.
• Log firewall traffic: enabled
• Match known users: disabled
• Web filtering > Web policy: select the prepared user- or group-dependent policy

Web policies can distinguish users and groups within proxy traffic, but take effect only when assigned to the firewall rule. This distinction belongs in the web policy, not in Match known users on this host rule. Check the switch again after selecting or changing the web policy, because a user dependency can enable it again.

Save with Save, reopen the rule and check Match known users, logging, the web policy and its position. The host rule permits the intended traffic path; the web policy determines access for users and groups within that path. A correctly identified user therefore does not automatically have the correct permissions.

The general AD SSO instructions also describe user rules with Match known users enabled. That is not the rule model for the multi-user IP entered here: the specific Per-Connection instructions explicitly require a dedicated rule with this switch disabled. Do not copy the service match from a transparent HTTP/HTTPS rule either: the proxy listening port describes the client-to-proxy path, while a separate proxy-to-destination connection uses destination services such as HTTP or HTTPS. Confirm the actual Rule ID and the appropriate port in the pilot using the logs. An IPv6 client with an IPv4 destination may require two rules; this IPv4 example is not a complete dual-stack guide.

Create a separate machine rule for DNS, updates and other necessary non-proxy connections. Do not add a blanket WAN-to-LAN rule; the inbound example shown by Sophos is not needed for normal RDS web access and would create unnecessary attack surface without a separate publishing requirement. Create firewall rules correctly explains setup, ordering and logging.

If there is a justified need for inbound access to the multi-user host independently of the proxy, Match known users must also be disabled on its dedicated rule. Tightly define the source zone and allowed source hosts, the destination zone and RDS01, and the services actually required; enable logging and check its position before competing user rules. This is not an instruction to expose RDP publicly; no new inbound rule is created for normal web access.

Run acceptance tests with two RDS users

A single successful browser request proves only that some proxy traffic works. Proper acceptance testing requires two simultaneous sessions.

1. Assign two AD pilot accounts to different web policy groups.
2. Open two new RDS sessions on RDS01.
3. Check the effective proxy configuration in both sessions.
4. In each session, make one allowed HTTP or HTTPS request and one request deliberately subject to different policy results.
5. Under Current activities > Live users, check that both users have Client Type Multi-host client.
6. Under Log viewer > Authentication, check the users and Log Comp for Kerberos or NTLM.
7. Compare the user, policy, Rule ID, action and timestamp in the web and firewall logs.
8. Run a necessary non-proxy test and confirm that it does not incorrectly receive a user identity.
9. From the pilot host, record which local HTTP and HTTPS services on the firewall are reachable through the proxy. If a service prohibited by the security design is reachable, stop the rollout and resume only with an additional protective measure whose effectiveness has been demonstrated.

A meaningful comparison uses the same approved test destination in both sessions: an account in RDS-Web-Standard can open it, while one in RDS-Web-Restricted is blocked by the prepared web policy. Record the date, time, user, source IP, Rule ID, policy and result. Then access a control destination that both groups are allowed to use. This distinguishes an intended group restriction from a general proxy or DNS failure. Use destinations from your own approved test list; do not block a production business website solely for acceptance testing.

Add further RDS hosts only once both users are correctly distinguished simultaneously, the intended web policy results are achieved and the non-proxy path is understood. Test Sophos Firewall rules in a controlled manner helps with general rule acceptance testing.

Troubleshooting

The proxy is unreachable

Check FQDN resolution, the port, the PAC/GPO result, the source zone and the Web proxy and AD SSO permissions. A successful AD server test does not prove proxy access. For SD-WAN routes, the proxy port or Any must match the service criteria; the firewall creates the external proxy connection itself, so not all client attributes apply as they do for normal routed traffic.

The browser prompts for credentials or uses NTLM

Check the proxy destination, DNS, HTTP SPN, browser zone and integrated authentication. Kerberos requires the matching FQDN, not the firewall IP. NTLM fallback is a symptom that should first be explained, not a reason for a precautionary NTLM-only rollout.

Both sessions appear as the same user

Check whether both browsers are actually using the explicit proxy and whether an application is creating connections outside the respective user session. An upstream proxy or NAT can also change the intended connection model. The type Multi-host client must appear in Live Users; a normal IP-based mapping is the wrong path for this host.

The user is visible, but the web policy does not take effect

Check the AD group, Main Group, web policy order, firewall rule and log entry together. Match known users must remain disabled in the dedicated host rule. Visible authentication does not yet prove that the request uses the expected web policy or Firewall Rule ID.

If the pilot user is in the Default group rather than the expected imported AD group, first check Authentication > Groups, the search base and group import. Do not assign a broader default group policy to conceal the error. After a controlled correction, use a new logon to check that the assignment and both policy tests are correct.

Non-web traffic shows no user

This is expected behaviour. Per-Connection AD SSO identifies only HTTP and HTTPS through the Direct Web Proxy. Required machine traffic uses a rule without user-based matching. If RDP, SMB, database or other non-proxy traffic must be distinguished per session, switch to SATC.

SSO stops working after an upgrade or HA failover

AD SSO may require a new domain join after an upgrade, when using multiple AD servers or in HA. The delegated join account must therefore remain valid. After a controlled failover, test with a new proxy connection and both pilot accounts; do not assume that existing proxy connections or Kerberos tickets continue uninterrupted. In every HA mode, each node stores only the logs for traffic it has processed itself. For an event, therefore, check the node that was active or processing the traffic at that time.

When upgrading directly from SFOS 21.5 or earlier to SFOS 22.0 GA Build 411, Known Issue NC-176853 is another possibility: NTLM and Kerberos AD SSO can fail immediately after the upgrade, causing identity-based policies not to match. Sophos lists SFOS 22.0 MR1 Build 490 as the fixed version. The internal procedure for KBA-000048429 describes diagnosis and the workaround. The Known Issues List does not list Per-Connection AD SSO separately; this issue is therefore relevant only if the underlying AD SSO path fails after this exact upgrade. Preserve the firmware build, timestamp and logs, check the KBA for the affected build and do not work around the issue with broad rules or a change of authentication method.

Read the relevant logs

These files are relevant in the Advanced Shell:

cd /log
tail -n 200 nasm.log
tail -n 200 access_server.log
tail -n 200 awarrenhttp.log

nasm.log shows NTLM, Kerberos and possible KVNO problems. access_server.log helps with authentication and authorisation, and awarrenhttp.log with the Web Proxy. awarrenhttp_access.log is created only when debug is temporarily enabled and is not part of the normal first step. Before restarting services or expanding debugging, first preserve the time window, user, destination, rule and existing logs.

Rollback

A clean rollback restores not only the proxy settings but also the previous authentication model.

1. Document the current multi-user list, Device Access exceptions, rules, web policy and proxy deployment.
2. Remove RDS01 from Multi-user hosts and save with Apply.
3. Roll back the proxy GPO, PAC file or application configuration in a controlled manner.
4. Restore the previous STAS, Clientless or Captive Portal mapping only if it was documented beforehand and was appropriate for this IP.
5. After checking other dependencies, remove the pilot ACL exception or temporary AD SSO and Web Proxy zone permissions, or restore them exactly to their previous state.
6. Disable or remove the dedicated host and machine rules once the replacement path has been confirmed.
7. Retest with new browser and RDS sessions and, for HA, in both operational roles.

Checklist

• Per-Connection AD SSO is intended only for explicit HTTP/HTTPS proxy traffic.
• The pilot host has a fixed, unique IP with no unrelated systems behind it.
• AD, groups, domain join, FQDN, DNS, SPN and time have been checked.
• AD SSO zone prerequisite and security impact reviewed; required LAN zone enabled and Apply selected, with Web proxy access separately scoped to the pilot host and no broad proxy permission. If the zone permission is unacceptable, stop rollout and obtain a supported, scoped design.
• Browsers and applications use fw01.corp.example:3128 or your own replacement values.
• The dedicated host rule has logging enabled and Match known users disabled.
• Non-proxy traffic is planned as machine traffic, or the design has been changed to SATC.
• Two simultaneous users, different policies and management access have been tested for both permitted and denied access.
• HA failover and upgrades have a documented rejoin and retest procedure.
• Rollback of the multi-user list, proxy deployment, Device Access, rules and previous authentication is documented.

Frequently asked questions