Naar de inhoud
Avanet

Lokale gebruikers op Sophos Firewall maken en beheren

Een lokale gebruiker wordt rechtstreeks op Sophos Firewall opgeslagen en via de lokale gebruikersdatabase geauthenticeerd. Dit past bij kleine omgevingen, pilotaccounts, afzonderlijke externe medewerkers of een bewust onderhouden fallback. Alleen het aanmaken van het account verleent echter nog geen toegang. Groep, authenticatiemethode, portal of client, firewall- of VPN-policy en de daaropvolgende controle moeten op elkaar aansluiten.

De veilige korte werkwijze is:

  1. Gebruiksscenario, doelgroep en benodigde service bepalen.
  2. Onder Authentication > Groups een beperkte groep van het type Normal voorbereiden.
  3. Onder Authentication > Users > Add een blijvende gebruikersnaam invoeren en User type: User kiezen.
  4. Een individueel sterk wachtwoord en de juiste groep toewijzen.
  5. Policyvelden bij de gebruiker ongewijzigd laten als de groepswaarden moeten gelden.
  6. Simultaneous sign-ins en Sign-in restriction bewust beperken.
  7. Onder Authentication > Services controleren of Local voor de gebruikte service is geselecteerd.
  8. Portal, gebruikersregel of Remote Access-policy afzonderlijk en zo beperkt mogelijk configureren.
  9. Met een pilotaccount een positieve en negatieve aanmelding en echt verkeer testen.
  10. Pas daarna MFA inschakelen, meer gebruikers aanmaken en offboarding documenteren.

⚠️ De gebruikersnaam kan later niet worden gewijzigd. Leg daarom vóór het opslaan het naamgevingsschema, accounttype en eigenaarschap vast. Een nieuw account met een andere naam vormt een nieuwe identiteit en kan regels, quota, VPN-toewijzingen, logs en auditsporen opsplitsen.

Wanneer een lokale gebruiker past

Lokale gebruikers hebben geen Active Directory en geen externe RADIUS- of LDAP-server nodig. Dat maakt ze eenvoudig, maar brengt wachtwoordbeheer, MFA, groepen, deactivering en reviews volledig onder bij de firewall. Voor enkele bewust beheerde accounts is dit praktisch. Bij veel medewerkers of frequente in- en uitdiensttredingen is een centrale directory meestal eenvoudiger te onderhouden.

Een normale lokale gebruiker is bijvoorbeeld geschikt voor:

  • een pilotaccount voor Captive Portal, User Portal of Remote Access;
  • een kleine omgeving zonder directoryservice;
  • één externe dienstverlener met een duidelijke looptijd en eigenaar;
  • een gedocumenteerde fallback als een externe gebruikersbron tijdelijk niet beschikbaar is.

Een lokaal account wordt niet aanbevolen als gedeeld verzamelaccount voor meerdere personen. Gedeelde aanmeldgegevens bemoeilijken wachtwoordwijzigingen, MFA, quota, audits en nette offboarding.

Gebruikerstypen niet door elkaar halen

SFOS kent verschillende vergelijkbare gebruikerstypen die elk een andere taak oplossen:

  • Een normale lokale gebruiker meldt zich aan met een gebruikersnaam en wachtwoord en ontvangt policies via een normale groep of bewuste gebruikersoverrides.
  • Een gastgebruiker is tijdelijk, gebruikt de Guest User-instellingen en wordt doorgaans via Captive Portal ingezet.
  • Een Clientless User wordt aan een IP-adres herkend en voert geen interactieve aanmelding uit.
  • Een lokale beheerder krijgt User type: Administrator en een Device Access-profiel voor WebAdmin-rechten.
  • Een AD-, LDAP-, RADIUS- of Entra-gebruiker wordt door een externe bron geauthenticeerd. Afhankelijk van de methode ontstaat het lokale record pas bij de eerste geslaagde aanmelding.

