Skapa och hantera lokala användare på Sophos Firewall

En lokal användare lagras direkt på Sophos Firewall och autentiseras mot den lokala användardatabasen. Det passar små miljöer, pilotkonton och enskilda externa medarbetare. Ett lokalt konto är endast lämpligt som reservlösning för en katalogtjänst om serverordningen, ett separat användarnamn, portalåtkomsten och beteendet när den externa källan inte är tillgänglig har testats för den aktuella tjänsten. SFOS-hjälpen beskriver serverordningen men garanterar inte automatisk växling för varje feltyp.

Den här artikeln gäller WebAdmin-gränssnittet i SFOS 22. Att enbart skapa en användare ger ingen åtkomst. Gruppen, autentiseringsmetoden, portalen eller klienten samt brandväggsregeln eller VPN-policyn måste vara korrekt konfigurerade tillsammans.

Snabbt arbetsflöde:

1. Fastställ användningsfall, målgrupp och nödvändig tjänst.
2. Förbered en restriktiv grupp av typen Normal under Authentication > Groups.
3. Ange ett permanent användarnamn under Authentication > Users > Add och välj User type: User.
4. Tilldela ett individuellt starkt lösenord och rätt grupp.
5. Lämna policyfälten på användaren oförändrade om gruppens värden ska gälla.
6. Begränsa Simultaneous sign-ins och Sign-in restriction medvetet.
7. Kontrollera under Authentication > Services att Local är valt för den tjänst som används.
8. Konfigurera portal, användarregel eller Remote Access-policy separat och så snävt som möjligt.
9. Testa en positiv och en negativ inloggning samt verklig trafik med ett pilotkonto.
10. Aktivera först därefter MFA, skapa fler användare och dokumentera avvecklingen.

⚠️ Användarnamnet kan inte ändras senare. Fastställ därför namnstandard, kontotyp och ansvar innan du sparar. SFOS omvandlar versaler i användarnamnet till gemener. Ett ersättningskonto får en ny identitet; kontrollera därför regler, kvoter, VPN-tilldelningar och granskningsspår på nytt.

När en lokal användare passar

Lokala användare kräver varken Active Directory eller en extern RADIUS- eller LDAP-server. Det gör dem enkla att använda, men innebär att all hantering av lösenord, MFA, grupper, inaktivering och granskning sker på brandväggen. Det är praktiskt för ett fåtal noggrant hanterade konton. Vid många medarbetare eller täta in- och utträden är en central katalog vanligtvis lättare att underhålla.

En normal lokal användare passar till exempel för:

• ett pilotkonto för Captive Portal, User Portal eller Remote Access;
• en liten miljö utan katalogtjänst;
• en enskild extern leverantör med tydlig tidsperiod och ansvarig;
• en testad reservlösning med ett eget användarnamn när en extern användarkälla tillfälligt inte är tillgänglig.

Använd inte ett lokalt konto för flera personer. Delade inloggningsuppgifter försvårar lösenordsbyten, MFA, kvoter, granskning och en ordnad avveckling.

Blanda inte användartyper

SFOS har flera liknande användartyper som löser olika uppgifter:

• En normal lokal användare loggar in med användarnamn och lösenord och får policyer via en normal grupp eller medvetna användarundantag.
• En gästanvändare är tidsbegränsad, använder Guest User-inställningarna och används normalt via Captive Portal.
• En Clientless User identifieras via en IP-adress och utför ingen interaktiv inloggning.
• En lokal administratör får User type: Administrator och en Device Access-profil för WebAdmin-rättigheter.
• En AD-, LDAP-, RADIUS- eller Entra-användare autentiseras av en extern källa. Beroende på metod skapas den lokala posten först vid den första lyckade inloggningen.

För en person som ska logga in på Captive Portal eller en VPN-tjänst används User type: User. Det ger inte kontot WebAdmin- eller SSH-åtkomst.

Exempel och förutsättningar

Följande exempel använder:

• användarnamn pilotuser01;
• visningsnamn Local Pilot User;
• e-postadress pilotuser01@example.com;
• grupp Local_Pilot_Users;
• brandväggsregel Local-Pilot-to-WAN;
• tillåtet intervall för inloggningskällor från 10.20.30.10 till 10.20.30.50.

