Tworzenie i zarządzanie lokalnymi użytkownikami Sophos Firewall

Użytkownik lokalny jest przechowywany bezpośrednio na Sophos Firewall i uwierzytelniany w lokalnej bazie użytkowników. Takie rozwiązanie sprawdza się w małych środowiskach, na kontach pilotażowych i w przypadku pojedynczych współpracowników zewnętrznych. Konto lokalne może służyć jako rozwiązanie awaryjne dla usługi katalogowej tylko wtedy, gdy dla danej usługi przetestowano kolejność serwerów, odrębną nazwę użytkownika, dostęp do portalu oraz zachowanie po awarii źródła zewnętrznego. Pomoc SFOS opisuje kolejność serwerów, ale nie gwarantuje przełączenia awaryjnego dla każdego rodzaju błędu.

Niniejszy artykuł dotyczy interfejsu WebAdmin w SFOS 22. Samo utworzenie użytkownika nie zapewnia dostępu. Grupa, metoda uwierzytelniania, portal lub klient oraz reguła firewalla albo zasada VPN muszą być ze sobą zgodne.

Skrócona procedura:

1. Określić przypadek użycia, grupę docelową i potrzebną usługę.
2. W Authentication > Groups przygotować restrykcyjną grupę typu Normal.
3. W Authentication > Users > Add wprowadzić trwałą nazwę użytkownika i wybrać User type: User.
4. Przypisać indywidualne silne hasło oraz właściwą grupę.
5. Pozostawić pola zasad użytkownika bez zmian, jeśli mają obowiązywać wartości grupy.
6. Świadomie ograniczyć Simultaneous sign-ins i Sign-in restriction.
7. W Authentication > Services sprawdzić, czy dla używanej usługi wybrano Local.
8. Oddzielnie i możliwie wąsko skonfigurować portal, regułę użytkownika lub zasadę Remote Access.
9. Przy użyciu konta pilotażowego przetestować poprawne i odrzucone logowanie oraz rzeczywisty ruch.
10. Dopiero potem włączyć MFA, utworzyć kolejnych użytkowników i udokumentować offboarding.

⚠️ Nazwy użytkownika nie można później zmienić. Przed zapisaniem określ schemat nazw, typ konta i osobę odpowiedzialną. SFOS zamienia wielkie litery w nazwie użytkownika na małe. Konto zastępcze ma nową tożsamość, dlatego ponownie sprawdź reguły, limity, przypisania VPN i ślady audytowe.

Kiedy lokalny użytkownik jest odpowiedni

Lokalni użytkownicy nie wymagają Active Directory ani zewnętrznego serwera RADIUS lub LDAP. Upraszcza to wdrożenie, ale przenosi całe zarządzanie hasłami, MFA, grupami, dezaktywacją i okresowymi przeglądami na administratora firewalla. Jest to praktyczne w przypadku kilku starannie zarządzanych kont. Przy wielu pracownikach lub częstych zmianach zatrudnienia centralny katalog jest zazwyczaj łatwiejszy w utrzymaniu.

Zwykłe lokalne konto użytkownika nadaje się na przykład jako:

• konto pilotażowe dla Captive Portal, User Portal lub Remote Access;
• konto w małym środowisku bez usługi katalogowej;
• konto pojedynczego zewnętrznego usługodawcy z jasno określonym okresem obowiązywania i właścicielem;
• przetestowane konto awaryjne z własną nazwą użytkownika na wypadek tymczasowej niedostępności zewnętrznego źródła użytkowników.

Nie należy używać jednego konta lokalnego dla kilku osób. Współdzielone dane logowania utrudniają zmianę haseł, stosowanie MFA i limitów, prowadzenie audytu oraz prawidłową obsługę odejścia użytkownika.

Nie mieszać typów użytkowników

SFOS udostępnia kilka podobnych typów użytkowników, które rozwiązują różne zadania:

• Zwykły lokalny użytkownik loguje się przy użyciu nazwy użytkownika i hasła oraz otrzymuje zasady za pośrednictwem zwykłej grupy lub celowo ustawionych wyjątków dla użytkownika.
• Użytkownik gościnny ma ograniczony czas ważności, korzysta z ustawień Guest User i zwykle jest używany przez Captive Portal.
• Clientless User jest rozpoznawany na podstawie adresu IP i nie wykonuje interaktywnego logowania.
• Lokalny administrator otrzymuje User type: Administrator oraz profil Device Access z uprawnieniami WebAdmin.
• Użytkownik AD, LDAP, RADIUS lub Entra jest uwierzytelniany przez zewnętrzne źródło. W zależności od metody jego lokalny rekord powstaje dopiero przy pierwszym udanym logowaniu.

