Sophos Firewall Synchronized User ID Authentication einrichten

Synchronized User ID Authentication verbindet die Windows-Anmeldung eines verwalteten Endpoints mit der Sophos Firewall. Sophos Endpoint übermittelt den Domänenbenutzer per Security Heartbeat, die Firewall validiert ihn über Active Directory und zeigt ihn anschliessend unter Current activities > Live users an.

Der Ansatz passt zu verwalteten Einzelplatzrechnern, auf denen Sophos Endpoint und Security Heartbeat bereits funktionieren. Er benötigt keinen zusätzlichen Authentifizierungsagenten auf Client oder Server. Sophos Endpoint selbst bleibt aber Voraussetzung.

⚠️ Die aktuelle Sophos-Dokumentation bestätigt diesen Ablauf für Windows 10. Server Protection, lokale Windows-Benutzer, andere Verzeichnisdienste und weitere Windows-Versionen sind nicht als gleichwertig unterstützt beschrieben. Solche Systeme nicht ohne eigene Freigabe oder Test auf diesen Ablauf umstellen.

Synchronized User ID in acht Schritten

1. Einen Windows-10-Domänenclient mit Sophos Endpoint als Pilot festlegen.
2. Sophos Central, Security Heartbeat und die Firewall-Lizenz prüfen.
3. Active Directory als Authentifizierungsserver der Firewall verbinden.
4. UPN-Domäne, sAMAccountName, E-Mail und Benutzerprofil zwischen AD, Sophos Central und Firewall abgleichen.
5. Eine eng begrenzte, geloggte Benutzerregel für eine Pilotgruppe vorbereiten.
6. Den Piloten frisch an Windows anmelden und einen grünen Heartbeat bestätigen.
7. Benutzer, IP-Adresse und Client Type unter Current activities > Live users sowie den echten Traffic im Log Viewer prüfen.
8. Heartbeat-Verlust, HA-Verhalten und einen kontrollierten Rückweg testen, bevor weitere Endpoints folgen.

Wann Synchronized User ID passt

Synchronized User ID ist kein allgemeiner Ersatz für jede Sophos-Authentifizierung. Das Verfahren passt, wenn ein verwalteter Windows-10-Endpoint typischerweise genau einem AD-Benutzer gehört und Sophos Endpoint bereits einen Security Heartbeat an die Firewall sendet.

Andere Betriebsmodelle benötigen andere Verfahren:

• STAS auf Sophos Firewall ordnet Windows-Anmeldungen über Domain Controller, STA Agent und Collector einer Client-IP zu.
• SATC für Remote Desktop Services unterscheidet mehrere Sitzungen hinter einer RDS- oder Citrix-IP.
• Per-Connection AD SSO unterscheidet HTTP- und HTTPS-Verbindungen mehrerer Benutzer über den Direct Web Proxy.
• Captive Portal oder Client Authentication Agent passen, wenn eine interaktive Anmeldung benötigt wird.

Ein Server- oder Terminalserver-Szenario nicht mit Synchronized User ID erzwingen. Sophos nennt Server Protection ausdrücklich als nicht unterstützt. Wenn mehrere Benutzer dieselbe IP teilen oder Non-Web-Verbindungen pro Sitzung zugeordnet werden müssen, passt SATC besser.

Sind Synchronized User ID und STAS gleichzeitig konfiguriert, verwendet der Authentifizierungsserver laut Sophos den Mechanismus, dessen Sign-in-Request zuerst eintrifft. Diese Koexistenz nicht als feste Priorität behandeln; den Piloten eindeutig abgrenzen und den Client Type bei jeder Abnahme prüfen.

So funktioniert die Zuordnung

Der Ablauf besteht aus vier getrennten Ebenen:

1. Der Benutzer meldet sich am Windows-Domänenclient an.
2. Sophos Endpoint sendet den Domänenbenutzer über Security Heartbeat an die Firewall.
3. Die Firewall liest die Domäne aus dem UPN und den Benutzernamen aus sAMAccountName.
4. Die Firewall validiert den Benutzer über den passenden Active-Directory-Server und aktiviert ihn für benutzerbasierte Regeln.