example.com är en reserverad dokumentationsdomän och adressintervallet ligger i ett privat exempelnät. Ersätt användarnamn, e-postadress, grupp, regel och adresser med värden från din miljö. Användarnamnet innehåller ingen e-postadress och förblir därför giltigt även om e-postadressen ändras. Namnstandarden bör vara anpassad till helpdesk, avvecklingsprocessen och befintliga namn i katalogtjänsten.

Följande behöver klargöras innan kontot skapas:

• Vilken tjänst autentiserar användaren: Captive Portal, User Portal, VPN Portal, SSL VPN, IPsec eller en annan åtkomst som stöds?
• Vilken normal grupp innehåller den gemensamma grundkonfigurationen?
• Vilken brandväggs- eller Remote Access-policy tillåter den senare åtkomsten?
• Från vilka IPv4-adresser får kontot logga in?
• Hur många samtidiga inloggningar behövs i praktiken?
• Krävs lokal MFA och via vilken portal sker den första registreringen?
• Vem inaktiverar kontot och kontrollerar befintliga sessioner vid avveckling?

Hantera användargrupper och Main Group på Sophos Firewall förklarar den gemensamma grupplogiken. För normala lokala användare används en grupp av typen Normal. En grupp av typen Clientless hör till den IP-baserade modellen och är inte rätt baslinje för detta inloggningsflöde.

Skapa den lokala användaren

Kontot skapas under Authentication > Users > Add:

1. Ange pilotuser01 under Username. SFOS lagrar värdet med gemener och det kan inte ändras senare.
2. Ange Local Pilot User vid Name.
3. Ställ in User type på User.
4. Ange och bekräfta ett långt, individuellt lösenord från den fastställda lösenordsprocessen.
5. Ange pilotuser01@example.com eller personens e-postadress under Email. Använd en övervakad adress med en tydligt utsedd ansvarig för ett tekniskt konto.
6. Välj Local_Pilot_Users vid Group.
7. Ändra endast fälten för Quarantine digest, policy och Remote Access när funktionen eller ett dokumenterat användarundantag behövs.
8. Ställ in Simultaneous sign-ins och Sign-in restriction på lämpligt sätt.
9. Spara med Save.

SFOS avvisar vanliga lösenord och ord som identifieras av ordbokskontrollen. Använd ett långt och unikt lösenord enligt den fastställda lösenordsprocessen för varje konto. Ett kopierbart exempellösenord skulle omedelbart bli en känd hemlighet och är därför ingen säker mall.

Samma användarvy visar även externt autentiserade poster. För användare som har importerats från Active Directory skriver brandväggen vid autentiseringen över den lokalt angivna Email med adressen från AD. En lokal korrigering blir därför inte bestående; den ansvariga AD-administrationen måste korrigera värdet i källan.

För AD-användare som tillhör flera grupper visar Group användarens Main Group och Other group memberships de övriga AD-grupperna. Other group memberships är nedtonat och kan inte redigeras lokalt för användare som synkroniseras via en extern autentiseringsserver som AD eller RADIUS. Medlemskap kontrolleras och ändras i den ansvariga källan och ska inte kringgås med en lokal ersättningsgrupp. Gruppartikeln som länkas ovan förklarar vilka funktioner som använder ytterligare AD-grupper; det stödet gäller inte automatiskt för RADIUS.

Gruppvärden eller användarundantag

I användarposten kan Surfing quota, Access time, Network traffic och Traffic shaping samt flera Remote Access-fält anges. Tillverkarens hjälpsidor beskriver företrädet olika: guiden för att skapa användare ger användarvärden generellt företräde, medan användaröversikten även tar hänsyn till valet av användare och grupper i regler och policyer. Kontrollen av användarundantag och regelval förklarar begränsningen; anta inte att en avvikande användarpolicy får effekt utan villkor. Om gruppen ska förbli den underhållbara baslinjen ska dessa fält inte åsidosättas enbart för säkerhets skull.

Ett användarundantag passar för ett tydligt dokumenterat undantag, till exempel en snävare Access Time under ett tillfälligt uppdrag. Dokumentera:

• vilket fält som avviker från gruppvärdet;
• varför undantaget behövs;
• när det ska granskas eller tas bort;
• hur det ursprungliga gruppvärdet blir aktivt igen.

Access Time för användare och Surfing- respektive Network Traffic-kvoter förklarar respektive policy i sin helhet. Tilldela endast policyer vars funktion redan är känd till användarobjektet.

Begränsa antal och källa för inloggningar

Simultaneous sign-ins begränsar samtidiga sessioner. Global setting övertar värdet som gäller för nya användare under Authentication > Services. Alternativt kan ett eget värde eller Unlimited väljas. Obegränsade sessioner behövs sällan för en normal personlig användare och gör delade inloggningsuppgifter svårare att upptäcka.

Sign-in restriction begränsar de IPv4-adresser som användaren får logga in från:

• Any node: tillåt inloggning från alla nåbara källor;
• User group nodes: ärv gruppvärdet;
• Selected nodes: ange enskilda avsedda IPv4-adresser;
• Node range: tillåt ett sammanhängande IPv4-intervall.

Välj Node range och ange 10.20.30.10 som startadress och 10.20.30.50 som slutadress. Ersätt båda värdena med det minsta sammanhängande intervall som användaren faktiskt loggar in från. Om du behöver enskilda IPv4-adresser som inte ligger i ett sammanhängande intervall använder du Selected nodes. Ett alltför snävt urval blockerar legitima inloggningar; Any node ersätter varken en brandväggsregel, en portal-ACL eller MFA.

Aktivera inte MAC binding för detta grundflöde. Det stöder klientbaserad autentisering, men inte Remote Access VPN eller Captive Portal. Om det aktiveras utan MAC-adress binder SFOS automatiskt den först identifierade MAC-adressen vid den första inloggningen. På mobila enheter, efter ett byte av wifi eller på delade klienter kan detta snabbt bli ett oväntat beroende.

XML-API: håll användar- och administratörsbegränsningar åtskilda

För automatisering skiljer XML-API-referensen för SFOS 22 och 23 mellan samma områden när User läggs till och uppdateras. Följande sökvägar visar hur dokumentationen är indelad; de utgör inte en fullständig, körbar begäran:

• Kontotyp och rättigheter: User/UserType tillåter User eller Administrator; parametertabellen anger User som standardvärde och fältet som valfritt. User/Profile är där markerat med Mandatory: Yes, men gäller enligt en uttrycklig anmärkning endast för Administrator. Detta innebär inget krav på profil för normala användare. För administratörer behövs fortfarande en medvetet restriktiv Device Access-profil.
• Inloggningskälla för normala användare: För User/LoginRestriction anger exemplet värdena AnyNode, UserGroupNode, SelectedNodes och NodeRange. Vid SelectedNodes anges IPv4-adresserna under User/NodeList/IPAddress; vid NodeRange utgör User/FromIP och User/ToIP intervallets gränser. Tabellmarkeringen Mandatory: Yes för dessa fält gäller uttryckligen under förutsättning att ett intervall väljs. Den gör inte fälten obligatoriska för alla typer av begränsningar.
• Inloggningskälla för administratörer: User/LoginRestrictionForAppliance gäller administratörens inloggning på enheten, inte normal användarinloggning. Tabellen tillåter AnyNode, SelectedNodes och NodeRange och anger AnyNode som standardvärde. Enligt exemplet anges enskilda IPv4-adresser under User/AdminAccessNodeList/IPAddress och intervallgränser under User/AdminAccessFromIP och User/AdminAccessToIP. Administratörsfälten får inte förväxlas med fälten för normala användare; tabellmarkeringen Yes får inte tolkas som ett allmänt krav oberoende av kontotyp och vald begränsning. Ett dokumenterat standardvärde är ingen rekommendation om obegränsad administratörsåtkomst.
• Åtkomsttid för administratörer: User/ScheduleForApplianceAccess väljer schemat för enhetsåtkomst och gäller enligt tabellens anmärkning endast administratörer. Exemplet visar All The Time, men kolumnen för standardvärde är tom. Exempelvärdet är därför inget bekräftat standardvärde, och fältet ersätter inte Access Time-policyn för en normal användare.
• Statiska SSL VPN-adresser: User/SSLVPNIPv4Address och User/SSLVPNIPv6Address är valfria. Båda hänvisar till det reserverade statiska intervallet under SSL VPN global settings, inte till godtyckliga LAN-adresser. Aktiveringen som beskrivs nedan och valet av en ledig adress från rätt IPv4- respektive IPv6-intervall gäller även för denna tilldelning.