Dla osoby, która ma logować się do Captive Portal lub usługi VPN, stosuje się User type: User. Nie daje to kontu dostępu do WebAdmin ani SSH.

Przykład i warunki wstępne

Poniższy przykład wykorzystuje:

• nazwę użytkownika pilotuser01;
• nazwę wyświetlaną Local Pilot User;
• adres e-mail pilotuser01@example.com;
• grupę Local_Pilot_Users;
• regułę firewalla Local-Pilot-to-WAN;
• dozwolone źródło logowania od 10.20.30.10 do 10.20.30.50.

example.com jest domeną zastrzeżoną do celów dokumentacyjnych, a zakres adresów należy do prywatnej sieci przykładowej. Zastąp nazwę użytkownika, adres e-mail, grupę, regułę i adresy wartościami ze swojego środowiska. Nazwa użytkownika nie jest oparta na adresie e-mail, dlatego pozostaje aktualna po zmianie tego adresu. Schemat nazewnictwa powinien być zgodny z zasadami helpdesku, procesem offboardingu i istniejącymi nazwami w usłudze katalogowej.

Przed utworzeniem konta należy wyjaśnić:

• Która usługa uwierzytelnia użytkownika: Captive Portal, User Portal, VPN Portal, SSL VPN, IPsec czy inny obsługiwany dostęp?
• Która zwykła grupa zawiera wspólną konfigurację bazową?
• Która zasada firewalla lub Remote Access zezwala na późniejszy dostęp?
• Z jakich adresów IPv4 konto może się logować?
• Ile równoczesnych logowań jest rzeczywiście potrzebnych?
• Czy wymagane jest lokalne MFA i przez który portal odbywa się pierwsza rejestracja?
• Kto dezaktywuje konto i sprawdza istniejące sesje podczas offboardingu?

Zarządzanie grupami użytkowników i Main Group na Sophos Firewall wyjaśnia wspólną logikę grup. Dla zwykłych lokalnych użytkowników stosuje się grupę typu Normal. Grupa typu Clientless należy do modelu opartego na adresie IP i nie jest właściwą bazą dla tego procesu logowania.

Tworzenie lokalnego użytkownika

Konto tworzy się w Authentication > Users > Add:

1. W polu Username wpisz pilotuser01. SFOS zapisuje wartość małymi literami; nazwy użytkownika nie można później zmienić.
2. W polu Name wprowadzić Local Pilot User.
3. Ustawić User type na User.
4. Wprowadzić i potwierdzić długie, indywidualne hasło zgodne z przyjętym procesem haseł.
5. W polu Email wpisz pilotuser01@example.com lub adres skrzynki pocztowej tej osoby. W przypadku konta technicznego użyj monitorowanego adresu z jasno określonym właścicielem.
6. W polu Group wybrać Local_Pilot_Users.
7. Pola Quarantine digest, zasad i Remote Access należy zmieniać tylko wtedy, gdy wymaga tego dana funkcja lub udokumentowany wyjątek dla użytkownika.
8. Odpowiednio ustawić Simultaneous sign-ins i Sign-in restriction.
9. Zapisać przez Save.

SFOS odrzuca często używane hasła i słowa wykryte przez mechanizm kontroli słownikowej. Dla każdego konta należy użyć długiego, unikatowego hasła wygenerowanego zgodnie z przyjętą procedurą zarządzania hasłami. Hasło podane jako przykład do skopiowania natychmiast stałoby się znanym sekretem, dlatego nie jest bezpiecznym wzorcem.

Ten sam widok użytkowników pokazuje również rekordy użytkowników uwierzytelnianych zewnętrznie. W przypadku użytkowników importowanych z Active Directory firewall podczas uwierzytelniania nadpisuje lokalnie wprowadzoną wartość Email adresem z AD. Lokalna poprawka nie jest więc trwała; administrator odpowiedzialny za AD musi poprawić wartość w źródle.

