STAS auf Sophos Firewall einrichten

STAS steht für Sophos Transparent Authentication Suite. Die Funktion ordnet Windows-Anmeldungen aus Active Directory einer Client-IP zu, damit die Sophos Firewall Benutzer und Gruppen in Firewallregeln verwenden kann, ohne dass sich Benutzer im Browser oder Portal separat anmelden müssen.

Das ist in klassischen Windows-Domänen weiterhin nützlich. Gleichzeitig ist STAS kein Allzweck-SSO. Die Zuordnung funktioniert nur zuverlässig, wenn die Firewall die echte Client-IP sieht, die Domain Controller passende Anmeldeereignisse schreiben und technische Konten sauber ausgeschlossen werden. Für RDS-, Terminalserver- oder Citrix-Umgebungen braucht es meist ein anderes Design, zum Beispiel SATC.

Wann STAS sinnvoll ist

STAS passt vor allem zu Umgebungen mit normalen Windows-Clients in einer Active-Directory-Domäne. Typische Ziele sind:

• Firewallregeln mit AD-Benutzern oder AD-Gruppen
• Reporting mit Benutzerbezug statt nur IP-Adressen
• transparente Benutzerzuordnung ohne Captive Portal
• Internetregeln für interne Client-Netze
• ergänzende Authentifizierung in Umgebungen ohne Entra-ID-SSO-Design

STAS ist weniger geeignet, wenn mehrere Benutzer dieselbe Quell-IP verwenden. Das betrifft zum Beispiel Remote Desktop Server, Terminalserver, Citrix-Server oder Systeme mit NAT zwischen Client und Firewall. In solchen Fällen sollte man früh prüfen, ob Sophos Authentication for Thin Client (SATC) oder ein anderes Authentifizierungsmodell besser passt.

Videoanleitung

Die folgenden Sophos-Techvids zeigen den STAS-Aufbau visuell. Die Videos wurden mit SFOS v21 erstellt, sind für das Grundprinzip, die Architektur und die wichtigsten Konfigurationsschritte aber weiterhin hilfreich. Einzelne Masken können in SFOS 22 leicht anders aussehen.

Funktionsweise

STAS besteht aus zwei Komponenten:

• STA Agent: Läuft auf einem Domain Controller oder einem geeigneten Windows-System und erkennt AD-Anmeldeereignisse.
• STA Collector: Sammelt Informationen von einem oder mehreren STA Agents und übermittelt sie an die Sophos Firewall.

Der typische Ablauf:

1. Ein Benutzer meldet sich an einem Windows-Client an.
2. Active Directory schreibt ein passendes Security Event.
3. Der STA Agent liest dieses Ereignis.
4. Der STA Collector erhält Benutzer, Client-IP und Domäneninformation.
5. Die Sophos Firewall aktualisiert die Live Users.
6. Firewallregeln können Benutzer oder Gruppen auswerten.

Zusätzlich kann der Collector Clients per WMI oder Registry Read Access prüfen. Dieses Workstation Polling hilft, eine IP-Adresse einem Benutzer zuzuordnen oder veraltete Einträge zu korrigieren. Dafür müssen aber Windows-Firewall, Dienste, Berechtigungen und Netzpfade passen.

Voraussetzungen

Vor der Installation sollten diese Punkte geklärt sein:

• Sophos Firewall läuft im Gateway-Modus.
• Active Directory ist bereits auf der Firewall angebunden.
• Domain Controller schreiben die benötigten Anmeldeereignisse.
• Windows-Clients sind Mitglied der Domäne.
• Kein NAT liegt zwischen Clients, Collector und Sophos Firewall.
• Client Authentication ist unter Device Access für die betroffenen Zonen erlaubt.
• DNS, Zeit, Routing und Firewallregeln zwischen den beteiligten Systemen stimmen.
• Ein Servicekonto und ein Passwortwechselprozess sind definiert.
• Technische Konten für Exclusions sind bekannt.

