Sophos Firewall Benutzergruppen und Main Group richtig verwalten

Benutzergruppen auf der Sophos Firewall bündeln gemeinsame Policies für authentifizierte Benutzer. Sie können Access Time, Quoten, Traffic Shaping, Remote Access und Sign-in Restrictions vereinheitlichen. Eine Gruppe ist aber keine automatische Freigabe: Ob ein Benutzer wirklich Zugriff erhält, entscheiden zusätzlich die erkannte Identität, die wirksame Main Group, die konkrete Firewall- oder VPN-Policy und deren Reihenfolge.

Der sichere Kurzweg lautet:

1. Festlegen, aus welcher Quelle die Benutzer stammen und welche Aufgabe die Gruppe lösen soll.
2. Für normale Benutzer eine Gruppe vom Typ Normal verwenden; IP-basierte Geräteidentitäten separat als Clientless planen.
3. Eine kleine Pilotgruppe mit eindeutiger Funktion und möglichst wenigen gemeinsamen Policies anlegen oder importieren.
4. Unter Authentication > Services die beabsichtigte Default Group beziehungsweise beim Entra-Server die Fallback-Gruppe kontrollieren.
5. Bei Active Directory die Reihenfolge unter Authentication > Groups > Reorder dokumentieren und die erwartete Main Group festlegen.
6. Benutzer-Overrides vermeiden oder ausdrücklich dokumentieren, weil sie Gruppen-Policies übersteuern.
7. Einen frischen Sign-in erzeugen und unter Authentication > Users die Felder Group und Other group memberships prüfen.
8. Die betroffene Funktion mit einem positiven und einem negativen Benutzer testen; bei Traffic zusätzlich die erwartete Firewall Rule ID kontrollieren.
9. Erst nach erfolgreichem Pilot weitere Benutzer aufnehmen und Gruppenreihenfolge, Default Group sowie Ausnahmen regelmässig überprüfen.

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

Das Gruppenmodell in wenigen Minuten verstehen

Eine Gruppe ist auf der Firewall ein gemeinsamer Policy-Träger. Sie kann mehreren Benutzern dieselben Einstellungen geben, damit man nicht jeden Account einzeln pflegen muss. Sie ersetzt weder die Authentifizierung noch eine Firewall-Regel. Ein Benutzer kann korrekt in einer Gruppe erscheinen und trotzdem keinen Zugriff erhalten, wenn die erwartete Regel, VPN-Policy, Zone, Route oder der Rückweg fehlt.

Für den Betrieb helfen vier getrennte Fragen:

1. Woher stammt die Identität? Lokal, Active Directory, LDAP, RADIUS, Microsoft Entra ID oder eine IP-basierte Clientless-Zuordnung.
2. Welche Gruppe ist wirksam? Bei AD kann dies die Main Group oder bei unterstützten Funktionen eine weitere Gruppenmitgliedschaft sein.
3. Welche Gruppen-Policy gilt? Access Time, Quota, Remote Access und andere Felder haben unterschiedliche Auswertungsregeln.
4. Welche Regel erlaubt den Traffic? Gruppen-Policies allein öffnen keinen Netzwerkpfad.

Normal, importiert und Clientless nicht vermischen

Eine lokale Gruppe vom Typ Normal passt für Benutzer, die sich über einen unterstützten Dienst authentifizieren. Ein lokaler Benutzer erhält seine Gruppe im Benutzerobjekt. Bei einer externen Benutzerquelle entstehen die lokalen Benutzerdatensätze normalerweise erst beim ersten erfolgreichen Sign-in.

Gastbenutzer verwenden ebenfalls eine Gruppe, werden aber über einen eigenen zeitlich begrenzten Ablauf erzeugt. Gastbenutzer auf Sophos Firewall erstellen und sicher betreiben erklärt Default-Gruppe, Gültigkeit, Captive Portal, Ausgabe und Bereinigung.

AD-Gruppen werden über den Import-Assistenten übernommen. Ihre Mitgliedschaften werden im Verzeichnis gepflegt und beim Sign-in ausgewertet. Der vollständige Server-, LDAPS- und Importablauf steht unter Active Directory mit Sophos Firewall verbinden. Für generisches LDAP sind Suchbasis, memberOf oder ein anderes Gruppenattribut sowie die lokale Default Group separat zu planen; diese Felder erklärt LDAP-Server mit Sophos Firewall verbinden.

