Hantera användargrupper och Main Group korrekt i Sophos Firewall

Användargrupper samlar gemensamma policyer för autentiserade användare. Innan du ändrar en grupp behöver du klargöra två saker: varifrån identiteten kommer och om den berörda funktionen endast utvärderar Main Group eller även andra AD-grupper. Först därefter kan du avgöra om gruppordningen, en policytilldelning eller själva brandväggs- eller VPN-regeln behöver ändras.

Snabbguide:

Ange användarkälla och syftet med gruppen.
Skapa en lokal grupp eller importera den behövda kataloggruppen selektivt.
Kontrollera den effektiva Default group under Authentication > Services eller Fallback user group på Entra-servern.
För AD dokumenterar du ordningen under Authentication > Groups > Reorder och förväntad Main Group.
Logga ut pilotanvändaren och logga in igen. Kontrollera därefter fälten Group och Other group memberships under Authentication > Users > användare > Policies.
Testa den berörda funktionen med en behörig och en obehörig användare. Vid nätverkstrafik kontrollerar du dessutom förväntat Firewall Rule ID.

⚠️ Reorder är inte en harmlös sorteringsfunktion. För AD-användare kan en förflyttning ändra Main Group och därmed MFA, kvoter, åtkomsttider, fjärråtkomst och andra policyer för många användare. Dokumentera ordningen, gruppolicyerna och återställningsplanen i förväg.

Förstå gruppmodellen

En grupp har gemensamma policyer och inställningar. Den ersätter varken autentisering eller en brandväggsregel. En användare kan därför tillhöra rätt grupp och ändå inte få åtkomst om den förväntade regeln, VPN-policyn, zonen, rutten eller återvägen saknas.

Ställ fyra separata frågor vid felsökning:

Kommer identiteten från den lokala databasen, Active Directory, LDAP, RADIUS, Microsoft Entra ID eller från en klientlös tilldelning?
Vilken grupp är Main Group?
Stöder den berörda funktionen ytterligare AD-gruppmedlemskap?
Vilken regel eller policy bearbetar den faktiska datatrafiken?

Skilj mellan lokala, importerade och klientlösa grupper

Normal och Clientless är grupptyper. Importerad beskriver däremot ursprunget för en grupp och är ingen egen Group type.

En lokal grupp av typen Normal är lämplig för användare som loggar in. Lokala användare tilldelas sin grupp i användarobjektet. För en extern användarkälla skapas de lokala användarposterna vanligtvis först vid den första lyckade inloggningen.

Gästanvändare har ett separat, tidsbegränsat flöde. Skapa och hantera gästanvändare säkert på Sophos Firewall förklarar standardgrupp, giltighet, Captive Portal och rensning.

AD- och Entra-grupper importeras via guiden på respektive server. Katalogen förblir källan för medlemskap. För AD dokumenterar Sophos även alternativet att skapa gruppen manuellt både i AD och på brandväggen. Även då måste grupptilldelningen och behörigheterna kontrolleras efter en ny inloggning. Den fullständiga AD-, LDAPS- och importprocessen beskrivs i Anslut Active Directory till Sophos Firewall.

För generiskt LDAP måste Base DN, Authentication attribute, Group name attribute, serverordning och Default group stämma överens. Sophos rekommenderar memberOf som gruppattribut. Anslut LDAP-server till Sophos Firewall vägleder dig genom konfigurationen.

En grupp av typen Clientless samlar Clientless-användare och deras gemensamma inställningar. Dessa användare loggar inte in via en klient; brandväggen styr deras åtkomst baserat på IP-adressen. Den fasta IP-adressen lagras på den enskilda Clientless-användaren, inte i gruppobjektet. Ställ in Clientless-användare på Sophos Firewall beskriver IP-tilldelning, regel och negativt test.

Default Group och Entra-fallback är inte samma sak

