Sophos Firewall lokale Benutzer erstellen und verwalten

Ein lokaler Benutzer wird direkt auf der Sophos Firewall gespeichert und mit der lokalen Benutzerdatenbank authentifiziert. Das passt für kleine Umgebungen, Pilotkonten, einzelne externe Mitarbeitende oder einen bewusst gepflegten Fallback. Das Konto erhält aber nicht allein durch seine Erstellung Zugriff. Gruppe, Authentifizierungsmethode, Portal oder Client, Firewall- beziehungsweise VPN-Policy und die anschliessende Kontrolle müssen zusammenpassen.

Der sichere Kurzweg lautet:

1. Einsatzfall, Zielgruppe und benötigten Dienst festlegen.
2. Unter Authentication > Groups eine restriktive Gruppe vom Typ Normal vorbereiten.
3. Unter Authentication > Users > Add einen dauerhaften Username eintragen und User type: User wählen.
4. Ein individuelles starkes Passwort und die richtige Gruppe zuweisen.
5. Policy-Felder am Benutzer unverändert lassen, wenn die Gruppenwerte gelten sollen.
6. Simultaneous sign-ins und Sign-in restriction bewusst begrenzen.
7. Unter Authentication > Services prüfen, ob Local für den verwendeten Dienst ausgewählt ist.
8. Portal, Benutzerregel oder Remote-Access-Policy separat und möglichst eng konfigurieren.
9. Mit einem Pilotkonto einen positiven und einen negativen Login sowie den echten Traffic testen.
10. Erst danach MFA aktivieren, weitere Benutzer anlegen und Offboarding dokumentieren.

⚠️ Der Username kann später nicht geändert werden. Vor dem Speichern werden deshalb Namensschema, Kontoart und Zuständigkeit festgelegt. Ein neues Konto mit anderem Namen erzeugt eine neue Identität und kann Regeln, Quoten, VPN-Zuweisungen, Logs und Auditspuren auseinanderziehen.

Wann ein lokaler Benutzer passt

Lokale Benutzer benötigen kein Active Directory und keinen externen RADIUS- oder LDAP-Server. Das macht sie einfach, verlagert aber Passwortpflege, MFA, Gruppen, Deaktivierung und Review vollständig auf die Firewall. Für wenige bewusst verwaltete Konten ist das praktikabel. Bei vielen Mitarbeitenden oder häufigen Ein- und Austritten ist ein zentrales Verzeichnis meistens wartbarer.

Ein normaler lokaler Benutzer eignet sich beispielsweise für:

• ein Pilotkonto für Captive Portal, User Portal oder Remote Access;
• eine kleine Umgebung ohne Verzeichnisdienst;
• einen einzelnen externen Dienstleister mit klarer Laufzeit und Verantwortlichkeit;
• einen dokumentierten Fallback, wenn eine externe Benutzerquelle vorübergehend ausfällt.

Ein lokales Konto wird nicht als gemeinsamer Sammelbenutzer für mehrere Personen empfohlen. Geteilte Zugangsdaten erschweren Passwortwechsel, MFA, Quoten, Audit und sauberes Offboarding.

Benutzerarten nicht vermischen

SFOS führt mehrere ähnliche Benutzerarten, die unterschiedliche Aufgaben lösen:

• Ein normaler lokaler Benutzer meldet sich mit Username und Passwort an und erhält Policies über eine normale Gruppe oder bewusste Benutzer-Overrides.
• Ein Gastbenutzer ist zeitlich begrenzt, verwendet die Guest-User-Einstellungen und wird typischerweise über Captive Portal eingesetzt.
• Ein Clientless User wird über eine IP-Adresse erkannt und führt keine interaktive Anmeldung durch.
• Ein lokaler Administrator erhält User type: Administrator und ein Device-Access-Profil für WebAdmin-Rechte.
• Ein AD-, LDAP-, RADIUS- oder Entra-Benutzer wird von einer externen Quelle authentifiziert. Sein lokaler Datensatz entsteht je nach Methode erst beim ersten erfolgreichen Sign-in.

Für eine Person, die sich am Captive Portal oder an einem VPN-Dienst anmelden soll, wird User type: User verwendet. Dieses Konto erhält dadurch weder WebAdmin- noch SSH-Zugriff.

Beispiel und Voraussetzungen planen

Das folgende Beispiel verwendet:

• Username pilotuser01;
• Anzeigename Local Pilot User;
• E-Mail-Adresse pilotuser01@example.com;
• Gruppe Local_Pilot_Users;
• Firewall-Regel Local-Pilot-to-WAN;
• erlaubte Anmeldequelle 10.20.30.0/24.

