Hantera användargrupper och huvudgruppen korrekt i Sophos Firewall

Användargrupper i Sophos Firewall samlar gemensamma policyer för autentiserade användare. De kan standardisera Access Time, kvoter, Traffic Shaping, Remote Access och Sign-in Restrictions. En grupp ger dock inte automatiskt åtkomst. Även den identifierade identiteten, den gällande huvudgruppen, den konkreta brandväggs- eller VPN-policyn och dess ordning avgör resultatet.

Den säkra snabbvägen är:

1. Fastställa varifrån användarna kommer och vilken uppgift gruppen ska lösa.
2. Använda en grupp av typen Normal för vanliga användare och planera IP-baserade enhetsidentiteter separat som Clientless.
3. Skapa eller importera en liten pilotgrupp med ett tydligt syfte och så få gemensamma policyer som möjligt.
4. Under Authentication > Services kontrollera avsedd Default Group eller reservgruppen på Entra-servern.
5. För Active Directory dokumentera ordningen under Authentication > Groups > Reorder och fastställa den förväntade huvudgruppen.
6. Undvika användarspecifika åsidosättningar eller dokumentera dem uttryckligen, eftersom de ersätter gruppolicyer.
7. Skapa en ny inloggning och kontrollera Group och Other group memberships under Authentication > Users.
8. Testa den berörda funktionen med en positiv och en negativ användare och kontrollera även förväntad Firewall Rule ID vid trafik.
9. Lägga till fler användare först efter en lyckad pilot och regelbundet granska gruppordning, Default Group och undantag.

⚠️ Reorder är inte en ofarlig sorteringsfunktion. För AD-användare kan en flytt ändra huvudgruppen och därmed MFA, kvoter, Access Time, Remote Access och andra policyer för många användare. Dokumentera först befintlig ordning, gruppolicyer, pilotanvändare och återställningsväg.

Förstå gruppmodellen på några minuter

En grupp är en gemensam policybärare på brandväggen. Den kan ge flera användare samma inställningar så att varje konto inte behöver hanteras separat. Den ersätter varken autentisering eller en brandväggsregel. En användare kan visas i rätt grupp och ändå sakna åtkomst om förväntad regel, VPN-policy, zon, rutt eller returväg saknas.

Fyra separata frågor hjälper vid driften:

1. Varifrån kommer identiteten? Lokalt, från Active Directory, LDAP, RADIUS, Microsoft Entra ID eller en IP-baserad Clientless-mappning.
2. Vilken grupp gäller? För AD kan det vara huvudgruppen eller, för funktioner som stöder det, ett annat gruppmedlemskap.
3. Vilken gruppolicy gäller? Access Time, Quota, Remote Access och andra fält har olika utvärderingsregler.
4. Vilken regel tillåter trafiken? Enbart gruppolicyer öppnar ingen nätverksväg.

Blanda inte Normal-, importerade och Clientless-grupper

En lokal grupp av typen Normal passar för användare som autentiserar sig via en funktion som stöds. En lokal användare får sin grupp i användarobjektet. Med en extern användarkälla skapas lokala användarposter normalt först efter den första lyckade inloggningen.

Tillfälliga gästkonton genereras via Guest user settings och ärver en medvetet vald restriktiv grupp. Skapa och hantera gästanvändare säkert i Sophos Firewall beskriver skapande, giltighet, validering i Captive Portal och avveckling.

AD-grupper hämtas med importguiden. Medlemskap hanteras i katalogen och utvärderas vid inloggning. Hela arbetsflödet för server, LDAPS och import beskrivs i Anslut Active Directory till Sophos Firewall. För allmän LDAP måste sökbasen, memberOf eller ett annat gruppattribut samt den lokala Default Group planeras separat. Anslut en LDAP-server till Sophos Firewall förklarar dessa fält.

