Sophos Firewall Synchronized User ID Authentication einrichten

Synchronized User ID Authentication verbindet die Anmeldung eines verwalteten Endpoints mit der Sophos Firewall. Sophos Endpoint übermittelt die Identität per Security Heartbeat. Im AD-Ablauf für SFOS 22 validiert die Firewall den Domänenbenutzer über Active Directory; die SFOS-23-Hilfe beschreibt zusätzlich Microsoft Entra ID mit UPN-Auflösung und Gruppenabfrage. Erfolgreich zugeordnete Benutzer erscheinen unter Current activities > Live users.

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 SFOS-22-Hilfe bestätigt den älteren AD-Ablauf für Windows 10 und schliesst andere Verzeichnisdienste aus. Diese Aussage gilt nicht pauschal für SFOS 23: Dort ist ein eigener Entra-ID-Ablauf dokumentiert. Lokale Benutzer und Geräte mit Server Protection bleiben ausgeschlossen. Die SFOS-23-Seite nennt keine konkrete Betriebssystemversion; daraus oder aus einem erfolgreichen Pilot keine zusätzliche Betriebssystemfreigabe ableiten.

SFOS 23: Entra-Identität über Security Heartbeat

Dieser Zweig beschreibt die Anmeldung am Endpoint, nicht den interaktiven SSO-Login am VPN Portal oder WebAdmin. Die Entra-Integration muss bereits korrekt eingerichtet sein. Die gemeinsame Entra-Grundkonfiguration erklärt App, Berechtigungen, Authentifizierungsserver und Gruppenimport; der VPN-Login selbst ist keine Voraussetzung für diesen Heartbeat-Pilot. Für Administratorzugriff gilt separat Entra ID für WebAdmin.

Mindestvoraussetzungen und Identitätsauflösung

Vor dem Pilot diese Voraussetzungen prüfen:

• Die Firewall läuft auf dem vorgesehenen SFOS-23-Build, ist mit Sophos Central beziehungsweise Sophos Fusion verbunden und hat einen funktionierenden Security Heartbeat. Die unten erhaltenen Lizenzangaben sind ausdrücklich aus der SFOS-22-Hilfe; sie belegen keine neue oder geänderte SFOS-23-Lizenzpflicht. Die Berechtigung für die tatsächlich eingesetzte Version separat prüfen.
• Sophos Endpoint 2025.1 oder neuer ist auf dem verwalteten Pilot installiert. Die SFOS-23-Hilfe verlangt Endpoint auf domänengebundenen Geräten; daraus keine zusätzliche Freigabe für beliebige Join-Modelle oder Betriebssysteme ableiten.
• Das Benutzerkonto verwendet dieselbe E-Mail-Adresse in Sophos Central/Fusion, auf der Firewall und im konfigurierten Verzeichnis. Der angemeldete Entra-Benutzer muss eindeutig zuordenbar sein.
• Microsoft Entra ID ist auf der Firewall erfolgreich als Authentifizierungsserver konfiguriert. Unter Authentication > Servers den Entra-Server und Test connection prüfen; Zeitabgleich, Erreichbarkeit, App-Berechtigungen und Gruppenimport gemäss der verlinkten Grundkonfiguration kontrollieren.
• Endpoint überträgt den gültigen UPN des angemeldeten Entra-Benutzers per Heartbeat. Ab Endpoint 2025.1 werden Loginname, Domänenname und UPN übertragen; ältere Versionen senden keinen UPN. Ohne UPN kann die Firewall den Heartbeat keinem Entra-Benutzer zuordnen. Ein grüner Heartbeat allein genügt deshalb nicht.

⚠️ Benutzer einer einzelnen Domäne nicht gleichzeitig über AD und Entra ID synchronisieren. Die Entra-Voraussetzungen schliessen diese Kombination aus. Einen bestehenden AD-Pfad nicht als automatische Migration umdeuten: Verzeichniszuständigkeit und Rückweg zuerst klären; bei ungeklärter Doppelzuordnung den Pilot stoppen.

Der Entra-Ablauf besteht aus fünf Schritten:

1. Der Benutzer meldet sich mit seinem Entra-ID-Konto am durch Sophos Endpoint geschützten Gerät an.
2. Endpoint sendet die Identitätsinformationen per Security Heartbeat an die Firewall.
3. Die Firewall löst den Entra-Benutzer anhand seines UPN auf. Anders als im AD-Zweig dient hier nicht sAMAccountName als Entra-Zuordnungsschlüssel.
4. Die Firewall ruft die Entra-Gruppenmitgliedschaften ab und aktiviert den Benutzer mit den passenden Benutzer- und Gruppenpolicies sowie den entsprechenden Synchronized-Security-Policies.
5. Der Benutzer erscheint unter Current activities > Live users. Die Firewall verwendet oder teilt dabei keine Kennwörter.