Voor een persoon die zich bij Captive Portal of een VPN-service moet aanmelden, wordt User type: User gebruikt. Dit account krijgt daardoor geen WebAdmin- of SSH-toegang.

Voorbeeld en voorwaarden plannen

Het volgende voorbeeld gebruikt:

  • gebruikersnaam pilotuser01;
  • weergavenaam Local Pilot User;
  • e-mailadres pilotuser01@example.com;
  • groep Local_Pilot_Users;
  • firewallregel Local-Pilot-to-WAN;
  • toegestane aanmeldbron 10.20.30.0/24.

example.com is een gereserveerd documentatiedomein; 10.20.30.0/24 wordt hier alleen als privénetwerk voor het voorbeeld gebruikt. Vervang gebruikersnaam, e-mailadres, groep, regel en netwerk door waarden uit de eigen omgeving. De gebruikersnaam is bewust functieneutraal en bevat geen e-mailadres, zodat een latere e-mailwijziging de aanmeldidentiteit niet verandert. In een productieomgeving hoort het naamgevingsschema aan te sluiten op helpdesk, offboarding en bestaande directorynamen.

Maak vóór het aanmaken duidelijk:

  • Welke service authenticeert de gebruiker: Captive Portal, User Portal, VPN Portal, SSL VPN, IPsec of een andere ondersteunde toegang?
  • Welke normale groep bevat de gezamenlijke basisinstellingen?
  • Welke firewall- of Remote Access-policy staat de latere toegang toe?
  • Vanaf welke IPv4-adressen mag het account zich aanmelden?
  • Hoeveel gelijktijdige aanmeldingen zijn operationeel nodig?
  • Is lokale MFA vereist en via welke portal vindt de eerste registratie plaats?
  • Wie deactiveert het account en controleert bestaande sessies bij offboarding?

Gebruikersgroepen en Main Group op Sophos Firewall beheren legt de gezamenlijke groepslogica uit. Voor normale lokale gebruikers wordt een groep van het type Normal gebruikt. Een groep van het type Clientless hoort bij het IP-gebaseerde model en is niet de juiste basis voor deze aanmeldworkflow.

Lokale gebruiker aanmaken

Maak het account aan onder Authentication > Users > Add:

  1. Bij Username pilotuser01 invoeren.
  2. Bij Name Local Pilot User invoeren.
  3. User type op User zetten.
  4. Een lang, individueel wachtwoord uit het vastgelegde wachtwoordproces invoeren en bevestigen.
  5. Bij Email pilotuser01@example.com of het echte verantwoordelijke adres invoeren.
  6. Bij Group Local_Pilot_Users selecteren.
  7. Policy- en Remote Access-velden alleen wijzigen wanneer een gedocumenteerde gebruikersexceptie bedoeld is.
  8. Simultaneous sign-ins en Sign-in restriction passend instellen.
  9. Met Save opslaan.

SFOS weigert veelgebruikte wachtwoorden en woorden die door de woordenboekcontrole worden herkend. Dit artikel toont bewust geen voorbeeldwachtwoord. Een wachtwoord dat uit documentatie kan worden gekopieerd, is onmiddellijk een bekend geheim en geen veilige sjabloon.

Groepswaarden of gebruikersoverrides

In het gebruikersrecord kunnen Surfing quota, Access time, Network traffic en Traffic shaping, plus verschillende Remote Access-velden worden ingesteld. Gebruikersspecifieke waarden hebben voorrang op groepswaarden. Als de groep de onderhoudbare basis moet blijven, worden deze velden niet preventief overschreven.

Een gebruikersoverride past bij een duidelijk gedocumenteerde uitzondering, bijvoorbeeld een beperktere Access Time tijdens een tijdelijke opdracht. Leg vast:

  • welk veld van de groepswaarde afwijkt;
  • waarom de uitzondering nodig is;
  • wanneer deze wordt gecontroleerd of verwijderd;
  • hoe de oorspronkelijke groepswaarde weer actief wordt.