En grupp av typen Clientless löser en annan uppgift. Den kopplar en identitet till en fast IP-adress utan att en person loggar in. Det är avsett för skrivare eller andra tydligt hänförbara system och ersätter inte användarinloggning. Konfigurera Clientless Users i Sophos Firewall beskriver ett säkert test av IP, regel och negativt resultat.

Välj Default Group och reservgrupp medvetet

Under Authentication > Services > Firewall authentication methods avgör Default group vilken grupp en extern användare får när det inte finns någon matchande lokal grupp. En bred eller historiskt framvuxen Default Group kan därför tilldela oväntade policyer. En medvetet restriktiv reservgrupp vars verkan har testats både positivt och negativt är säkrare.

Microsoft Entra ID SSO använder en egen Fallback user group i Entra-serverns konfiguration. Inställningen gäller också när servern används under Firewall authentication methods. Den allmänna Default Group och Entras reservgrupp ska därför inte behandlas som samma inställning.

Planera exempel och förutsättningar

Följande exempel skiljer tre syften åt:

• Local_Contractors: lokal pilotgrupp för ett fåtal externa medarbetare;
• SFOS_Internet_Standard: importerad AD-grupp för vanlig internetåtkomst;
• SFOS_SSLVPN: importerad AD-grupp för en SSL VPN-policy;
• auth-pilot@example.com: avsiktligt skapat testkonto;
• LAN-Users-to-WAN: loggad brandväggsregel för internettestet.

example.com är en reserverad dokumentationsdomän. Ersätt gruppnamn, användare och regelnamn med den egna namnstandarden. Ett bra gruppnamn beskriver funktionen och inte bara en avdelning. SFOS_SSLVPN förblir exempelvis begripligt även om organisationsstrukturen ändras senare.

Dokumentera före den första ändringen:

• den aktuella ordningen under Authentication > Groups;
• Default Group och, för Entra ID, reservgruppen;
• gruppolicyer och användarspecifika åsidosättningar;
• berörda autentiseringstjänster och Remote Access-policyer;
• en testad administratörsåtkomst och en oberoende hanteringsväg;
• en pilotanvändare med förväntad positiv och negativ verkan.

Skapa en lokal användargrupp

Skapa den gemensamma baslinjen under Authentication > Groups > Add:

1. Ange Local_Contractors vid Name.
2. Välj Normal vid Group type.
3. Ange Surfing quota, Access time, Network traffic och Traffic shaping endast om gruppen verkligen behöver dessa funktioner gemensamt.
4. Aktivera Remote Access-fält som SSL VPN policy eller IPsec remote access endast för den planerade åtkomsten.
5. Begränsa Sign-in restriction till de källadresser eller det avsedda intervall som verkligen behövs, om autentiseringsmodellen tillåter det.
6. Aktivera Quarantine digest och MAC binding endast medvetet.
7. Spara med Save.

Fältnamnen är produktkrav. De valda policyerna är däremot miljöberoende. En vanlig internetgrupp behöver inte automatiskt VPN, Quota eller MAC Binding. Ju färre uppgifter en grupp blandar, desto enklare är det att förstå dess verkan och återställning.

Tilldela användare utan att skapa dolda åsidosättningar

Skapa och hantera normala lokala användare beskriver användarnamn, lösenord, grupparv, autentiseringsmetod och verifiering fullständigt. De kan tilldelas en grupp under Authentication > Users. Vid gruppredigering visar Show group members medlemmarna och Add member(s) kan lägga till lämpliga lokala användare. För externt hanterade identiteter förblir katalogen källan till medlemskapet. En manuell lokal tilldelning ersätter inte en korrekt AD-, LDAP- eller Entra-konfiguration.

Användarspecifika policyer har företräde framför gruppolicyer. En åsidosättning kan vara användbar för ett dokumenterat undantag eller en pilot, men den kan få en senare gruppändring att verka verkningslös. Dokumentera därför för varje avvikande användare vilket fält som har åsidosatts, varför undantaget finns och hur man återgår till gruppvärdet.