Under Authentication > Services > Firewall authentication methods fastställer Default group vilken grupp en användare får från en extern autentiseringsserver om ingen av användarens kataloggrupper finns som lokal grupp. Fabriksinställningen är Open group. Kontrollera det aktuella värdet i stället för att förutsätta standardvärdet. För drift rekommenderar Avanet en separat, restriktiv fallback-grupp utan oavsiktliga VPN-, kvot- eller inloggningsbehörigheter.

Motstridiga AD-beskrivningar av den första inloggningen: AD-installationsguiden beskriver att användaren automatiskt läggs till i Default group vid den första inloggningen. AD-FAQ:n anger däremot att Default group endast används när ingen av användarens AD-grupper finns på brandväggen. AD-serveröversikten anger uttryckligen Open group för användare som endast tillhör en OU och ingen kataloggrupp, medan gruppöversikten och FAQ:n hänvisar till den konfigurerade Default group. Dessa beskrivningar är motstridiga och ger inget stöd för att det finns en särskild, universellt gällande grupp för den första inloggningen eller att en sådan grupp har företräde. Den konfigurerade Default group måste skiljas från fabriksinställningen Open group.

Kontrollera den faktiska Default group och dess ärvda behörigheter före utrullningen. Kontrollera den första inloggningen separat med två pilotkonton avsedda för detta: ett med en AD-grupp som redan har importerats till brandväggen och ett vars AD-grupper inte har importerats dit. Kontrollera för båda kontona fälten Group och Other group memberships under Policies, samt både tillåten åtkomst och åtkomst som avsiktligt inte ska vara tillåten. Stoppa utrullningen och utred orsaken om grupptilldelningen är oväntad. Radera inte produktionsgrupper och utöka inte fallback-behörigheterna för detta ändamål. Detta är begränsade kontrollsteg inför införandet, inte en rapport om ett genomfört test på en brandväggsenhet.

Microsoft Entra ID SSO använder den separata Fallback user group i Entra-serverkonfigurationen. Den gäller även om Entra-servern är vald under Firewall authentication methods. Den allmänna standardgruppen gäller inte i det här fallet.

Ordningen på autentiseringsservrarna är också relevant. Sophos Firewall tillåter högst 20 servrar per autentiseringsmetod och vidarebefordrar förfrågningar i den visade ordningen. Ändra inte denna ordning för att kringgå ett gruppproblem innan du har kontrollerat den berörda servern och dess mappning.

Planera exempel och utgångsläge

Exemplet använder tre grupper med separata funktioner:

Local_Contractors: lokal pilotgrupp för några externa medarbetare;
SFOS_Internet_Standard: importerad AD-grupp för normal internetåtkomst;
SFOS_SSLVPN: importerad AD-grupp för en SSL-VPN-policy.

auth-pilot@example.com används som testkonto och den loggade regeln LAN-Users-to-WAN som trafiktest. example.com är en reserverad dokumentationsdomän. Byt ut namn och användare enligt din egen namnstandard. Ett funktionsrelaterat namn som SFOS_SSLVPN förblir begripligt även efter en omorganisation.

Dokumentera före ändringen:

aktuell gruppordning;
Default group och eventuellt Fallback user group;
gruppolicyer och användarspecifika åsidosättningar;
berörda autentiseringstjänster och VPN-policyer;
ett testat administratörskonto och en andra administrationsväg, om Main Group, MFA eller inloggningsbegränsningar påverkas;
pilotanvändare, förväntad Main Group samt positivt och negativt test.

Skapa lokal användargrupp

Gå till Authentication > Groups och klicka på Add:

Ange gruppnamnet Local_Contractors.
Välj Normal under Group type.
Välj endast de gemensamma policyer som behövs:
- Surfing quota begränsar användningstiden efter tidsperiod och cykel.
- Access time tillåter eller nekar återkommande tidsperioder.
- Network traffic begränsar överförd datamängd.
- Traffic shaping tilldelar en QoS-policy med prioritet och bandbreddsbegränsningar.
Ange SSL VPN policy, Clientless SSL VPN policy, L2TP, PPTP och IPsec remote access endast för den åtkomst som faktiskt planeras. PPTP är inte lämpligt för nya lösningar. L2TP är fortfarande ett begränsat kompatibilitetsalternativ, vilket beskrivs i L2TP-fjärråtkomst på Sophos Firewall.
Begränsa om möjligt Sign-in restriction med Selected nodes eller Node range till de nödvändiga källorna. Selected nodes tillåter endast de angivna IP-adresserna; Node range tillåter adresser inom det angivna IP-intervallet. Any node tillåter inloggning från vilket nätverk som helst.
Slå på Quarantine digest och MAC binding endast om gruppen behöver dessa funktioner. Quarantine digest skickar en sammanfattning av de e-postmeddelanden som hålls i karantän till användarens brevlåda. MAC binding begränsar inloggningen till de avsedda enheterna.
Klicka på Save för att spara.

Fältnamnen och deras effekt bestäms av produkten; valet beror på miljön. En internetgrupp behöver inte automatiskt VPN, kvot eller MAC-bindning. Grupper med tydligt avgränsade funktioner är enklare att testa och återställa.

Tilldela lokala användare och identifiera åsidosättningar

Skapa och hantera vanliga lokala användare beskriver användarnamn, lösenord, grupparv och acceptanstestning i detalj. Lokala användare kan tilldelas en grupp under Authentication > Users. I gruppredigeringen visar Show group members medlemmarna; via Add member(s) kan du lägga till lämpliga lokala användare. För externt hanterade identiteter förblir däremot katalogen källan för medlemskapet.

Vilka användar- eller gruppinställningar en regel eller policy använder beror på det faktiska valet av användare och grupper. Kontrollera under Policies för användaren om ett eget värde har valts i stället för gruppinställningen. Om gruppolicyn ska gälla igen återställer du det tidigare dokumenterade arvsläget och testar endast den berörda funktionen på nytt. En åsidosättning är fortfarande motiverad om ett välgrundat undantag uttryckligen har dokumenterats.

Sophos skiljer mellan två fall för valet i den berörda regeln eller policyn:

Endast gruppen vald: Brandväggen använder gruppens inställningar, inte automatiskt användarens åsidosättning.
Användaren och dennes grupp valda: Brandväggen använder användarens inställningar.

Ett begränsat pilottest gör skillnaden synlig: dokumentera för auth-pilot@example.com i Local_Contractors ett gruppvärde A och ett avvikande användarvärde B för samma inställning som stöds. A och B är platshållare för två medvetet planerade testvärden i din miljö. Kontrollera först det faktiska valet i en isolerad testregel eller testpolicy med val av användare och grupper: endast Local_Contractors innebär A; auth-pilot@example.com tillsammans med Local_Contractors innebär B. Testa den berörda tjänsten eller datavägen med en ny inloggning i varje fall; kontrollera även Firewall Rule ID för brandväggstrafik. Återställ därefter det tidigare dokumenterade valet och båda inställningarna och testa igen. Utöka inte en produktionsregel och ändra inte gruppordningen för detta test.

Detta val är inte ordningen för Main Group. Begränsningarna för stöd för flera grupper och kombinationen av matchande SSL-VPN-policyer som beskrivs nedan gäller fortfarande; detta innebär inte att användarpolicyer alltid har företräde för varje tjänst.

Hur du skapar åtkomsttidspolicyer, surf- och nätverkstrafikkvoter samt MFA för Sophos Firewall förklaras i sin helhet i respektive specialartikel. I gruppobjektet tilldelas endast en redan planerad policy.

Förstå gruppfälten i XML API

Den som hanterar grupper automatiserat hittar i XML-modellen UserGroup som gruppobjekt, GroupDetail som konfigurationsdel och GroupMembers med GroupName och UserName som medlemskapsdata. Detta är ingen import av AD-medlemskap; för kataloganvändare förblir katalogen styrande. Autentisering, explicita operationsomslag och utvärdering av XML-svaret behandlas i Använd XML API säkert.

