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 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 with exactly one pilot server and document the existing authentication path first.

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. Allow AD SSO and Web proxy only for the required source zone or pilot host.
5. Create the RDS server as an exact IP host object.
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 turned off.
9. Test two parallel 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 they solve different problems.

• STAS is suitable for normal Windows clients when one client IP typically belongs to exactly one user. The firewall receives a user-to-IP mapping from Windows sign-in events.
• Per-Connection AD SSO is suitable for multi-user hosts when only explicitly proxied HTTP and HTTPS connections must be distinguished. No SATC agent is required on the RDS server, but every application must reliably use the Direct Web Proxy.
• SATC is suitable for RDS or Citrix systems when other connection types from individual user sessions also need an identity. Sophos Server Protection is required on the Session Host.

Standard STAS on Sophos Firewall can’t 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. If an application doesn’t support an explicit proxy or non-web protocols require user-based rules, stop here and evaluate SATC.

Example and replaceable values

This guide uses the following example:

• Multi-user host: RDS01
• IP address: 10.20.30.40
• Firewall FQDN and proxy target: 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 fixed IP of the pilot server as seen by the firewall. No additional systems may appear behind this address through NAT. fw01.corp.example is a documentation name and must be replaced with the real firewall FQDN that resolves internally. The host portion should be no more than 15 characters and use lowercase so that the hostname, NetBIOS name, AD computer object, and SPN remain consistent.

Port 3128 is the default for the Direct Web Proxy. If the environment uses a different listening port, the firewall, PAC file or GPO, browser, 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 the organization’s permission model.

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, search base, group import, and the general AD SSO prerequisites.

A read-only account is sufficient for normal LDAP queries. The domain join and SPN creation, however, require a Domain Admin account or an account with properly delegated permissions. The stored account must also allow a later rejoin because HA, additional AD servers, or upgrades can trigger it again. An unrestricted Domain Admin account should not remain in use unnecessarily.

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

Check FQDN, DNS, SPN, and time

Kerberos works only when clients use the firewall FQDN as the proxy target. A proxy IP address isn’t sufficient. The following read-only checks help on a Windows pilot client:

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

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

The DNS response must point to the intended firewall. The client, domain controller, and firewall must also have time settings suitable for Kerberos. These commands don’t change anything. Don’t modify the SPN, domain join, or time configuration on suspicion; first prove the actual error.

Inventory proxy support and exceptions

Every browser and application whose web traffic needs a user identity must use the explicit proxy and support 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 that run in the system context instead of 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 matching for required 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. Then, under Authentication > Web authentication, select Kerberos & NTLM for If Active Directory (AD) SSO is configured. NTLM is technically supported as a fallback, but Kerberos should work reliably in larger installations because Per-Connection AD SSO can generate many additional authentication requests.

After AD SSO initialization, the following success messages must appear under Authentication in Log Viewer:

• Kerberos authentication initialized successfully
• NTLM authentication channel established successfully

The firewall offers these methods only when both channels work. Cannot initialize Kerberos authentication or Cannot establish NTLM authentication channel are stop signals, not instructions for a blind service restart.

2. Allow Device Access narrowly

Under Administration > Device access, AD SSO and Web proxy must be allowed for the intended source path. For a fixed pilot IP, a targeted Local service ACL exception rule is usually narrower than access for the whole LAN zone. An additional accept exception doesn’t restrict an already active zone permission, however; for a truly narrow design, leave the broad permission turned off. Device Access and Local Service ACL explains the complete 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 when its zone isn’t allowed in the normal Local Service matrix. Therefore, negatively test WebAdmin, User Portal, and other local targets from the pilot host. If this exposure isn’t acceptable in the network’s security design, don’t 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 when the PAC file, GPO, and all managed applications can be adjusted consistently.

3. Create the multi-user host

Create a new host object at the following 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

Don’t enter an entire range or subnet for the first test. Otherwise, many systems may simultaneously lose their existing IP-based authentication. After successful individual acceptance testing, several approved hosts can be combined into a host group in a controlled manner.

4. Enable Per-Connection AD SSO

Go to:

Authentication > Web authentication > Authentication settings for direct web proxy

Then:

1. Turn on Use per-connection AD SSO authentication for multi-user hosts.
2. Add the RDS01 object under Multi-user hosts.
3. Save with Apply.

From this point, 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 don’t use an existing RDS session as the only test.

5. Deploy the Direct Web Proxy

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

fw01.corp.example:3128

Kerberos requires the exact FQDN that matches the SPN. An IP address as the proxy target, an unresolvable short name, or another alias often results in NTLM fallback or a credential prompt. Keep bypass entries deliberately limited and document them because each bypassed connection receives no Per-Connection identity.

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