STAS 2.5 und neuer unterstützt nach offizieller Dokumentation Windows Server 2008 R2, 2012 R2, 2016, 2019, 2022 und 2025. Für neue Installationen sollte man trotzdem nicht mehr mit alten Servergenerationen planen. Relevant ist vor allem, dass STAS entweder direkt auf einem Domain Controller oder ab STAS 2.5 auch auf einem Member Server betrieben werden kann. Bei Member-Server-Designs muss man besonders sauber prüfen, ob Event-Log-Zugriff, WMI/Registry-Zugriff und Netzwerkpfade wirklich passen.

Die AD-Anbindung selbst ist in Active Directory mit Sophos Firewall verbinden beschrieben. STAS sollte nicht als Ersatz für eine saubere AD-Serverkonfiguration verstanden werden.

Wenn über Jahre sehr viele Benutzer und Gruppen auf der Firewall entstehen, sollte zusätzlich das Sophos Firewall User-ID-Limit im Blick behalten werden. Das ist besonders relevant, wenn Portal- oder VPN-Funktionen nur für einzelne Benutzer fehlschlagen.

Architektur planen

Für kleine Umgebungen kann Agent und Collector auf demselben Domain Controller laufen. Das ist einfach, aber nicht immer die beste Betriebsvariante.

Der Collector erzeugt eigene Kommunikations- und Prüfpfade zur Firewall, zu Agents und je nach Polling-Methode auch zu Clients. Deshalb sollte er nicht automatisch auf einem Domain Controller landen, nur weil dort bereits der Agent läuft. Sophos weist selbst darauf hin, dass die Installation des Collectors auf einem Domain Controller wegen des erzeugten Traffics nicht immer empfehlenswert ist. In produktiven Umgebungen ist ein separater Windows-Server oft sauberer zu überwachen, zu aktualisieren und bei Problemen neu zu starten.

In grösseren Umgebungen ist oft sauberer:

• STA Agent auf jedem relevanten Domain Controller
• ein oder zwei STA Collectors auf separaten Windows-Systemen
• Collector-Gruppen pro AD-Domäne
• klare Exclusion List für technische Konten
• definierte Firewallregeln und Device-Access-Freigaben
• Monitoring für Dienste, Event Logs und Live-User-Zuordnung

Wichtig ist die IP-Sicht. STAS ordnet Benutzer einer IP-Adresse zu. Wenn ein Proxy, NAT, Terminalserver oder VPN-Gateway die echte Client-IP verdeckt, kann die Firewall die Zuordnung nicht zuverlässig verwenden.

Active Directory vorbereiten

STAS hängt stark davon ab, dass die richtigen Anmeldeereignisse im Security Event Log vorhanden sind. Die folgenden Einstellungen müssen auf jedem Domain Controller geprüft werden, auf dem der STA Agent eingesetzt wird.

Zusätzlich sollte man vor der Installation NetBIOS-Name, FQDN und Search DN der Domäne notieren. Diese Werte werden später in Sophos Firewall und STAS-Konfiguration gebraucht.

Audit account logon events aktivieren

Auf dem Domain Controller Local Security Policy öffnen. Das geht zum Beispiel über secpol.msc.

Danach den Pfad öffnen:

Security Settings > Local Policies > Audit Policy

Dort Audit account logon events öffnen.

Anschliessend Success und Failure aktivieren und die Änderung speichern.

STAS-Konto vorbereiten

Der STAS-Dienst sollte mit einem dokumentierten Konto laufen. In einfachen Testumgebungen wird häufig ein Administratorkonto verwendet. Für produktive Umgebungen ist ein dediziertes STAS-Konto besser, sofern die benötigten Rechte sauber gesetzt und getestet werden.

Das Konto muss je nach Design:

• den Dienst starten können
• relevante Event Logs lesen können
• bei WMI oder Registry Read Access auf Clients zugreifen können
• Passwortwechsel planbar überstehen
• in Monitoring und Dokumentation eindeutig erkennbar sein

Das Konto muss nicht zwingend Domain Admin sein. Für den Domain Controller sind mindestens die passenden Gruppen- und Dateirechte wichtig. In der Praxis sollte man prüfen:

• Mitgliedschaft in Domain Users
• Mitgliedschaft in Event Log Readers
• Lese- und Schreibrechte auf C:\Program Files (x86)\Sophos\Sophos Transparent Authentication Suite\
• bei WMI-Polling passende Rechte auf den Endpoints, zum Beispiel Remote Desktop Users, Distributed COM Users sowie WMI-Berechtigungen auf Root\CIMV2 mit Execute Methods und Remote Enable

Diese Endpoint-Rechte lassen sich in grösseren Umgebungen besser über Gruppenrichtlinien verteilen. Wenn man Workstation Polling nicht verwendet, sollte man keine unnötig breiten Rechte vergeben.

Wenn der Dienst mit einem eigenen Konto läuft, muss dieses Konto Log on as a service erhalten.

Pfad in der Local Security Policy:

Security Settings > Local Policies > User Rights Assignment

Danach das Konto hinzufügen.

Ports und Dienste prüfen

Zwischen Sophos Firewall, STA Collector, STA Agent, Domain Controller und Clients müssen die benötigten Verbindungen möglich sein. Als Basis gelten:

• STA Collector zu Sophos Firewall: Benutzerinformationen senden, UDP 6060.
• Sophos Firewall zu STA Collector: Collector-Kommunikation, UDP 6677.
• STA Agent zu STA Collector: Agent-Daten an Collector senden, TCP 5566.

Zusätzliche Ports hängen von den aktivierten Methoden ab:

• Workstation Polling per WMI: TCP 135, TCP 445, RPC/DCOM/WMI-Dienste.
• Registry Read Access: TCP 445, Remote Registry.
• Logoff Detection Ping: ICMP zum Client.
• STAS Collector Test: UDP 50001.
• STAS Configuration Sync: TCP 27015.

Wenn Windows Firewall auf Clients oder Servern aktiv ist, sollte man die Regeln eng auf den Collector einschränken. Eine Beispielvorlage für WMI:

New-NetFirewallRule -DisplayName "Sophos STAS Collector WMI" -Direction Inbound -RemoteAddress 10.10.10.10 -Action Allow -Profile Domain

Dieser Befehl ist nur eine Vorlage. In produktiven Umgebungen müssen Quell-IP, Zielports, Profile und Gruppenrichtlinien zur gewählten Polling-Methode passen.

Active Directory auf der Firewall hinterlegen

Bevor STAS aktiviert wird, muss die Sophos Firewall den Active-Directory-Server kennen.

Im WebAdmin:

Authentication > Servers

Dort einen Active-Directory-Server hinzufügen oder die bestehende Konfiguration prüfen.

Die einzelnen Felder sind in Active Directory mit Sophos Firewall verbinden erklärt. Für STAS sind besonders NetBIOS-Domäne, Domänenname, Suchbasis und Gruppenauflösung wichtig.

STAS herunterladen und installieren

Die STAS-Installation wird über die Sophos Firewall bereitgestellt.

Im WebAdmin:

Authentication > Client downloads

Unter Single Sign-on befindet sich Sophos Transparent Authentication Suite (STAS).

Die heruntergeladene STAS.exe auf dem vorgesehenen Windows-System als Administrator starten.

Typische Installationsvarianten:

• SSO Suite auf einem Server: kleine Umgebung oder Labor.
• STA Agent auf Domain Controllern, Collector separat: bessere Trennung und Skalierung.
• Mehrere Collectors: Redundanz oder grössere Umgebung.

Bei mehreren Domain Controllern braucht man normalerweise auf jedem relevanten Domain Controller einen STA Agent. Ein Collector kann Informationen von mehreren Agents sammeln.

STAS konfigurieren

Nach der Installation wird die STA Suite konfiguriert. Die wichtigsten Bereiche sind General, STA Agent, STA Collector und Exclusion List.

General

Im Tab General prüft man vor allem Servicekonto, Domänenangaben, NetBIOS-Name und FQDN.

Wenn hier falsche Domänenwerte stehen, sieht die Installation später oft gesund aus, aber Benutzer oder Gruppen werden nicht richtig zugeordnet. Der NetBIOS-Name muss in STAS in Grossbuchstaben eingetragen werden.

STA Agent

Im Tab STA Agent sind diese Punkte entscheidend:

• STA Agent Mode: Für lokale Event-Log-Erkennung ist EVENTLOG der typische Startpunkt.
• Specify the networks to be monitored: Client-Netze eintragen, in denen STAS Benutzer erkennen soll.
• Domain Controller IP: Nur setzen, wenn der Agent nicht direkt auf dem Domain Controller läuft. Wenn die SSO Suite auf einem Domain Controller installiert ist, bleibt dieses Feld normalerweise leer.
• Collector List: IP-Adressen der Collector-Systeme eintragen.

Die überwachten Netzwerke sollten bewusst gewählt werden. Servernetze, Managementnetze oder Netze ohne normale Benutzer-Workstations erzeugen sonst unnötige Fehler oder falsche Erwartungen.

STA Collector

Im Tab STA Collector wird die Sophos Firewall hinterlegt und das Client-Polling geplant.

Wichtige Punkte:

• Sophos Appliance: IP-Adresse der Sophos Firewall eintragen.
• Workstation Polling Method: WMI oder Registry Read Access bewusst wählen.
• Enable Logoff Detection: Nur aktivieren, wenn Ping und Timeouts zum Clientnetz passen.
• Dead entry timeout: Wert passend zur STAS-Version und zum Betriebsmodell testen.

Bei HA-Clustern sollte man die erreichbare interne Firewall-Adresse verwenden, die zum STAS-Verkehr passt. Separate Peer-Administrationsadressen sind dafür meistens nicht der richtige Zielpunkt.

Exclusion List

Die Exclusion List verhindert, dass technische Konten normale Benutzerzuordnungen überschreiben. Das ist einer der wichtigsten Betriebsbereiche von STAS.

Typische Einträge:

• Servicekonten für Backup, Monitoring, Softwareverteilung oder Endpoint-Tools
• Administrations- und Installationskonten
• Konten, die sich im Hintergrund auf vielen Clients anmelden
• Server oder Systeme, auf denen keine Arbeitsplatzbenutzer erwartet werden

Ohne Exclusion List kann ein echter Benutzer aus den Live Users verschwinden, weil kurz danach ein Dienstkonto auf demselben Client erkannt wurde. Das wirkt später wie ein Firewallregelproblem, obwohl die Ursache in der Authentifizierungszuordnung liegt.

Collector-Gruppen und Redundanz

Für kleine Umgebungen reicht oft ein Collector. In grösseren Umgebungen sollte man Collector-Gruppen bewusst planen.

Bewährte Regeln:

• Pro AD-Domäne eine passende Collector-Gruppe verwenden.
• Mindestens zwei Collectors einplanen, wenn Benutzerregeln kritisch sind.
• STA Agents mit allen vorgesehenen Collectors konfigurieren.
• Firewall und Collectors in beide Richtungen testen.
• Collectors nicht auf Systemen platzieren, die häufig neu gestartet werden.

Ein STA Agent kann mehrere Collectors bedienen. Ein STA Collector kann auch mehrere Sophos Firewalls bedienen. Trotzdem sollte die Zuordnung dokumentiert werden, sonst wird Troubleshooting später unnötig schwer.

Auf der Firewall wird ein Collector mit Collector IP, Collector port und Collector group eingetragen. Pro Collector-Gruppe sind maximal fünf Collectors möglich. Die Reihenfolge in der Gruppe ist wichtig: Der erste Collector ist primär, die weiteren Collectors dienen als Backup. Collectors derselben Domäne gehören in dieselbe Collector-Gruppe. Für Subdomänen oder getrennte AD-Domänen sollte man eigene Collector-Gruppen verwenden.

STAS auf der Sophos Firewall aktivieren

Wenn Agent, Collector, AD und Netzwerk vorbereitet sind, wird STAS auf der Firewall aktiviert.

Im WebAdmin:

Authentication > STAS

STAS aktivieren und den Collector oder die Collector-Gruppe eintragen.

Wenn die Einrichtung funktioniert, erscheinen Benutzer im Dashboard und im Live-User-Bereich.

Wenn dort keine Benutzer erscheinen, sollte man zuerst AD-Events, Agent, Collector, Device Access und Ports prüfen. Firewallregeln sind erst der nächste Schritt.

Wichtige STAS-Optionen auf der Firewall