Följande utdrag visar endast den dokumenterade strukturen för de befintliga pilotexemplen. Det är inte en fullständig Add/Edit-begäran eller en begäran som har testats på en brandväggsenhet; framför allt saknas operationsomslaget och ytterligare nödvändiga konfigurationsfält. Att fält har utelämnats innebär inte att en ändring bevarar befintliga värden.

<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>

Gruppnamnet och användaren ska ersättas med det exakt planerade lokala målet. 192.0.2.10 är en IPv4-dokumentationsadress och måste ersättas med en tillåten inloggningskälla som faktiskt behövs. XML-fältnamnen förblir oförändrade. Mappningen till UI-fälten är:

SurfingQuotaPolicy: Surfing quota; AccessTimePolicy: Access time.
DataTransferPolicy: Network traffic; QoSPolicy: Traffic shaping.
SSLVPNPolicy: SSL VPN policy; ClientlessPolicy: Clientless SSL VPN policy, inte grupptypen Clientless.
SophosConnectClient: IPsec remote access via Sophos Connect Client.

För LoginRestriction skiljer referensexemplet mellan AnyNode, SelectedNodes och NodeRange. AnyNode motsvarar Any node och begränsar inte inloggningskällan; det är inget standardval för felsökning. SelectedNodes använder NodeList med de enskilda IPAddress-posterna. NodeRange använder i stället FromIP och ToIP, exempelvis 192.0.2.10 till 192.0.2.20. Även båda intervallgränserna är dokumentationsvärden och ska ersättas med det minsta nödvändiga IPv4-intervallet, utan att befintliga begränsningar vidgas. Även om tabellen markerar FromIP och ToIP som obligatoriska fält begränsar beskrivningen dem till Node range; detta innebär inget generellt krav för de andra varianterna.

API-referensen anger Enable eller Disable för vart och ett av fälten QuarantineDigest, MACBinding, L2TP, PPTP och SophosConnectClient och dokumenterar Disable som standardvärde. Detta är referensinformation, inte ett bevis på gruppens aktuella sparade tillstånd. När QuarantineDigest är aktivt skickas karantänsammanfattningen dagligen via e-post. PPTP är fortsatt uteslutet för nya lösningar; L2TP är fortfarande endast det begränsade kompatibilitetsalternativ som beskrivs ovan.

Referensexemplets begränsningar: Det skiljer inställningar för Normal-grupper från en Clientless-gren som visar QoSPolicy. För GroupType är det dock motsägelsefullt: Mallen innehåller Normal/Clienless, beskrivningen anger Normal eller Clientless och betecknar datatypen som INTEGER. Dessutom innehåller mallen kolonplatshållare i stället för fullständigt XML-innehåll. Av detta får man varken härleda en korrigerad Clientless-kodning eller en numerisk mappning. För en skrivoperation ska ett avläst eller exporterat värde från den installerade versionen användas, vars mappning redan är fastställd; använd annars det säkra UI-flödet. Alternativ med snedstreck, som Enable/Disable, är inte enskilda värden som kan användas direkt.

Mallen visar dessutom After med ett nästlat Name som positionsangivelse. Den andra tabellraden för Name nämner moveto, men belägger ingen operation som kan utföras fristående. En positionsändring ska behandlas på samma sätt som Reorder: Den kan ändra Main Group. Säkra först ordningen, medlemskapen, det aktuella och avsedda policytillståndet samt återställningsvägen; kontrollera därefter med pilotanvändaren och återställ den sparade ordningen vid oväntad effekt. Mallen belägger varken ersättnings- eller sammanslagningsbeteendet för GroupMembers eller uppdateringssemantiken för After eller utelämnade fält.