Access Time voor gebruikers en Surfing- en Network Traffic-quota leggen elke policy volledig uit. Wijs in het gebruikersobject alleen een policy toe die al wordt begrepen.

Aantal en bron van aanmeldingen beperken

Simultaneous sign-ins beperkt gelijktijdige sessies. Global setting neemt de waarde voor nieuwe gebruikers over uit Authentication > Services. Als alternatief kan een eigen waarde of Unlimited worden gekozen. Onbeperkte sessies zijn voor een normale persoonlijke gebruiker zelden nodig en maken gedeelde aanmeldgegevens moeilijker herkenbaar.

Sign-in restriction beperkt de IPv4-adressen waarvan de gebruiker zich mag aanmelden:

  • Any node: aanmelden vanaf iedere bereikbare bron toestaan;
  • User group nodes: de groepswaarde overnemen;
  • Selected nodes: afzonderlijke bedoelde IPv4-adressen invoeren;
  • Node range: een aaneengesloten IPv4-bereik toestaan.

Gebruik in het voorbeeld het echte beheer-, gebruikers- of VPN-bronnetwerk en kopieer niet blind 10.20.30.0/24. Een te beperkte selectie blokkeert legitieme aanmeldingen. Any node verruimt daarentegen alleen de mogelijke aanmeldbron en vervangt geen firewallregel, portal-ACL of MFA.

Schakel MAC binding niet in voor deze basisworkflow. Het ondersteunt clientgebaseerde authenticatie, maar geen Remote Access VPN of Captive Portal. Als het zonder MAC-adres wordt ingeschakeld, koppelt SFOS bij de eerste aanmelding automatisch het eerst herkende MAC-adres. Bij mobiele apparaten, na wisselen van wifi of op gedeelde clients kan dit snel een onverwachte afhankelijkheid worden.

Authenticatiemethode en toegang koppelen

Een opgeslagen gebruiker kan zich alleen aanmelden bij een service die de lokale database daadwerkelijk raadpleegt. Selecteer daarom onder Authentication > Services Local voor de bedoelde service.

De onderdelen zijn gescheiden:

  • Firewall authentication methods voor firewallverkeer en Captive Portal;
  • User portal authentication methods voor User Portal;
  • VPN portal authentication methods voor VPN Portal;
  • VPN (IPsec/dial-in/L2TP/PPTP) authentication methods voor deze VPN-methoden;
  • SSL VPN authentication methods voor Remote Access SSL VPN.

Meerdere bronnen worden in de weergegeven volgorde geraadpleegd. Een geslaagde test op User Portal bewijst daarom niet automatisch dat dezelfde gebruiker ook voor SSL VPN of IPsec juist is geconfigureerd.

Portal, regel of VPN-policy blijft afzonderlijk

De lokale identiteit opent geen netwerkpad. Captive Portal vereist daarnaast Device Access, Web Authentication en een passende gebruikersregel. De volledige workflow staat in Sophos Firewall Captive Portal instellen en testen.

User Portal en VPN Portal zijn eveneens afzonderlijke services. Het portalmodel van Sophos Firewall legt poorten, doel, Device Access en WAN-grenzen uit. Remote Access-policies worden in de bijbehorende VPN-handleidingen onderhouden en zijn niet voltooid enkel omdat er een veld op het gebruikersobject is ingesteld.

Definieer bij een gebruikersgebaseerde firewallregel bron, bestemming, service en gebruiker of groep zo beperkt mogelijk. Laat Log firewall traffic tijdens de acceptatietest ingeschakeld. De basisprincipes staan in Sophos Firewall-regels begrijpen en veilig configureren.

Met positieve en negatieve tests valideren

