Sophos Firewall Benutzergruppen und Main Group richtig verwalten

Benutzergruppen bündeln gemeinsame Richtlinien für authentifizierte Benutzer. Bevor man eine Gruppe ändert, muss man zwei Dinge klären: Woher stammt die Identität, und wertet die betroffene Funktion nur die Main Group oder auch weitere AD-Gruppen aus? Erst danach lässt sich beurteilen, ob die Gruppenreihenfolge, eine Policy-Zuweisung oder die eigentliche Firewall- beziehungsweise VPN-Regel geändert werden muss.

Der Kurzweg:

1. Benutzerquelle und Zweck der Gruppe festlegen.
2. Eine lokale Gruppe anlegen oder die benötigte Verzeichnisgruppe gezielt importieren.
3. Unter Authentication > Services die wirksame Default group beziehungsweise beim Entra-Server die Fallback user group prüfen.
4. Bei AD die Reihenfolge unter Authentication > Groups > Reorder und die erwartete Main Group dokumentieren.
5. Den Pilotbenutzer abmelden und neu anmelden. Danach unter Authentication > Users > Benutzer > Policies die Felder Group und Other group memberships prüfen.
6. Die betroffene Funktion mit einem berechtigten und einem nicht berechtigten Benutzer testen. Bei Netzwerkverkehr zusätzlich die erwartete Firewall Rule ID kontrollieren.

⚠️ Reorder ist keine harmlose Sortierfunktion. Bei AD-Benutzern kann eine Verschiebung die Main Group und damit MFA, Quoten, Access Time, Remote Access und weitere Richtlinien für viele Benutzer ändern. Notiere vorher die Reihenfolge, die Gruppen-Policies und den Rückweg.

Das Gruppenmodell verstehen

Eine Gruppe trägt gemeinsame Policies und Einstellungen. Sie ersetzt weder die Authentifizierung noch eine Firewall-Regel. Ein Benutzer kann deshalb in der richtigen Gruppe stehen und trotzdem keinen Zugriff erhalten, wenn die erwartete Regel, VPN-Policy, Zone, Route oder der Rückweg fehlt.

Im Fehlerfall helfen vier getrennte Fragen:

1. Stammt die Identität aus der lokalen Datenbank, Active Directory, LDAP, RADIUS, Microsoft Entra ID oder einer Clientless-Zuordnung?
2. Welche Gruppe ist die Main Group?
3. Unterstützt die betroffene Funktion weitere AD-Gruppenmitgliedschaften?
4. Welche Regel oder Policy verarbeitet den tatsächlichen Datenverkehr?

Lokale, importierte und Clientless-Gruppen unterscheiden

Normal und Clientless sind Gruppentypen. Importiert beschreibt dagegen die Herkunft einer Gruppe und ist kein eigener Group type.

Eine lokale Gruppe vom Typ Normal eignet sich für Benutzer, die sich anmelden. Lokale Benutzer erhalten ihre Gruppe im Benutzerobjekt. Bei einer externen Benutzerquelle entstehen die lokalen Benutzerdatensätze normalerweise erst bei der ersten erfolgreichen Anmeldung.

Gastbenutzer folgen einem eigenen zeitlich begrenzten Ablauf. Gastbenutzer auf Sophos Firewall erstellen und sicher betreiben erklärt Default-Gruppe, Gültigkeit, Captive Portal und Bereinigung.

AD- und Entra-Gruppen werden über den Assistenten des jeweiligen Servers importiert. Das Verzeichnis bleibt die Quelle der Mitgliedschaften; eine lokale Gruppe mit demselben Namen ersetzt keinen korrekten Import. Der vollständige AD-, LDAPS- und Importablauf steht unter Active Directory mit Sophos Firewall verbinden.

Bei generischem LDAP müssen Base DN, Authentication attribute, Group name attribute, Serverreihenfolge und Default group zusammenpassen. Sophos empfiehlt memberOf als Gruppenattribut. LDAP-Server mit Sophos Firewall verbinden führt durch diese Konfiguration.

Eine Gruppe vom Typ Clientless bündelt Clientless-Benutzer und deren gemeinsame Einstellungen. Diese Benutzer melden sich nicht über einen Client an; die Firewall steuert ihren Zugriff anhand der IP-Adresse. Die feste IP-Adresse wird am einzelnen Clientless-Benutzer hinterlegt, nicht im Gruppenobjekt. Clientless Users auf Sophos Firewall einrichten beschreibt IP-Zuordnung, Regel und Negativtest.