W przypadku użytkowników AD należących do wielu grup pole Group pokazuje Main Group, a Other group memberships — pozostałe grupy AD. Pole Other group memberships jest wyszarzone i nie można go edytować lokalnie w przypadku użytkowników synchronizowanych przez zewnętrzny serwer uwierzytelniania, taki jak AD lub RADIUS. Członkostwa należy sprawdzać i zmieniać w odpowiednim źródle, a nie obchodzić za pomocą zastępczej grupy lokalnej. Artykuł o grupach, do którego odnośnik znajduje się powyżej, wyjaśnia, które funkcje uwzględniają dodatkowe grupy AD; obsługa ta nie obejmuje automatycznie RADIUS.

Wartości grupy lub nadpisania użytkownika

W rekordzie użytkownika można ustawić Surfing quota, Access time, Network traffic i Traffic shaping, a także kilka pól Remote Access. Instrukcje producenta opisują pierwszeństwo różnie: instrukcja tworzenia użytkownika wskazuje ogólnie wartości użytkownika, a przegląd użytkowników uwzględnia wybór użytkownika i grupy w regułach i politykach. Kontrola nadpisania użytkownika i wyboru w regule opisuje to ograniczenie; nie należy zakładać, że odrębna polityka użytkownika działa bezwarunkowo. Jeśli grupa ma pozostać łatwą w utrzymaniu konfiguracją bazową, tych pól nie należy nadpisywać zapobiegawczo.

Nadpisanie wartości dla użytkownika jest właściwe w przypadku jasno udokumentowanego wyjątku, na przykład bardziej restrykcyjnego Access Time podczas czasowego zlecenia. Należy zapisać:

• które pole różni się od wartości grupy;
• dlaczego wyjątek jest potrzebny;
• kiedy zostanie sprawdzony lub usunięty;
• jak ponownie zacznie obowiązywać pierwotna wartość grupy.

Access Time dla użytkowników oraz limity Surfing i Network Traffic szczegółowo wyjaśniają poszczególne zasady. W obiekcie użytkownika należy przypisywać tylko zasady, których działanie jest już znane.

Ograniczyć liczbę i źródło logowań

Simultaneous sign-ins ogranicza równoczesne sesje. Global setting przejmuje wartość obowiązującą dla nowych użytkowników z Authentication > Services. Alternatywnie można ustawić własną wartość lub wybrać Unlimited. Nieograniczone sesje są rzadko potrzebne zwykłemu indywidualnemu użytkownikowi i utrudniają wykrycie współdzielonych danych logowania.

Sign-in restriction ogranicza adresy IPv4, z których użytkownik może się logować:

• Any node: zezwolić na logowanie z każdego osiągalnego źródła;
• User group nodes: przejąć wartość grupy;
• Selected nodes: podać pojedyncze przewidziane adresy IPv4;
• Node range: zezwolić na logowanie z ciągłego zakresu adresów IPv4.

W tym przykładzie wybierz Node range i wprowadź 10.20.30.10 jako adres początkowy oraz 10.20.30.50 jako adres końcowy. Zastąp obie wartości najmniejszym ciągłym zakresem, z którego użytkownik rzeczywiście się loguje. Jeśli potrzebne są pojedyncze, niekolejne adresy IPv4, użyj Selected nodes. Zbyt wąski zakres zablokuje prawidłowe logowania; Any node nie zastępuje reguły firewalla, listy ACL portalu ani MFA.

W tym podstawowym procesie nie należy włączać MAC binding. Obsługuje ono uwierzytelnianie oparte na kliencie, ale nie Remote Access VPN ani Captive Portal. Jeśli zostanie włączone bez adresu MAC, SFOS automatycznie powiąże pierwszy wykryty adres MAC przy pierwszym logowaniu. Na urządzeniach mobilnych, po zmianie Wi-Fi lub przy współdzielonych klientach może to szybko stać się nieoczekiwaną zależnością.

XML-API: rozdzielenie ograniczeń użytkowników i administratorów

W przypadku automatyzacji dokumentacja referencyjna XML-API dla SFOS 22 i 23 rozróżnia te same obszary podczas dodawania i aktualizowania User. Poniższe ścieżki wskazują odpowiednie miejsca w dokumentacji; nie stanowią kompletnego żądania gotowego do wykonania:

