Sophos Firewall-gebruikersgroepen en de hoofdgroep correct beheren
Gebruikersgroepen op Sophos Firewall bundelen gemeenschappelijk beleid voor geauthenticeerde gebruikers. Ze kunnen Access Time, quota, Traffic Shaping, Remote Access en Sign-in Restrictions uniform maken. Een groep verleent echter niet automatisch toegang: ook de herkende identiteit, de effectieve hoofdgroep, het concrete firewall- of VPN-beleid en de volgorde daarvan zijn bepalend.
De veilige korte werkwijze is:
- Bepalen uit welke bron de gebruikers komen en welk probleem de groep moet oplossen.
- Voor gewone gebruikers een groep van het type Normal gebruiken; IP-gebaseerde apparaatidentiteiten afzonderlijk als Clientless plannen.
- Een kleine pilotgroep met een duidelijke functie en zo weinig mogelijk gemeenschappelijk beleid maken of importeren.
- Onder Authentication > Services de beoogde Default Group of de fallbackgroep op de Entra-server controleren.
- Voor Active Directory de volgorde onder Authentication > Groups > Reorder documenteren en de verwachte hoofdgroep bepalen.
- Gebruikersoverrides vermijden of expliciet documenteren, omdat ze groepsbeleid overschrijven.
- Een nieuwe aanmelding genereren en onder Authentication > Users de velden Group en Other group memberships controleren.
- De betrokken functie met een positieve en een negatieve gebruiker testen; bij verkeer ook de verwachte Firewall Rule ID controleren.
- Pas na een geslaagde pilot meer gebruikers toevoegen en groepsvolgorde, Default Group en uitzonderingen regelmatig controleren.
⚠️ Reorder is geen onschuldige sorteerfunctie. Bij AD-gebruikers kan het verplaatsen van een groep de hoofdgroep wijzigen en daarmee MFA, quota, Access Time, Remote Access en ander beleid voor veel gebruikers veranderen. Documenteer vooraf de bestaande volgorde, het groepsbeleid, de pilotgebruikers en de terugweg.
Het groepsmodel in enkele minuten begrijpen
Een groep is op de firewall een gemeenschappelijke drager van beleid. Dezelfde instellingen kunnen aan meerdere gebruikers worden toegekend, zodat niet elk account afzonderlijk hoeft te worden beheerd. Een groep vervangt noch de authenticatie, noch een firewallregel. Een gebruiker kan in de juiste groep verschijnen en toch geen toegang krijgen als de verwachte regel, het VPN-beleid, de zone, route of retourroute ontbreekt.
Vier afzonderlijke vragen helpen bij het beheer:
- Waar komt de identiteit vandaan? Lokaal, Active Directory, LDAP, RADIUS, Microsoft Entra ID of een IP-gebaseerde Clientless-toewijzing.
- Welke groep is effectief? Bij AD kan dit de hoofdgroep zijn of, voor ondersteunde functies, een ander groepslidmaatschap.
- Welk groepsbeleid geldt? Access Time, Quota, Remote Access en andere velden hebben verschillende evaluatieregels.
- Welke regel staat het verkeer toe? Alleen groepsbeleid opent geen netwerkpad.
Normal, geïmporteerde en Clientless-groepen niet mengen
Een lokale groep van het type Normal past bij gebruikers die zich via een ondersteunde dienst authenticeren. Een lokale gebruiker krijgt de groep in het gebruikersobject. Bij een externe gebruikersbron worden lokale gebruikersrecords normaal gesproken pas na de eerste geslaagde aanmelding gemaakt.
Tijdelijke gastaccounts worden via Guest user settings gegenereerd en erven een bewust gekozen beperkte groep. Gastgebruikers op Sophos Firewall veilig aanmaken en beheren behandelt het aanmaken, de geldigheid, de validatie in Captive Portal en de offboarding.
AD-groepen worden via de importwizard overgenomen. Lidmaatschappen worden in de directory beheerd en bij de aanmelding geëvalueerd. De volledige server-, LDAPS- en importprocedure staat in Active Directory met Sophos Firewall verbinden. Voor generieke LDAP moeten de zoekbasis, memberOf of een ander groepsattribuut en de lokale Default Group afzonderlijk worden gepland; Een LDAP-server met Sophos Firewall verbinden licht deze velden toe.
Een groep van het type Clientless heeft een andere functie. Ze koppelt een identiteit aan een vast IP-adres zonder dat een persoon zich aanmeldt. Dit is bedoeld voor printers of andere duidelijk toewijsbare systemen en vervangt geen gebruikersaanmelding. Clientless Users op Sophos Firewall instellen beschrijft de veilige IP-, regel- en negatieve test.
De Default Group en fallbackgroep bewust kiezen
Onder Authentication > Services > Firewall authentication methods bepaalt Default group welke groep een externe gebruiker krijgt als er geen overeenkomende lokale groep bestaat. Een brede of historisch gegroeide Default Group kan daardoor onverwacht beleid toekennen. Een bewust restrictieve fallbackgroep waarvan de werking positief en negatief is getest, is veiliger.
Microsoft Entra ID SSO gebruikt een eigen Fallback user group in de configuratie van de Entra-server. Deze instelling geldt ook wanneer de server onder Firewall authentication methods wordt gebruikt. De algemene Default Group en de Entra-fallbackgroep worden daarom niet als dezelfde instelling behandeld.
Voorbeeld en vereisten plannen
Het volgende voorbeeld scheidt drie doelen:
Local_Contractors: lokale pilotgroep voor enkele externe medewerkers;SFOS_Internet_Standard: geïmporteerde AD-groep voor gewone internettoegang;SFOS_SSLVPN: geïmporteerde AD-groep voor een SSL VPN-beleid;auth-pilot@example.com: bewust gemaakt testaccount;LAN-Users-to-WAN: gelogde firewallregel voor de internettest.
example.com is een gereserveerd documentatiedomein. Vervang de groepsnamen, gebruiker en regelnaam door de eigen naamgevingsconventie. Een goede groepsnaam beschrijft de functie en niet alleen een afdeling. SFOS_SSLVPN blijft bijvoorbeeld duidelijk als de organisatiestructuur later verandert.
Leg vóór de eerste wijziging vast:
- de huidige volgorde onder Authentication > Groups;
- de Default Group en, bij Entra ID, de fallbackgroep;
- groepsbeleid en gebruikersspecifieke overrides;
- betrokken authenticatiediensten en Remote Access-beleid;
- een geteste beheerderstoegang en een onafhankelijk beheerpad;
- een pilotgebruiker met de verwachte positieve en negatieve werking.
Een lokale gebruikersgroep maken
Maak onder Authentication > Groups > Add de gemeenschappelijke basis:
- Voer bij Name
Local_Contractorsin. - Kies bij Group type Normal.
- Stel Surfing quota, Access time, Network traffic en Traffic shaping alleen in wanneer de groep deze functies werkelijk gezamenlijk nodig heeft.
- Activeer Remote Access-velden zoals SSL VPN policy of IPsec remote access alleen voor de geplande toegang.
- Beperk Sign-in restriction tot de werkelijk benodigde bronadressen of het bedoelde bereik, als het authenticatiemodel dit toestaat.
- Schakel Quarantine digest en MAC binding alleen bewust in.
- Sla op met Save.
De veldnamen zijn productvoorschriften. Het geselecteerde beleid is daarentegen afhankelijk van de omgeving. Een normale internetgroep heeft niet automatisch VPN, Quota of MAC Binding nodig. Hoe minder taken een groep combineert, hoe eenvoudiger de werking en terugdraaiing te begrijpen zijn.
Gebruikers toewijzen zonder verborgen overrides te maken
Normale lokale gebruikers maken en beheren beschrijft gebruikersnaam, wachtwoord, groepsovererving, authenticatiemethode en validatie volledig. Ze kunnen onder Authentication > Users aan een groep worden toegewezen. In de groepsbewerking toont Show group members de leden en kan Add member(s) geschikte lokale gebruikers toevoegen. Voor extern beheerde identiteiten blijft de directory de bron van het lidmaatschap. Een handmatige lokale toewijzing vervangt geen correcte AD-, LDAP- of Entra-configuratie.
Gebruikersspecifiek beleid heeft voorrang op groepsbeleid. Een override kan nuttig zijn voor een gedocumenteerde uitzondering of pilot, maar kan een latere groepswijziging schijnbaar zonder effect maken. Leg daarom voor elke afwijkende gebruiker vast welk veld is overschreven, waarom de uitzondering bestaat en hoe naar de groepswaarde wordt teruggekeerd.
De volledige aanmaak en validatie van Access Time-beleid, Surfing- en Network Traffic-quota en MFA voor Sophos Firewall blijft in de betreffende specialistische artikelen. In het groepsobject wordt alleen het reeds geplande beleid toegewezen.
Geïmporteerde AD-groepen gecontroleerd beheren
AD-groepen worden onder Authentication > Servers > Import naar de firewall geïmporteerd. In een HA-cluster gebeurt de import op het Primary-apparaat. De importwizard neemt alleen de geselecteerde groepen over. Een groep die later in AD wordt aangemaakt, verschijnt daarom niet automatisch op de firewall en moet opnieuw worden geïmporteerd of bewust passend worden gemaakt.
Geneste AD-groepen worden niet geëvalueerd. Als een subgroep voor een firewallregel, VPN-beleid of andere functie moet worden gebruikt, moet precies die subgroep worden geïmporteerd. De primaire AD-groep van een gebruiker wordt evenmin als normaal lidmaatschap overgenomen. Expliciete beveiligingsgroepen zijn daarom beter geschikt voor beleid dan de standaard AD-groep Domain Users.
Genereer na een wijziging van AD-lidmaatschappen, geïmporteerde groepen of groepsvolgorde een nieuwe aanmelding. Pas dan evalueert de firewall de groepen opnieuw en werkt hij het gebruikersobject bij.
Hoofdgroep en groepsvolgorde begrijpen
Bij een AD-gebruiker toont Authentication > Users twee verschillende niveaus:
- Group: de eerste overeenkomende groep in de firewalllijst en daarmee de hoofdgroep;
- Other group memberships: de andere geïmporteerde groepen van de gebruiker.
Wijzig de volgorde onder Authentication > Groups > Reorder. Als auth-pilot@example.com lid is van SFOS_Internet_Standard en SFOS_SSLVPN, wordt bij de volgende aanmelding de overeenkomende groep die hoger in de lijst staat de hoofdgroep.
Verander deze volgorde niet spontaan voor één incident. Controleer eerst welke concrete functie is betrokken en of deze andere groepen überhaupt ondersteunt. Anders kan een verplaatsing een VPN-geval herstellen en tegelijk MFA, Quota of Access Time voor andere gebruikers wijzigen.
Meerdere groepen worden per functie anders geëvalueerd
De volgende grens geldt uitdrukkelijk voor groepslidmaatschappen in Active Directory. Pas deze niet zonder controle toe op LDAP, RADIUS of Microsoft Entra ID.
Meerdere AD-groepen kunnen worden meegenomen bij:
- Firewall rules en SSL/TLS inspection rules;
- SD-WAN routes;
- Web policies;
- IPS en Application control policies;
- Policy test;
- Remote access SSL VPN;
- Clientless SSL VPN.
Bij Remote access SSL VPN worden rechten uit overeenkomend gebruikers- en groepsbeleid gecombineerd. Zodra een overeenkomend Full Tunnel-beleid is betrokken, ontstaat een Full Tunnel. Deze combinatie hoort daarom in een echte clienttest en niet alleen in een vergelijking van groepsnamen.
Alleen de hoofdgroep of een expliciete gebruikerstoewijzing wordt meegenomen bij:
- WAF rules, My policy overrides en Hotspots;
- Remote access IPsec VPN, L2TP en PPTP;
- Surfing quota, Access time, Network traffic en Traffic shaping;
- Quarantine digest, MAC binding en Sign-in restriction;
- MFA.
Bij functies met ondersteuning voor meerdere groepen blijft de volgorde van de betreffende regel of het beleid bepalend. Een firewallregel kan bijvoorbeeld via SFOS_SSLVPN matchen, hoewel SFOS_Internet_Standard de hoofdgroep is. Dat betekent niet dat MFA of Quota eveneens SFOS_SSLVPN gebruikt.
De groepswerking met een echte gebruiker testen
Een opgeslagen groep en een zichtbare gebruiker zijn nog geen bewijs van succes. Gebruik voor de pilot dezelfde werkwijze die later in productie geldt:
- Beëindig de bestaande sessie van de pilotgebruiker en genereer een nieuwe aanmelding.
- Documenteer onder Authentication > Users de status, Group, Other group memberships en mogelijke gebruikersoverrides.
- Controleer onder Current activities > Live users de gebruikersnaam, bron-IP en Client Type.
- Genereer bij een gebruikersfirewallregel de verwachte flow en controleer in Log Viewer de Firewall Rule ID.
- Test bij Access Time, Quota, MFA of Remote Access de betrokken dienst afzonderlijk.
- Voer dezelfde flow als negatieve test uit met een gebruiker zonder de pilotgroep.
- Leg resultaat, tijdstip, groepsvolgorde en effectief beleid vast.
Firewallregels met Log Viewer, Policy Test en Packet Capture testen toont de volledige verkeerstest. Als al onduidelijk is of de dienstselectie, identiteit, hoofdgroep of latere regel faalt, leidt Sophos Firewall-authenticatiefouten systematisch oplossen door de volledige controleketen.
Wijzigingen, terugdraaiing en beheer
Behandel groepswijzigingen als beleidswijzigingen:
- Documenteer de uitgangssituatie en betrokken gebruikers.
- Wijzig slechts één groep, beleid of positie tegelijk.
- Authenticeer de pilotgebruiker opnieuw.
- Controleer de hoofdgroep, andere lidmaatschappen en de concrete functie opnieuw.
- Herstel bij onverwachte werking de vorige groepsvolgorde en beleidstoewijzing.
- Genereer opnieuw een verse aanmelding en herhaal de positieve en negatieve test.
Ruim een AD-groep eerst in de directory en daarna op de firewall op. Een gebruiker die nog in AD bestaat, kan bij een latere aanmelding opnieuw lokaal worden gemaakt. Purge AD users is daarom geen synchronisatieknop en geen normale stap na een groepswijziging.
Gebruikers en groepen delen het interne ID-bereik tot 65535. Een groot zichtbaar aantal objecten bewijst op zichzelf geen limietprobleem. Als een gebruiker een User ID boven 65535 toont en geen Live User wordt, volg dan de aparte procedure voor de Sophos Firewall User-ID-limiet.
Fouten per symptoom afbakenen
Nieuwe AD-groep verschijnt niet op de firewall
Nieuwe groepen worden niet automatisch gesynchroniseerd. Voer de importwizard opnieuw uit en doe dit bij HA op de Primary. Controleer daarna onder Authentication > Groups of precies de benodigde groep aanwezig is. Maak geen brede vervangende groep alleen om een aanmelding te laten werken.
Gebruiker heeft de verkeerde hoofdgroep
Documenteer eerst de AD-lidmaatschappen, geïmporteerde groepen en huidige volgorde. Controleer daarna of de verwachte groep überhaupt op de firewall aanwezig is. Beoordeel een geplande wijziging onder Reorder pas na een nieuwe aanmelding en test deze met meerdere representatieve gebruikers.
Firewallregel matcht, maar MFA of Quota werkt niet
Firewallregels ondersteunen andere AD-groepen, MFA en quota niet. Controleer in het gebruikersobject welke groep onder Group als hoofdgroep staat. Controleer daarna gebruikersspecifieke overrides en de werkelijke beleidstoewijzing. De werking van de regel bewijst niet dat MFA of Quota groepen op dezelfde manier evalueert.
Groepswijziging werkt alleen voor één gebruiker verkeerd
Vergelijk onder Authentication > Users de gebruikersspecifieke beleidsvelden. Een individuele override heeft voorrang op het groepsbeleid. Wijzig de waarde niet blind, maar vergelijk deze eerst met de gedocumenteerde uitzondering en de gewenste overervingsstatus.
Gebruiker komt in de Default Group terecht
Bij AD of een andere klassieke authenticatieserver ontbreekt waarschijnlijk een overeenkomende lokale groep of groepstoewijzing. Controleer import, groepsnaam, zoekbasis en teruggegeven attributen. Controleer bij Microsoft Entra ID SSO in plaats daarvan de Fallback user group van de Entra-server. Maak de Default Group niet algemeen breder om de werkelijke mappingfout te verbergen.
Geneste AD-groep werkt niet
Importeer de benodigde subgroep zelf en voeg de gebruiker er rechtstreeks aan toe. Genereer daarna een nieuwe aanmelding en controleer Group en Other group memberships. Alleen de bovenliggende groep importeren is niet voldoende.
Beheerchecklist
- Het groepsdoel en de verantwoordelijke gebruikersbron zijn gedocumenteerd.
- Lokale, geïmporteerde en Clientless-groepen worden niet gemengd.
- De Default Group of Entra-fallbackgroep is bewust en restrictief gekozen.
- Groepsvolgorde en verwachte hoofdgroepen zijn gedocumenteerd.
- Gebruikersoverrides zijn gemotiveerd of verwijderd.
- De concrete functie ondersteunt het gebruikte groepslidmaatschap.
- De pilotgebruiker is opnieuw geauthenticeerd en onder Authentication > Users gecontroleerd.
- Positieve en negatieve tests bevestigen het verwachte beleid of de Firewall Rule ID.
- Remote Access, MFA, Access Time en quota zijn afzonderlijk gevalideerd wanneer ze worden gebruikt.
- De terugweg voor groepsvolgorde en beleidstoewijzing is vastgelegd.