⚠️ XML-exemplet innehåller för LoginRestrictionForAppliance det avklippta värdet AnyNode/. Det är varken en fullständig lista över värden eller en mall att kopiera; tabellen anger de tre värden som räknas upp ovan. Om referensen för den version som används, en befintlig export och den planerade tilldelningen skiljer sig åt, avbryter man innan något skrivs och klargör kontotyp, fält och tillåtet värde med hjälp av rätt referens eller Sophos Support. Man kompletterar inte det avklippta värdet på måfå och lättar inte på någon åtkomstbegränsning för att få igenom en begäran.

Konfigurera autentiseringsmetod och åtkomst

En sparad användare kan bara logga in på en tjänst som använder den lokala databasen. Aktivera metoden Local i listan för den aktuella tjänsten under Authentication > Services.

Områdena är separata:

• Firewall authentication methods för brandväggstrafik och Captive Portal;
• User portal authentication methods för User Portal;
• VPN portal authentication methods för VPN Portal;
• VPN (IPsec/dial-in/L2TP/PPTP) authentication methods för dessa VPN-metoder;
• SSL VPN authentication methods för Remote Access SSL VPN.

Flera källor frågas i den visade ordningen. Ett lyckat test på User Portal visar därför inte automatiskt att samma användare är korrekt konfigurerad för SSL VPN eller IPsec.

Du kan välja högst 20 servrar per autentiseringsmetod. För User Portal och VPN Portal är alternativet för att ärva inställningen Set authentication methods same as firewall. För SSL VPN visar SFOS Same as VPN eller Same as firewall, beroende på den valda referensen. Kontrollera alternativet och den resulterande ordningen innan du lägger till eller flyttar Local.

Konfigurera åtkomst separat

Den lokala identiteten ger inte i sig någon nätverksåtkomst. Captive Portal kräver dessutom Device Access, Web Authentication och en lämplig användarregel. Hela arbetsgången finns i Konfigurera och testa Captive Portal på Sophos Firewall.

User Portal och VPN Portal är också separata tjänster. Portalmodellen för Sophos Firewall förklarar portar, syfte, Device Access och WAN-gränser. Remote Access-policyer hanteras i respektive VPN-guide och betraktas inte som färdiga bara för att ett fält har ställts in i användarobjektet.

Tolka Remote Access-fälten korrekt

För andra Remote Access-metoder än SSL VPN har användarspecifika policyvärden företräde framför gruppen. SSL VPN följer en annan logik: Användaren får resurserna från alla Full och Split Tunnel-policyer där användaren själv eller någon av de grupper som stöds ingår. Fältet SSL VPN policy ersätter därför inte gruppolicyerna på ett enkelt sätt.

Två ytterligare gruppfält visas bara under vissa förutsättningar:

• Group SSL VPN policies visar gruppernas Remote Access SSL VPN-policyer endast om användaren tillhör flera AD-grupper och minst två av dessa grupper ingår i Remote Access SSL VPN-policyer.
• Group clientless SSL VPN policies visar gruppernas Clientless SSL VPN-policyer endast om användaren tillhör flera AD-grupper och minst två av dessa grupper ingår i Clientless SSL VPN-policyer.

Om något av fälten saknas kontrollerar man först båda villkoren för just den VPN-typen. Att fältet visas innebär inte att åtkomst beviljas separat; resurser, bokmärken, verifiering och avveckling hanteras fortfarande i respektive VPN-guide.

SSL VPN IP address visas bara när statiska adresser är aktiverade under SSL VPN global settings. IPv4- eller IPv6-adressen måste vara ledig och komma från det statiska intervall som skapats automatiskt där. Om en RADIUS-server tilldelar adresser gäller den tilldelningen. IPsec remote access aktiverar i stället åtkomst med Sophos Connect och kan få en egen leaseadress.