• Typ konta i uprawnienia: User/UserType dopuszcza User lub Administrator; tabela parametrów podaje User jako wartość domyślną i oznacza pole jako opcjonalne. User/Profile jest w niej oznaczone jako Mandatory: Yes, ale zgodnie z wyraźną uwagą dotyczy tylko Administrator. Nie oznacza to obowiązku przypisania profilu zwykłym użytkownikom. W przypadku administratorów nadal wymagany jest celowo restrykcyjny profil Device Access.
• Źródło logowania zwykłego użytkownika: Przykład podaje dla User/LoginRestriction wartości AnyNode, UserGroupNode, SelectedNodes i NodeRange. W przypadku SelectedNodes adresy IPv4 znajdują się pod User/NodeList/IPAddress; w przypadku NodeRange granice wyznaczają User/FromIP i User/ToIP. Ich oznaczenie w tabeli jako Mandatory: Yes jest wyraźnie uzależnione od wybrania zakresu. Nie oznacza ono, że te pola są wymagane dla każdego typu ograniczenia.
• Źródło logowania administratora: User/LoginRestrictionForAppliance dotyczy logowania administratora do urządzenia, a nie logowania zwykłego użytkownika. Tabela dopuszcza AnyNode, SelectedNodes i NodeRange oraz podaje AnyNode jako wartość domyślną. Zgodnie z przykładem pojedyncze adresy IPv4 należy umieszczać pod User/AdminAccessNodeList/IPAddress, a granice zakresu pod User/AdminAccessFromIP i User/AdminAccessToIP. Pól administratora nie wolno zamieniać z polami zwykłego użytkownika; oznaczenia Yes w tabeli nie wolno interpretować jako ogólnego wymogu niezależnie od typu konta i wybranego ograniczenia. Udokumentowana wartość domyślna nie jest zaleceniem nieograniczonego dostępu administratora.
• Czas dostępu administratora: User/ScheduleForApplianceAccess wybiera harmonogram dostępu do urządzenia i zgodnie z uwagą w tabeli dotyczy tylko administratorów. Przykład pokazuje All The Time, ale kolumna wartości domyślnej pozostaje pusta. Wartość z przykładu nie jest więc potwierdzoną wartością domyślną, a to pole nie zastępuje zasady Access Time zwykłego użytkownika.
• Statyczne adresy SSL VPN: User/SSLVPNIPv4Address i User/SSLVPNIPv6Address są opcjonalne. Oba odwołują się do zarezerwowanego zakresu adresów statycznych w SSL VPN global settings, a nie do dowolnych adresów LAN. Opisane poniżej włączenie tej funkcji i wybór wolnego adresu z odpowiedniego zakresu IPv4 lub IPv6 dotyczą również tego przypisania.

⚠️ Przykład XML zawiera dla LoginRestrictionForAppliance uciętą wartość AnyNode/. Nie jest ona ani pełną listą wartości, ani wzorcem do skopiowania; tabela podaje trzy wartości wymienione powyżej. Jeśli dokumentacja referencyjna używanej wersji, istniejący eksport i planowane przypisanie różnią się od siebie, należy zatrzymać się przed zapisem i wyjaśnić typ konta, pole oraz dopuszczalną wartość na podstawie właściwej dokumentacji referencyjnej lub z pomocą Sophos Support. Nie należy uzupełniać uciętej wartości na chybił trafił ani łagodzić ograniczeń dostępu, aby żądanie zostało przyjęte.

Powiązanie metody uwierzytelniania z dostępem

Zapisany użytkownik może zalogować się tylko do usługi korzystającej z lokalnej bazy danych. W Authentication > Services włącz metodę Local na liście używanej przez daną usługę.

Obszary są rozdzielone:

• Firewall authentication methods dla ruchu firewalla i Captive Portal;
• User portal authentication methods dla User Portal;
• VPN portal authentication methods dla VPN Portal;
• VPN (IPsec/dial-in/L2TP/PPTP) authentication methods dla tych metod VPN;
• SSL VPN authentication methods dla Remote Access SSL VPN.

Wiele źródeł jest odpytywanych w wyświetlonej kolejności. Udana próba w User Portal nie dowodzi więc automatycznie, że ten sam użytkownik jest prawidłowo skonfigurowany dla SSL VPN lub IPsec.

Dla każdej metody uwierzytelniania można wybrać maksymalnie 20 serwerów. W przypadku User Portal i VPN Portal opcja dziedziczenia to Set authentication methods same as firewall. Dla SSL VPN system SFOS wyświetla Same as VPN lub Same as firewall, zależnie od wybranego odwołania. Przed dodaniem lub przeniesieniem metody Local sprawdź tę opcję i wynikającą z niej kolejność.