Die Funktion authentifiziert keine lokalen Windows-Benutzer und ersetzt keine AD-Verbindung. Stimmen UPN-Domäne, Verzeichnisserver oder Benutzerprofil nicht überein, kann ein grüner Endpoint trotzdem ohne verwendbare Benutzeridentität bleiben.

Sophos Firewall teilt oder verwendet dabei keine Kennwortinformationen. Über den Heartbeat werden die für die Zuordnung nötigen Domänen- und Benutzerdaten übertragen; die Validierung erfolgt am konfigurierten AD-Server.

Beispiel und austauschbare Werte

Der Ablauf verwendet diese Dokumentationswerte:

• Firewall: fw01.example.com
• AD-Domäne und UPN-Suffix: example.com
• Windows-Client: WS-101
• Client-IP: 10.20.30.101
• Benutzername: anna.muster
• UPN: anna.muster@example.com
• sAMAccountName: anna.muster
• AD-Gruppe: SFOS-Internet-Users
• Pilotregel: LAN_User_Internet

example.com, WS-101, 10.20.30.101, Benutzer und Gruppe sind Muster und werden durch die echten Werte ersetzt. Entscheidend ist nicht der Name des Objekts, sondern dass Sophos Central, Windows, Active Directory und Firewall denselben Benutzer eindeutig zuordnen.

Voraussetzungen vorbereiten

Sophos Central und Security Heartbeat prüfen

Die Firewall muss mit Sophos Central verbunden sein und über eine gültige Network Protection Subscription verfügen. Der Pilot benötigt Sophos Central Endpoint Protection als Trial oder Vollizenz. Registrierung und Heartbeat-Baseline stehen unter Sophos Firewall mit Sophos Central verbinden.

Unter System > Sophos Central müssen Registrierung und Security Heartbeat aktiv sein. Im Control Center und in Sophos Central muss der Pilot mit einem plausiblen Status erscheinen. Erst diese Baseline herstellen, danach die Identitätszuordnung prüfen.

Synchronized User ID ist standardmässig aktiv. Es gibt deshalb keinen normalen WebAdmin-Schalter, der für den Pilot erst eingeschaltet werden muss. Die weiter unten beschriebenen Shell-Befehle dienen nur einem kontrollierten Deaktivieren oder Wiederaktivieren.

Active Directory und Benutzerattribute abgleichen

Unter Authentication > Servers muss ein passender Active-Directory-Server vorhanden und erreichbar sein. Active Directory mit Sophos Firewall verbinden erklärt LDAPS, Suchbasis, Gruppenimport und Serverreihenfolge.

Für den Pilot müssen mindestens diese Werte zusammenpassen:

• Die Domäne im UPN entspricht der Domäne des von der Firewall verwendeten AD-Servers.
• sAMAccountName ist im Active Directory eindeutig und wird von der Firewall gefunden.
• Benutzerprofil und E-Mail-Adresse passen zwischen AD, Sophos Central und dem lokalen Benutzerdatensatz der Firewall.
• Die benötigte AD-Gruppe ist importiert und dem richtigen Firewall-Benutzerprofil zugeordnet.

Eine Domäne mit abweichendem UPN-Suffix, ein doppelter sAMAccountName in ungeeigneten Suchbereichen oder ein nicht passender AD-Server sind Stop-Signale. Nicht mit einer breiteren Benutzerregel kompensieren.

Pilotregel vorbereiten

Unter Rules and policies > Firewall rules eine eng begrenzte Regel für die Pilotgruppe erstellen oder eine vorhandene Benutzerregel kontrolliert verwenden:

• Source zones: tatsächliche Clientzone
• Source networks and devices: Pilotnetz oder engerer Quellbereich
• Users or groups: SFOS-Internet-Users
• Destination zones: nur der benötigte Zielpfad
• Services: nur die für den Test nötigen Dienste
• Log firewall traffic: aktiv

Regelreihenfolge, Logging und negativer Test sind wichtiger als eine breite Freigabe. Den Aufbau erklärt Firewall-Regeln richtig erstellen.

Pilot anmelden und abnehmen