L2TP och PPTP är äldre VPN-metoder. Båda fälten i användarobjektet tillåter respektive Remote Access-typ och har var sitt inmatningsfält för den IP-adress som ska leasas till fjärranvändaren. Det är en användarspecifik leasetilldelning, inte en fullständig tunnelkonfiguration eller ett skäl att aktivera ny åtkomst med en äldre VPN-metod. Efter tilldelningen måste användaren först logga in på VPN Portal och skapa ett lösenord innan anslutningen är möjlig. Den aktuella bedömningen och migreringsvägen för L2TP finns under L2TP Remote Access; PPTP ska inte längre planeras för ny åtkomst. Clientless SSL VPN policy öppnar endast de tilldelade webbläsarbokmärkena och är inte en fullständig tunnel. Det separata arbetsflödet finns under Clientless Access.

För en användarbaserad brandväggsregel definieras källa, destination, tjänst och användare eller grupp så snävt som möjligt. Log firewall traffic förblir aktivt under verifieringen. Grunderna finns i Förstå och konfigurera Sophos Firewall-regler säkert.

Verifiera med positiva och negativa tester

Ett synligt konto med status Active är ännu inget bevis på att allt fungerar. Pilotkontot testas via exakt den tjänst som senare ska användas:

1. Logga in som pilotuser01 i ett privat webbläsarfönster eller från en ren testklient.
2. Kontrollera användarnamn, käll-IP och Client Type under Current activities > Live users.
3. Kontrollera lyckad inloggning, lokal autentisering och tidpunkt i Log Viewer > Authentication.
4. Skapa den avsedda trafiken och verifiera Local-Pilot-to-WAN eller dess Firewall Rule ID som den förväntade matchen i brandväggs- eller VPN-loggen.
5. Använd en uttryckligen otillåten källa eller funktion som negativt test.
6. Om en kvot eller Access Time är aktiv testas effekten separat innanför och utanför gränsen.
7. Dokumentera resultatet, vald grupp, användarundantag och autentiseringsmetod.

En negativ inloggning bör inte misslyckas enbart därför att ett avsiktligt felaktigt lösenord användes. Kontrollera också att en otillåten källa, en användare utan rätt grupp eller en oavsedd funktion faktiskt inte får åtkomst. På så sätt skiljs lösenordskontrollen från policy- och regelverkan.

Om det är oklart om användarstatus, autentiseringsmetod, grupp eller åtkomstregel orsakar felet, ger Felsök autentiseringsfel på Sophos Firewall systematiskt en stegvis kontrollkedja. För detaljerad analys innehåller /log/access_server.log händelser för autentisering, auktorisering och redovisning; Log Viewer är fortfarande det första steget.

Hantera lösenord, MFA och användning

För att som administratör ändra lösenordet för ett befintligt lokalt konto i SFOS 22 och 23 öppnar man den berörda användaren under Authentication > Users och klickar på Change password. Först kontrolleras kontot och den ansvariga personen, och ett nytt långt och unikt lösenord tas fram enligt den godkända lösenordsprocessen. Det nya lösenordet anges, ändringen sparas och hemligheten överlämnas säkert till den behöriga personen. Därefter testas en ny inloggning med det nya lösenordet till den tjänst som faktiskt används. Denna åtgärd i WebAdmin är skild från självbetjäning i User Portal; externt autentiserade konton hanteras fortfarande i respektive användarkälla. Detta garanterar inte att befintliga sessioner avslutas automatiskt.

En lokal användare kan själv ändra lösenordet under User Portal > Personal > Change Password. Det gäller den lokala databasen, inte externt autentiserade AD-, LDAP- eller RADIUS-konton. Under Personal > Personal Details kan användaren också ändra visningsnamnet. Användarnamnet och e-postadressen är skrivskyddade där. Administratören hanterar e-postadressen i användarobjektet; användarnamnet förblir oföränderligt även där. User Portal görs bara nåbar från de nödvändiga zonerna och öppnas inte brett mot WAN enbart för denna hantering.