Default Group und Entra-Fallback nicht gleichsetzen

Unter Authentication > Services > Firewall authentication methods legt Default group fest, welche Gruppe ein Benutzer von einem externen Authentifizierungsserver erhält, wenn keine seiner Verzeichnisgruppen als lokale Gruppe vorhanden ist. Im Auslieferungszustand ist dies Open group. Prüfe den aktuellen Wert, statt den Default anzunehmen. Für den Betrieb empfiehlt Avanet eine eigene restriktive Fallback-Gruppe ohne unbeabsichtigte VPN-, Quota- oder Sign-in-Freigaben.

Microsoft Entra ID SSO verwendet die separate Fallback user group in der Entra-Serverkonfiguration. Sie gilt auch dann, wenn der Entra-Server unter Firewall authentication methods ausgewählt ist. Die allgemeine Default Group greift in diesem Fall nicht.

Die Reihenfolge der Authentifizierungsserver ist ebenfalls relevant. Sophos Firewall erlaubt pro Authentifizierungsmethode höchstens 20 Server und leitet Anfragen in der angezeigten Reihenfolge weiter. Ändere diese Reihenfolge nicht als Gruppen-Workaround, bevor der zuständige Server und sein Mapping geprüft wurden.

Beispiel und Ausgangszustand planen

Das Beispiel verwendet drei getrennte Gruppenaufgaben:

• Local_Contractors: lokale Pilotgruppe für wenige externe Mitarbeitende;
• SFOS_Internet_Standard: importierte AD-Gruppe für normalen Internetzugriff;
• SFOS_SSLVPN: importierte AD-Gruppe für eine SSL-VPN-Policy.

auth-pilot@example.com dient als Testkonto, die geloggte Regel LAN-Users-to-WAN als Verkehrstest. example.com ist eine reservierte Dokumentationsdomain. Ersetze Namen und Benutzer durch die eigene Namenskonvention. Ein funktionsbezogener Name wie SFOS_SSLVPN bleibt auch nach einer Reorganisation verständlich.

Notiere vor der Änderung:

• aktuelle Gruppenreihenfolge;
• Default group und gegebenenfalls Fallback user group;
• Gruppen-Policies und benutzerspezifische Overrides;
• betroffene Authentifizierungsdienste und VPN-Policies;
• einen getesteten Adminzugang und einen zweiten Managementpfad, falls Main Group, MFA oder Sign-in Restrictions betroffen sind;
• Pilotbenutzer, erwartete Main Group sowie Positiv- und Negativtest.

Lokale Benutzergruppe anlegen

Gehe zu Authentication > Groups und klicke auf Add:

1. Als Gruppennamen Local_Contractors eintragen.
2. Bei Group type Normal wählen.
3. Nur die benötigten gemeinsamen Policies auswählen:
   • Surfing quota begrenzt die Nutzungszeit nach Zeitraum und Zyklus.
   • Access time erlaubt oder verweigert wiederkehrende Zeiträume.
   • Network traffic begrenzt die übertragene Datenmenge.
   • Traffic shaping weist eine QoS-Richtlinie mit Priorität und Bandbreitengrenzen zu.
4. SSL VPN policy, Clientless SSL VPN policy, L2TP, PPTP und IPsec remote access nur für den tatsächlich geplanten Zugang setzen. PPTP ist keine Wahl für neue Designs; L2TP bleibt ein begrenzter Kompatibilitätspfad, den L2TP Remote Access auf Sophos Firewall einordnet.
5. Sign-in restriction nach Möglichkeit mit Selected nodes oder Node range auf die benötigten Quellen begrenzen. Any node erlaubt die Anmeldung aus jedem Netz.
6. Quarantine digest und MAC binding nur einschalten, wenn die Gruppe diese Funktionen benötigt.
7. Mit Save speichern.

Die Feldnamen und ihre Wirkung gibt das Produkt vor; die Auswahl hängt von der Umgebung ab. Eine Internetgruppe benötigt nicht automatisch VPN, Quota oder MAC Binding. Gruppen mit klar abgegrenzter Aufgabe sind leichter zu testen und zurückzubauen.

Lokale Benutzer zuordnen und Overrides erkennen

Normale lokale Benutzer erstellen und verwalten beschreibt Username, Passwort, Gruppenvererbung und Abnahme vollständig. Lokale Benutzer lassen sich unter Authentication > Users einer Gruppe zuordnen. In der Gruppenbearbeitung zeigt Show group members die Mitglieder; über Add member(s) nimmt man passende lokale Benutzer auf. Bei extern verwalteten Identitäten bleibt dagegen das Verzeichnis die Quelle der Mitgliedschaft.

