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:

Benutzerquelle und Zweck der Gruppe festlegen.
Eine lokale Gruppe anlegen oder die benötigte Verzeichnisgruppe gezielt importieren.
Unter Authentication > Services die wirksame Default group beziehungsweise beim Entra-Server die Fallback user group prüfen.
Bei AD die Reihenfolge unter Authentication > Groups > Reorder und die erwartete Main Group dokumentieren.
Den Pilotbenutzer abmelden und neu anmelden. Danach unter Authentication > Users > Benutzer > Policies die Felder Group und Other group memberships prüfen.
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. Vorher die Reihenfolge, die Gruppen-Policies und den Rückweg notieren.

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:

Stammt die Identität aus der lokalen Datenbank, Active Directory, LDAP, RADIUS, Microsoft Entra ID oder einer Clientless-Zuordnung?
Welche Gruppe ist die Main Group?
Unterstützt die betroffene Funktion weitere AD-Gruppenmitgliedschaften?
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. Für AD dokumentiert Sophos alternativ das manuelle Anlegen der Gruppe sowohl im AD als auch auf der Firewall. Auch dabei müssen Gruppenzuordnung und Berechtigungen nach einer neuen Anmeldung geprüft werden. 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. Den aktuellen Wert prüfen, statt den Default anzunehmen. Für den Betrieb empfiehlt Avanet eine eigene restriktive Fallback-Gruppe ohne unbeabsichtigte VPN-, Quota- oder Sign-in-Freigaben.

Abweichende AD-Beschreibungen zur ersten Anmeldung: Die AD-Einrichtungsanleitung beschreibt eine automatische Aufnahme in die Default Group bei der ersten Anmeldung; die AD-FAQ nennt die Default Group dagegen nur, wenn keine AD-Gruppe des Benutzers auf der Firewall vorhanden ist. Die AD-Serverübersicht nennt für Benutzer, die nur einer OU und keiner Verzeichnisgruppe angehören, ausdrücklich Open group, während die Gruppenübersicht und die FAQ auf die konfigurierte Default group verweisen. Diese Beschreibungen sind nicht widerspruchsfrei und belegen keine besondere, universell geltende Erstlogin-Gruppe oder deren Vorrang. Die konfigurierte Default group ist von der Werkseinstellung Open group zu unterscheiden.

Vor dem Rollout die tatsächliche Default group und ihre geerbten Berechtigungen prüfen. Die erste Anmeldung getrennt mit zwei dafür vorgesehenen Pilotkonten prüfen: eines mit einer bereits importierten AD-Gruppe auf der Firewall und eines, dessen AD-Gruppen dort nicht importiert sind. Bei beiden unter Policies die Felder Group und Other group memberships sowie erlaubte und bewusst nicht erlaubte Zugriffe prüfen. Bei unerwarteter Zuordnung den Rollout stoppen und die Ursache klären. Dafür weder produktive Gruppen löschen noch Fallback-Berechtigungen erweitern.

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. Diese Reihenfolge nicht als Gruppen-Workaround ändern, 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. Namen und Benutzer durch die eigenen Werte gemäss Namenskonvention ersetzen. Ein funktionsbezogener Name wie SFOS_SSLVPN bleibt auch nach einer Reorganisation verständlich.

Vor der Änderung notieren:

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

Unter Authentication > Groups auf Add klicken:

Als Gruppennamen Local_Contractors eintragen.
Bei Group type Normal wählen.
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.
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.
Sign-in restriction nach Möglichkeit mit Selected nodes oder Node range auf die benötigten Quellen begrenzen. Selected nodes erlaubt nur die angegebenen IP-Adressen; Node range erlaubt Adressen innerhalb des angegebenen IP-Bereichs. Any node erlaubt die Anmeldung aus jedem Netz.
Quarantine digest und MAC binding nur einschalten, wenn die Gruppe diese Funktionen benötigt. Quarantine digest sendet eine Zusammenfassung der in Quarantäne zurückgehaltenen E-Mails an das Postfach des Benutzers. MAC binding beschränkt die Anmeldung auf die vorgesehenen Geräte.
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. Beim Benutzer unter Policies prüfen, ob ein eigener Wert statt der Gruppeneinstellung ausgewählt ist. Soll die Gruppenrichtlinie wieder gelten, gezielt den zuvor dokumentierten Vererbungszustand herstellen und nur die betroffene Funktion erneut testen. 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.

Gruppenfelder in der XML API einordnen