Een zichtbaar account met status Active is nog geen bewijs van succes. Test de pilot via precies de service die later wordt gebruikt:

  1. Als pilotuser01 aanmelden in een privébrowservenster of vanaf een schone testclient.
  2. Onder Current activities > Live users gebruikersnaam, bron-IP en Client Type controleren.
  3. In Log Viewer > Authentication de geslaagde aanmelding, lokale authenticatie en het tijdstip controleren.
  4. Het bedoelde verkeer genereren en in het firewall- of VPN-log de verwachte regel of policy controleren.
  5. Een uitdrukkelijk niet toegestane bron of functie als negatieve test gebruiken.
  6. Als een quota of Access Time actief is, het effect afzonderlijk binnen en buiten de grens testen.
  7. Resultaat, gebruikte groep, gebruikersoverrides en authenticatiemethode documenteren.

Een negatieve aanmelding mag niet alleen mislukken omdat er bewust een verkeerd wachtwoord is gebruikt. Controleer ook dat een niet-toegestane bron, een gebruiker zonder passende groep of een onbedoelde functie daadwerkelijk geen toegang krijgt. Zo wordt wachtwoordcontrole gescheiden van de werking van policies en regels.

Als nog onduidelijk is of de lokale database, servicekeuze, gebruikersstatus, groep of pas de latere regel faalt, geeft authenticatiefouten op Sophos Firewall systematisch oplossen de volledige controleketen. Voor diepere analyse bevat /log/access_server.log gebeurtenissen voor authenticatie, autorisatie en accounting; Log Viewer blijft de eerste stap.

Wachtwoord, MFA en gebruik beheren

Een lokale gebruiker kan het wachtwoord zelf wijzigen onder User Portal > Personal > Change Password. Dit geldt voor de lokale database, niet voor extern geauthenticeerde AD-, LDAP- of RADIUS-accounts. Maak User Portal alleen bereikbaar vanuit de benodigde zones en stel het niet breed open voor WAN enkel voor wachtwoordbeheer.

Voor extra beveiliging kan het account onder Authentication > Multi-factor authentication worden geselecteerd. Met Generate OTP token with next sign-in registreert de gebruiker het token via User Portal of VPN Portal. MFA voor Sophos Firewall legt hash-algoritme, portaltoegang, herstel en pilotfase uit. Schakel MFA pas in wanneer de normale aanmelding en het herstelpad werken.

Onder Authentication > Users > > View usage zijn toegewezen quota, Surfing-tijd en dataverbruik zichtbaar. Daarvoor moet verkeer een gebruikersgebaseerde firewallregel met Log firewall traffic raken. Reset user accounting start de Surfing- en Network Traffic-tellers opnieuw en wordt daarom niet als algemene aanmeldoplossing gebruikt.

Account deactiveren en netjes verwijderen

Wanneer iemand vertrekt of het doel van het account eindigt, wordt het account niet meteen zonder controle verwijderd:

  1. Afhankelijkheden in regels, groepen, Remote Access-policies, quota, MFA en documentatie controleren.
  2. Onder Authentication > Users de gebruiker selecteren en met Change status inactief maken.
  3. Een nieuwe aanmelding als negatieve test uitvoeren.
  4. Onder Current activities > Live users bestaande sessies controleren en een normale gebruiker zo nodig met Disconnect verbreken.
  5. Firewall- en VPN-logs op verdere pogingen of restverkeer controleren.
  6. Het account pas verwijderen nadat afhankelijkheden zijn opgehelderd, of volgens het bewaarbeleid inactief houden.

Behandel deactivering niet als garantie dat elke bestaande verbinding automatisch wordt beëindigd. Controleer sessies, tunnels en verkeer afzonderlijk. Voer na reactivering opnieuw de positieve en negatieve tests uit.

Gebruikers en groepen delen interne ID’s. Alleen een groot aantal objecten bewijst nog geen probleem. Als een gebruiker echter een User ID hoger dan 65535 toont en niet wordt geauthenticeerd, gebruik dan de afzonderlijke workflow voor de Sophos Firewall User ID-limiet, in plaats van op goed geluk wachtwoorden of regels te wijzigen.

