Set up Sophos Firewall Client Authentication Agent

The Client Authentication Agent, or CAA, suits individual Windows, macOS, or Linux endpoints where users deliberately sign in to the firewall. After a successful login, the identity appears as Authentication agent under Current activities > Live users. User- or group-based firewall and web rules can then associate traffic with that identity.

The agent does not replace every SSO architecture. A terminal server with multiple concurrent users needs SATC, while STAS can handle sign-in without an endpoint agent in a Windows domain. CAA mainly suits a manageable number of individual devices where manual user sign-in is acceptable.

Important: The agent must reach the authentication path documented by Sophos. Windows and macOS clients communicate through 1.2.3.4 and TCP 9922; a VPN, different default route, or upstream router can lead this path around the firewall. Before a broad rollout, test the route, TLS CA, pilot login, and real rule match on one device.

CAA in ten steps

1. Verify that the endpoint represents one active user; use SATC for RDS, Citrix, or other multi-user hosts.
2. Document the authentication server, user group, firewall policy, and a local recovery method.
3. From the pilot device, verify the path to 1.2.3.4 through Sophos Firewall and TCP 9922.
4. Download the appropriate agent and its server CA under Authentication > Client downloads.
5. For mass Windows deployment, plan Download MSI and Download CA for MSI together; standalone installers include the agent and CA.
6. Install the agent on one pilot device, but do not distribute it broadly yet.
7. Under Authentication > Services > Firewall authentication methods, verify the intended authentication server and its order.
8. Sign in with a pilot user and confirm the Authentication agent client type under Current activities > Live users.
9. Run one allowed and one blocked test flow, then verify user, policy, and Firewall Rule ID in Log Viewer.
10. Only then document deployment, MFA behavior, the HA test, support process, and rollback.

When Client Authentication Agent fits

CAA sends the user sign-in from the endpoint to the firewall. It is particularly suitable for:

• non-domain-joined but managed individual endpoints;
• small environments without STAS infrastructure;
• devices where a user change deliberately triggers a new agent login;
• policies that need a real username instead of only a source IP.

The agent is not a general solution for several concurrent users behind the same host IP. SATC on Remote Desktop systems covers the session-based approach for Citrix, RDS, and terminal servers. In an AD environment, STAS on Sophos Firewall is the clientless alternative.

CAA authenticates the user, but it does not create network access. Firewall rules, web policies, groups, quotas, and access-time policies remain separate layers. A visible Live User therefore does not prove that the required traffic matches the correct rule.

Example and prerequisites

The pilot uses:

• Firewall LAN IP: 10.20.30.1
• Pilot device: 10.20.30.50
• Pilot user: fw-user-pilot
• User group: CAA-Pilot
• Agent destination: 1.2.3.4
• TCP port: 9922

10.20.30.1 and 10.20.30.50 are private documentation values and must be replaced with the real addresses. By contrast, 1.2.3.4 and TCP 9922 are the agent path documented by Sophos for Windows and macOS and aren’t replaced there like normal environment-specific values. For Linux, the current User Portal instructions use a separate configuration file and require the firewall’s actual IP address.

Before installation, clarify these points:

• The pilot device uses Sophos Firewall as its gateway or has a verified path to the agent destination.
• No full-tunnel VPN or external route pulls 1.2.3.4 away from the intended SFOS gateway.
• The user exists locally or on a server selected under Firewall authentication methods.
• Groups and policies are ready; do not give the pilot broader permissions as a precaution.
• Obtain the CA that belongs to the installer only from the firewall itself.
• Keep an existing alternative authentication path available during the pilot.
• If MFA is enabled, register the token and test agent behavior separately.

The current SFOS 22 help lists Windows 10 and later, Ubuntu 16.4 and later, and macOS Catalina 10.15 and later as supported systems. This is a boundary in the current product documentation, not a guarantee for every future operating-system version. Pilot the exact combination of SFOS build, agent package, and endpoint version before rollout.

Prepare authentication on the firewall

Under Authentication > Services > Firewall authentication methods, select at least one suitable server or the local database. With multiple servers, SFOS forwards the request in the displayed order. The Default Group, imported group, and user status must therefore be clear before testing the agent.

For local pilot accounts, see create and test local users securely. For AD, LDAP, or RADIUS, first test the relevant server with its standard service dialog. A green Test connection, however, does not prove the later CAA path from the endpoint.

If MFA is enabled for the User portal, Sophos states that this requirement also applies to Client Authentication Agents. Test token registration and entry with the same pilot user. Do not enable MFA unexpectedly only after rollout.

Download the agent and server CA

Administrators download the packages here:

Authentication > Client downloads

Sophos provides these variants:

• Download MSI: Windows agent for automated deployment;
• Download CA for MSI: separate Authentication Server CA for MSI deployment;
• Download for Windows: standalone installer with agent and CA;
• Download for macOS: standalone installer with agent and CA;
• Download for Linux 32 or Download for Linux 64: archive containing agent, configuration, and CA.

Alternatively, authorized users can download the packages themselves from Download client > Authentication clients in the User Portal. Allow User Portal access only from the intended networks. Broad WAN access only for the download is unnecessary.

A factory reset makes the firewall regenerate the CA. Users must then reinstall the Authentication Server CA. Do not repair an old agent with an old CA by disabling certificate validation or introducing an unrelated CA; download the current package again from the correct firewall.

Install the agent on the pilot device

Windows and macOS

