Sophos Firewall Client Authentication Agent einrichten

Der Client Authentication Agent, kurz CAA, passt zu einzelnen Windows-, macOS- oder Linux-Endgeräten, auf denen sich der Benutzer bewusst an der Firewall anmelden soll. Nach erfolgreichem Login erscheint die Identität als Authentication agent unter Current activities > Live users. Benutzer- oder gruppenabhängige Firewall- und Web-Regeln können den Traffic danach dieser Identität zuordnen.

Der Agent ist kein Ersatz für jede SSO-Architektur. Auf einem Terminalserver mit mehreren gleichzeitigen Benutzern braucht es SATC, in einer Windows-Domäne kann STAS die Anmeldung ohne Endpoint-Agent übernehmen. CAA ist vor allem für überschaubare Einzelgeräte sinnvoll, bei denen die manuelle Benutzeranmeldung akzeptiert ist.

Wichtig: Der Agent muss den von Sophos dokumentierten Authentifizierungspfad erreichen. Dazu muss unter Administration > Device access der lokale Dienst Clients für die Quellzone erlaubt sein. CAA verwendet TCP 9922; ein VPN, eine andere Default Route oder ein vorgeschalteter Router kann den Pfad zu 1.2.3.4 an der Firewall vorbeiführen. Vor einem breiten Rollout werden deshalb Local Service ACL, Route, TLS-CA, Pilotlogin und echter Regelmatch auf einem Gerät geprüft.

CAA in zehn Schritten

1. Prüfen, ob das Endgerät wirklich einen einzelnen aktiven Benutzer repräsentiert; für RDS, Citrix oder andere Multi-User-Hosts SATC verwenden.
2. Authentifizierungsserver, Benutzergruppe, Firewall-Policy und eine lokale Recovery-Methode dokumentieren.
3. Unter Administration > Device access für die Quellzone Clients erlauben. Bei Windows und macOS den Pfad zu 1.2.3.4, bei Linux die in caa.conf gesetzte Firewall-IP über TCP 9922 verifizieren.
4. Unter Authentication > Client downloads den passenden Agent und die zugehörige Server-CA laden.
5. Für Windows-Massenverteilung Download MSI und Download CA for MSI gemeinsam einplanen; Einzelinstaller enthalten Agent und CA.
6. Den Agent auf einem Pilotgerät installieren, aber noch nicht breit verteilen.
7. Unter Authentication > Services > Firewall authentication methods den vorgesehenen Authentifizierungsserver und seine Reihenfolge prüfen.
8. Mit einem Pilotbenutzer anmelden und unter Current activities > Live users den Clienttyp Authentication agent bestätigen.
9. Einen erlaubten und einen blockierten Testfluss ausführen und Benutzer, Policy sowie Firewall Rule ID im Log Viewer prüfen.
10. Erst danach Deployment, MFA-Verhalten, HA-Test, Supportprozess und Rollback dokumentieren.

Wann der Client Authentication Agent passt

CAA übermittelt die Benutzeranmeldung vom Endgerät an die Firewall. Das eignet sich besonders für:

• nicht domänengebundene, aber verwaltete Einzelgeräte;
• kleine Umgebungen ohne STAS-Infrastruktur;
• Geräte, auf denen ein Benutzerwechsel bewusst eine neue Agentanmeldung auslöst;
• Policies, die einen echten Benutzernamen statt nur eine Source-IP benötigen.

Nicht geeignet ist der Agent als pauschale Lösung für mehrere gleichzeitige Benutzer hinter derselben Host-IP. Für Citrix-, RDS- und Terminalserver erklärt SATC auf Remote-Desktop-Systemen den sitzungsbezogenen Ansatz. In einer AD-Umgebung ist STAS auf Sophos Firewall die clientlose Alternative.