Unter Authentication > STAS gibt es einige Optionen, die man bewusst setzen sollte.

• STAS quarantine: Bei eingehendem Traffic fragt die Firewall den Collector nach Benutzer- und Ziel-IP-Zuordnung. Ohne Treffer wird Traffic verworfen. Das ist sinnvoll für strenge Benutzerregeln, kann bei instabiler STAS-Erkennung aber wie ein Netzwerkproblem wirken.
• Identity probe time-out: Zeit, wie lange die Firewall auf die Antwort des Collectors wartet. Standard ist 120 Sekunden. Diesen Wert sollte man nicht blind erhöhen, sondern zuerst prüfen, warum der Collector nicht oder zu spät antwortet.
• Restrict client traffic during identity probe: Bei Yes kann Traffic während der Identitätsprüfung blockiert werden, bis die Firewall eine Antwort aus STAS erhält. Bei No wird Traffic während der Prüfung weitergeleitet. Die Werkseinstellung ist Yes, deshalb können auch lange unveränderte STAS-Installationen betroffen sein. Vor SFOS-22-Upgrades sollte diese Option geprüft werden, weil sie in SFOS 22.0 MR1 für ein dokumentiertes STAS-Upgrade- und Betriebsproblem relevant ist.
• Enable user inactivity: Entfernt inaktive Benutzer aus den Live Users. Das hilft, Live Users sauber zu halten, muss aber zu Clients, Polling und Timeout passen.
• Inactivity timer: Minuten bis zum Sign-out inaktiver Benutzer. Standard ist 3. Zu kurze Werte können bei ruhigen Clients zu irritierenden Abmeldungen führen.
• Data transfer threshold: Mindestdatenmenge in Bytes, damit ein Benutzer als aktiv gilt. Standard ist 100. Niedrige Schwellen sind für Office-Clients meist sinnvoller als sehr aggressive Werte.

Firewallregel mit Benutzerbezug erstellen

Sobald STAS stabil Benutzer erkennt, können Firewallregeln mit Benutzern oder Gruppen aus Active Directory verwendet werden.

Wichtig:

• Regel mit einer echten Testgruppe prüfen.
• Log firewall traffic aktivieren, wenn die Regel später analysiert werden muss.
• Regelposition kontrollieren.
• Fallback-Regeln vermeiden, die Authentifizierungsfehler verdecken.
• Live Users und Log Viewer gemeinsam prüfen.

Für die Regelanalyse passt Firewall-Regel testen mit Log Viewer, Policy Test und Packet Capture.

Validierung nach der Einrichtung

Ein grüner Dienststatus reicht nicht. Nach der Einrichtung sollte man die ganze Kette testen.

Praktischer Ablauf:

1. Testbenutzer an einem Domain-Client anmelden.
2. Security Event auf dem Domain Controller prüfen.
3. STA Agent Status prüfen.
4. STA Collector Status und erkannte Benutzer prüfen.
5. Live Users auf der Sophos Firewall prüfen.
6. Benutzerbasierte Firewallregel mit Logging testen.
7. Logoff oder Benutzerwechsel testen.
8. Technische Konten gegen die Exclusion List prüfen.

In STAS selbst kann man unter Advanced > Show live users prüfen, welche Benutzer der Collector aktuell kennt. Auf der Firewall ist der passende Ort Current activities > Live users. Beide Ansichten sollten zum Testzeitpunkt logisch zusammenpassen.

Wenn STAS geschäftskritische Regeln steuert, sollte dieser Test nach Windows-Updates, Domain-Controller-Änderungen, Firewall-Upgrades und Passwortwechseln des Servicekontos wiederholt werden.

Tests, Logs und Backup

STAS bietet mehrere lokale Prüfwerkzeuge. Diese sind oft schneller als ein reiner Blick auf den Firewall Log Viewer.