Wer Gruppen automatisiert verwaltet, findet im XML-Modell UserGroup als Gruppenobjekt, GroupDetail als Konfigurationskörper und GroupMembers mit GroupName und UserName als Mitgliedschaftsdaten. Das ist kein AD-Mitgliedschaftsimport; bei Verzeichnisbenutzern bleibt das Verzeichnis massgebend. Authentifizierung, ausdrückliche Operationshüllen und Auswertung der XML-Antwort behandelt XML API sicher verwenden.

Der folgende Ausschnitt zeigt nur die dokumentierte Struktur für die vorhandenen Pilotbeispiele. Er ist keine vollständige Add/Edit-Anfrage; insbesondere fehlen Operationshülle und weitere benötigte Konfigurationsfelder. Aus den ausgelassenen Feldern folgt nicht, dass eine Änderung bestehende Werte erhält.

<UserGroup>
  <GroupDetail>
    <Name>Local_Contractors</Name>
    <LoginRestriction>SelectedNodes</LoginRestriction>
    <NodeList>
      <IPAddress>192.0.2.10</IPAddress>
    </NodeList>
  </GroupDetail>
  <GroupMembers>
    <GroupName>Local_Contractors</GroupName>
    <UserName>auth-pilot@example.com</UserName>
  </GroupMembers>
</UserGroup>

Gruppenname und Benutzer sind durch das genau geplante lokale Ziel zu ersetzen. 192.0.2.10 ist eine IPv4-Dokumentationsadresse und muss durch eine tatsächlich benötigte erlaubte Anmeldequelle ersetzt werden. Die XML-Feldnamen bleiben unverändert. Die Zuordnung zu den UI-Feldern lautet:

SurfingQuotaPolicy: Surfing quota; AccessTimePolicy: Access time.
DataTransferPolicy: Network traffic; QoSPolicy: Traffic shaping.
SSLVPNPolicy: SSL VPN policy; ClientlessPolicy: Clientless SSL VPN policy, nicht der Gruppentyp Clientless.
SophosConnectClient: IPsec remote access über den Sophos Connect Client.

Für LoginRestriction unterscheidet das Referenzbeispiel AnyNode, SelectedNodes und NodeRange. AnyNode entspricht Any node und begrenzt die Anmeldequelle nicht; es ist kein Fehlerbehebungs-Default. SelectedNodes verwendet NodeList mit den einzelnen IPAddress-Einträgen. NodeRange verwendet stattdessen FromIP und ToIP, beispielsweise 192.0.2.10 bis 192.0.2.20. Auch beide Bereichsgrenzen sind Dokumentationswerte und durch den kleinsten erforderlichen IPv4-Bereich zu ersetzen, ohne bestehende Einschränkungen zu verbreitern. Obwohl die Tabelle FromIP und ToIP als Pflichtfelder markiert, beschränkt ihre Beschreibung sie auf Node range; daraus ergibt sich keine allgemeine Pflicht für die anderen Varianten.

Die API-Referenz nennt für QuarantineDigest, MACBinding, L2TP, PPTP und SophosConnectClient jeweils Enable oder Disable und dokumentiert Disable als Default. Das ist Referenzinformation, kein Nachweis über den aktuell gespeicherten Gruppenzustand. Bei aktivem QuarantineDigest wird die Quarantäne-Zusammenfassung täglich per E-Mail gesendet. PPTP bleibt für neue Designs ausgeschlossen; L2TP ist weiterhin nur der oben eingeordnete begrenzte Kompatibilitätspfad.

Grenzen des Referenzbeispiels: Es trennt Einstellungen für Normal-Gruppen von einem Clientless-Zweig, der QoSPolicy zeigt. Bei GroupType ist es jedoch widersprüchlich: Das Muster enthält Normal/Clienless, die Beschreibung nennt Normal oder Clientless und bezeichnet den Datentyp als INTEGER. Zudem enthält das Muster Doppelpunkt-Platzhalter statt vollständiger XML-Inhalte. Daraus darf man weder eine korrigierte Clientless-Codierung noch eine numerische Zuordnung ableiten. Für einen Schreibvorgang einen ausgelesenen oder exportierten Wert der installierten Version verwenden, dessen Zuordnung bereits feststeht; andernfalls den sicheren UI-Ablauf nutzen. Slash-Alternativen wie Enable/Disable sind keine einzelnen Werte zum Übernehmen.