CAA authentifiziert den Benutzer, erstellt aber keine Netzwerkfreigabe. Firewallregeln, Web Policies, Gruppen, Quoten und Access-Time-Policies bleiben eigenständige Ebenen. Ein sichtbarer Live User beweist deshalb noch nicht, dass der gewünschte Traffic die richtige Regel trifft.

Beispiel und Voraussetzungen

Der Pilot verwendet:

• Firewall-LAN-IP: 10.20.30.1
• Pilotgerät: 10.20.30.50
• Pilotbenutzer: fw-user-pilot
• Benutzergruppe: CAA-Pilot
• Agentziel: 1.2.3.4
• TCP-Port: 9922

10.20.30.1 und 10.20.30.50 sind private Dokumentationswerte und werden durch die echten Adressen ersetzt. 1.2.3.4 und TCP 9922 sind dagegen der von Sophos dokumentierte Agentpfad für Windows und macOS und werden dort nicht wie normale Umgebungswerte ausgetauscht. Für Linux nennt die User-Portal-Anleitung eine eigene Konfigurationsdatei und verlangt dort die tatsächliche Firewall-IP.

Vor der Installation müssen diese Punkte geklärt sein:

• Das Pilotgerät verwendet die Sophos Firewall als Gateway oder besitzt einen belegten Pfad zum Agentziel.
• Kein Full-Tunnel-VPN und keine fremde Route zieht 1.2.3.4 am vorgesehenen SFOS-Gateway vorbei.
• In der Spalte der tatsächlichen Quellzone ist unter Administration > Device access der Dienst Clients erlaubt. Eine Firewallregel kann diese Local Service ACL nicht ersetzen.
• Der Benutzer existiert lokal oder auf einem unter Firewall authentication methods ausgewählten Server.
• Gruppe und Policies sind vorbereitet; der Pilot erhält nicht vorsorglich breitere Rechte.
• Der zum Installer gehörende Authentication Server CA wird nur aus der eigenen Firewall bezogen.
• Eine bestehende alternative Anmeldung bleibt während des Piloten verfügbar.
• Bei aktiviertem MFA ist der Token registriert und das Agentverhalten separat getestet.

Für SFOS 22 umfasst die unterstützte Betriebssystemgrenze des Client Authentication Agent Windows 10 und neuer, Ubuntu 16.4 und neuer sowie macOS Catalina 10.15 und neuer. Diese versionsgebundene Produktgrenze ist keine Garantie für jede zukünftige Betriebssystemversion; testen Sie deshalb vor dem Rollout die genaue Endpoint-Version.

Avanet empfiehlt, die konkrete Kombination aus SFOS-Build, Agentpaket, Endpoint-Version und Endpoint-Schutz zuerst auf einem Gerät zu prüfen. Auch der anschliessende Negativtest und das HA-Verhalten sind Betriebsempfehlungen; Sophos dokumentiert damit keine unterbrechungsfreie Sitzung bei einem Failover.

Authentifizierung auf der Firewall vorbereiten

Unter Authentication > Services > Firewall authentication methods wird mindestens ein passender Server oder die lokale Datenbank ausgewählt. Bei mehreren Servern sendet SFOS die Anfrage in der angezeigten Reihenfolge weiter. Default Group, importierte Gruppe und Benutzerstatus müssen deshalb vor dem Agenttest feststehen.

CAA ist ein lokaler Authentifizierungsdienst der Firewall. Unter Administration > Device access wird in der Spalte der Quellzone Clients aktiviert; laut Sophos umfasst dieser Eintrag CAA auf TCP 9922 sowie STAS und SATC auf UDP 6060. Local Services werden nicht durch normale Firewallregeln freigegeben. Bei einer Custom Zone kann der Zugriff zusätzlich unter Network > Zones gesteuert werden.

Für lokale Pilotkonten passt lokale Benutzer sicher erstellen und testen. Bei AD, LDAP oder RADIUS wird zuerst der jeweilige Server mit einem normalen Dienstdialog getestet. Ein grüner Test connection beweist jedoch nicht den späteren CAA-Pfad vom Endgerät.

