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. Diese Lizenzvorgaben stammen aus der SFOS-22-Hilfe zu Security Heartbeat; 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.

Laut SFOS-22-Hilfe zu Security Heartbeat tauschen Endpoint und Firewall Heartbeat-Daten über eine verschlüsselte TLS-Verbindung zu 52.5.76.173 auf TCP 8347 aus. Ein grüner Status bedeutet, dass die Sophos-Schutzsoftware korrekt arbeitet und keine aktive oder inaktive Malware beziehungsweise PUA erkannt ist. Er beweist aber noch nicht, dass AD den Benutzer validiert hat. Bei Verbindungsproblemen deshalb Transport, Central-Tenant und Endpoint-Zertifikat getrennt von der Benutzerzuordnung 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.

Danach unter Authentication > Services > Firewall authentication methods den AD-Server nach Selected authentication server verschieben. Die SFOS-22-Hilfe zu Authentication Services bestätigt: Mindestens ein Server muss ausgewählt sein; bei mehreren Servern arbeitet die Firewall die Liste in der angezeigten Reihenfolge ab. Das blosse Anlegen unter Servers reicht für Firewall-Authentifizierung nicht aus.

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 auf Add firewall rule > New firewall rule klicken und eine eng begrenzte Regel für die Pilotgruppe erstellen oder eine vorhandene Benutzerregel kontrolliert verwenden. Im Abschnitt für die Benutzeridentität Match known users aktivieren; erst dann Users or groups auswählen:

• 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: Heartbeat angezeigt werden.
6. Einen erlaubten Traffic-Test über LAN_User_Internet auslösen.
7. Den Log viewer oben rechts öffnen, das Firewall-Modul wählen und 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.

SFOS-22-Release-Notes und bekannte Grenzen einordnen

Für die Abnahme zählt der installierte Maintenance Release, nicht nur «SFOS 22». Dieser aktuelle Synchronized-User-ID-Artikel dokumentiert die beiden konkreten NC-Aussagen selbst. Der SFOS-22-Upgrade-Check ist hier ausschliesslich für die Prüfung von Version, Build und freigegebenem Upgrade-Pfad sowie die Änderungsvorbereitung zuständig. Die Produktkorrekturen lauten: MR1 Build 490 behebt die Verzögerung des Internetzugangs nach manuell ausgelöstem HA-Failover bei Heartbeat-Authentifizierung (NC-165361); MR2 Build 546 behebt falsche Missing-Heartbeat-Meldungen, wenn zwei Endpoints dieselbe Dockingstation oder USB-Schnittstelle verwenden (NC-176012). Wenn eines dieser Symptome auf einer älteren 22.0-Version auftritt, zuerst den exakten Build sichern und einen freigegebenen Updatepfad prüfen.

Das Runbook für Missing-Heartbeat-Alerts behandelt ausserdem NC-147863: Bei SSL-VPN-Split-Tunneling zu einer externen Firewall kann ein neuer VPN-Adapter die Heartbeat-Verbindung unterbrechen. Der Benutzer verliert dann seine Heartbeat-Authentifizierung und gerät unter Umständen in eine Verbindungs- und Trennungsschleife. Wenn der Pilot dieses Szenario umfasst, muss es gezielt getestet werden. Als Workaround nennt Sophos, Match known users in der VPN-Regel der lokalen Firewall zu deaktivieren oder Captive Portal zur Authentifizierung zu verwenden. Eine solche Änderung zuerst auf die betroffene VPN-Regel begrenzen und deren Wirkung sowie Rückweg dokumentieren.

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.

Die offizielle SFOS-22-Anleitung nennt für eine dauerhafte Deaktivierung diese Befehle:

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