example.com ist eine reservierte Dokumentationsdomain; 10.20.30.0/24 dient hier nur als privates Beispielnetz. Username, E-Mail-Adresse, Gruppe, Regel und Netz werden durch Werte der eigenen Umgebung ersetzt. Der Username ist bewusst funktionsneutral und enthält keine E-Mail-Adresse, damit ein späterer Mailwechsel die Anmeldeidentität nicht verändert. In einer produktiven Umgebung sollte das Namensschema zu Helpdesk, Offboarding und vorhandenen Verzeichnisnamen passen.

Vor dem Anlegen werden geklärt:

• Welcher Dienst authentifiziert den Benutzer: Captive Portal, User Portal, VPN Portal, SSL VPN, IPsec oder ein anderer unterstützter Zugang?
• Welche normale Gruppe trägt die gemeinsame Baseline?
• Welche Firewall- oder Remote-Access-Policy erlaubt den späteren Zugriff?
• Von welchen IPv4-Adressen darf sich das Konto anmelden?
• Wie viele gleichzeitige Anmeldungen sind fachlich nötig?
• Wird lokales MFA verlangt und über welches Portal erfolgt die Ersteinrichtung?
• Wer deaktiviert das Konto und prüft bestehende Sessions beim Austritt?

Die gemeinsame Gruppenlogik erklärt Benutzergruppen und Main Group auf Sophos Firewall. Für normale lokale Benutzer wird eine Gruppe vom Typ Normal verwendet. Eine Gruppe vom Typ Clientless gehört zum IP-basierten Modell und ist für diesen Login-Ablauf nicht die passende Baseline.

Lokalen Benutzer anlegen

Unter Authentication > Users > Add wird das Konto erstellt:

1. Bei Username pilotuser01 eintragen.
2. Bei Name Local Pilot User eintragen.
3. User type auf User setzen.
4. Ein langes, individuelles Passwort aus dem vorgesehenen Passwortprozess eintragen und bestätigen.
5. Bei Email pilotuser01@example.com oder die reale zuständige Adresse eintragen.
6. Bei Group Local_Pilot_Users auswählen.
7. Policy- und Remote-Access-Felder nur ändern, wenn eine dokumentierte Benutzer-Ausnahme beabsichtigt ist.
8. Simultaneous sign-ins und Sign-in restriction passend festlegen.
9. Mit Save speichern.

SFOS weist häufig verwendete Passwörter und Wörter aus seiner Wörterbuchprüfung zurück. Der Artikel zeigt bewusst kein Beispielpasswort. Ein kopierbares Passwort in einer Dokumentation würde sofort zum bekannten Geheimnis und wäre keine sichere Vorlage.

Gruppenwerte oder Benutzer-Overrides

Am Benutzer können Surfing quota, Access time, Network traffic und Traffic shaping sowie mehrere Remote-Access-Felder gesetzt werden. Benutzerspezifische Werte haben Vorrang vor Gruppenwerten. Soll die Gruppe die wartbare Baseline bleiben, werden diese Felder nicht vorsorglich überschrieben.

Ein Benutzer-Override passt für eine klar dokumentierte Ausnahme, beispielsweise eine engere Access Time während eines befristeten Einsatzes. Dabei wird festgehalten:

• welches Feld vom Gruppenwert abweicht;
• warum die Ausnahme nötig ist;
• wann sie geprüft oder entfernt wird;
• wie der ursprüngliche Gruppenwert wieder wirksam wird.

Access Time für Benutzer und Surfing beziehungsweise Network Traffic Quotas erklären die jeweilige Policy vollständig. Im Benutzerobjekt wird nur eine bereits verstandene Policy zugewiesen.

Anmeldeanzahl und Quelle begrenzen

Simultaneous sign-ins begrenzt parallele Sessions. Global setting übernimmt den für neue Benutzer geltenden Wert unter Authentication > Services. Alternativ kann ein eigener Wert oder Unlimited gewählt werden. Unbegrenzt ist für einen normalen persönlichen Benutzer selten nötig und erschwert die Erkennung geteilter Zugangsdaten.

Sign-in restriction beschränkt die IPv4-Adressen, von denen sich der Benutzer anmelden darf:

• Any node: Anmeldung von jeder erreichbaren Quelle;
• User group nodes: Gruppenwert übernehmen;
• Selected nodes: einzelne vorgesehene IPv4-Adressen;
• Node range: zusammenhängenden IPv4-Bereich erlauben.

Im Beispiel wird das tatsächliche Management-, Benutzer- oder VPN-Quellnetz verwendet, nicht blind 10.20.30.0/24. Eine zu enge Auswahl blockiert legitime Anmeldungen; Any node erweitert dagegen nur die mögliche Loginquelle und ersetzt keine Firewall-Regel, Portal-ACL oder MFA.