Wenn MFA für das User portal aktiviert ist, gilt diese Anforderung laut Sophos auch für Client Authentication Agents. Tokenregistrierung und Eingabe werden deshalb mit demselben Pilotbenutzer geprüft. MFA wird nicht erst nach dem Rollout überraschend aktiviert.

Agent und Server-CA herunterladen

Administratoren laden die Pakete hier:

Authentication > Client downloads

Sophos stellt diese Varianten bereit:

• Download MSI: Windows-Agent für eine automatisierte Verteilung;
• Download CA for MSI: separate Authentication Server CA für das MSI-Deployment;
• Download for Windows: Einzelinstaller mit Agent und CA;
• Download for macOS: Einzelinstaller mit Agent und CA;
• Download for Linux 32 beziehungsweise Download for Linux 64: Archiv mit Agent, Konfiguration und CA.

Alternativ können berechtigte Benutzer die Pakete im User Portal unter Download client > Authentication clients selbst beziehen. Dafür wird unter Authentication > Services > User portal authentication methods mindestens der passende Server gewählt und unter Administration > Device access der Dienst User portal nur für die vorgesehene Quellzone aktiviert. Der Standardport ist TCP 4443. Sophos warnt vor einer Freigabe des User Portals aus der WAN-Zone; eine breite WAN-Freigabe allein für den Download ist nicht erforderlich.

Bei einem Factory Reset erzeugt die Firewall die CA neu. Danach müssen Benutzer die Authentication Server CA erneut installieren. Ein alter Agent mit alter CA wird nicht durch das Deaktivieren der Zertifikatsprüfung oder durch eine fremde CA repariert; das Paket wird erneut aus der richtigen Firewall bezogen.

Agent auf dem Pilotgerät installieren

Windows und macOS

Unter Windows wird client_auth_agent.exe aus dem User Portal ausgeführt. Im Assistenten werden Installationsort und Startmenüordner gewählt; Install installiert den Client, Finish schliesst den Assistenten und startet den Agent. Für ein verwaltetes MSI-Deployment müssen Agent und Download CA for MSI gemeinsam verteilt werden. Nur der Agent ohne die zugehörige CA erfüllt den dokumentierten TLS-Pfad nicht.

Unter macOS wird Client+Authentication+Agent.dmg geöffnet. Beide Symbole werden in den jeweils angegebenen Ordner gezogen; danach wird der Installer beendet und Client Authentication Agent unter Applications gestartet. Auch hier stammt die eingebettete CA aus der Firewall, an der sich der Benutzer später anmeldet.

Der Pilot wird zuerst interaktiv installiert. Paketverteilung, Autostart und Upgradeverhalten werden erst nach dem erfolgreichen End-to-End-Test automatisiert. Es wird kein alter Agent aus einem anderen Firewall-Backup oder einer anderen Appliance wiederverwendet.

Linux

Für Linux nennt Sophos diesen Extraktionspfad, wobei <FILENAME> durch das geladene Archiv ersetzt wird:

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

Danach wird die mitgelieferte Konfiguration unter $HOME/.caa/caa.conf geprüft. Die User-Portal-Hilfe verlangt für Linux, den Wert hinter Copernicus host durch die tatsächliche Firewall-IP zu ersetzen sowie Benutzername und Passwort einzutragen. Ein echtes Passwort wird nicht in ein Verteilungsskript, Ticket oder öffentliches Beispiel geschrieben. Sophos weist darauf hin, dass der Agent das zunächst im Klartext hinterlegte Passwort beim ersten Start verschlüsselt.

Dateirechte, Besitzer und der Inhalt der mitgelieferten $HOME/.caa/README werden vor dem Start kontrolliert. Danach wird caa als Pilot ausgeführt. Weil die Linux-Anleitung einen anderen Zielwert als der allgemeine Windows-/macOS-Pfad nennt, werden die Plattformabläufe nicht vermischt.