Dokumentera målnamnet och det avsedda tillståndet före en snävt avgränsad Add/Edit-skrivoperation. Utvärdera därefter det faktiska resultatet av XML-operationen, läs ut exakt den namngivna gruppen igen och utför de positiva och negativa tester som beskrivs ovan på den berörda tjänsten. För Add och Edit kopplar referensen 502 till nyckeln UserGroupRecordExists och 503 till nyckeln UserGroupDuplicateIPInLoginRestriction. Vid ett motsvarande resultat ska du först kontrollera det avsedda befintliga gruppnamnet respektive dubbla adresser i SelectedNodes. Skicka inte på nytt utan kontroll och vidga inte LoginRestriction. Dessa mappningar belägger referensnycklar, inte renderade körtidsmeddelanden som har observerats här.

Importera kataloggrupper kontrollerat

Active Directory-grupper

Gå till Authentication > Servers och starta importguiden för den konfigurerade AD-servern. I ett HA-kluster måste importen ske på Primary. Guiden importerar endast de valda grupperna. En grupp som senare skapas i AD visas därför inte automatiskt och måste importeras på nytt.

Före importen måste AD-frågan fungera: servern behöver rätt NetBIOS domain, Domain name, ett ADS username med behörighet att söka, läsa och fråga efter gruppmedlemskap samt tillhörande Password. Ett domänadministratörskonto behövs inte för gruppimporten. Connection security erbjuder SSL/TLS som standard och STARTTLS som krypterat alternativ; Plaintext överför inloggningsuppgifter okrypterat och är ingen säker lösning för produktion. Port måste stämma överens med den valda anslutningstypen. Vid Validate server certificate laddas AD-servercertifikatet upp under Certificates > Certificates > Add > Upload certificate; Server IP/domain måste använda det CNAME som anges i certifikatet. Om brandväggen inte kan slå upp detta namn behöver den interna DNS-namnuppslagningen eller Network > DNS > DNS host entry kontrolleras. Den fullständiga serverkonfigurationen beskrivs i AD-artikeln som länkas ovan.

Search queries begränsar vilka användare som omfattas. Exempelvis söker OU=VPN_Users,DC=example,DC=com i OU:n VPN_Users i dokumentationsdomänen example.com; OU och domändelar måste ersättas med det faktiska Distinguished Name. En snävare sökbas gör användarurvalet överskådligt, men får inte utesluta de avsedda användarna. Endast användare som omfattas kan visas som Live Users via denna server. Test connection kontrollerar anslutningen och inloggningsuppgifterna, men bevisar ännu inte att en vanlig användare får rätt grupptilldelning. Strikt framtvingad LDAP Channel Binding och LDAP Signing stöds inte; ett sådant AD-säkerhetskrav måste klarläggas före integrationen och får inte kringgås som om det vore ett gruppfel.

Själva importen går till så här:

Klicka på Import för den avsedda AD-servern och starta Import group wizard med Start.
Välj rätt Base DN för gruppsökningen. Den måste omfatta de grupper som behövs och ska skiljas från sökbasen för användare.
Markera endast de avsedda AD-grupperna, exempelvis SFOS_Internet_Standard och SFOS_SSLVPN.
Välj de gemensamma gruppolicyerna och kontrollera därefter urvalet och resultaten.
Kontrollera båda grupperna och deras policyer under Authentication > Groups. Guiden importerar grupper, inte omedelbart alla användarposter eller medlemskap.
Kontrollera under Authentication > Services > Firewall authentication methods att AD-servern är vald för den planerade tjänsten. Om AD ska tillfrågas först i den här konfigurationsprocessen flyttar du servern till första plats och klickar på Apply. I en befintlig miljö ska du behålla den tidigare planerade serverordningen i stället för att ändra den generellt.

Kapslade AD-grupper utvärderas inte. Om en undergrupp ska gälla för en brandväggsregel eller VPN-policy måste just den undergruppen importeras. Användarens primära AD-grupp tas inte heller över som ett vanligt medlemskap. För policyer är därför explicita säkerhetsgrupper bättre än standardgruppen Domain Users i AD.

Detta gäller inte bara Domain Users: Om exempelvis SFOS_Internet_Standard blir användarens primära AD-grupp tas just det medlemskapet inte över som ett vanligt AD-medlemskap. Nästa matchande importerade grupp kan därmed bli Main Group. Brandväggens Main Group fastställs utifrån brandväggens egen grupplista och är inte den primära gruppen i AD.

