Lokale Benutzer auf der Sophos Firewall 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 und einzelne externe Mitarbeitende. Als Fallback für einen Verzeichnisdienst eignet sich ein lokales Konto nur, wenn Serverreihenfolge, abweichender Username, Portalzugang und das Verhalten beim Ausfall der externen Quelle mit diesem Dienst getestet wurden. Die SFOS-Hilfe dokumentiert die Reihenfolge der Server, aber keinen garantierten Wechsel für jeden Fehlerfall.

Dieser Artikel gilt für die WebAdmin-Oberfläche von SFOS 22. Ein Benutzer erhält nicht allein durch seine Erstellung Zugriff. Gruppe, Authentifizierungsmethode, Portal oder Client sowie Firewall- beziehungsweise VPN-Policy müssen zusammenpassen.

Kurzablauf:

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. Legen Sie Namensschema, Kontoart und Zuständigkeit deshalb vor dem Speichern fest. SFOS wandelt Grossbuchstaben im Username in Kleinbuchstaben um. Ein Ersatzkonto erhält eine neue Identität; prüfen Sie deshalb Regeln, Quoten, VPN-Zuweisungen und Auditspuren neu.

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 getesteten Fallback mit eigenem Username, wenn eine externe Benutzerquelle vorübergehend ausfällt.

Verwenden Sie ein lokales Konto nicht für mehrere Personen. 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

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 von 10.20.30.10 bis 10.20.30.50.

example.com ist eine reservierte Dokumentationsdomain; der Adressbereich liegt in einem privaten Beispielnetz. Ersetzen Sie Username, E-Mail-Adresse, Gruppe, Regel und Adressen durch Werte Ihrer Umgebung. Der funktionsneutrale Username enthält keine E-Mail-Adresse und bleibt deshalb auch bei einem Adresswechsel gültig. Das Namensschema sollte zu Helpdesk, Offboarding und vorhandenen Verzeichnisnamen passen.

Klären Sie vor dem Anlegen:

• 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

Erstellen Sie das Konto unter Authentication > Users > Add:

1. Bei Username pilotuser01 eintragen. SFOS speichert den Wert in Kleinbuchstaben; er lässt sich später nicht ändern.
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 beziehungsweise das Postfach dieser Person eintragen. Für ein technisches Konto wird eine überwachte, eindeutig verantwortete Adresse verwendet.
6. Bei Group Local_Pilot_Users auswählen.
7. Quarantine digest, Policy- und Remote-Access-Felder nur ändern, wenn die Funktion beziehungsweise eine dokumentierte Benutzer-Ausnahme benötigt wird.
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. Verwenden Sie für jedes Konto ein langes, individuelles Passwort aus Ihrem Passwortprozess. Ein kopierbares Beispielpasswort wäre sofort ein bekanntes Geheimnis und ist deshalb 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.

Für das Beispiel wählen Sie Node range und tragen 10.20.30.10 als Start- sowie 10.20.30.50 als Endadresse ein. Ersetzen Sie beide Werte durch den kleinsten zusammenhängenden Bereich, aus dem sich der Benutzer wirklich anmeldet. Benötigen Sie einzelne, nicht zusammenhängende IPv4-Adressen, verwenden Sie Selected nodes. Eine zu enge Auswahl blockiert legitime Anmeldungen; Any node ersetzt weder Firewall-Regel noch 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 abfragt. Aktivieren Sie unter Authentication > Services die Methode Local in der Liste des verwendeten Dienstes.

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.

Pro Authentifizierungsmethode können höchstens 20 Server ausgewählt werden. Für User Portal und VPN Portal lautet die Übernahmeoption Set authentication methods same as firewall. Bei SSL VPN zeigt SFOS je nach gewählter Referenz Same as VPN oder Same as firewall. Prüfen Sie diese Option und die dadurch wirksame Reihenfolge, bevor Sie Local hinzufügen oder verschieben.

Zugriff separat konfigurieren

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.

Remote-Access-Felder richtig einordnen

Bei Remote-Access-Verfahren ausser SSL VPN haben benutzerspezifische Policy-Werte Vorrang vor der Gruppe. Bei SSL VPN gilt eine andere Logik: Der Benutzer erhält die Ressourcen aller Full- und Split-Tunnel-Policies, in denen er selbst oder eine seiner unterstützten Gruppen enthalten ist. Das Feld SSL VPN policy ist deshalb kein einfacher Ersatz der Gruppen-Policies.

SSL VPN IP address erscheint nur, wenn unter SSL VPN global settings statische Adressen aktiviert sind. Die IPv4- beziehungsweise IPv6-Adresse muss frei sein und aus dem dort automatisch angelegten statischen Bereich stammen. Wenn ein RADIUS-Server Adressen vergibt, übernimmt er diese Zuweisung. IPsec remote access aktiviert dagegen den Zugriff mit Sophos Connect und kann eine eigene Lease-Adresse erhalten.