Eine Gruppe vom Typ Clientless löst eine andere Aufgabe. Sie ordnet einer festen IP-Adresse eine Identität zu, ohne dass sich ein Mensch anmeldet. Das ist für Drucker oder andere klar zuordenbare Systeme gedacht und kein Ersatz für Benutzeranmeldung. Den sicheren IP-, Regel- und Negativtest beschreibt Clientless Users auf Sophos Firewall einrichten.

Default Group und Fallback-Gruppe bewusst wählen

Unter Authentication > Services > Firewall authentication methods legt Default group fest, welche Gruppe ein externer Benutzer erhält, wenn keine passende lokale Gruppe vorhanden ist. Eine breite oder historisch gewachsene Default Group kann dadurch unerwartete Policies vergeben. Sicherer ist eine bewusst restriktive Fallback-Gruppe, deren Wirkung positiv und negativ getestet wurde.

Microsoft Entra ID SSO verwendet eine eigene Fallback user group in der Entra-Serverkonfiguration. Diese Einstellung gilt auch dann, wenn der Server unter Firewall authentication methods verwendet wird. Die allgemeine Default Group und die Entra-Fallback-Gruppe werden deshalb nicht gleichgesetzt.

Beispiel und Voraussetzungen planen

Das folgende Beispiel trennt drei Zwecke:

• 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: bewusst angelegtes Testkonto;
• LAN-Users-to-WAN: geloggte Firewall-Regel für den Internettest.

example.com ist eine reservierte Dokumentationsdomain. Gruppennamen, Benutzer und Regelname werden durch die eigene Namenskonvention ersetzt. Ein guter Gruppenname beschreibt die Funktion und nicht nur eine Abteilung. SFOS_SSLVPN bleibt beispielsweise nachvollziehbar, wenn sich die Organisationsstruktur später ändert.

Vor der ersten Änderung werden festgehalten:

• aktuelle Reihenfolge unter Authentication > Groups;
• Default Group und bei Entra ID die Fallback-Gruppe;
• Gruppen-Policies und benutzerspezifische Overrides;
• betroffene Authentifizierungsdienste und Remote-Access-Policies;
• ein getesteter Adminzugang und ein unabhängiger Managementpfad;
• ein Pilotbenutzer mit erwarteter positiver und negativer Wirkung.

Lokale Benutzergruppe anlegen

Unter Authentication > Groups > Add wird die gemeinsame Baseline erstellt:

1. Bei Name Local_Contractors eintragen.
2. Bei Group type Normal wählen.
3. Surfing quota, Access time, Network traffic und Traffic shaping nur setzen, wenn die Gruppe diese Funktionen tatsächlich gemeinsam benötigt.
4. Remote-Access-Felder wie SSL VPN policy oder IPsec remote access nur für den geplanten Zugang aktivieren.
5. Sign-in restriction auf die real benötigten Quelladressen oder den vorgesehenen Bereich begrenzen, sofern das Anmeldemodell dies erlaubt.
6. Quarantine digest und MAC binding nur bewusst einschalten.
7. Mit Save speichern.

Die Namen der Felder sind Produktvorgaben. Die ausgewählten Policies sind dagegen umgebungsabhängig. Eine normale Internetgruppe benötigt nicht automatisch VPN, Quota oder MAC Binding. Je weniger Aufgaben eine Gruppe mischt, desto leichter lassen sich Wirkung und Rückbau verstehen.

Benutzer zuordnen, ohne versteckte Overrides zu erzeugen

Normale lokale Benutzer erstellen und verwalten beschreibt Username, Passwort, Gruppenvererbung, Authentifizierungsmethode und Abnahme vollständig. Sie können über Authentication > Users einer Gruppe zugeordnet werden. In der Gruppenbearbeitung zeigt Show group members die Mitglieder; Add member(s) kann passende lokale Benutzer aufnehmen. Bei extern verwalteten Identitäten bleibt das Verzeichnis die Quelle der Mitgliedschaft. Eine manuelle lokale Zuordnung ersetzt dort keine saubere AD-, LDAP- oder Entra-Konfiguration.

Benutzerspezifische Policies haben Vorrang vor Gruppen-Policies. Ein Override ist für eine dokumentierte Ausnahme oder einen Pilot sinnvoll, kann eine spätere Gruppenänderung aber scheinbar wirkungslos machen. Deshalb wird bei jedem abweichenden Benutzer festgehalten, welches Feld überschrieben wurde, warum die Ausnahme existiert und wie man zum Gruppenwert zurückkehrt.