Problemen per symptoom afbakenen

Gebruikersnaam en wachtwoord worden geweigerd

Controleer onder Authentication > Users of het account lokaal, actief en met de verwachte gebruikersnaam aanwezig is. Controleer daarna voor de concrete service onder Authentication > Services of Local is geselecteerd. Een geslaagde aanmelding bij een andere portal bewijst deze servicekeuze niet.

Aanmelden lukt, maar de gebruikersregel matcht niet

Controleer onder Current activities > Live users identiteit, bron-IP en Client Type. Controleer daarna regelpositie, Source Zone, gebruiker of groep en Firewall Rule ID in Log Viewer. Een netwerkregel boven de gebruikersregel kan de flow al hebben overgenomen.

Een groepswijziging heeft geen effect

Zoek bij de gebruiker naar specifieke waarden voor quota, Access Time, Traffic Shaping of Remote Access. Deze overrides hebben voorrang op de groep. Zet de waarde pas terug op groepsovererving nadat deze met de gedocumenteerde uitzondering is vergeleken.

Gebruiker kan zich vanaf een onverwachte bron aanmelden

Controleer Sign-in restriction bij zowel de gebruiker als de groep. Controleer daarnaast de daadwerkelijk gebruikte service, Device Access en de netwerkregel. Een instelling Any node wordt niet automatisch gecompenseerd door MFA of een beperkte firewallregel.

View usage blijft leeg

Controleer of de gebruiker als Live User wordt herkend en of het verkeer een gebruikersgebaseerde regel met Log firewall traffic raakt. Controleer vervolgens periode, quotatoewijzing en werkelijk testverkeer. Reset user accounting maakt geen ontbrekende logs en herstelt geen verkeerde regel.

Operationele checklist

  • Gebruiksscenario, eigenaar en vervaldatum van het account zijn gedocumenteerd.
  • Gebruikersnaam en gebruikerstype zijn vóór het opslaan bewust gekozen.
  • Een groep van het type Normal bevat de gezamenlijke basisinstellingen.
  • Gebruikersoverrides zijn vermeden of onderbouwd.
  • Simultaneous sign-ins en Sign-in restriction passen bij het gebruiksscenario.
  • Local is geselecteerd voor elke benodigde authenticatieservice.
  • Portal, firewallregel of VPN-policy is afzonderlijk geconfigureerd.
  • Positieve en negatieve aanmelding en werkelijk verkeer zijn gecontroleerd.
  • Live Users, Authentication Log en de verwachte regel of policy komen overeen.
  • MFA en herstel zijn getest als MFA wordt gebruikt.
  • Een verantwoordelijke beheert wachtwoordwijzigingen, gebruik en offboarding.
  • Deactivering, bestaande sessies en latere verwijdering zijn afzonderlijke stappen.

Veelgestelde vragen

Wanneer zijn lokale gebruikers beter geschikt dan Active Directory?

Lokale gebruikers passen bij enkele bewust beheerde accounts, pilottoegang of een gedocumenteerde fallback. Voor veel gebruikers, frequente rolwijzigingen of centrale offboarding is een directoryservice meestal eenvoudiger te onderhouden.

Is een groep voldoende om een lokale gebruiker internettoegang te geven?

Nee. De groep levert gezamenlijke gebruikerspolicies. Ook authenticatiemethode, portal of client, firewallregel of VPN-policy, route en retourpad moeten bij de geplande toegang passen.

Kan een lokale gebruiker het eigen wachtwoord wijzigen?

Ja. Een gebruiker in de lokale firewalldatabase kan het wachtwoord onder Personal > Change Password in User Portal wijzigen. User Portal moet veilig bereikbaar zijn; extern geauthenticeerde gebruikers wijzigen hun wachtwoord bij hun betreffende bron.