Entra-Pilot und Autorisierung abnehmen

Als Dokumentationsbeispiel dienen anna.muster@example.com, die Client-IP 10.20.30.101, die Entra-Pilotgruppe SFOS-Internet-Users und die Regel LAN_User_Internet. UPN, IP und Gruppe durch die Werte des eigenen Piloten ersetzen. Die Gruppe bewusst auf die benötigten Testbenutzer begrenzen; der Name allein beweist keine Mitgliedschaft oder Berechtigung.

1. Vorzustand von Verzeichniszuordnung, Benutzer- und Gruppenobjekten, Regeln und HA-Nodes sowie einen unabhängigen administrativen Zugang dokumentieren. Einen freigegebenen Testclient und Testkonten verwenden, keine produktiven Konten sperren oder löschen.
2. Die benötigte Entra-Gruppe gemäss Grundkonfiguration importieren und in einer engen, geloggten Regel unter Rules and policies > Firewall rules mit Match known users und Users or groups auswählen. Quelle, Ziel und Services auf den Pilot begrenzen; die weiter unten beschriebene Pilotregel zeigt die Felder.
3. Den Piloten vollständig abmelden und mit dem Entra-Konto neu anmelden. Heartbeat und Current activities > Live users gemeinsam prüfen: erwarteter Benutzer, Client-IP und Client Type: Heartbeat müssen zur Testanmeldung passen. Tatsächlich angezeigte Identität dokumentieren, keinen bestimmten Darstellungsnamen voraussetzen.
4. Einen erlaubten neuen Testflow erzeugen und im Log viewer Benutzer, Quelle, Ziel, Service, Aktion, Zeitpunkt und Firewall Rule ID vergleichen. Erst der richtige Flow belegt die Regelwirkung; ein Live-users-Eintrag allein belegt keine Gruppenautorisierung.
5. Mit einem separaten Testbenutzer ausserhalb der Pilotgruppe denselben Zielpfad prüfen. Dieser darf nicht über die Pilotgruppenregel freigegeben werden. Eine andere zulässige Regel kann weiterhin greifen: deren Rule ID dokumentieren statt eine pauschale Gesamtsperre zu erwarten.
6. Fehlenden oder ungültigen UPN, nicht vorhandenes beziehungsweise inaktives Entra-Testkonto und fehlende Firewall-zu-Entra-Erreichbarkeit als negative Prüffälle abnehmen. Störungen nur in einer isolierten, freigegebenen Testumgebung herstellen, nicht durch tenantweite Sperren oder globale Netzblockaden. Ohne solche Umgebung die Prüffälle als offen dokumentieren, nicht als erfolgreich getestet. Bei fehlendem UPN keine Entra-Zuordnung erwarten; für Konto- und Erreichbarkeitsfehler keine bestimmte Fehlermeldung oder sofortige Abmeldung bestehender Sessions zusagen.
7. Heartbeat-Verlust und Sleep/Wake kontrolliert prüfen. Bei fehlendem Heartbeat wird der synchronisierte Benutzer abgemeldet; andere Authentifizierungsmethoden können weiter greifen, Traffic kann bis zur erneuten Anmeldung unterbrochen sein. Die folgende Heartbeat-Prüfkette gilt auch hier.

Entra-Benutzer fehlt oder hat die falsche Gruppe

Bei grünem Heartbeat ohne passende Identität zuerst Endpoint-Version und tatsächlich gemeldeten UPN prüfen. Danach kontrollieren, ob das Entra-Konto existiert und aktiv ist, ob Firewall-Dienste Entra erreichen und ob die Entra-Konfiguration erfolgreich abgeschlossen ist. Unter Authentication > Servers erneut Test connection ausführen. Ein erfolgreicher Verbindungstest allein belegt weder den UPN des Endpoints noch die Gruppenautorisierung.

Ist die Identität sichtbar, aber die Gruppe oder Regel falsch, Entra-Mitgliedschaft, importierte Firewall-Gruppe, Benutzerzuordnung und Regelreihenfolge vergleichen. Den betroffenen Flow mit Rule ID und Zeitpunkt sichern. Keine Regeln verbreitern, Benutzerobjekte löschen oder Dienste vorsorglich neu starten. Für eine Eskalation SFOS-Build, Endpoint-Version, anonymisierten UPN, Heartbeat-Status, Client-IP, Zeitfenster und verarbeitenden HA-Node zusammen mit den unten genannten Logs sichern.

HA und Rückweg für den Entra-Pilot

Auch die SFOS-23-Hilfe beschreibt Synchronized User ID als standardmässig aktiv und verlangt das Ein- oder Ausschalten auf beiden HA-Geräten. Die Änderung des Zustands wird nicht im Backup gespeichert. Die erhaltenen Shell-Befehle weiter unten sind auch in SFOS 23 dokumentiert; sie schalten die Funktion insgesamt um, nicht nur Entra. Ein solcher Dienstneustart ist deshalb kein harmloser Pilot-Rollback.