Pilot anmelden und Policies testen

Der Pilot meldet sich im Agent mit seinem vorgesehenen Firewall-Benutzernamen und Passwort an. Bei externer Authentifizierung muss genau diese Schreibweise zur Serverkonfiguration passen. Eine erfolgreiche Agentanzeige ist erst der erste Test.

Auf der Firewall wird danach geprüft:

1. Unter Current activities > Live users erscheint fw-user-pilot.
2. Der Clienttyp lautet Authentication agent.
3. Source-IP und Benutzergruppe entsprechen dem Pilotgerät und dem vorgesehenen Mapping.
4. Ein erlaubter Testfluss trifft die erwartete benutzer- oder gruppenbezogene Regel.
5. Ein bewusst nicht erlaubtes Ziel bleibt blockiert.
6. Im Firewall-Log stehen Benutzer, Regel, Action und Firewall Rule ID.
7. Nach Disconnect unter Live users erhält der Agent die dokumentierte Benachrichtigung und der Traffic wird erneut bewertet.

Für die Testregel wird keine breite Any-Policy erstellt. Bestehende Regeln werden nur kontrolliert um den Pilotbenutzer oder die Pilotgruppe ergänzt. Der allgemeine Ablauf für echte Regeltests steht in Sophos Firewall Regeln systematisch testen.

Logs und HA prüfen

Der Log viewer wird oben rechts in der WebAdmin-Konsole geöffnet. Im Modul Authentication wird über Add filter oder die Freitextsuche nach Benutzer, Source-IP und Testzeitpunkt gefiltert. Der Eintrag muss zum Agentlogin passen; zusätzlich werden im Firewall-Modul der echte Nutztraffic, Action und Firewall Rule ID geprüft. Damit der Regeltest dort erscheint, muss in der betreffenden Regel Log firewall traffic aktiviert sein. Eine Session kann erst beim Schliessen protokolliert werden, daher wird der Testfluss sauber beendet oder die Anzeige nach kurzer Wartezeit aktualisiert.

Für die tiefere Korrelation sind access_server.log für Authentifizierung und Autorisierung sowie der Log Viewer beziehungsweise das konfigurierte Syslog-Ziel relevant. Ein einzelner Clientstatus ohne passenden Firewall-Logeintrag ist kein vollständiger Erfolgsnachweis.

In HA wird keine unterbrechungsfreie Fortsetzung einer bestehenden Agentanmeldung vorausgesetzt. Nach einem kontrollierten Failover werden eine neue Anmeldung, Live User, Policy-Match und Nutztraffic erneut geprüft. Logs liegen auf dem Node, der das Ereignis verarbeitet hat; bei unklarem Zeitpunkt werden beide Nodes oder eine konsolidierte Auswertung verwendet.

Fehler nach Symptom eingrenzen

Der Agent erreicht die Firewall nicht

Zuerst unter Administration > Device access kontrollieren, ob Clients für die Quellzone aktiviert ist. Danach Routingpfad und TCP 9922 prüfen. Unter Diagnostics > Packet capture > Configure kann im Feld Enter BPF string der Filter host 1.2.3.4 and port 9922 gesetzt werden; der Mitschnitt zeigt, ob der Agenttraffic die Sophos Firewall erreicht. Bei Linux wird statt 1.2.3.4 die in caa.conf eingetragene Firewall-IP verwendet.

Wenn das Problem erst nach dem Start eines anderen VPN-Clients auftritt, wird kontrolliert, ob dessen Full-Tunnel-Route das Agentziel übernimmt. Die Lösung ist kein blind gesetzter Host-Route-Befehl: Split-Tunnel, Routing und Sicherheitswirkung werden zuerst im konkreten Design geprüft. Bleibt der Authentifizierungspfad unklar, wird der Rollout gestoppt.