Die vollständige Erstellung und Abnahme von Access-Time-Policies, Surfing und Network Traffic Quotas sowie MFA für Sophos Firewall bleibt in den jeweiligen Spezialartikeln. Im Gruppenobjekt wird nur die bereits geplante Policy zugewiesen.

Importierte AD-Gruppen kontrolliert betreiben

AD-Gruppen werden unter Authentication > Servers > Import auf die Firewall übernommen. In einem HA-Cluster erfolgt der Import auf dem Primary-Gerät. Der Import-Assistent übernimmt nur die ausgewählten Gruppen. Eine später im AD neu angelegte Gruppe erscheint deshalb nicht automatisch auf der Firewall und muss erneut importiert oder bewusst passend angelegt werden.

Verschachtelte AD-Gruppen werden nicht ausgewertet. Soll eine Untergruppe für eine Firewall-Regel, VPN-Policy oder andere Funktion verwendet werden, 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 einer Änderung an AD-Mitgliedschaften, importierten Gruppen oder der Gruppenreihenfolge wird ein neuer Sign-in erzeugt. Erst dabei wertet die Firewall die Gruppen erneut aus und aktualisiert das Benutzerobjekt.

Main Group und Gruppenreihenfolge verstehen

Bei einem AD-Benutzer zeigt Authentication > Users zwei unterschiedliche Ebenen:

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

Unter Authentication > Groups > Reorder ändert man die Reihenfolge. Gehört auth-pilot@example.com zu SFOS_Internet_Standard und SFOS_SSLVPN, wird die in der Liste weiter oben stehende passende Gruppe beim nächsten Sign-in zur Main Group.

Diese Reihenfolge wird nicht für einen einzelnen Fehlerfall spontan verschoben. Zuerst wird geprüft, welche konkrete Funktion betroffen ist und ob sie weitere Gruppen überhaupt unterstützt. Eine Verschiebung kann sonst einen VPN-Fall reparieren und gleichzeitig MFA, Quota oder Access Time für andere Benutzer verändern.

Mehrfachgruppen werden je Funktion anders ausgewertet

Die folgende Grenze gilt ausdrücklich für Active-Directory-Gruppenmitgliedschaften. Sie wird nicht ungeprüft auf LDAP, RADIUS oder Microsoft Entra ID übertragen.

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 Berechtigungen passender Benutzer- und Gruppen-Policies kombiniert. Sobald eine passende Full-Tunnel-Policy beteiligt ist, entsteht ein Full Tunnel. Diese Kombination gehört deshalb in einen echten Clienttest und nicht nur in einen Vergleich der Gruppennamen.

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 Funktionen mit Mehrfachgruppen-Unterstützung zählt weiterhin die Reihenfolge der jeweiligen Regel oder Policy. Eine Firewall-Regel kann beispielsweise über SFOS_SSLVPN matchen, obwohl SFOS_Internet_Standard die Main Group ist. Das bedeutet nicht, dass MFA oder Quota ebenfalls SFOS_SSLVPN verwenden.

Gruppenwirkung mit einem echten Benutzer testen

Eine gespeicherte Gruppe und ein sichtbarer Benutzer sind noch kein Erfolgsnachweis. Für den Pilot wird derselbe Ablauf verwendet, der später produktiv gelten soll:

1. Bestehende Sitzung des Pilotbenutzers beenden und einen frischen Sign-in erzeugen.
2. Unter Authentication > Users den Status, Group, Other group memberships und mögliche Benutzer-Overrides dokumentieren.
3. Unter Current activities > Live users Benutzername, Quell-IP und Client Type prüfen.
4. Bei einer Benutzer-Firewall-Regel den erwarteten Flow erzeugen und im Log Viewer die Firewall Rule ID kontrollieren.
5. Bei Access Time, Quota, MFA oder Remote Access genau den betroffenen Dienst separat testen.
6. Mit einem Benutzer ohne die Pilotgruppe denselben Flow als Negativtest ausführen.
7. Ergebnis, Zeitpunkt, Gruppenreihenfolge und wirksame Policy festhalten.

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

Änderungen, Rückbau und Betrieb

Gruppenänderungen werden wie Policy-Änderungen behandelt:

1. Ausgangszustand und betroffene Benutzer dokumentieren.
2. Nur eine Gruppe, Policy oder Position gleichzeitig ändern.
3. Pilotbenutzer neu authentifizieren.
4. Main Group, weitere Mitgliedschaften und die konkrete Funktion erneut prüfen.
5. Bei unerwarteter Wirkung die vorherige Gruppenreihenfolge und Policy-Zuweisung wiederherstellen.
6. Erneut einen frischen Sign-in sowie Positiv- und Negativtest ausführen.

Eine AD-Gruppe wird zuerst im Verzeichnis und danach auf der Firewall bereinigt. Ein Benutzer, der im AD weiterhin vorhanden ist, kann bei einem späteren Sign-in erneut lokal angelegt werden. Purge AD users ist deshalb kein Synchronisationsknopf und kein normaler Schritt nach einer Gruppenänderung.

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

Fehler nach Symptom eingrenzen

Neue AD-Gruppe erscheint nicht auf der Firewall

Neue Gruppen werden nicht automatisch synchronisiert. Den Import-Assistenten erneut verwenden und in HA auf dem Primary ausführen. Danach unter Authentication > Groups prüfen, ob genau die benötigte Gruppe vorhanden ist. Keine breite Ersatzgruppe anlegen, nur damit ein Login funktioniert.

Benutzer hat die falsche Main Group

Zuerst AD-Mitgliedschaften, importierte Gruppen und die aktuelle Reihenfolge dokumentieren. Danach kontrollieren, ob die erwartete Gruppe überhaupt auf der Firewall vorhanden ist. Eine geplante Änderung unter Reorder wird erst nach einem neuen Sign-in bewertet und muss mit mehreren repräsentativen Benutzern getestet werden.

Firewall-Regel matcht, aber MFA oder Quota greift nicht

Firewall-Regeln unterstützen weitere AD-Gruppen, MFA und Quoten dagegen nicht. Im Benutzerobjekt prüfen, welche Gruppe unter Group als Main Group steht. Danach benutzerspezifische Overrides und die tatsächliche Policy-Zuweisung kontrollieren. Die Regelwirkung ist kein Beweis für dieselbe Gruppenauswertung bei MFA oder Quota.

Gruppenänderung wirkt nur bei einem Benutzer nicht

Unter Authentication > Users die benutzerspezifischen Policy-Felder vergleichen. Ein einzelner Override hat Vorrang vor der Gruppen-Policy. Der Wert wird nicht blind geändert, sondern zuerst gegen die dokumentierte Ausnahme und den gewünschten Vererbungszustand geprüft.

Benutzer landet in der Default Group

Bei AD oder einem anderen klassischen Authentifizierungsserver fehlt wahrscheinlich eine passende lokale Gruppe oder Gruppenzuordnung. Import, Gruppenname, Suchbasis und zurückgelieferte Attribute prüfen. Bei Microsoft Entra ID SSO stattdessen die Fallback user group des Entra-Servers kontrollieren. Die Default Group wird nicht pauschal verbreitert, um den eigentlichen Mappingfehler zu verdecken.

Verschachtelte AD-Gruppe greift nicht

Die benötigte Untergruppe selbst importieren und den Benutzer dort direkt aufnehmen. Danach einen neuen Sign-in erzeugen und Group sowie Other group memberships kontrollieren. Nur die übergeordnete Gruppe zu importieren reicht nicht.

Betriebscheckliste

• Gruppenzweck und zuständige Benutzerquelle sind dokumentiert.
• Lokale, importierte und Clientless-Gruppen werden nicht vermischt.
• Default Group beziehungsweise Entra-Fallback-Gruppe ist bewusst und restriktiv gewählt.
• Gruppenreihenfolge und erwartete Main Groups sind dokumentiert.
• Benutzer-Overrides sind begründet oder entfernt.
• Die konkrete Funktion unterstützt die verwendete Gruppenmitgliedschaft.
• Pilotbenutzer wurde neu authentifiziert und unter Authentication > Users geprüft.
• Positiv- und Negativtest bestätigen die erwartete Policy oder Firewall Rule ID.
• Remote Access, MFA, Access Time und Quoten wurden getrennt abgenommen, wenn sie verwendet werden.
• Rückweg für Gruppenreihenfolge und Policy-Zuweisung ist festgehalten.

Häufige Fragen