MAC binding wird für diesen Basisablauf nicht aktiviert. Es unterstützt clientbasierte Authentifizierung, aber nicht Remote Access VPN oder Captive Portal. Wenn es ohne MAC-Adresse eingeschaltet wird, bindet SFOS beim ersten Sign-in automatisch die zuerst erkannte MAC-Adresse. Das ist für mobile Geräte, WLAN-Wechsel oder gemeinsam genutzte Clients schnell eine unerwartete Abhängigkeit.

Authentifizierungsmethode und Zugriff anschliessen

Ein gespeicherter Benutzer kann sich nur an einem Dienst anmelden, der die lokale Datenbank tatsächlich abfragt. Unter Authentication > Services wird deshalb beim vorgesehenen Dienst Local ausgewählt.

Die Bereiche sind getrennt:

• Firewall authentication methods für Firewall-Traffic und Captive Portal;
• User portal authentication methods für das User Portal;
• VPN portal authentication methods für das VPN Portal;
• VPN (IPsec/dial-in/L2TP/PPTP) authentication methods für diese VPN-Verfahren;
• SSL VPN authentication methods für Remote Access SSL VPN.

Mehrere Quellen werden in der angezeigten Reihenfolge abgefragt. Ein erfolgreicher Test am User Portal beweist deshalb nicht automatisch, dass derselbe Benutzer auch für SSL VPN oder IPsec korrekt konfiguriert ist.

Portal, Regel oder VPN-Policy bleibt separat

Die lokale Identität öffnet keinen Netzwerkpfad. Für Captive Portal werden zusätzlich Device Access, Web Authentication und eine passende Benutzerregel benötigt. Den vollständigen Ablauf zeigt Sophos Firewall Captive Portal einrichten und testen.

User Portal und VPN Portal sind ebenfalls getrennte Dienste. Das Portal-Modell der Sophos Firewall erklärt Ports, Zweck, Device Access und WAN-Grenzen. Remote-Access-Policies werden in den jeweiligen VPN-Anleitungen gepflegt und nicht allein am Benutzerobjekt als fertig betrachtet.

Für eine benutzerbasierte Firewall-Regel werden Quelle, Ziel, Dienst und Benutzer beziehungsweise Gruppe möglichst eng gesetzt. Log firewall traffic bleibt während der Abnahme aktiv. Die Regelgrundlagen stehen unter Sophos Firewall-Regeln verstehen und sicher konfigurieren.

Mit Positiv- und Negativtest abnehmen

Ein sichtbares Konto und der Status Active sind noch kein Erfolgsnachweis. Der Pilot wird über genau den später verwendeten Dienst getestet:

1. In einem privaten Browserfenster oder einem sauberen Testclient mit pilotuser01 anmelden.
2. Unter Current activities > Live users Username, Quell-IP und Client Type prüfen.
3. Im Log Viewer > Authentication erfolgreichen Login, lokale Authentifizierung und Zeitpunkt kontrollieren.
4. Den vorgesehenen Traffic erzeugen und im Firewall- oder VPN-Log die erwartete Regel beziehungsweise Policy prüfen.
5. Eine ausdrücklich nicht erlaubte Quelle oder Funktion als Negativtest verwenden.
6. Falls Quota oder Access Time aktiv ist, diese Wirkung separat innerhalb und ausserhalb der Grenze testen.
7. Ergebnis, verwendete Gruppe, Benutzer-Overrides und Authentifizierungsmethode dokumentieren.

Ein negativer Login darf nicht nur wegen eines absichtlich falschen Passworts scheitern. Zusätzlich wird geprüft, dass eine nicht erlaubte Quelle, ein Benutzer ohne passende Gruppe oder eine nicht vorgesehene Funktion wirklich keinen Zugriff erhält. So trennt man Passwortprüfung von Policy- und Regelwirkung.

Wenn schon unklar ist, ob lokale Datenbank, Dienstwahl, Benutzerstatus, Gruppe oder erst die spätere Regel scheitert, führt Sophos Firewall Authentifizierungsfehler systematisch beheben durch die vollständige Prüfkette. Für die tiefe Analyse enthält /log/access_server.log Authentication-, Authorization- und Accounting-Ereignisse; der Log Viewer bleibt der erste Schritt.

Passwort, MFA und Nutzung betreiben

Ein lokaler Benutzer kann sein Passwort im User Portal > Personal > Change Password selbst ändern. Das gilt für die lokale Datenbank, nicht für extern authentifizierte AD-, LDAP- oder RADIUS-Konten. Das User Portal wird dafür nur aus den benötigten Zonen erreichbar gemacht und nicht allein wegen Passwortpflege pauschal ins WAN geöffnet.

Für zusätzliche Absicherung kann das Konto unter Authentication > Multi-factor authentication ausgewählt werden. Mit Generate OTP token with next sign-in registriert der Benutzer den Token über User Portal oder VPN Portal. Hashalgorithmus, Portalzugriff, Recovery und Pilotierung erklärt MFA für Sophos Firewall. MFA wird erst aktiviert, wenn der normale Login und der Rückweg funktionieren.