TLS- oder CA-Fehler erscheint

Installer und CA müssen aus derselben aktiven Firewall stammen. Nach einem Factory Reset ist die alte CA ungültig und wird durch das aktuelle Paket ersetzt. Zertifikatsprüfung, Endpoint-Schutz oder TLS werden nicht als Schnellfix deaktiviert.

Passwort funktioniert im Portal, aber nicht im Agent

Unter Firewall authentication methods Serverreihenfolge, Default Group und Benutzerstatus prüfen. Danach MFA-Anforderung, Schreibweise des Benutzernamens, Source-IP- oder MAC-Bindung und die Authentication-Logmeldung kontrollieren. Ein erfolgreicher Portal-Login beweist nicht automatisch dieselbe Methode oder denselben Agentpfad.

Benutzer ist live, aber die falsche Regel greift

Regelreihenfolge, Match known users, ausgewählten Benutzer beziehungsweise Gruppe, Service, Ziel und Firewall Rule ID prüfen. Zuerst wird die tatsächlich passende Regel identifiziert; eine breite Allow-Regel ist kein Diagnoseersatz.

Auf einem Terminalserver erscheint nur eine Identität

CAA ist für diesen Multi-User-Pfad nicht der richtige Ansatz. Der Host wird nicht durch mehrere parallele Agentinstanzen zu einem sitzungsbezogenen System. Für RDS oder Citrix wird SATC verwendet und separat abgenommen.

Für die methodenübergreifende Analyse passt Sophos Firewall Authentifizierung systematisch prüfen.

Rollback und Betrieb

Bei einem fehlgeschlagenen Pilot wird der Agent am Pilotgerät beendet oder entfernt. Temporäre Benutzer-, Gruppen-, Portal- und Regeländerungen werden auf den dokumentierten Vorzustand zurückgesetzt. Wurde Clients für den Pilot neu freigegeben, wird die Checkbox nur dann zurückgenommen, wenn keine andere CAA-, STAS- oder SATC-Installation dieser Zone sie benötigt. Danach wird die frühere Authentifizierungsmethode mit einem neuen Login und echtem Traffic erneut geprüft.

Die Authentication Server CA wird nicht global gelöscht, solange andere CAA-Installationen sie verwenden. Vor Factory Reset, Reimage oder Appliance-Wechsel wird eingeplant, dass die neu erzeugte CA auf allen betroffenen Endgeräten aktualisiert werden muss.

Im Betrieb werden mindestens diese Punkte dokumentiert:

• zuständige Person für Agentpaket und Deployment;
• freigegebene Betriebssystemversionen;
• Herkunft und Erneuerung der Authentication Server CA;
• erwarteter Pfad zu Agentziel und TCP 9922;
• MFA- und Passwortablauf;
• Pilot- und Negativtest nach SFOS-, Endpoint- oder VPN-Änderungen;
• Offboarding und Entfernung bestehender Live Sessions.

Checkliste

• Einzelbenutzer-Endgerät statt Multi-User-Host bestätigt
• Authentifizierungsserver und Reihenfolge dokumentiert
• Clients in der Local Service ACL nur für die benötigte Quellzone aktiviert
• Agentpfad über die Sophos Firewall belegt
• Agent und Authentication Server CA aus derselben Firewall geladen
• MSI und separate CA gemeinsam geplant
• Plattformgrenzen und Linux-Sonderpfad berücksichtigt
• Pilotbenutzer mit minimaler Gruppe und Policy vorbereitet
• MFA-Verhalten getestet
• Live User zeigt Authentication agent
• erlaubter und blockierter Nutztraffic geprüft
• Benutzer, Action und Firewall Rule ID im Log bestätigt
• VPN- und HA-Verhalten mit neuer Anmeldung getestet
• Factory-Reset-/CA-Folge und Rollback dokumentiert

Häufige Fragen