Oddzielna konfiguracja dostępu

Lokalna tożsamość nie otwiera ścieżki sieciowej. Captive Portal wymaga dodatkowo Device Access, Web Authentication i odpowiedniej reguły użytkownika. Pełny proces opisano w artykule Konfiguracja i testowanie Captive Portal na Sophos Firewall.

User Portal i VPN Portal również są oddzielnymi usługami. Model portali Sophos Firewall wyjaśnia porty, przeznaczenie, Device Access i ograniczenia dotyczące WAN. Zasady Remote Access konfiguruje się zgodnie z odpowiednimi instrukcjami VPN; samo ustawienie pola w obiekcie użytkownika nie oznacza jeszcze ukończenia konfiguracji.

Prawidłowa interpretacja pól Remote Access

Dla metod Remote Access innych niż SSL VPN wartości zasad ustawione bezpośrednio dla użytkownika mają pierwszeństwo przed grupą. SSL VPN działa inaczej: Użytkownik otrzymuje zasoby ze wszystkich zasad Full i Split Tunnel, które obejmują bezpośrednio użytkownika lub jedną z jego obsługiwanych grup. Pole SSL VPN policy nie zastępuje więc w prosty sposób zasad grupowych.

Dwa dodatkowe pola grup są widoczne tylko pod określonymi warunkami:

• Group SSL VPN policies pokazuje zasady Remote Access SSL VPN przypisane do grup tylko wtedy, gdy użytkownik należy do wielu grup AD i co najmniej dwie z tych grup są uwzględnione w zasadach Remote Access SSL VPN.
• Group clientless SSL VPN policies pokazuje zasady Clientless SSL VPN przypisane do grup tylko wtedy, gdy użytkownik należy do wielu grup AD i co najmniej dwie z tych grup są uwzględnione w zasadach Clientless SSL VPN.

Jeśli brakuje któregoś z tych pól, należy najpierw sprawdzić oba warunki dla tego konkretnego typu VPN. Wyświetlane pole nie jest osobnym przełącznikiem zezwalającym na dostęp; zasoby, zakładki, testy odbiorcze i wycofanie konfiguracji są nadal opisane w odpowiednich instrukcjach VPN.

SSL VPN IP address pojawia się tylko wtedy, gdy w SSL VPN global settings włączono adresy statyczne. Adres IPv4 lub IPv6 musi być wolny i pochodzić z automatycznie utworzonego tam zakresu statycznego. Jeśli adresy dzierżawi serwer RADIUS, to on wykonuje przypisanie. IPsec remote access włącza natomiast dostęp przez Sophos Connect i może otrzymać własny adres dzierżawy.

L2TP i PPTP są przestarzałymi metodami. Każde z tych pól w obiekcie użytkownika zezwala na odpowiedni typ Remote Access i umożliwia osobne wprowadzenie adresu IP, który ma zostać wydzierżawiony użytkownikowi zdalnemu. Jest to przypisanie dzierżawy do konkretnego użytkownika, a nie pełna konfiguracja tunelu ani powód do uruchomienia nowego dostępu opartego na przestarzałej metodzie. Po przypisaniu użytkownik musi najpierw zalogować się do VPN Portal i utworzyć hasło, zanim będzie mógł nawiązać połączenie. Aktualną ocenę L2TP i ścieżkę migracji opisano w artykule L2TP Remote Access; PPTP nie należy już planować dla nowych dostępów. Clientless SSL VPN policy otwiera wyłącznie przypisane zakładki przeglądarki i nie zapewnia pełnego tunelu. Oddzielną procedurę opisano w artykule Clientless Access.

W regule firewalla opartej na użytkowniku należy możliwie precyzyjnie określić źródło, cel, usługę oraz użytkownika lub grupę. Podczas testów odbiorczych należy pozostawić włączoną opcję Log firewall traffic. Podstawy reguł opisano w Zrozumienie i bezpieczna konfiguracja reguł Sophos Firewall.

Weryfikacja za pomocą testów pozytywnych i negatywnych

Widoczne konto ze statusem Active nie jest jeszcze dowodem sukcesu. Konto pilotażowe należy przetestować przez dokładnie tę usługę, która będzie używana później:

1. Zalogować się jako pilotuser01 w prywatnym oknie przeglądarki lub z czystego klienta testowego.
2. W Current activities > Live users sprawdzić nazwę użytkownika, źródłowy adres IP i Client Type.
3. W Log Viewer > Authentication sprawdzić udane logowanie, lokalne uwierzytelnienie i czas.
4. Wygenerować planowany ruch i sprawdzić w dzienniku firewalla lub VPN, czy zgodnie z oczekiwaniami został dopasowany do reguły Local-Pilot-to-WAN albo jej Firewall Rule ID.
5. Jako test negatywny wykorzystać źródło lub funkcję, które jawnie nie są dozwolone.
6. Jeśli aktywny jest limit lub Access Time, oddzielnie przetestować działanie wewnątrz i poza ograniczeniem.
7. Udokumentować wynik, używaną grupę, nadpisania użytkownika i metodę uwierzytelniania.

Negatywny test logowania nie powinien kończyć się niepowodzeniem wyłącznie dlatego, że celowo użyto błędnego hasła. Należy też sprawdzić, czy niedozwolone źródło, użytkownik bez odpowiedniej grupy lub nieprzewidziana funkcja rzeczywiście nie uzyskują dostępu. Pozwala to oddzielić kontrolę hasła od działania zasad i reguł.

Jeżeli nie jest jasne, czy błąd powoduje status użytkownika, metoda uwierzytelniania, grupa czy reguła dostępu, artykuł Systematyczne rozwiązywanie problemów z uwierzytelnianiem na Sophos Firewall przedstawia właściwą kolejność kontroli. Do szczegółowej analizy można użyć pliku /log/access_server.log, który zawiera zdarzenia uwierzytelniania, autoryzacji i rozliczania; pierwszym krokiem powinien jednak pozostać Log Viewer.

Zarządzanie hasłami, MFA i wykorzystaniem

Aby jako administrator zmienić hasło istniejącego konta lokalnego w SFOS 22 i 23, należy otworzyć odpowiedniego użytkownika w Authentication > Users i kliknąć Change password. Najpierw sprawdza się konto i osobę za nie odpowiedzialną oraz przygotowuje nowe, długie i unikatowe hasło zgodnie z zatwierdzoną procedurą zarządzania hasłami. Następnie wprowadza się nowe hasło, zapisuje zmianę i bezpiecznie przekazuje hasło uprawnionej osobie. Potem sprawdza się nowe logowanie z nowym hasłem do rzeczywiście używanej usługi. Ta operacja w WebAdmin różni się od samodzielnej zmiany hasła w User Portal; konta uwierzytelniane zewnętrznie nadal są zarządzane w odpowiednim źródle użytkowników. Nie gwarantuje to automatycznego zakończenia istniejących sesji.

Lokalny użytkownik może samodzielnie zmienić hasło w User Portal > Personal > Change Password. Dotyczy to lokalnej bazy danych, a nie zewnętrznie uwierzytelnianych kont AD, LDAP czy RADIUS. W Personal > Personal Details użytkownik może również zmienić nazwę wyświetlaną. Nazwa użytkownika i adres e-mail pozostają tam tylko do odczytu. Administrator zarządza adresem e-mail w obiekcie użytkownika; nazwa użytkownika również tam pozostaje niezmienna. User Portal powinien być dostępny tylko z potrzebnych stref i nie należy otwierać go szeroko na WAN wyłącznie ze względu na tę obsługę.

Aby zwiększyć ochronę, wybierz konto w Authentication > Multi-factor authentication. Opcja Generate OTP token with next sign-in umożliwia użytkownikowi zarejestrowanie tokenu za pośrednictwem User Portal lub VPN Portal. Artykuł MFA dla Sophos Firewall opisuje algorytm skrótu, dostęp do portalu, procedurę odzyskiwania i wdrożenie pilotażowe. MFA należy włączyć dopiero po przetestowaniu zwykłego logowania oraz procedury odzyskiwania dostępu.

W Authentication > Users > <użytkownik> > View usage widać przypisane limity, czas Surfing i zużycie danych. Aby dane się pojawiły, ruch musi trafić w regułę firewalla opartą na użytkowniku z Log firewall traffic. Reset user accounting zeruje liczniki Surfing i Network Traffic, dlatego nie służy jako ogólna naprawa logowania.

Odwrócenie zmiany i usunięcie konta