Welche Benutzer- oder Gruppeneinstellung eine Regel oder Policy verwendet, hängt von der tatsächlichen Benutzer-/Gruppenauswahl ab. Prüfe beim Benutzer unter Policies, ob ein eigener Wert statt der Gruppeneinstellung ausgewählt ist. Soll die Gruppenrichtlinie wieder gelten, stelle gezielt den zuvor dokumentierten Vererbungszustand her und teste nur die betroffene Funktion erneut. Ein Override bleibt sinnvoll, wenn eine begründete Ausnahme ausdrücklich dokumentiert ist.

Für die Auswahl in der betroffenen Regel oder Policy unterscheidet Sophos zwei Fälle:

• Nur die Gruppe ausgewählt: Die Firewall verwendet die Gruppeneinstellungen, nicht automatisch den Benutzer-Override.
• Benutzer und seine Gruppe ausgewählt: Die Firewall verwendet die Benutzereinstellungen.

Ein begrenzter Pilot macht den Unterschied sichtbar: Für auth-pilot@example.com in Local_Contractors dokumentiert man für dieselbe unterstützte Einstellung einen Gruppenwert A und einen abweichenden Benutzerwert B. A und B sind Platzhalter für zwei bewusst geplante Testwerte der eigenen Umgebung. In einer isolierten Testregel oder Testpolicy mit Benutzer-/Gruppenauswahl prüft man zuerst die tatsächliche Auswahl: nur Local_Contractors bedeutet A; auth-pilot@example.com zusammen mit Local_Contractors bedeutet B. Den betroffenen Dienst beziehungsweise Datenpfad jeweils mit einer frischen Anmeldung testen; bei Firewall-Verkehr zusätzlich die Firewall Rule ID kontrollieren. Danach die zuvor notierte Auswahl und beide Einstellungen wiederherstellen und erneut testen. Dafür weder eine produktive Regel verbreitern noch die Gruppenreihenfolge ändern.

Diese Auswahl ist nicht die Reihenfolge der Main Group. Die unten beschriebenen Grenzen der Mehrfachgruppen-Unterstützung und die Kombination passender SSL-VPN-Policies gelten weiterhin; daraus wird kein allgemeiner Vorrang einer Benutzer-Policy bei jedem Dienst.

Die vollständige Erstellung von Access-Time-Policies, Surfing und Network Traffic Quotas sowie MFA für Sophos Firewall erklären die jeweiligen Spezialartikel. Im Gruppenobjekt wird nur eine bereits geplante Policy zugewiesen.

Verzeichnisgruppen kontrolliert importieren

Active-Directory-Gruppen

Gehe zu Authentication > Servers und starte den Import-Assistenten für den konfigurierten AD-Server. In einem HA-Cluster muss der Import auf dem Primary erfolgen. Der Assistent übernimmt nur ausgewählte Gruppen. Eine später im AD angelegte Gruppe erscheint daher nicht automatisch und muss erneut importiert werden.

Verschachtelte AD-Gruppen werden nicht ausgewertet. Soll eine Untergruppe für eine Firewall-Regel oder VPN-Policy gelten, muss genau diese Untergruppe importiert werden. Die primäre AD-Gruppe eines Benutzers wird ebenfalls nicht als normale Mitgliedschaft übernommen. Für Policies eignen sich deshalb explizite Sicherheitsgruppen besser als die AD-Standardgruppe Domain Users.

Nach Änderungen an AD-Mitgliedschaften, importierten Gruppen oder der Gruppenreihenfolge muss sich der Benutzer neu anmelden. Erst dann wertet die Firewall die Gruppen erneut aus und aktualisiert das Benutzerobjekt.

Entra-Gruppen

Für den Entra-Gruppenimport benötigt die App-Registrierung in Microsoft Graph die Application Permission Group.Read.All mit Admin Consent. Die Uhrzeit von Firewall und Microsoft Entra ID muss synchron sein, sonst kann die Verbindung fehlschlagen.

Gehe danach zu Authentication > Servers und klicke beim Microsoft-Entra-ID-Server auf den Assistenten zum Gruppenimport. Man kann alle Gruppen oder nur Gruppen importieren, deren Display name oder Description einem Filter entspricht. Surfing quota, Access time, Network traffic und Traffic shaping lassen sich für alle oder einzelne importierte Gruppen zuweisen. Neu importierte Gruppen müssen zusätzlich in die verwendeten Remote-Access-IPsec- oder SSL-VPN-Policies aufgenommen werden; der Import allein gewährt keinen VPN-Zugriff.