Efter ändringar i AD-medlemskap, importerade grupper eller gruppordning måste användaren logga in igen. Först då utvärderar brandväggen grupperna på nytt och uppdaterar användarobjektet.

Om STAS och Synchronized User ID är konfigurerade samtidigt använder autentiseringsservern den mekanism från vilken inloggningsbegäran kommer först. Om pilottesterna ger olika resultat ska du därför även kontrollera Client Type i stället för att omedelbart ändra ordningen på grupper eller servrar.

Entra-grupper

För import av Entra-grupper behöver appregistreringen i Microsoft Graph applikationsbehörigheten Group.Read.All med Admin Consent. Klockorna på brandväggen och Microsoft Entra ID måste vara synkroniserade, annars kan anslutningen misslyckas.

Gå sedan till Authentication > Servers och klicka på guiden för gruppimport på Microsoft Entra-ID-servern. Du kan importera alla grupper eller endast grupper vars Display name eller Description motsvarar ett filter. Surfing quota, Access time, Network traffic och Traffic shaping kan tilldelas för alla eller enskilda importerade grupper. Nyligen importerade grupper måste dessutom läggas till i de policyer för Remote access IPsec eller SSL VPN som används; själva importen ger ingen VPN-åtkomst.

Utvärdera Main Group och flera grupper korrekt

Öppna användaren under Authentication > Users och rulla ned till Policies:

Group visar den första matchande gruppen i brandväggslistan och därmed Main Group.
Other group memberships visar ytterligare importerade AD-grupper för användaren.

Ytterligare två fält visas under Policies endast när båda förutsättningarna är uppfyllda för respektive fält:

Group SSL VPN policies: Användaren tillhör flera AD-grupper, och minst två av dessa grupper ingår i policyer för Remote access SSL VPN.
Group clientless SSL VPN policies: Användaren tillhör flera AD-grupper, och minst två av dessa grupper ingår i policyer för Clientless SSL VPN.

Om något av dessa fält saknas kontrollerar du därför först AD-medlemskapen, de importerade grupperna och att grupperna ingår i respektive VPN-policy. Medlemskap i flera AD-grupper räcker inte i sig för att fältet ska visas. Utöka inte VPN-behörigheter i produktion för att göra fältet synligt. Att fältet visas är inte heller ett åtkomsttest; hur behörigheterna faktiskt kombineras förklaras längre ned.

Under Authentication > Groups > Reorder kan ordningen ändras genom att dra och släppa. Klicka på Close för att stänga dialogrutan. Om auth-pilot@example.com tillhör SFOS_Internet_Standard och SFOS_SSLVPN blir den högre placerade matchande gruppen Main Group vid nästa inloggning.

Denna ordning gäller inte bara för det aktuella felärendet. Kontrollera innan du gör en ändring om den berörda funktionen stöder fler grupper. Annars kan en förflyttning lösa ett VPN-fall och samtidigt ändra MFA, kvot eller åtkomsttid för andra användare.

Funktioner med stöd för flera AD-grupper

Följande matris gäller uttryckligen för Active Directory. Förutsätt inte utan kontroll att den även gäller för LDAP, RADIUS eller Microsoft Entra ID.

Flera AD-grupper kan beaktas vid:

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.

Vid Remote access SSL VPN kombineras behörigheter från matchande användar- och gruppolicyer. Om en matchande full-tunnel-policy ingår blir resultatet en full tunnel. Kontrollera denna kombination med ett verkligt klienttest.

Vid Clientless SSL VPN beaktas behörigheterna från alla policyer som någon av användarens AD-grupper ingår i. Kontrollera därför inte bara den förväntade policyn, utan även ytterligare tillåtna bokmärken eller resurser från andra grupper.

Hotspots beaktar uteslutande Main Group.

Endast Main Group eller en uttrycklig användartilldelning beaktas vid:

WAF rules, My policy overrides;
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.