On Windows, run client_auth_agent.exe from the User Portal. A managed MSI deployment must distribute the agent and Download CA for MSI together. The agent alone without the matching CA does not implement the documented TLS path.

On macOS, open Client+Authentication+Agent.dmg and move the agent to the designated application folder. Here too, the embedded CA must originate from the firewall where the user later signs in.

Install the pilot interactively first. Automate package deployment, autostart, and upgrade behavior only after a successful end-to-end test. Do not reuse an old agent from another firewall backup or appliance.

Linux

For Linux, Sophos specifies the following extraction path, replacing <FILENAME> with the downloaded archive:

sudo tar -xzvf <FILENAME> -p -C $HOME
sudo mv ~/bin/caa /usr/local/bin

Then review the supplied configuration at $HOME/.caa/caa.conf. The current User Portal help instructs Linux users to replace the value after Copernicus host with the firewall’s actual IP address and enter username and password. Never place a real password in a deployment script, ticket, or public example. Sophos states that the agent encrypts the initially plain-text password when it first runs.

Check file permissions, ownership, and the supplied $HOME/.caa/README before starting. Then run caa as the pilot. Because the Linux instructions use a different destination value from the general Windows and macOS path, don’t mix the platform procedures.

Sign in the pilot and test policies

The pilot signs in to the agent using the intended firewall username and password. With external authentication, this exact format must match the server configuration. A successful agent display is only the first test.

Then verify on the firewall:

1. fw-user-pilot appears under Current activities > Live users.
2. The client type is Authentication agent.
3. Source IP and user group match the pilot device and intended mapping.
4. An allowed test flow hits the expected user- or group-based rule.
5. A deliberately unauthorized destination remains blocked.
6. The firewall log shows user, rule, action, and Firewall Rule ID.
7. After Disconnect under Live users, the agent receives the documented notification and traffic is evaluated again.

Do not create a broad Any policy for the test rule. Add only the pilot user or pilot group to existing rules in a controlled way. Test Sophos Firewall rules systematically covers the general end-to-end rule validation process.

Check logs and HA

In Log viewer, filter Authentication by user, source IP, and test time. The client field must show Authentication Agent. Also verify the real firewall traffic and its Firewall Rule ID.

For deeper correlation, use access_server.log for authentication and authorization together with Log Viewer or the configured syslog destination. A single client status without a matching firewall log entry is not a complete success criterion.

In HA, don’t assume an existing agent sign-in continues without interruption. After a controlled failover, retest a fresh sign-in, Live User, policy match, and real traffic. Logs are stored on the node that processed the event; if the time is unclear, check both nodes or a consolidated view.

Troubleshoot by symptom

The agent can’t reach the firewall

First check the routing path to the documented agent destination and TCP 9922. A controlled packet capture using host 1.2.3.4 and port 9922 can show whether Windows or macOS traffic reaches Sophos Firewall. For Linux, check the firewall IP configured in caa.conf instead.

If the issue starts only after another VPN client connects, determine whether its full-tunnel route takes over the agent destination. The solution isn’t a blindly applied host-route command: assess split tunnel, routing, and security impact in the actual design first. Stop the rollout if the authentication path remains unclear.

A TLS or CA error appears

Installer and CA must come from the same active firewall. After a factory reset, the old CA is invalid and must be replaced with the current package. Don’t disable certificate validation, endpoint protection, or TLS as a quick fix.

The password works in the portal but not in the agent

Under Firewall authentication methods, verify server order, Default Group, and user status. Then check the MFA requirement, username format, source-IP or MAC binding, and the Authentication log message. A successful portal login doesn’t automatically prove the same method or agent path.

The user is live, but the wrong rule applies

Verify rule order, Match known users, the selected user or group, service, destination, and Firewall Rule ID. Identify the rule that actually matches first; a broad allow rule is not a diagnostic substitute.

Only one identity appears on a terminal server

CAA is not the right approach for this multi-user path. Multiple parallel agent instances don’t turn the host into a session-aware system. Use SATC for RDS or Citrix and validate it separately.

For cross-method diagnostics, see troubleshoot Sophos Firewall authentication systematically.

Rollback and operations

For a failed pilot, stop or remove the agent on the pilot device. Return temporary user, group, portal, and rule changes to the documented previous state. Then retest the earlier authentication method with a fresh login and real traffic.

Don’t delete the Authentication Server CA globally while other CAA installations still use it. Before a factory reset, reimage, or appliance replacement, plan to update the newly generated CA on every affected endpoint.

At minimum, document these operating details:

• owner of the agent package and deployment;
• approved operating-system versions;
• origin and renewal of the Authentication Server CA;
• expected path to the agent destination and TCP 9922;
• MFA and password process;
• pilot and negative tests after SFOS, endpoint, or VPN changes;
• offboarding and removal of existing live sessions.

Checklist

• individual-user endpoint rather than multi-user host confirmed
• authentication server and order documented
• agent path through Sophos Firewall verified
• agent and Authentication Server CA downloaded from the same firewall
• MSI and separate CA planned together
• platform boundaries and Linux-specific path considered
• pilot user prepared with minimal group and policy
• MFA behavior tested
• Live User shows Authentication agent
• allowed and blocked real traffic tested
• user, action, and Firewall Rule ID confirmed in the log
• VPN and HA behavior tested with a fresh sign-in
• factory-reset/CA impact and rollback documented

Frequently asked questions