1. Bestehenden Benutzer am Pilotclient vollständig abmelden.
2. anna.muster@example.com frisch an Windows anmelden.
3. In Sophos Central und auf der Firewall einen grünen Heartbeat prüfen.
4. Unter Current activities > Live users nach anna.muster und 10.20.30.101 suchen.
5. Kontrollieren, ob Benutzer, IP-Adresse und Client Type zur erwarteten Methode passen.
6. Einen erlaubten Traffic-Test über LAN_User_Internet auslösen.
7. Im Log Viewer Benutzername, Quelle, Ziel, Service, Firewall Rule ID, Aktion und Zeitpunkt vergleichen.
8. Mit einem Benutzer ausserhalb der Pilotgruppe einen negativen Test durchführen.

Ein Eintrag unter Live users beweist nur die Identitätszuordnung. Erst der geloggte Testflow beweist, dass auch die richtige Benutzerregel greift. Bleibt im Trafficlog nur die IP sichtbar oder trifft der Flow eine andere Rule ID, nicht die Regel verbreitern, sondern Zuordnung und Reihenfolge prüfen.

Heartbeat-Verlust bewusst testen

Fehlt der Security Heartbeat oder geht er beim Sleep/Wake-Übergang verloren, meldet die Firewall den über Synchronized User ID erkannten Benutzer ab. Andere konfigurierte Authentifizierungsmethoden können danach weiterhin greifen, benutzerbasierter Traffic kann aber bis zur erneuten Anmeldung unterbrochen sein.

Für einen kontrollierten Test:

1. Aktiven Benutzer, IP, Heartbeat-Status und Regel zuerst dokumentieren.
2. Den Piloten in den Ruhezustand versetzen und wieder aufwecken.
3. Heartbeat-Status und Live users erneut prüfen.
4. Einen neuen Traffic-Test auslösen und den tatsächlich verwendeten Benutzer sowie die Rule ID kontrollieren.
5. Bei Abweichungen Endpoint, Pfad und Logs prüfen, nicht Synchronized User ID vorsorglich global deaktivieren.

Ein Missing Heartbeat ist nicht automatisch Malware. Den vollständigen Diagnoseweg erklärt Missing Heartbeat Alerts systematisch prüfen.

Fehler systematisch eingrenzen

Endpoint erscheint nicht mit grünem Heartbeat

Zuerst Central-Registrierung, Endpoint-Lizenz, Network-Protection-Lizenz, Firewall-Zuordnung, DNS, Zeit und Netzwerkpfad prüfen. Ohne funktionierenden Security Heartbeat kann Synchronized User ID keine Identität übertragen.

Benutzer fehlt unter Live users

Windows-Anmeldung, UPN, sAMAccountName, AD-Server, Suchbereich und Benutzerprofil gemeinsam prüfen. Ein grüner Heartbeat bestätigt die Endpoint-Verbindung, nicht automatisch eine erfolgreiche AD-Validierung.

Falscher Benutzer oder falsche Gruppe

UPN-Domäne, AD-Suchbereich, importierte Gruppe, Main Group und lokale Benutzerobjekte vergleichen. Keine Benutzerobjekte löschen, bevor Abhängigkeiten zu VPN, Portal, Regeln, Quoten und Reporting geprüft sind.

Benutzer ist sichtbar, aber die Regel greift nicht

Quellzone, Quellnetz, Benutzer oder Gruppe, Service, Ziel und Regelreihenfolge prüfen. Im Log Viewer muss der echte Flow die erwartete Firewall Rule ID zeigen. Eine sichtbare Identität allein bestätigt keine Autorisierung.

Server oder nicht bestätigte Windows-Version

Server Protection ist für diesen Ablauf nicht unterstützt. Die aktuelle Sophos-Hilfe nennt Windows 10 ausdrücklich. Für andere Windows-Versionen oder unbekannte Endpoint-Typen keine Produktionsfreigabe aus dem Verhalten eines einzelnen Piloten ableiten.

Relevante Logs lesen

In der Advanced Shell helfen diese lesenden Prüfungen:

cd /log
tail -n 200 heartbeatd.log
tail -n 200 access_server.log
tail -n 200 hbtrust.log