För ytterligare skydd väljer du kontot under Authentication > Multi-factor authentication. Med Generate OTP token with next sign-in registrerar användaren tokenen via User Portal eller VPN Portal. MFA för Sophos Firewall förklarar hashalgoritmen, portalåtkomst, återställning och pilotinförande. Aktivera MFA först efter att den vanliga inloggningen och återställningsprocessen har testats.

Under Authentication > Users > <användare> > View usage visas tilldelade kvoter, Surfing-tid och dataförbrukning. För att uppgifterna ska visas måste trafiken matcha en användarbaserad brandväggsregel med Log firewall traffic. Reset user accounting nollställer räknarna för Surfing och Network Traffic och används därför inte som en generell lösning på inloggningsproblem.

Rulla tillbaka förändringen och ta bort kontot

Före pilotfasen dokumenterar du den befintliga ordningen under Authentication > Services och alla grupp-, portal-, regel- och VPN-inställningar som du ändrar. På så sätt behöver återställningen inte bygga på gissade standardvärden. När en person slutar, ett pilottest misslyckas eller kontot inte längre behövs arbetar du i omvänd ordning:

1. Kontrollera beroenden i regler, grupper, Remote Access-policyer, kvoter, MFA och dokumentation.
2. Under Authentication > Users väljer du användaren och ställer in Change status till Inactive.
3. Utför en ny inloggning som negativt test.
4. Kontrollera befintliga sessioner under Current activities > Live users och koppla vid behov från en normal användare med Disconnect.
5. Ta bort användaren från brandväggsregler och Remote Access-policyer eller återställ det dokumenterade tidigare valet.
6. Återställ ändrade grupp-, portal- och autentiseringstjänstinställningar exakt till deras registrerade tidigare tillstånd.
7. Kontrollera brandväggs-, VPN- och konfigurationsloggar för ytterligare försök, resttrafik och de ändringar som gjorts.
8. Ta endast bort kontot efter att alla beroenden har hanterats, eller behåll det inaktivt enligt bevarandeprocessen.

XML-API: kontrollera raderingsmål och resultat separat. Referensen för Delete i SFOS 22 och 23 kräver det exakta sparade värdet i Username. Beskrivningsfragmentet <Name><username></Name> avser detta användarnamn, inte visningsnamnet Name i formuläret för att lägga till användare och inte något antaget internt ID. Det är inte en fullständig, körbar begäran. Arbetsflödet ovan gäller normala användare; administratörer och det konto som för närvarande är inloggat ska hållas åtskilda från dessa. Före varje radering säkerställs att en oberoende, fungerande administrationsåtkomst finns kvar.

Statusraderna för denna operation kopplar 200 till Message.UserDeleteSuccess, 204 till Message.UserAdminOrCurrentUserNotDeleted, 205 till Message.AuthorizerExists, 206 till Message.UserForeignKeyExists, 210 till Message.UserIMRuleExists och 500 till Message.UserDeleteFailed. Detta är identifierare i källtexten, inte bekräftade meddelandetexter eller resultat. I synnerhet innebär identifierarna för utebliven radering och beroenden vid 204, 205, 206 och 210 inte generellt att raderingen har lyckats; denna operationstabell är ingen klassificering av HTTP-statuskoder. Identifierarna ger inte grund för att anta automatisk kaskadradering eller härleda åtgärder för att rensa Authorizer, främmande nycklar eller IM-regler; IM-identifieraren bekräftar inte någon GUI-funktion som stöds i nuläget.

Vid ett oklart resultat eller en avbruten skrivåtgärd kontrollerar man före ett nytt försök exakt det sparade användarnamnet och dess aktuella tillstånd under Authentication > Users. För en godkänd radering som stöds använder man det gränssnitt som stöds, eller klargör med Sophos Support hur begäran och resultat ska hanteras i den installerade programversionen innan man gör osäkra API-skrivningar. Därefter kontrollerar man att exakt det avsedda kontot inte längre finns och att andra konton som behövs samt administrationsåtkomsten fortfarande fungerar oförändrat. Beroenden och bevarandekrav måste klargöras i förväg; inaktivering och frånkoppling av sessioner ersätter inte denna verifiering av raderingen.