Main Group und Mehrfachgruppen richtig auswerten

Öffne unter Authentication > Users den Benutzer und scrolle zu Policies:

• Group zeigt die erste passende Gruppe in der Firewall-Liste und damit die Main Group.
• Other group memberships zeigt weitere importierte AD-Gruppen des Benutzers.

Unter Authentication > Groups > Reorder lässt sich die Reihenfolge per Drag-and-drop ändern. Mit Close schliesst man den Dialog. Gehört auth-pilot@example.com zu SFOS_Internet_Standard und SFOS_SSLVPN, wird die weiter oben stehende passende Gruppe bei der nächsten Anmeldung zur Main Group.

Diese Reihenfolge gilt nicht nur für den aktuellen Fehlerfall. Prüfe vor einer Änderung, ob die betroffene Funktion weitere Gruppen unterstützt. Sonst kann eine Verschiebung einen VPN-Fall lösen und gleichzeitig MFA, Quota oder Access Time für andere Benutzer verändern.

Funktionen mit Unterstützung für mehrere AD-Gruppen

Die folgende Matrix gilt ausdrücklich für Active Directory. Sie darf nicht ungeprüft auf LDAP, RADIUS oder Microsoft Entra ID übertragen werden.

Mehrere AD-Gruppen können berücksichtigt werden bei:

• Firewall rules und SSL/TLS inspection rules;
• SD-WAN routes;
• Web policies;
• IPS und Application control policies;
• Policy test;
• Remote access SSL VPN;
• Clientless SSL VPN.

Bei Remote access SSL VPN werden die Berechtigungen passender Benutzer- und Gruppen-Policies kombiniert. Sobald eine passende Full-Tunnel-Policy beteiligt ist, entsteht ein Full Tunnel. Prüfe diese Kombination mit einem echten Clienttest.

Nur die Main Group oder eine ausdrückliche Benutzerzuweisung wird berücksichtigt bei:

• WAF rules, My policy overrides und Hotspots;
• Remote access IPsec VPN, L2TP und PPTP;
• Surfing quota, Access time, Network traffic und Traffic shaping;
• Quarantine digest, MAC binding und Sign-in restriction;
• MFA.

Bei WAF, L2TP, PPTP und Remote access IPsec kann die Benutzer-Policy Enable anzeigen, obwohl die Freigabe nur aus Other group memberships stammt und der Zugriff deshalb nicht erlaubt wird. Beurteile diese Dienste anhand der Main Group beziehungsweise einer direkten Benutzerzuweisung, nicht allein anhand der Anzeige.

Bei Funktionen mit Mehrfachgruppen-Unterstützung entscheidet weiterhin die Reihenfolge der jeweiligen Regel oder Policy. Eine Firewall-Regel kann über SFOS_SSLVPN greifen, obwohl SFOS_Internet_Standard die Main Group ist. Das bedeutet nicht, dass MFA oder Quota ebenfalls SFOS_SSLVPN verwenden.

Gruppenwirkung prüfen

Eine gespeicherte Gruppe und ein sichtbarer Benutzer sind noch kein Erfolgsnachweis:

1. Bestehende Sitzung des Pilotbenutzers beenden und neu anmelden.
2. Unter Authentication > Users > Benutzer > Policies den Status, Group, Other group memberships und mögliche Overrides notieren.
3. Unter Current activities > Live users Benutzername, Quell-IP und Client Type prüfen.
4. Bei einer benutzerbasierten Firewall-Regel den vorgesehenen Datenverkehr auslösen und im Log Viewer die Firewall Rule ID kontrollieren.
5. Access Time, Quota, MFA und Remote Access jeweils über den tatsächlich betroffenen Dienst testen.
6. Den gleichen Versuch mit einem Benutzer ausserhalb der Pilotgruppe als Negativtest wiederholen.

Für die Quota-Prüfung öffnet man Authentication > Users > Benutzer > View usage. Nutzungsdaten stehen nur zur Verfügung, wenn eine benutzerbasierte Firewall-Regel den Verkehr verarbeitet und Log firewall traffic aktiviert ist.

Firewall-Regeln mit Log Viewer, Policy Test und Packet Capture prüfen zeigt den vollständigen Verkehrstest. Wenn schon Dienstwahl, Identität oder Main Group unklar ist, führt Sophos Firewall Authentifizierungsfehler systematisch beheben durch die gesamte Prüfkette.