Fullständig konfiguration och kontroll av Access Time-policyer, Surfing- och Network Traffic-kvoter samt MFA för Sophos Firewall finns kvar i respektive specialartikel. I gruppobjektet tilldelas endast den policy som redan har planerats.

Hantera importerade AD-grupper kontrollerat

AD-grupper importeras till brandväggen under Authentication > Servers > Import. I ett HA-kluster utförs importen på Primary-enheten. Importguiden tar bara med de valda grupperna. En grupp som skapas senare i AD visas därför inte automatiskt på brandväggen utan måste importeras på nytt eller avsiktligt skapas så att den stämmer.

Kapslade AD-grupper utvärderas inte. Om en undergrupp ska användas för en brandväggsregel, VPN-policy eller annan funktion måste just den undergruppen importeras. En användares primära AD-grupp importeras inte heller som ett vanligt medlemskap. För policyer passar därför uttryckliga säkerhetsgrupper bättre än AD-standardgruppen Domain Users.

Efter en ändring av AD-medlemskap, importerade grupper eller gruppordning ska en ny inloggning genereras. Först då utvärderar brandväggen grupperna på nytt och uppdaterar användarobjektet.

Förstå huvudgruppen och gruppordningen

För en AD-användare visar Authentication > Users två olika nivåer:

• Group: den första matchande gruppen i brandväggens lista och därmed huvudgruppen;
• Other group memberships: användarens övriga importerade grupper.

Ändra ordningen under Authentication > Groups > Reorder. Om auth-pilot@example.com tillhör SFOS_Internet_Standard och SFOS_SSLVPN blir den matchande grupp som ligger högre i listan huvudgrupp vid nästa inloggning.

Ändra inte denna ordning spontant för ett enskilt fel. Kontrollera först vilken konkret funktion som berörs och om den överhuvudtaget stöder andra grupper. Annars kan en flytt reparera ett VPN-fall och samtidigt ändra MFA, Quota eller Access Time för andra användare.

Flera grupper utvärderas olika för varje funktion

Följande gräns gäller uttryckligen för gruppmedlemskap i Active Directory. Överför den inte utan kontroll till LDAP, RADIUS eller Microsoft Entra ID.

Flera AD-grupper kan beaktas för:

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

För Remote access SSL VPN kombineras behörigheter från matchande användar- och gruppolicyer. Så snart en matchande Full Tunnel-policy ingår blir resultatet en Full Tunnel. Kombinationen ska därför verifieras med ett verkligt klienttest och inte bara genom jämförelse av gruppnamn.

Endast huvudgruppen eller en uttrycklig användartilldelning beaktas för:

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

För funktioner som stöder flera grupper är ordningen på den berörda regeln eller policyn fortfarande avgörande. En brandväggsregel kan till exempel matcha via SFOS_SSLVPN även om SFOS_Internet_Standard är huvudgruppen. Det betyder inte att MFA eller Quota också använder SFOS_SSLVPN.

Testa gruppens verkan med en riktig användare

En sparad grupp och en synlig användare är ännu inget bevis på framgång. Använd samma procedur för piloten som senare ska gälla i produktion:

1. Avsluta pilotanvändarens befintliga session och generera en ny inloggning.
2. Dokumentera status, Group, Other group memberships och möjliga användaråsidosättningar under Authentication > Users.
3. Kontrollera användarnamn, käll-IP och Client Type under Current activities > Live users.
4. Generera det förväntade flödet för en användarbaserad brandväggsregel och kontrollera Firewall Rule ID i Log Viewer.
5. Testa den berörda tjänsten separat för Access Time, Quota, MFA eller Remote Access.
6. Kör samma flöde som negativt test med en användare som inte tillhör pilotgruppen.
7. Dokumentera resultat, tidpunkt, gruppordning och gällande policy.

Testa brandväggsregler med Log Viewer, Policy Test och Packet Capture visar hela trafiktestet. Om det redan är oklart om val av tjänst, identitet, huvudgrupp eller den senare regeln misslyckas leder Felsök autentiseringsfel i Sophos Firewall systematiskt genom hela kontrollkedjan.