heartbeatd.log zeigt Heartbeat-Ereignisse, access_server.log hilft bei Authentifizierung und Autorisierung, hbtrust.log bei der Vertrauensbeziehung zu Sophos Central. Ein einzelnes Log ist kein vollständiger Beweis. Zeitfenster, Benutzer, Endpoint, IP, Rule ID und betroffenen HA-Node gemeinsam sichern. Weitere Logpfade erklärt Sophos Firewall Logdateien und Services.

Wenn unklar bleibt, ob Verzeichnis, Methode, lokaler Benutzerdatensatz oder erst die Regel scheitert, führt Authentifizierungsfehler systematisch beheben durch die methodenübergreifende Prüfkette.

Funktion kontrolliert deaktivieren

⚠️ Die folgenden Befehle verändern den Authentifizierungszustand und starten access_server neu. Vorher aktive Benutzer, betroffene Regeln, alternativen Zugang und Rückweg dokumentieren. In HA müssen beide Nodes bewusst behandelt werden.

Für eine dauerhafte Deaktivierung legt Sophos diese Datei an:

touch /content/no_userid
service access_server:restart -ds nosync

Nur bis zum nächsten Firewall-Neustart deaktiviert diese Variante:

touch /tmp/no_userid
service access_server:restart -ds nosync

Für die Wiederaktivierung wird die persistente Datei entfernt und der Dienst neu gestartet:

rm /content/no_userid
service access_server:restart -ds nosync

Nach jeder Änderung eine frische Windows-Anmeldung, Live users, den echten Traffic und die Logs prüfen. Die Deaktivierung wird nicht in Konfigurationsbackups gespeichert. Nach einem Restore muss der gewünschte Zustand deshalb erneut kontrolliert und bei Bedarf auf beiden HA-Nodes gesetzt werden.

HA, Backup und Betrieb

In einem HA-Cluster wird Synchronized User ID auf beiden Geräten ein- oder ausgeschaltet. Jeder Node speichert nur die Logs des Traffics und der Ereignisse, die er selbst verarbeitet. Für eine Störung deshalb den zum Zeitpunkt aktiven oder verarbeitenden Node prüfen.

Ein kontrollierter HA-Test benötigt eine neue Windows-Anmeldung und einen neuen Trafficflow. Nicht voraussetzen, dass Benutzerzustand oder laufende Sessions ohne Unterbruch fortgesetzt werden. Nach Failover mindestens Heartbeat, Live users, Benutzerregel und Logs erneut abnehmen.

Der Zustand von /content/no_userid gehört nicht zum Backup. Diese Ausnahme muss in Betriebsdokumentation, Restore-Test und RMA-Ablauf ausdrücklich stehen.

Rollback

1. Aktuellen Heartbeat-, Benutzer-, Regel- und HA-Zustand dokumentieren.
2. Pilotregel deaktivieren oder auf den dokumentierten Vorzustand setzen.
3. Bei der persistenten Variante /content/no_userid kontrolliert entfernen und access_server neu starten. Die temporäre Variante endet laut Sophos erst mit dem nächsten Firewall-Neustart.
4. Auf beiden HA-Nodes denselben beabsichtigten Zustand herstellen.
5. Pilot frisch an Windows anmelden und Heartbeat sowie Live users prüfen.
6. Benutzerregel und alternativen Authentifizierungspfad mit echtem Traffic erneut testen.
7. Erst danach temporäre Testobjekte oder Pilotzuordnungen entfernen.

Checkliste

• Der Pilot ist ein unterstützter Windows-10-Domänenclient mit Sophos Endpoint.
• Firewall, Endpoint und Security Heartbeat sind in Sophos Central sichtbar.
• Network Protection und Endpoint-Lizenz sind gültig.
• AD-Server, UPN-Domäne, sAMAccountName, E-Mail und Benutzerprofil stimmen zusammen.
• Die Pilotgruppe ist importiert und die Benutzerregel eng sowie geloggt.
• Live users zeigt den erwarteten Benutzer und die korrekte Client-IP.
• Der echte Traffic trifft die erwartete Firewall Rule ID.
• Heartbeat-Verlust und Sleep/Wake wurden kontrolliert getestet.
• HA-Nodes, Logs, Restore-Grenze und Rückweg sind dokumentiert.
• Synchronized User ID wurde nicht als Ersatz für SATC, STAS oder andere Verzeichnisdienste überdehnt.

Häufige Fragen