Das Muster zeigt ausserdem After mit einem darin verschachtelten Name als Positionsangabe. Die zweite Tabellenzeile für Name erwähnt moveto, belegt aber keine eigenständig ausführbare Operation. Eine Positionsänderung ist wie Reorder zu behandeln: Sie kann die Main Group verändern. Vorher Reihenfolge, Mitgliedschaften, aktuellen und beabsichtigten Policy-Zustand sowie den Rückweg sichern; danach mit dem Pilot prüfen und bei unerwarteter Wirkung die gespeicherte Reihenfolge wiederherstellen. Das Muster belegt weder Ersetzungs- oder Zusammenführungsverhalten von GroupMembers noch Update-Semantik von After oder ausgelassenen Feldern.

Vor einem eng begrenzten Add/Edit-Schreibvorgang Zielname und Sollzustand festhalten. Danach das tatsächliche XML-Operationsergebnis auswerten, genau die benannte Gruppe erneut auslesen und die oben beschriebenen Positiv-/Negativtests am betroffenen Dienst durchführen. Die Referenz ordnet bei Add und Edit 502 dem Schlüssel UserGroupRecordExists und 503 dem Schlüssel UserGroupDuplicateIPInLoginRestriction zu. Bei einem entsprechenden Ergebnis zuerst den beabsichtigten vorhandenen Gruppennamen beziehungsweise doppelte Adressen in SelectedNodes prüfen. Nicht blind erneut senden oder LoginRestriction verbreitern. Diese Zuordnungen bezeichnen Referenzschlüssel, keine aufgelösten Laufzeitmeldungen.

Verzeichnisgruppen kontrolliert importieren

Active-Directory-Gruppen

Unter Authentication > Servers den Import-Assistenten für den konfigurierten AD-Server starten. 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.

Vor dem Import muss die AD-Abfrage funktionieren: Der Server benötigt die richtige NetBIOS domain, Domain name, ein ADS username mit Rechten zum Suchen, Lesen und Abfragen von Gruppenmitgliedschaften sowie dessen Password. Ein Domain-Admin-Konto ist für den Gruppenimport nicht nötig. Connection security bietet SSL/TLS als Standard und STARTTLS als verschlüsselte Alternative; Plaintext überträgt Zugangsdaten unverschlüsselt und ist keine sichere Produktionslösung. Der Port muss zur gewählten Verbindungsart passen. Bei Validate server certificate wird das AD-Serverzertifikat unter Certificates > Certificates > Add > Upload certificate hochgeladen; Server IP/domain muss den im Zertifikat angegebenen CNAME verwenden. Falls die Firewall diesen Namen nicht auflösen kann, ist die interne DNS-Auflösung beziehungsweise Network > DNS > DNS host entry zu prüfen. Die vollständige Servereinrichtung bleibt im oben verlinkten AD-Artikel.

Die Search queries begrenzen den erfassten Benutzerkreis. Beispielsweise sucht OU=VPN_Users,DC=example,DC=com in der OU VPN_Users der Dokumentationsdomain example.com; OU und Domainbestandteile müssen durch den tatsächlichen Distinguished Name ersetzt werden. Eine engere Suchbasis hält den Benutzerkreis übersichtlich, darf aber die vorgesehenen Benutzer nicht ausschliessen. Nur erfasste Benutzer können über diesen Server als Live Users erscheinen. Test connection prüft Verbindung und Zugangsdaten, beweist aber noch nicht die richtige Gruppenzuordnung eines normalen Benutzers. Strikt erzwungenes LDAP Channel Binding und LDAP Signing werden nicht unterstützt; eine entsprechende AD-Sicherheitsvorgabe wird vor der Integration geklärt, nicht als Gruppenfehler umgangen.

Der eigentliche Import läuft so ab:

Beim vorgesehenen AD-Server Import anklicken und im Import group wizard mit Start beginnen.
Die passende Base DN für die Gruppensuche auswählen. Sie muss die benötigten Gruppen einschliessen und ist von der Suchbasis für Benutzer zu unterscheiden.
Nur die vorgesehenen AD-Gruppen markieren, beispielsweise SFOS_Internet_Standard und SFOS_SSLVPN.
Die gemeinsamen Gruppen-Policies auswählen; danach Auswahl und Ergebnisse kontrollieren.
Unter Authentication > Groups beide Gruppen und ihre Policies prüfen. Der Assistent importiert Gruppen, nicht sofort alle Benutzerdatensätze oder Mitgliedschaften.
Unter Authentication > Services > Firewall authentication methods kontrollieren, dass der AD-Server für den geplanten Dienst ausgewählt ist. Soll AD in diesem Einrichtungsweg zuerst abgefragt werden, den Server an die erste Position verschieben und Apply anklicken. In einer bestehenden Umgebung die zuvor geplante Serverreihenfolge erhalten, statt sie pauschal zu ändern.

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.