Przed rozpoczęciem fazy pilotażowej udokumentuj istniejącą kolejność w Authentication > Services oraz wszystkie zmieniane ustawienia grup, portali, reguł i VPN. Dzięki temu wycofanie zmian nie będzie zależało od odgadywania wartości domyślnych. Po odejściu użytkownika, niepowodzeniu pilotażu lub ustaniu celu konta wykonaj czynności w odwrotnej kolejności:

1. Sprawdzić zależności w regułach, grupach, zasadach Remote Access, limitach, MFA i dokumentacji.
2. Pod Authentication > Users wybierz użytkownika i ustaw Change status na Inactive.
3. Wykonać nową próbę logowania jako test negatywny.
4. W Current activities > Live users sprawdzić istniejące sesje i w razie potrzeby rozłączyć zwykłego użytkownika przez Disconnect.
5. Usunąć użytkownika z reguł firewalla i zasad Remote Access albo przywrócić udokumentowany wcześniejszy wybór.
6. Przywrócić zmienione ustawienia grup, portali i usług uwierzytelniania dokładnie do udokumentowanego stanu początkowego.
7. Sprawdzić dzienniki firewalla, VPN i konfiguracji pod kątem kolejnych prób, pozostałego ruchu i wykonanych zmian.
8. Usunąć konto dopiero po wyjaśnieniu wszystkich zależności albo pozostawić je nieaktywne zgodnie z zasadami retencji.

XML-API: osobno sprawdzać konto przeznaczone do usunięcia i wynik operacji. Dokumentacja referencyjna operacji Delete dla SFOS 22 i 23 wymaga dokładnej zapisanej wartości Username. Fragment opisu <Name><username></Name> oznacza tę nazwę użytkownika, a nie nazwę wyświetlaną Name z formularza dodawania ani domniemany wewnętrzny identyfikator. Nie jest to kompletne żądanie gotowe do wykonania. Powyższa procedura dotyczy zwykłych użytkowników; administratorów i aktualnie zalogowane konto należy traktować oddzielnie. Przed każdym usunięciem należy zachować niezależny, działający dostęp administracyjny.

Wiersze statusów tej operacji wiążą 200 z Message.UserDeleteSuccess, 204 z Message.UserAdminOrCurrentUserNotDeleted, 205 z Message.AuthorizerExists, 206 z Message.UserForeignKeyExists, 210 z Message.UserIMRuleExists i 500 z Message.UserDeleteFailed. Są to dosłowne identyfikatory w kodzie źródłowym, a nie potwierdzone treści komunikatów zwracanych podczas działania. W szczególności identyfikatory wskazujące na nieusunięcie lub zależności przy 204, 205, 206 i 210 nie oznaczają ogólnie pomyślnego usunięcia; ta tabela operacji nie jest klasyfikacją statusów HTTP. Z identyfikatorów nie należy wywodzić ani automatycznego usuwania kaskadowego, ani czynności porządkowych dotyczących Authorizer, kluczy obcych lub reguł IM; identyfikator IM nie potwierdza obecnie obsługiwanej funkcji GUI.

W przypadku niejasnego wyniku lub przerwanej operacji zapisu przed ponowną próbą należy sprawdzić w Authentication > Users dokładną zapisaną nazwę użytkownika i aktualny stan tego konta. Aby wykonać zatwierdzone usunięcie obsługiwaną metodą, należy użyć obsługiwanego interfejsu lub przed niepewnymi operacjami zapisu przez API wyjaśnić z Sophos Support kontrakt żądania i wyniku dla zainstalowanej kompilacji. Następnie należy sprawdzić, czy dokładnie to konto, które miało zostać usunięte, już nie istnieje oraz czy pozostałe potrzebne konta i dostęp administracyjny nadal działają bez zmian. Zależności i zasady retencji należy wyjaśnić wcześniej; dezaktywacja i rozłączenie sesji nie zastępują tego potwierdzenia usunięcia.

Pomoc SFOS nie potwierdza, że dezaktywacja kończy wszystkie istniejące połączenia. Sesje i tunele należy sprawdzić i rozłączyć oddzielnie. Po ponownej aktywacji konta trzeba powtórzyć testy pozytywne i negatywne.