Failover nur in einem freigegebenen Wartungsfenster mit unabhängigem administrativem Zugang testen. Auf dem danach verarbeitenden Node Heartbeat, neue Entra-Anmeldung, Live users, Gruppenregel und neuen Testflow erneut abnehmen. Keine unterbrechungsfreie Übernahme von Benutzerzustand oder Sessions voraussetzen; die unten genannten SFOS-22-Fixes sind keine neue SFOS-23-Failover-Garantie.

Für den Rückweg zuerst Pilotregel und Pilotzuordnungen auf ihren dokumentierten Vorzustand setzen und den bisherigen Authentifizierungspfad mit frischer Anmeldung und echtem Traffic prüfen. Gemeinsam von VPN, Portal oder WebAdmin genutzte Entra-App, Server, Berechtigungen und Gruppen nicht als Testbereinigung löschen oder global deaktivieren. Falls im Wartungsfenster auch der globale Synchronized-User-ID-Zustand geändert wurde, den beabsichtigten Zustand auf beiden Nodes ausdrücklich wiederherstellen und nach Restore separat prüfen. Einen AD-Rückweg erst wieder aktivieren, wenn die Entra-Synchronisierung derselben Domäne kontrolliert beendet ist.

Die folgenden AD-Schritte und Beispiele bleiben als eigener, älterer SFOS-22-Pfad erhalten. Die AD-Identitätsauflösung wird auch in der SFOS-23-Hilfe beschrieben, ersetzt dort aber nicht die Entra-Prüfung.

SFOS 22 mit AD: Synchronized User ID in acht Schritten

1. Einen Windows-10-Domänenclient mit Sophos Endpoint als Pilot festlegen.
2. Sophos Fusion (ehemals 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 Fusion 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. Der erhaltene SFOS-22-AD-Pfad passt, wenn ein verwalteter Windows-10-Endpoint typischerweise genau einem AD-Benutzer gehört und Sophos Endpoint bereits einen Security Heartbeat sendet. Für Entra-Benutzer unter SFOS 23 gelten die Voraussetzungen und die Abnahme im eigenen Zweig oben.

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

AD-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 Fusion, Windows, Active Directory und Firewall denselben Benutzer eindeutig zuordnen.

Voraussetzungen vorbereiten

Sophos Fusion und Security Heartbeat prüfen

Die Firewall muss mit Sophos Fusion 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 Fusion verbinden.

Unter System > Sophos Fusion müssen Registrierung und Security Heartbeat aktiv sein. Im Control Center und in Sophos Fusion 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, Fusion-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 (AD-Pfad)

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

AD-Pilot anmelden und abnehmen

1. Bestehenden Benutzer am Pilotclient vollständig abmelden.
2. anna.muster@example.com frisch an Windows anmelden.
3. In Sophos Fusion 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 Fusion-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

Für den AD-Pfad 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. Unter SFOS 23 bei Entra-Benutzern stattdessen die UPN-, Konto- und Erreichbarkeitsprüfung im Entra-Zweig verwenden.

Falscher Benutzer oder falsche Gruppe

Für AD UPN-Domäne, AD-Suchbereich, importierte Gruppe, Main Group und lokale Benutzerobjekte vergleichen. Für Entra unter SFOS 23 gelten zusätzlich die Entra-Mitgliedschaft und UPN-Zuordnung im eigenen Zweig. 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 beide Pfade nicht unterstützt. Die SFOS-22-Hilfe nennt für AD Windows 10 ausdrücklich; die SFOS-23-Seite legt keine konkrete Betriebssystemversion fest. Für andere Betriebssysteme, Join-Modelle oder unbekannte Endpoint-Typen keine Produktionsfreigabe aus der Dokumentationsverfügbarkeit oder 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 Fusion. 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 offiziellen SFOS-22- und SFOS-23-Anleitungen nennen 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. Nur wenn der globale Funktionszustand im Test verändert wurde, den dokumentierten Vorzustand kontrolliert wiederherstellen. Für eine beabsichtigte Wiederaktivierung nach persistenter Deaktivierung /content/no_userid entfernen und access_server neu starten; nicht pauschal eine vorher deaktivierte Funktion einschalten. Die temporäre Variante endet laut Sophos mit dem nächsten Firewall-Neustart. Einen Neustart nicht allein zur Testbereinigung ausserhalb eines freigegebenen Wartungsfensters auslösen.
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 für den SFOS-22-AD-Pfad

• Der Pilot ist ein unterstützter Windows-10-Domänenclient mit Sophos Endpoint.
• Firewall, Endpoint und Security Heartbeat sind in Sophos Fusion 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