Das gilt nicht nur für Domain Users: Wird beispielsweise SFOS_Internet_Standard zur primären AD-Gruppe des Benutzers, wird gerade diese Mitgliedschaft nicht wie eine normale AD-Mitgliedschaft übernommen. Die nächste passende importierte Gruppe kann dadurch zur Main Group werden. Die Firewall-Main-Group wird aus ihrer eigenen Gruppenliste ermittelt und ist nicht die primäre Gruppe im AD.

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.

Sind STAS und Synchronized User ID gleichzeitig eingerichtet, verwendet der Authentifizierungsserver den Mechanismus, von dem die Anmeldeanforderung zuerst eintrifft. Bei unterschiedlichen Pilotresultaten deshalb zusätzlich Client Type prüfen, statt sofort Gruppen oder Server umzusortieren.

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.

Danach unter Authentication > Servers beim Microsoft-Entra-ID-Server auf den Assistenten zum Gruppenimport klicken. 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

Unter Authentication > Users den Benutzer öffnen und zu Policies scrollen:

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.

Zwei weitere Felder erscheinen unter Policies nur, wenn jeweils beide Voraussetzungen erfüllt sind:

Group SSL VPN policies: Der Benutzer gehört mehreren AD-Gruppen an, und mindestens zwei dieser Gruppen sind in Remote-Access-SSL-VPN-Policies enthalten.
Group clientless SSL VPN policies: Der Benutzer gehört mehreren AD-Gruppen an, und mindestens zwei dieser Gruppen sind in Clientless-SSL-VPN-Policies enthalten.

Fehlt eines dieser Felder, prüft man deshalb zuerst die AD-Mitgliedschaften, die importierten Gruppen und deren Aufnahme in die jeweilige VPN-Policy. Mehrere AD-Gruppen allein reichen für die Anzeige nicht aus. Um das Feld sichtbar zu machen, erweitert man keine produktiven VPN-Berechtigungen. Die Anzeige ist zudem kein Zugriffstest; die tatsächliche Kombination der Berechtigungen wird weiter unten eingeordnet.

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. Vor einer Änderung prüfen, 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. Diese Kombination mit einem echten Clienttest prüfen.

Bei Clientless SSL VPN werden die Berechtigungen aller Policies berücksichtigt, denen eine der AD-Gruppen des Benutzers angehört. Deshalb nicht nur die erwartete Policy, sondern auch zusätzliche freigegebene Bookmarks beziehungsweise Ressourcen aus anderen Gruppen prüfen.

Hotspots berücksichtigen ausschliesslich die Main Group.

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

WAF rules, My policy overrides;
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. Diese Dienste anhand der Main Group beziehungsweise einer direkten Benutzerzuweisung beurteilen, 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.

Bei Web policies sind es zwei getrennte Entscheidungen: Zuerst bestimmt die passende Firewall-Regel die Web-Policy. Darin greift die erste Regel, die sowohl zum Benutzer als auch zur Website passt. Gehört der Pilot zu beiden Beispielgruppen und blockiert die erste Web-Regel Sportseiten für SFOS_SSLVPN, wird eine Sportseite blockiert, auch wenn SFOS_Internet_Standard seine Main Group ist und eine spätere Regel Nachrichten für diese Gruppe erlaubt. IPS und Application control übernehmen dagegen die Policy der passenden Firewall-Regel; die Gruppenreihenfolge erzeugt keine zusätzliche Zusammenführung dieser Policies.

Für MFA kann statt einer Gruppenauswahl der Benutzer ausdrücklich aufgenommen oder MFA auf alle Benutzer angewendet werden. Eine Freigabe nur über Other group memberships reicht nicht. Hotspots im User Portal richten sich ausschliesslich nach der Main Group; eine weitere AD-Gruppe erweitert diese Liste nicht.

Gruppenwirkung prüfen

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

Bestehende Sitzung des Pilotbenutzers beenden und neu anmelden.
Unter Authentication > Users > Benutzer > Policies den Status, Group, Other group memberships und mögliche Overrides notieren.
Unter Current activities > Live users Benutzername, Quell-IP und Client Type prüfen.
Bei einer benutzerbasierten Firewall-Regel den vorgesehenen Datenverkehr auslösen und im Log Viewer die Firewall Rule ID kontrollieren.
Access Time, Quota, MFA und Remote Access jeweils über den tatsächlich betroffenen Dienst testen.
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