Vid WAF, L2TP, PPTP och Remote access IPsec kan användarpolicyn visa Enable, även om behörigheten endast kommer från Other group memberships och åtkomst därför inte tillåts. Bedöm dessa tjänster utifrån Main Group eller en direkt användartilldelning, inte enbart utifrån det som visas.

För funktioner med stöd för flera grupper avgör fortfarande ordningen på respektive regel eller policy. En brandväggsregel kan tillämpas via SFOS_SSLVPN, även om SFOS_Internet_Standard är Main Group. Det betyder inte att MFA eller kvot också använder SFOS_SSLVPN.

För Web policies handlar det om två separata beslut: Först avgör den matchande brandväggsregeln vilken webbpolicy som används. I den tillämpas den första regel som matchar både användaren och webbplatsen. Om pilotanvändaren tillhör båda exempelgrupperna och den första webbregeln blockerar sportsidor för SFOS_SSLVPN, blockeras en sportsida även om SFOS_Internet_Standard är användarens Main Group och en senare regel tillåter nyheter för den gruppen. IPS och Application control använder däremot policyn från den matchande brandväggsregeln; gruppordningen leder inte till någon ytterligare sammanslagning av dessa policyer.

För MFA kan användaren läggas till uttryckligen i stället för att en grupp väljs, eller så kan MFA tillämpas på alla användare. En behörighet enbart via Other group memberships räcker inte. Hotspots i User Portal styrs uteslutande av Main Group; ytterligare en AD-grupp utökar inte denna lista.

Kontrollera gruppverkan

En sparad grupp och en synlig användare är ännu inget bevis på att konfigurationen fungerar:

Avsluta den befintliga sessionen för pilotanvändaren och logga in på nytt.
Notera statusen, Group, Other group memberships och eventuella åsidosättningar under Authentication > Users > användare > Policies.
Kontrollera användarnamn, käll-IP-adress och Client Type under Current activities > Live users.
Vid en användarbaserad brandväggsregel, generera den avsedda trafiken och kontrollera Firewall Rule ID i Log Viewer.
Testa åtkomsttid, kvot, MFA och fjärråtkomst var för sig via den tjänst som faktiskt berörs.
Upprepa samma försök med en användare utanför pilotgruppen som ett negativt test.

Öppna Authentication > Users > användare > View usage för att kontrollera kvoten. Användningsdata är endast tillgängliga om en användarbaserad brandväggsregel hanterar trafiken och Log firewall traffic är aktiverad.

Kontrollera brandväggsregler med Log Viewer, Policy Test och Packet Capture visar det fullständiga trafiktestet. Om tjänsteval, identitet eller Main Group redan är oklart leder Åtgärda autentiseringsfel i Sophos Firewall systematiskt dig genom hela kontrollkedjan.

Återställ ändringar och rensa grupper

Ändra endast en gruppolicy eller position i taget. Om pilottestet visar en oväntad effekt, återställ den noterade ordningen och policytilldelningen, logga in användaren igen och upprepa positiva och negativa tester.

AD-grupperna tas först bort i katalogen och sedan separat under Authentication > Groups på brandväggen. Purge AD users rensar inga grupper.

För AD-användare gäller:

Radera användaren först i AD. Så länge användaren finns där kan brandväggen återskapa kontot vid en senare inloggning.
Klicka på Purge AD users under Authentication > Users. Du behöver inte välja användarna i förväg; brandväggen kontrollerar AD-servern och tar bara bort användare som redan har raderats där.
Starta processen på Primary i HA. Poster tas bort på Primary och Auxiliary. Rensningen avbryter inte Sign-in, Sign-out eller User Accounting.

En konfigurationsexport innehåller importerade och lokalt skapade AD-grupper, men inga användare från externa autentiseringsservrar. En fullständig säkerhetskopia inkluderar däremot alla användare och grupper. Ta hänsyn till denna begränsning när återställningen inte bara berör en enskild policyändring.

Radera en namngiven grupp säkert via API