L2TP und PPTP sind Legacy-Verfahren. Nach einer Zuweisung muss sich der Benutzer zuerst am VPN Portal anmelden und ein Passwort erstellen, bevor die Verbindung möglich ist. Für L2TP bleiben die aktuelle Einordnung und der Migrationspfad unter L2TP Remote Access; PPTP wird für neue Zugänge nicht mehr eingeplant. Clientless SSL VPN policy öffnet nur die zugewiesenen Browser-Bookmarks und ist kein vollständiger Tunnel. Der getrennte Ablauf steht unter Clientless Access.

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 Local-Pilot-to-WAN beziehungsweise deren Firewall Rule ID als erwarteten Treffer 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.

Ist unklar, ob Benutzerstatus, Authentifizierungsmethode, Gruppe oder Zugriffsregel den Fehler verursacht, führt Sophos Firewall Authentifizierungsfehler systematisch beheben durch die Prüfkette. Für Detailanalysen enthält /log/access_server.log Authentication-, Authorization- und Accounting-Ereignisse; der Log Viewer bleibt der erste Schritt.

Passwort, MFA und Nutzung verwalten

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. Unter Personal > Personal Details kann der Benutzer zusätzlich seinen Anzeigenamen ändern. Username und E-Mail-Adresse bleiben dort schreibgeschützt und werden vom Administrator am Benutzerobjekt gepflegt. Das User Portal wird dafür nur aus den benötigten Zonen erreichbar gemacht und nicht allein wegen dieser Pflege 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. Aktivieren Sie MFA erst, nachdem der reguläre Login und der Recovery-Prozess getestet wurden.

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.

Änderung zurücknehmen und Konto entfernen

Dokumentieren Sie vor der Pilotphase die bestehende Reihenfolge unter Authentication > Services und alle geänderten Gruppen-, Portal-, Regel- und VPN-Einstellungen. So besteht der Rückweg nicht aus geschätzten Defaults. Beim Austritt, einem fehlgeschlagenen Pilot oder dem Ende des Einsatzzwecks gehen Sie in umgekehrter Reihenfolge vor:

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 Inactive 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. Benutzer aus Firewall-Regeln und Remote-Access-Policies entfernen oder durch die dokumentierte vorherige Auswahl ersetzen.
6. Geänderte Gruppen-, Portal- und Authentifizierungsdienste exakt auf den protokollierten Vorzustand zurücksetzen.
7. Firewall-, VPN- und Konfigurationslogs auf weitere Versuche, Restverkehr und die ausgeführten Änderungen prüfen.
8. Erst nach geklärten Abhängigkeiten das Konto löschen oder gemäss Aufbewahrungsprozess weiter inaktiv halten.

Die SFOS-Hilfe bestätigt nicht, dass eine Deaktivierung alle bestehenden Verbindungen beendet. Prüfen und trennen Sie Sessions und Tunnel daher separat. Bei einem späteren Reaktivieren folgen erneut Positiv- und Negativtest.

Vor einer riskanten Löschung lässt sich unter Backup and firmware > Import export das Konfigurationsobjekt User mit Include dependent entity exportieren. Dieser Export enthält sensible Daten einschliesslich Passwörtern und gehört verschlüsselt an einen zugriffsgeschützten Ort; auch der korrekte Secure Storage Master Key muss für einen späteren Import verfügbar sein. Ein Import aktualisiert die vorhandene Konfiguration und übernimmt bei Überschneidungen die importierten Werte. Mitexportierte gemeinsame Abhängigkeiten können deshalb ebenfalls überschrieben werden. Prüfen Sie Inhalt und Auswirkungen vor dem Import, möglichst in einer passenden Testumgebung.

Ein vollständiges Backup ist kein schneller Einzelbenutzer-Rollback: Ein Restore ersetzt die gesamte Konfiguration, startet die Firewall neu und verwirft spätere Änderungen. Den Ablauf erklärt Backup und Restore auf Sophos Firewall.

In einem HA-Verbund nehmen Sie die Änderung am Primary vor und prüfen danach den Synchronisationsstatus. Logs und Reports werden nicht zwischen den Knoten synchronisiert und müssen bei einer Diagnose getrennt betrachtet werden.

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

• Live users zeigt pilotuser01, die erwartete Quell-IP und den vorgesehenen Client Type.
• Das Authentication Log bestätigt die lokale Anmeldung; Local-Pilot-to-WAN beziehungsweise ihre Firewall Rule ID trifft den Testtraffic.
• Falsches Passwort, unerlaubte Quelle und nicht freigegebene Funktion liefern den erwarteten Negativnachweis.
• Benutzer-Overrides, Simultaneous sign-ins, Sign-in restriction und ein mögliches Ablaufdatum sind dokumentiert.
• MFA-Registrierung und Recovery-Prozess sind getestet, falls MFA verwendet wird.
• Vorzustand, Verantwortlichkeit, Deaktivierung, Session-Trennung und spätere Löschung sind dokumentiert.

Häufige Fragen