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. Windows- und macOS-Clients kommunizieren über 1.2.3.4 und TCP 9922; ein VPN, eine andere Default Route oder ein vorgeschalteter Router kann diesen Pfad an der Firewall vorbeiführen. Vor einem breiten Rollout werden deshalb 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. Vom Pilotgerät den Pfad zu 1.2.3.4 über die Sophos Firewall und 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 aktuelle 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.
• 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.

Die aktuelle SFOS-22-Hilfe nennt als unterstützte Systeme Windows 10 und neuer, Ubuntu 16.4 und neuer sowie macOS Catalina 10.15 und neuer. Das ist eine Produktgrenze der aktuellen Dokumentation, keine Garantie für jede zukünftige Betriebssystemversion. Vor einem Rollout wird die konkrete Kombination aus SFOS-Build, Agentpaket und Endpoint-Version mit einem Pilot getestet.

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.

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. Der User-Portal-Zugang wird dafür nur aus den vorgesehenen Netzen freigegeben. 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. 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 und der Agent in den vorgesehenen Programmordner verschoben. 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 aktuelle 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

Im Log viewer wird unter Authentication nach Benutzer, Source-IP und Testzeitpunkt gefiltert. Das Feld für den verwendeten Client muss Authentication Agent zeigen. Zusätzlich werden der echte Firewalltraffic und dessen Firewall Rule ID geprüft.

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 den Routingpfad zum dokumentierten Agentziel und TCP 9922 prüfen. Ein kontrollierter Paketmitschnitt kann mit dem Filter host 1.2.3.4 and port 9922 zeigen, ob Windows- oder macOS-Traffic die Sophos Firewall erreicht. Bei Linux wird stattdessen die in caa.conf eingetragene Firewall-IP geprüft.

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. 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
• 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