Ändringar, återställning och drift

Behandla gruppändringar som policyändringar:

1. Dokumentera utgångsläget och berörda användare.
2. Ändra endast en grupp, policy eller position åt gången.
3. Autentisera pilotanvändaren på nytt.
4. Kontrollera huvudgruppen, övriga medlemskap och den konkreta funktionen igen.
5. Återställ föregående gruppordning och policytilldelning vid oväntad verkan.
6. Generera ännu en ny inloggning och upprepa positivt och negativt test.

Rensa en AD-grupp först i katalogen och därefter på brandväggen. En användare som fortfarande finns i AD kan skapas lokalt igen vid en senare inloggning. Purge AD users är därför ingen synkroniseringsknapp och inget normalt steg efter en gruppändring.

Användare och grupper delar det interna ID-intervallet upp till 65535. Enbart ett stort antal synliga objekt bevisar inget gränsproblem. Om en användare visar en User ID över 65535 och inte blir Live User ska den separata proceduren för Sophos Firewalls användar-ID-gräns följas.

Avgränsa fel efter symptom

Ny AD-grupp visas inte på brandväggen

Nya grupper synkroniseras inte automatiskt. Kör importguiden igen och gör detta på Primary i HA. Kontrollera sedan under Authentication > Groups att exakt den grupp som behövs finns. Skapa inte en bred ersättningsgrupp bara för att få en inloggning att fungera.

Användaren har fel huvudgrupp

Dokumentera först AD-medlemskap, importerade grupper och aktuell ordning. Kontrollera sedan om den förväntade gruppen överhuvudtaget finns på brandväggen. Utvärdera en planerad ändring under Reorder först efter en ny inloggning och testa den med flera representativa användare.

Brandväggsregeln matchar, men MFA eller Quota gäller inte

Brandväggsregler stöder andra AD-grupper, medan MFA och kvoter inte gör det. Kontrollera i användarobjektet vilken grupp som står under Group som huvudgrupp. Kontrollera därefter användarspecifika åsidosättningar och den faktiska policytilldelningen. Att regeln matchar bevisar inte att MFA eller Quota utvärderar grupper på samma sätt.

Gruppändringen fungerar fel endast för en användare

Jämför de användarspecifika policyfälten under Authentication > Users. En individuell åsidosättning har företräde framför gruppolicyn. Ändra inte värdet utan kontroll, utan jämför först med det dokumenterade undantaget och önskat arvsstatus.

Användaren hamnar i Default Group

För AD eller en annan klassisk autentiseringsserver saknas troligen en matchande lokal grupp eller gruppmappning. Kontrollera import, gruppnamn, sökbas och returnerade attribut. För Microsoft Entra ID SSO ska i stället Entra-serverns Fallback user group kontrolleras. Bredda inte Default Group generellt för att dölja det verkliga mappningsfelet.

Kapslad AD-grupp tillämpas inte

Importera den undergrupp som behövs och lägg till användaren direkt i den. Generera därefter en ny inloggning och kontrollera Group och Other group memberships. Det räcker inte att bara importera den överordnade gruppen.

Driftchecklista

• Gruppens syfte och ansvarig användarkälla är dokumenterade.
• Lokala, importerade och Clientless-grupper blandas inte.
• Default Group eller Entra-reservgruppen är medvetet och restriktivt vald.
• Gruppordning och förväntade huvudgrupper är dokumenterade.
• Användaråsidosättningar är motiverade eller borttagna.
• Den konkreta funktionen stöder det använda gruppmedlemskapet.
• Pilotanvändaren har autentiserats på nytt och kontrollerats under Authentication > Users.
• Positiva och negativa test bekräftar förväntad policy eller Firewall Rule ID.
• Remote Access, MFA, Access Time och kvoter har validerats separat när de används.
• Återställningsvägen för gruppordning och policytilldelning är dokumenterad.

Vanliga frågor