6. Position a dedicated firewall rule

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

Use the following safe framework:

• Source zones: 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: a custom TCP service for 3128 or the actual proxy listening port; use Any only deliberately
• Log firewall traffic: on
• Match known users: off
• Web filtering > Web policy: select the prepared user- or group-dependent policy

Web Policies can distinguish users and groups within proxy traffic, but only after they are assigned to the firewall rule. This distinction belongs in the Web Policy, not in Match known users for this host rule. Recheck the switch after selecting or changing the Web Policy because a user dependency can turn it back on.

Create a separate machine rule for DNS, updates, and other required non-proxy connections. Don’t add a blanket WAN-to-LAN rule; the inbound example shown by Sophos isn’t needed for normal RDS web access and would create unnecessary attack surface without a separate publishing purpose. Create firewall rules correctly explains the structure, order, and logging.

Test with two RDS users

One successful browser request proves only that some proxy traffic works. Actual acceptance testing requires two parallel 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. Generate one allowed request and one HTTP or HTTPS request that is deliberately evaluated differently.
5. Under Current activities > Live users, verify both users with Client Type Multi-host client.
6. Under Log viewer > Authentication, check the user and Log Comp for Kerberos or NTLM.
7. Compare user, policy, Rule ID, action, and timestamp in the web and firewall logs.
8. Generate a required non-proxy test and confirm that it doesn’t incorrectly receive a user identity.
9. From the pilot host, record which local HTTP and HTTPS services of the firewall are reachable through the proxy. If a service prohibited by the security design is reachable, stop the rollout and continue only after proving an additional protective measure.

Add more RDS hosts only after both users are distinguished correctly at the same time, the intended Web Policy results occur, and the non-proxy path is understood. Test Sophos Firewall rules in a controlled manner helps with general rule acceptance testing.

Troubleshooting

The proxy isn’t reachable

Check FQDN resolution, port, PAC or GPO result, source zone, and the Web proxy and AD SSO permissions. A successful AD server test doesn’t prove proxy access. With SD-WAN routes, the proxy port or Any must match the service; the firewall creates the external proxy connection itself, so not all client characteristics apply as they would to normal routed traffic.

The browser asks for credentials or uses NTLM

Check the proxy target, 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 really use the explicit proxy and whether an application creates connections outside the respective user session. An upstream proxy or NAT can also change the intended connection model. Live Users must show the type Multi-host client; a normal IP-based mapping is the wrong path for this host.

The user is visible, but the Web Policy doesn’t apply

Check the AD group, Main Group, Web Policy order, firewall rule, and log entry together. Match known users must remain off in the dedicated host rule. Visible authentication doesn’t prove that the request uses the expected Web Policy or Firewall Rule ID.

Non-web traffic doesn’t show a user

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

SSO no longer works after an upgrade or HA failover

AD SSO can require another 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; don’t assume that existing proxy connections or Kerberos tickets continue without interruption. In every HA mode, each node stores only the logs for traffic it processed itself. Check the node that was active or processed the traffic at the time of the event.

Read the relevant logs

The following 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 issues. access_server.log helps with authentication and authorization, and awarrenhttp.log with Web Proxy. awarrenhttp_access.log is created only when debug is temporarily enabled and isn’t part of the normal first step. Before restarting services or extending debug, first preserve the time window, user, destination, rule, and existing logs.

Rollback

A clean rollback restores not only the proxy 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. Revert the proxy GPO, PAC file, or application configuration in a controlled manner.
4. Restore the former STAS, Clientless, or Captive Portal mapping only if it was documented beforehand and is suitable 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 as soon as the replacement path is confirmed.
7. Retest with new browser and RDS sessions and, in HA, in both operating roles.

Checklist

• Per-Connection AD SSO is intended only for explicit HTTP and HTTPS proxy traffic.
• The pilot host has a fixed, unique IP with no other systems behind it.
• AD, groups, domain join, FQDN, DNS, SPN, and time have been checked.
• AD SSO and Web Proxy are allowed only for the required source path.
• Browsers and applications use fw01.corp.example:3128 or the environment’s replacement values.
• The dedicated host rule has logging on and Match known users off.
• Non-proxy traffic is planned as machine traffic, or the design has been changed to SATC.
• Two parallel users, different policies, and management access have been tested positively and negatively.
• HA failover and upgrades have a documented rejoin and retest process.
• Rollback of the multi-user list, proxy deployment, Device Access, rules, and previous authentication is documented.

Frequently asked questions