Unter Authentication > Users > > View usage sieht man zugewiesene Quoten, Surfing-Zeit und Datenverbrauch. Dafür muss der Traffic eine benutzerbasierte Firewall-Regel mit Log firewall traffic treffen. Reset user accounting startet die Surfing- und Network-Traffic-Zählung neu und wird deshalb nicht als allgemeiner Login-Fix verwendet.

Konto deaktivieren und sauber entfernen

Beim Austritt oder Ende des Einsatzzwecks wird das Konto nicht sofort blind gelöscht:

1. Abhängigkeiten in Regeln, Gruppen, Remote-Access-Policies, Quoten, MFA und Dokumentation prüfen.
2. Unter Authentication > Users den Benutzer auswählen und Change status auf inaktiv setzen.
3. Eine neue Anmeldung als Negativtest durchführen.
4. Unter Current activities > Live users bestehende Sessions prüfen und einen normalen Benutzer bei Bedarf mit Disconnect trennen.
5. Firewall- und VPN-Logs auf weitere Versuche oder Restverkehr prüfen.
6. Erst nach geklärten Abhängigkeiten das Konto löschen oder gemäss Aufbewahrungsprozess weiter inaktiv halten.

Die Deaktivierung wird nicht als garantierte automatische Beendigung jeder bestehenden Verbindung behandelt. Session, Tunnel und Traffic werden separat geprüft. Bei einem späteren Reaktivieren folgen erneut Positiv- und Negativtest.

Benutzer und Gruppen teilen sich interne IDs. Eine hohe Objektzahl allein beweist noch kein Problem. Zeigt ein Benutzer jedoch eine User ID über 65535 und wird nicht authentifiziert, verwendet man den separaten Ablauf zum Sophos Firewall User-ID-Limit, statt Passwörter oder Regeln auf Verdacht zu ändern.

Fehler nach Symptom eingrenzen

Benutzername und Passwort werden abgelehnt

Unter Authentication > Users prüfen, ob das Konto lokal, aktiv und mit dem erwarteten Username vorhanden ist. Danach beim konkreten Dienst unter Authentication > Services kontrollieren, ob Local ausgewählt ist. Ein erfolgreicher Login an einem anderen Portal beweist diese Dienstwahl nicht.

Login klappt, aber die Benutzerregel greift nicht

Unter Current activities > Live users Identität, Quell-IP und Client Type prüfen. Danach Regelposition, Source Zone, Benutzer beziehungsweise Gruppe und Firewall Rule ID im Log Viewer kontrollieren. Eine Netzwerkregel oberhalb der Benutzerregel kann den Flow bereits übernehmen.

Gruppenänderung wirkt nicht

Am Benutzer nach benutzerspezifischen Werten für Quota, Access Time, Traffic Shaping oder Remote Access suchen. Diese Overrides haben Vorrang vor der Gruppe. Der Wert wird erst nach Vergleich mit der dokumentierten Ausnahme zurück auf Gruppenvererbung gesetzt.

Benutzer kann sich von einer unerwarteten Quelle anmelden

Sign-in restriction am Benutzer und in der Gruppe prüfen. Zusätzlich den tatsächlich verwendeten Dienst, Device Access und die Netzwerkregel kontrollieren. Eine Beschränkung auf Any node wird nicht durch MFA oder eine enge Firewall-Regel automatisch ersetzt.

View usage bleibt leer

Prüfen, ob der Benutzer als Live User erkannt wird und der Traffic eine benutzerbasierte Regel mit Log firewall traffic trifft. Danach Zeitraum, Quota-Zuweisung und tatsächlichen Testtraffic kontrollieren. Reset user accounting erzeugt keine fehlenden Logs und repariert keine falsche Regel.

Betriebscheckliste

• Einsatzfall, Eigentümer und Ablaufdatum des Kontos sind dokumentiert.
• Username und Benutzerart wurden vor dem Speichern bewusst gewählt.
• Gruppe vom Typ Normal trägt die gemeinsame Baseline.
• Benutzer-Overrides sind vermieden oder begründet.
• Simultaneous sign-ins und Sign-in restriction passen zum Einsatzfall.
• Local ist für jeden benötigten Authentifizierungsdienst ausgewählt.
• Portal, Firewall-Regel oder VPN-Policy wurde separat konfiguriert.
• Positiver und negativer Login sowie echter Traffic wurden geprüft.
• Live Users, Authentication Log und erwartete Regel beziehungsweise Policy stimmen überein.
• MFA und Recovery sind getestet, falls MFA verwendet wird.
• Passwortwechsel, Usage und Offboarding haben eine zuständige Person.
• Deaktivierung, bestehende Sessions und spätere Löschung sind getrennte Schritte.

Häufige Fragen