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.

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. Användarspecifika värden har företräde framför gruppvärden. 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.

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.

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 legacy-metoder. 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; planera inte PPTP för ny åtkomst. Clientless SSL VPN policy öppnar endast de tilldelade bokmärkena i webbläsaren 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 och hanteras av administratören i användarobjektet. 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.

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 har företräde framför gruppen. Å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