SFOS-hjälpen bekräftar inte att en inaktivering avslutar alla befintliga anslutningar. Kontrollera och koppla från sessioner och tunnlar separat. Upprepa de positiva och negativa testerna efter en återaktivering.

Innan en riskfylld radering kan du exportera User-konfigurationsobjektet med Include dependent entity under Backup and firmware > Import export. Denna export innehåller känsliga data, inklusive lösenord, och måste krypteras och lagras på en åtkomstkontrollerad plats. Rätt Secure Storage Master Key måste också vara tillgänglig för en senare import. En import uppdaterar befintlig konfiguration och tillämpar importerade värden där objekt överlappar varandra. Exporterade delade beroenden kan därför också skrivas över. Granska innehållet och påverkan innan du importerar, helst i en lämplig testmiljö.

En fullständig säkerhetskopia är ingen snabb återställning av en enskild användare: en återställning ersätter hela konfigurationen, startar om brandväggen och förkastar senare ändringar. Processen beskrivs i Säkerhetskopiering och återställning på Sophos Firewall.

I ett HA-kluster gör du ändringen på den primära enheten och kontrollerar därefter synkroniseringsstatusen. Loggar och rapporter synkroniseras inte mellan noderna och måste granskas separat vid felsökning.

Användare och grupper delar interna ID:n. Enbart ett stort antal objekt bevisar inte ett problem. Om en användare däremot visar ett User ID över 65535 och inte autentiseras, används den separata arbetsgången för Sophos Firewalls User ID-gräns, i stället för att ändra lösenord eller regler på måfå.

Avgränsa fel efter symtom

Användarnamn och lösenord avvisas

Kontrollera under Authentication > Users att kontot är lokalt, aktivt och finns med det förväntade användarnamnet. Kontrollera därefter för den aktuella tjänsten under Authentication > Services om Local är valt. En lyckad inloggning på en annan portal visar inte att Local är valt för den här tjänsten.

Inloggningen fungerar, men användarregeln matchar inte

Kontrollera identitet, käll-IP och Client Type under Current activities > Live users. Kontrollera sedan regelposition, Source Zone, användare eller grupp och Firewall Rule ID i Log Viewer. En nätverksregel ovanför användarregeln kan redan matcha trafiken.

En gruppändring får ingen effekt

Leta efter användarspecifika värden för kvot, Access Time, Traffic Shaping eller Remote Access. Dessa undantag kan ersätta gruppvärden; för kvot, Access Time och Traffic Shaping kontrolleras också det faktiska användar-/gruppvalet i den berörda regeln eller policyn. För Remote Access gäller de metodspecifika begränsningarna ovan. Återställ grupparvet först efter en jämförelse med det dokumenterade undantaget.

Användaren kan logga in från en oväntad källa

Kontrollera Sign-in restriction både på användaren och gruppen. Kontrollera dessutom den tjänst som faktiskt används, Device Access och nätverksregeln. En inställning på Any node kompenseras inte automatiskt av MFA eller en snäv brandväggsregel.

View usage förblir tomt

Kontrollera att användaren identifieras som Live User och att trafiken matchar en användarbaserad regel med Log firewall traffic. Kontrollera sedan tidsperiod, kvottilldelning och faktisk testtrafik. Reset user accounting skapar inga saknade loggar och reparerar ingen felaktig regel.

Operativ checklista

• Live users visar pilotuser01, förväntad käll-IP och avsedd Client Type.
• Autentiseringsloggen bekräftar den lokala inloggningen; Local-Pilot-to-WAN eller dess Firewall Rule ID matchar testtrafiken.
• Ett felaktigt lösenord, en otillåten källa och en obehörig funktion ger de förväntade negativa testresultaten.
• Användarundantag, Simultaneous sign-ins, Sign-in restriction och eventuella utgångsdatum är dokumenterade.
• MFA-registreringen och återställningsprocessen har testats om MFA används.
• Det tidigare tillståndet, ansvaret, inaktiveringen, frånkopplingen av sessioner och den senare raderingen är dokumenterade.

Vanliga frågor