• Firewall-Verbindung testen: Advanced > Troubleshooting > Test Connectivity > Sophos prüft, ob Agent oder Collector die Firewall erreichen.
• STA Agent testen: Advanced > Troubleshooting > Test Connectivity > STAS Agent prüft, ob der Collector einen Agent erreicht.
• STA Collector testen: Advanced > Troubleshooting > Test Connectivity > STAS Collector prüft, ob ein Agent einen Collector erreicht.
• WMI Verification: Advanced > Troubleshooting > STAS Polling Utilities > WMI Verification prüft Workstation Polling per WMI gegen eine Client-IP.
• Registry Read Verification: Advanced > Troubleshooting > STAS Polling Utilities > Registry Read Verification prüft Workstation Polling per Registry Read Access gegen eine Client-IP.

Das STAS-Log ist direkt in der STAS-Anwendung unter Advanced > View Log sichtbar. Zusätzlich liegt die Logdatei auf dem Windows-System unter:

C:\Program Files (x86)\Sophos\Sophos Transparent Authentication Suite\stas.log

Vor grösseren Änderungen sollte man die STAS-Konfiguration sichern. Das geht in der STAS-Anwendung unter Advanced > Backup / Restore > Backup Now. Die Sicherung wird als Datei im Format STAS_ConfigBackup_DD_MM_YYYY_THH_MM_SS.bkp erstellt. Für eine Wiederherstellung wird die .bkp-Datei unter Backup / Restore ausgewählt und über Upload and Restore eingespielt.

STAS vor SFOS 22 MR1 prüfen

STAS gehört zu den Funktionen, die vor einem Major Upgrade bewusst geprüft werden sollten. In der aktuellen Known-Issues-Liste gibt es ein Problem rund um SFOS 22.0 MR1, STAS und die Option Restrict client traffic during identity probe. Wenn diese Option auf Yes steht, kann ein Upgrade auf SFOS 22.0 MR1 verhindert werden oder nach dem Upgrade zu wiederholten Identity Probes und dadurch zu zeitweisen Traffic-Unterbrüchen führen. Weil Yes der Standardwert ist, sollte man nicht davon ausgehen, dass nur bewusst gehärtete Sonderkonfigurationen betroffen sind.

Für Admins ist wichtig: Das ist kein normales STAS-Einrichtungsproblem. Eine Umgebung kann jahrelang funktionieren und trotzdem beim Upgrade auffallen, weil eine bisher akzeptierte Einstellung im Zusammenspiel mit SFOS 22.0 MR1 kritisch wird. Deshalb sollte STAS in den SFOS 22 Upgrade Check aufgenommen werden.

Vor einem Upgrade auf SFOS 22.0 MR1 oder neuer prüfen:

• Ist STAS überhaupt aktiv?
• Werden benutzerbasierte Regeln produktiv genutzt?
• Ist Restrict client traffic during identity probe aktiviert?
• Gibt es bereits Meldungen zu wiederholten Identity Probes oder unerklärlichen kurzen Traffic-Unterbrüchen?
• Gibt es einen Testbenutzer, mit dem STAS nach dem Upgrade gezielt geprüft werden kann?

Wenn die betroffene Option aktiv ist, sollte sie nicht erst während des Firmware-Wartungsfensters bewertet werden. Besser ist ein separater kurzer Test vorab: Änderung dokumentieren, Testbenutzer anmelden, Live Users prüfen, benutzerbasierte Regel testen und Log Viewer kontrollieren. Falls STAS sicherheitskritische Regeln steuert, sollte auch geklärt sein, ob eine temporäre Fallback-Regel nötig ist, damit Benutzer nicht unkontrolliert blockiert werden.

Für den Upgradepfad auf SFOS 22.0 MR1 gilt pragmatisch: Wenn STAS aktiv ist und Restrict client traffic during identity probe auf Yes steht, sollte die Option vor dem Upgrade auf No gesetzt und danach mit echten Testbenutzern validiert werden. Wenn diese Änderung nicht vorab getestet werden kann, ist ein verschobenes Upgrade oft sauberer als ein riskantes Wartungsfenster. Auf bereits betroffenen SFOS-22.0-MR1-Systemen ist No ebenfalls die dokumentierte Entschärfung, bis ein korrigiertes Release verfügbar ist.

Nach dem Upgrade gezielt prüfen:

1. STAS-Status unter Authentication > STAS kontrollieren.
2. Live Users mit einem frischen Domain-Login prüfen.
3. Benutzerbasierte Firewallregel mit Logging testen.
4. Im Log Viewer prüfen, ob der Benutzername sichtbar ist und nicht nur die IP-Adresse.
5. Auf wiederholte Identity-Probe-Effekte oder kurze Unterbrüche achten.

Wenn das Upgrade durch eine STAS-Meldung blockiert wird oder nach dem Upgrade reproduzierbare Unterbrüche auftreten, sollte ein Sophos Support Case vorbereitet werden. Hilfreich sind dann Screenshot der Upgrade-Meldung, aktuelle STAS-Konfiguration, Firmwareversion, betroffene Benutzerregel und ein kurzer Testablauf.

Troubleshooting

Keine Benutzer in Live Users

Zuerst prüfen, ob der Domain Controller passende Security Events schreibt. Danach STA Agent, STA Collector, Ports und Device Access prüfen.

Typische Ursachen:

• Audit Policy nicht aktiv
• STA Agent läuft nicht oder liest falschen Domain Controller
• Collector ist nicht erreichbar
• UDP 6060 oder 6677 ist blockiert
• Client Authentication ist in Device Access nicht erlaubt
• NAT verdeckt die echte Client-IP

Benutzer wird falsch zugeordnet

Dann sind häufig Exclusions, Workstation Polling oder technische Konten beteiligt. Prüfen, ob Servicekonten, Monitoring-Konten oder Installationskonten denselben Client überschreiben.

Benutzer verschwindet zu schnell

Dann Logoff Detection, Dead Entry Timeout, Client-Erreichbarkeit und Polling-Methode prüfen. Wenn Clients nicht auf Ping, WMI oder Registry-Zugriff reagieren, können Einträge unerwartet verschwinden oder veraltet bleiben.

DCOM-Fehler oder STAS fragt falsche Netze ab

Wenn im Windows Event Viewer nach der STAS-Installation DCOM-Fehler wie Event ID 10009 oder 10028 auftauchen, ist nicht automatisch die Firewallregel schuld. Häufig versucht der Collector per WMI oder Registry Read Access Clients zu prüfen, die gar nicht erreichbar sind oder nicht zu den überwachten Netzen gehören.

Dann sollte man in STAS die überwachten Netze eingrenzen:

1. In der STAS-Anwendung den Tab STA Collector öffnen.
2. Unter Sophos appliances die betroffene Sophos-Firewall auswählen und Edit öffnen.
3. Enable subnet based filter aktivieren.
4. Nur die Netze eintragen, die wirklich überwacht werden sollen.
5. Im Tab STA Agent unter Specify the networks to be monitored dieselben Clientnetze prüfen.
6. Änderungen übernehmen und STAS neu starten.

Das reduziert unnötige WMI-Abfragen und verhindert, dass Benutzer aus unpassenden Netzen als LogonType: 1 auftauchen. Nach der Änderung sollte man stas.log, Windows Event Viewer und Current activities > Live users gemeinsam prüfen.

Firewallregel greift nicht

Dann nicht nur die Regel betrachten. Prüfen:

• Ist der Benutzer unter Live Users sichtbar?
• Wird die richtige AD-Gruppe erkannt?
• Greift eine frühere Firewallregel?
• Ist Logging auf der Regel aktiv?
• Sieht der Log Viewer den Benutzer oder nur die IP-Adresse?

Übergangszeit für unauthentifizierten Traffic

Für Übergangsphasen erlaubt die Firewall standardmässig eine kurze Zeit lang unauthentifizierten Traffic. Dieser Wert kann über die Device Console geprüft oder angepasst werden:

system auth cta unauth-traffic drop-period

Diese Einstellung sollte man nicht blind ändern. Zuerst muss klar sein, ob das Problem wirklich die Übergangszeit oder eine fehlerhafte STAS-Zuordnung ist.

Wenn die Firewall Traffic von einer IP-Adresse sieht, zu der STAS noch keinen Benutzer kennt, wird diese IP zunächst im Lernmodus geprüft. Während dieser Phase kann Traffic verworfen werden. Antwortet der Collector nicht, behandelt die Firewall die IP für eine gewisse Zeit als unauthentifiziert. Für Geräte ausserhalb der Domäne sollte man deshalb nicht erwarten, dass STAS sie automatisch sauber abdeckt. Für solche Systeme können Clientless Users oder eigene Regeln sinnvoller sein.