Fastställ målgruppens exakta Name före varje radering och säkra policyer, ordning, medlemmar och användningsområden. Att den äldre API-tabellen markerar Name som icke-obligatoriskt är inget frikort för en radering utan namn: Beskrivningen kräver ett namn för att identifiera objektet. Kontrollera först de faktiska gruppanvändarna, VPN-tilldelningarna inklusive L2TP/IPsec, valet för extern autentisering, referenser i brandväggsregler och användningen som standardgrupp för gäster. Om gruppen fortfarande behövs ska du genomföra en uttryckligen planerad, snävt avgränsad migrering eller stoppa. Varken framtvinga borttagningen, rensa användare eller lätta på åtkomstbegränsningar bara för att få igenom raderingen. AD-ordningen som beskrivs ovan och åtskillnaden från Purge AD users gäller fortfarande.

Raderingsreferensen kopplar resultatrader till JavaScript-meddelandenycklar för sådana beroenden. Därmed är dessa kontrollkategorier belagda, inte de saknade renderade meddelandetexterna eller ett fel på en brandväggsenhet som har observerats här. För hur begäran byggs upp och XML-resultatet hanteras gäller Använd XML API säkert; referensen för gruppradering ger inget payload-exempel, och därför uppfinns inget Delete-omslag här. Vid ett avslag ska gruppen bevaras och den referens som visas i resultatet kontrolleras riktat. Även efter ett lyckat resultat ska du läsa ut exakt målobjektet igen, kontrollera att det saknas och upprepa de planerade tjänste- och åtkomsttesterna.

Användare och grupper delar på det interna ID-området upp till 65535. Enbart ett stort antal synliga objekt bevisar inte att gränsen har nåtts. Om en användare har ett User ID över 65535 och inte visas som Live User motsvarar förloppet det som beskrivs i Sophos Firewall User-ID-gräns.

Felsök efter symptom

Logga in den berörda användaren på nytt efter varje korrigering och kontrollera Group samt Other group memberships. Därefter räcker ett riktat nästa steg per symptom.

Ny AD-grupp visas inte

Starta importguiden för AD-servern igen och kör den i HA på Primary. Kontrollera sedan under Authentication > Groups om just den grupp som behövs finns. Skapa inte en bred ersättningsgrupp bara för att en inloggning ska fungera.

LDAP-användare hamnar i standardgruppen

Kontrollera på LDAP-servern Base DN, Authentication attribute och Group name attribute, därefter under Authentication > Services serverordningen och Default group. Kör Test connection för LDAP-servern. AD-importguiden ansvarar inte för denna mappning.

Entra-användare hamnar i fallbackgruppen

Kontrollera om Entra-gruppen har importerats och om token ger den förväntade gruppen. Kontrollera därefter Fallback user group direkt på Entra-servern. Den allmänna Default group under Authentication > Services används inte för denna mappning.

Användaren har fel Main Group

Jämför AD-medlemskap, importerade grupper och den aktuella ordningen. Kontrollera den nya ordningen först efter nästa inloggning och med flera representativa användare.

Brandväggsregeln gäller, men inte MFA eller kvoten

Brandväggsregler stöder ytterligare AD-grupper, MFA och kvoter gör det däremot inte. Kontrollera under Authentication > Users > användare > Policies Main Group, eventuella åsidosättningar och den faktiska policytilldelningen. Regelns effekt bevisar inte att MFA eller kvot utvärderar samma grupp.

Gruppändringen påverkar inte en enskild användare

Jämför de användarspecifika policyfälten och det faktiska valet av användare och grupper i den berörda regeln eller policyn: endast gruppen vald innebär att gruppvärden används; användaren och dennes grupp valda innebär att användarvärden används. Kontrollera även funktionens begränsningar för Main Group och flera grupper. Återställ endast gruppvärdet om det dokumenterade undantaget inte längre behövs.

Kapslad AD-grupp fungerar inte

Importera den undergrupp som behövs och lägg till användaren där direkt. Att bara importera den överordnade gruppen räcker inte.