Änderungen zurückbauen und Gruppen bereinigen

Ändere jeweils nur eine Gruppen-Policy oder Position. Zeigt der Pilot eine unerwartete Wirkung, stelle die notierte Reihenfolge und Policy-Zuweisung wieder her, melde den Benutzer erneut an und wiederhole Positiv- und Negativtest.

AD-Gruppen werden zuerst im Verzeichnis und danach separat unter Authentication > Groups auf der Firewall gelöscht. Purge AD users bereinigt keine Gruppen.

Für AD-Benutzer gilt:

1. Benutzer zuerst im AD löschen. Solange er dort besteht, kann ihn die Firewall bei einer späteren Anmeldung erneut anlegen.
2. Unter Authentication > Users auf Purge AD users klicken. Man muss die Benutzer nicht vorher auswählen; die Firewall prüft den AD-Server und entfernt nur bereits dort gelöschte Benutzer.
3. In HA den Vorgang auf dem Primary starten. Die Datensätze werden auf Primary und Auxiliary entfernt. Die Bereinigung unterbricht Sign-in, Sign-out und User Accounting nicht.

Ein Konfigurationsexport enthält importierte und lokal erstellte AD-Gruppen, aber keine Benutzer von externen Authentifizierungsservern. Ein vollständiges Backup umfasst dagegen alle Benutzer und Gruppen. Berücksichtige diese Grenze, wenn der Rückweg nicht nur eine einzelne Policy-Änderung betrifft.

Benutzer und Gruppen teilen sich den internen ID-Bereich bis 65535. Ein hoher sichtbarer Objektbestand allein beweist kein Limitproblem. Zeigt ein Benutzer eine User ID über 65535 und wird nicht zum Live User, passt der Ablauf zum Sophos Firewall User-ID-Limit.

Fehler nach Symptom eingrenzen

Melde den betroffenen Benutzer nach jeder Korrektur neu an und kontrolliere Group sowie Other group memberships. Danach genügt pro Symptom ein gezielter nächster Schritt.

Neue AD-Gruppe erscheint nicht

Starte den Import-Assistenten des AD-Servers erneut und führe ihn in HA auf dem Primary aus. Prüfe anschliessend unter Authentication > Groups, ob genau die benötigte Gruppe vorhanden ist. Lege keine breite Ersatzgruppe an, nur damit eine Anmeldung funktioniert.

LDAP-Benutzer landet in der Default Group

Prüfe am LDAP-Server Base DN, Authentication attribute und Group name attribute, danach unter Authentication > Services die Serverreihenfolge und Default group. Führe Test connection für den LDAP-Server aus. Der AD-Import-Assistent ist für dieses Mapping nicht zuständig.

Entra-Benutzer landet in der Fallback-Gruppe

Prüfe, ob die Entra-Gruppe importiert wurde und ob der Token die erwartete Gruppe liefert. Kontrolliere danach die Fallback user group direkt am Entra-Server. Die allgemeine Default group unter Authentication > Services wird für dieses Mapping nicht verwendet.

Benutzer hat die falsche Main Group

Vergleiche AD-Mitgliedschaften, importierte Gruppen und die aktuelle Reihenfolge. Prüfe die neue Reihenfolge erst nach der nächsten Anmeldung und mit mehreren repräsentativen Benutzern.

Firewall-Regel greift, aber MFA oder Quota nicht

Firewall-Regeln unterstützen weitere AD-Gruppen, MFA und Quoten dagegen nicht. Prüfe unter Authentication > Users > Benutzer > Policies die Main Group, mögliche Overrides und die tatsächliche Policy-Zuweisung. Die Regelwirkung beweist nicht, dass MFA oder Quota dieselbe Gruppe auswertet.

Gruppenänderung wirkt nur bei einem Benutzer nicht

Vergleiche die benutzerspezifischen Policy-Felder und die tatsächliche Benutzer-/Gruppenauswahl der betroffenen Regel oder Policy: Nur die Gruppe verwendet die Gruppenwerte; Benutzer und seine Gruppe verwenden die Benutzerwerte. Prüfe zusätzlich die Funktionsgrenzen für Main Group und Mehrfachgruppen. Stelle den Gruppenwert nur wieder her, wenn die dokumentierte Ausnahme nicht mehr benötigt wird.

Verschachtelte AD-Gruppe greift nicht

Importiere die benötigte Untergruppe selbst und nimm den Benutzer dort direkt auf. Nur die übergeordnete Gruppe zu importieren reicht nicht.