Przed ryzykownym usunięciem można w Backup and firmware > Import export wyeksportować obiekt konfiguracyjny User z opcją Include dependent entity. Eksport zawiera dane wrażliwe, w tym hasła, dlatego należy go zaszyfrować i przechowywać w miejscu chronionym przed nieuprawnionym dostępem. Do późniejszego importu musi być również dostępny właściwy Secure Storage Master Key. Import aktualizuje istniejącą konfigurację i w przypadku nakładających się obiektów stosuje wartości z importu. Może więc również nadpisać wyeksportowane wspólne zależności. Przed importem należy sprawdzić zawartość i możliwe skutki, najlepiej w odpowiednim środowisku testowym.

Pełna kopia zapasowa nie umożliwia szybkiego wycofania zmian dotyczących jednego użytkownika: jej przywrócenie zastępuje całą konfigurację, ponownie uruchamia firewall i usuwa późniejsze zmiany. Proces opisano w artykule Tworzenie i przywracanie kopii zapasowej na Sophos Firewall.

W klastrze HA należy wprowadzić zmianę na urządzeniu Primary, a następnie sprawdzić stan synchronizacji. Dzienniki i raporty nie są synchronizowane między węzłami, dlatego podczas diagnostyki trzeba analizować je oddzielnie.

Użytkownicy i grupy współdzielą wewnętrzne identyfikatory. Sama duża liczba obiektów nie dowodzi problemu. Jeżeli jednak użytkownik ma User ID większy niż 65535 i nie jest uwierzytelniany, należy użyć oddzielnego procesu dotyczącego limitu User ID Sophos Firewall, zamiast zmieniać hasła lub reguły na chybił trafił.

Rozwiązywanie problemów według objawu

Nazwa użytkownika i hasło są odrzucane

W Authentication > Users sprawdzić, czy konto jest lokalne, aktywne i zapisane z oczekiwaną nazwą użytkownika. Następnie w Authentication > Services sprawdzić dla konkretnej usługi, czy wybrano Local. Udane logowanie w innym portalu nie dowodzi tego wyboru usługi.

Logowanie działa, ale reguła użytkownika nie pasuje

W Current activities > Live users sprawdzić tożsamość, źródłowy adres IP i Client Type. Następnie w Log Viewer sprawdzić pozycję reguły, Source Zone, użytkownika lub grupę i Firewall Rule ID. Reguła sieciowa znajdująca się nad regułą użytkownika może już obsługiwać ten ruch.

Zmiana grupy nie działa

W rekordzie użytkownika poszukać indywidualnych wartości dla limitu, Access Time, Traffic Shaping lub Remote Access. Te nadpisania mogą zastąpić wartości grupy; dla limitów, Access Time i Traffic Shaping należy także sprawdzić faktyczny wybór użytkownika i grupy w danej regule lub polityce. Dla Remote Access obowiązują opisane wyżej ograniczenia zależne od metody. Wartość należy przywrócić do dziedziczenia z grupy dopiero po porównaniu z udokumentowanym wyjątkiem.

Użytkownik może logować się z nieoczekiwanego źródła

Sprawdzić Sign-in restriction zarówno dla użytkownika, jak i grupy. Dodatkowo sprawdzić rzeczywiście używaną usługę, Device Access i regułę sieciową. Ustawienie Any node nie jest automatycznie kompensowane przez MFA ani restrykcyjną regułę firewalla.

Widok View usage pozostaje pusty

Sprawdzić, czy użytkownik jest rozpoznawany jako Live User i czy ruch trafia w regułę opartą na użytkowniku z Log firewall traffic. Następnie sprawdzić okres, przypisanie limitu i rzeczywisty ruch testowy. Reset user accounting nie tworzy brakujących logów ani nie naprawia błędnej reguły.

Operacyjna lista kontrolna

• Live users pokazuje użytkownika pilotuser01, oczekiwany źródłowy adres IP i właściwy Client Type.
• Dziennik uwierzytelniania potwierdza lokalne logowanie; reguła Local-Pilot-to-WAN lub jej Firewall Rule ID zgodnie z oczekiwaniami obsługuje ruch testowy.
• Nieprawidłowe hasło, niedozwolone źródło i nieautoryzowana funkcja dostarczają oczekiwanych negatywnych dowodów.
• Nadpisania ustawień użytkownika, Simultaneous sign-ins, Sign-in restriction i ewentualna data wygaśnięcia są udokumentowane.
• Jeśli używana jest funkcja MFA, przetestowano jej rejestrację oraz proces odzyskiwania.
• Stan początkowy, odpowiedzialność za konto, dezaktywacja, odłączenie sesji i późniejsze usunięcie są udokumentowane.

Często zadawane pytania