Jeweils nur eine Gruppen-Policy oder Position ändern. Zeigt der Pilot eine unerwartete Wirkung, die notierte Reihenfolge und Policy-Zuweisung wiederherstellen, den Benutzer erneut anmelden und Positiv- und Negativtest wiederholen.

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:

Benutzer zuerst im AD löschen. Solange er dort besteht, kann ihn die Firewall bei einer späteren Anmeldung erneut anlegen.
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.
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. Diese Grenze berücksichtigen, wenn der Rückweg nicht nur eine einzelne Policy-Änderung betrifft.

Eine benannte Gruppe per API sicher löschen

Vor jeder Löschung den exakten Name der Zielgruppe festlegen und Policies, Reihenfolge, Mitglieder und Verwendungen sichern. Dass die ältere API-Tabelle Name als nicht verpflichtend kennzeichnet, ist kein Freibrief für eine unbenannte Löschung: Die Beschreibung verlangt einen Namen zur Identifikation des Objekts. Vorher tatsächliche Gruppenbenutzer, VPN-Zuweisungen einschliesslich L2TP/IPsec, die Auswahl für externe Authentifizierung, Firewall-Regelreferenzen und die Verwendung als Gast-Default-Gruppe prüfen. Wird die Gruppe noch benötigt, eine ausdrücklich geplante, eng begrenzte Migration durchführen oder stoppen. Weder Entfernung erzwingen noch Benutzer bereinigen oder Zugriffe lockern, nur um die Löschung durchzubringen. Die oben beschriebene AD-Reihenfolge und die Trennung zu Purge AD users bleiben bestehen.

Die Löschreferenz verknüpft Ergebniszeilen mit JavaScript-Meldungsschlüsseln zu solchen Abhängigkeiten. Die Schlüssel ersetzen weder aufgelöste Meldungstexte noch die Auswertung eines konkreten Appliance-Fehlers. Für Anfrageaufbau und XML-Ergebnisbehandlung gilt XML API sicher verwenden; die Gruppen-Löschreferenz liefert kein Payload-Beispiel, deshalb wird hier keine Delete-Hülle erfunden. Bei einer Ablehnung die Gruppe erhalten und die im Ergebnis angezeigte Referenz gezielt prüfen. Auch nach einem Erfolgsergebnis genau das Ziel erneut auslesen, sein Fehlen kontrollieren und die vorgesehenen Dienst- und Zugriffstests wiederholen.

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

Den betroffenen Benutzer nach jeder Korrektur neu anmelden und Group sowie Other group memberships kontrollieren. Danach genügt pro Symptom ein gezielter nächster Schritt.

Neue AD-Gruppe erscheint nicht

Den Import-Assistenten des AD-Servers erneut starten und in HA auf dem Primary ausführen. Anschliessend unter Authentication > Groups prüfen, ob genau die benötigte Gruppe vorhanden ist. Keine breite Ersatzgruppe anlegen, nur damit eine Anmeldung funktioniert.

LDAP-Benutzer landet in der Default Group

Am LDAP-Server Base DN, Authentication attribute und Group name attribute prüfen, danach unter Authentication > Services die Serverreihenfolge und Default group. Test connection für den LDAP-Server ausführen. Der AD-Import-Assistent ist für dieses Mapping nicht zuständig.

Entra-Benutzer landet in der Fallback-Gruppe

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

Benutzer hat die falsche Main Group

AD-Mitgliedschaften, importierte Gruppen und die aktuelle Reihenfolge vergleichen. Die neue Reihenfolge erst nach der nächsten Anmeldung und mit mehreren repräsentativen Benutzern prüfen.

Firewall-Regel greift, aber MFA oder Quota nicht

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

Gruppenänderung wirkt nur bei einem Benutzer nicht

Die benutzerspezifischen Policy-Felder und die tatsächliche Benutzer-/Gruppenauswahl der betroffenen Regel oder Policy vergleichen: Nur die Gruppe verwendet die Gruppenwerte; Benutzer und seine Gruppe verwenden die Benutzerwerte. Zusätzlich die Funktionsgrenzen für Main Group und Mehrfachgruppen prüfen. Den Gruppenwert nur wiederherstellen, wenn die dokumentierte Ausnahme nicht mehr benötigt wird.

Verschachtelte AD-Gruppe greift nicht

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