STAS über VPN

STAS kann auch über ein IPsec-VPN-Szenario genutzt werden, wenn Benutzer an einem entfernten Standort gegen einen Domain Controller am Hauptstandort authentifiziert werden. Das sollte man aber nur bewusst planen, weil Routing, Quell-IP, STAS-Monitored-Networks und Firewall-Zonen zusammenpassen müssen.

Voraussetzungen für ein solches Design:

• IPsec-Verbindung ist aktiv und stabil.
• Branch-Traffic wird über den Tunnel geroutet.
• STAS und Active Directory sind am Hauptstandort korrekt eingerichtet.
• Das Branch-Netz ist in STAS als überwachtes Netzwerk eingetragen.
• Die Branch-Firewall ist in der STA-Collector-Konfiguration als Sophos Appliance hinterlegt.
• Client Authentication ist für die VPN-Zone in Device Access erlaubt.

Auf der Firewall am Hauptstandort muss das entfernte Netz für STAS über die Device Console ergänzt werden. Beispiel:

system auth cta vpnzonenetwork add source-network 172.50.50.0 netmask 255.255.255.0

Das Beispiel muss durch das echte Branch-Netz ersetzt werden. In vielen Umgebungen ist es trotzdem einfacher und robuster, STAS nur für lokale Clientnetze zu verwenden und entfernte Standorte separat zu designen.

STAS, SATC und Remote Desktop Server

Klassisches STAS funktioniert gut, wenn eine Client-IP typischerweise einem Benutzer gehört. Auf Remote Desktop Servern, Terminalservern oder Citrix-Systemen teilen sich aber mehrere Benutzer dieselbe IP-Adresse. Dann kann klassisches STAS Benutzer nicht sauber unterscheiden.

In solchen Umgebungen sollte man Sophos Authentication for Thin Client (SATC) prüfen. SATC ist kein einfacher Haken in STAS, sondern ein eigenes Design-Thema:

• Welche Server sind betroffen?
• Welche Benutzer arbeiten über diese Server?
• Welche Firewallregeln müssen wirklich benutzerbasiert sein?
• Gibt es gemischten Traffic von Serverdiensten und Benutzersessions?
• Wie wird das Verhalten getestet und dokumentiert?

Wenn Terminalserver nur selten genutzt werden, kann es sinnvoller sein, diese Verbindungen anders zu segmentieren oder eigene Regeln ohne Benutzerbezug zu verwenden. Entscheidend ist, dass die Authentifizierung zur tatsächlichen Netzwerkarchitektur passt.

Betriebscheckliste

Vor der Installation:

• AD-Server auf der Sophos Firewall funktioniert.
• Clientnetze und Domain Controller sind dokumentiert.
• Kein NAT verdeckt Client-IP-Adressen.
• Servicekonto und Rechte sind definiert.
• Audit Policy ist auf relevanten Domain Controllern aktiv.
• Exclusion List ist vorbereitet.

Nach der Installation:

• Agent und Collector laufen.
• Ports zwischen Agent, Collector, Firewall und Clients sind offen.
• Live Users zeigen Testbenutzer.
• Benutzerbasierte Firewallregel trifft im Log Viewer.
• Logoff, Benutzerwechsel und technische Konten wurden getestet.
• Collector-Redundanz ist dokumentiert, falls nötig.

Im Betrieb:

• Servicekonto überwachen.
• Exclusion List regelmässig pflegen.
• Windows-Firewall- und GPO-Änderungen mit STAS abgleichen.
• Subnet-based Filter und überwachte Netze regelmässig mit der echten Clientstruktur abgleichen.
• Nach Firewall- und Domain-Controller-Upgrades STAS testen.
• Vor SFOS 22.0 MR1 oder neuer Restrict client traffic during identity probe prüfen.
• Bei RDS/Citrix nicht mit STAS improvisieren, sondern SATC oder ein anderes Design prüfen.

FAQ