Sprawdzanie limitu User ID i porządkowanie użytkowników AD

Jeśli nowi lub pojedynczy użytkownicy nie są już uwierzytelniani mimo poprawnego katalogu, grupy i hasła, przyczyną może być wewnętrzny User ID Sophos Firewall. Sophos wskazuje też przypadki, w których użytkownicy nie mogą pobrać konfiguracji .ovpn z VPN Portal.

Sophos dokumentuje dla użytkowników i grup wspólny wewnętrzny zakres ID do 65535. Użytkownicy z wyższym ID nie są uwierzytelniani i nie mogą pojawić się jako Live Users. Sam objaw nie dowodzi jednak przekroczenia limitu; decydujący jest faktycznie przypisany ID.

Obiekt użytkownika można utworzyć również powyżej tej granicy. Sama jego obecność w Authentication > Users nie dowodzi więc, że logowanie działa.

Aktualne strony pomocy Sophos różnie liczą ten zakres: Authentication > Users podaje maksymalnie 65 535 User ID, natomiast Current activities > Live users podaje 65 536. Dla diagnostyki wiarygodna granica pozostaje taka sama w obu opisach: 65535 jest obsługiwane, a wyższa wartość nie.

Szybkie sprawdzanie limitu User ID

Konkretny identyfikator jest widoczny w WebAdmin:

1. Otworzyć Authentication > Users.
2. Wybrać Show additional properties i wyświetlić User ID.
3. Wyszukać użytkownika, którego dotyczy problem, i zanotować jego ID.
4. Jeśli to możliwe, porównać go z działającym użytkownikiem z tej samej grupy.
5. W Current activities > Live users sprawdzić, czy użytkownik pojawia się po zalogowaniu.

Interpretacja jest jednoznaczna:

• User ID do 65535: Udokumentowany limit nie został przekroczony dla tego użytkownika. Ogólna diagnostyka uwierzytelniania prowadzi następnie przez kontrolę serwera, usługi, Live Users, grupy, MFA, portalu i późniejszej ścieżki ruchu.
• User ID powyżej 65535: Obiekt użytkownika znajduje się poza obsługiwanym zakresem. Firewall nie uwierzytelnia tego użytkownika. Sophos wskazuje brak pobierania .ovpn również jako możliwy problem funkcjonalny.
• Brak użytkownika na liście: Użytkownicy zewnętrznych serwerów uwierzytelniania zwykle pojawiają się tutaj dopiero po pierwszym udanym logowaniu do usługi firewalla. Najpierw sprawdzić właściwą ścieżkę uwierzytelniania.

⚠️ Liczba widocznych użytkowników nie wystarcza do diagnozy. Grupy również zajmują ID, a w numeracji mogą występować luki. Dopiero kolumna User ID pokazuje, czy problem dotyczy konkretnego użytkownika.

Potwierdzone udane logowanie do VPN Portal przemawia przeciwko limitowi User ID jako głównej przyczynie. Jeśli po zalogowaniu brakuje pliku .ovpn, pozostaje on pusty lub nie można go wygenerować, artykuł Sophos Firewall: brak pliku .ovpn lub 0 bajtów rozróżnia błędy polityk, użytkownika, certyfikatu i systemu. Limit User ID jest przy tym tylko jedną z możliwych ścieżek diagnostycznych.

Max Live Users to inny limit

Wewnętrznego limitu User ID wynoszącego 65535 nie należy mylić z maksymalną liczbą jednocześnie utrzymywanych Live Users. Według Sophos SFOS 22 obsługuje maksymalnie 32 000 Live Users. Konfigurowalna wartość graniczna wynosi natomiast 32768; dodatkowe 768 wartości ustawienia nie zwiększa udokumentowanej pojemności operacyjnej.

W WebAdmin należy otworzyć menu administratora w prawym górnym rogu, wybrać Console, a następnie 4. Device Console. Administracyjne logowanie SSH prowadzi do tego samego menu głównego. Bieżącą wartość pokazuje polecenie:

system auth max-live-users show

SFOS akceptuje wartości max-live-users od 8192 do 32768:

⚠️ Poniższe polecenie set to wzorzec składni dla Device Console, a nie polecenie do wykonania bez zmian. Zastąpić <8192-32768> wartością liczbową zaplanowaną dla firewalla, bez nawiasów kątowych. Zmieniać pojemność dopiero po sprawdzeniu wymiarowania i udokumentowaniu wycofania zmiany; nie rozwiązuje to problemu z User ID.

system auth max-live-users set <8192-32768>

Udokumentowany zakres nie jest ogólnym zaleceniem, aby zawsze ustawiać 32768. Przed zmianą należy zapisać bieżącą wartość, rzeczywistą liczbę Live Users, używaną metodę uwierzytelniania i ścieżkę rollback. Następnie sprawdza się show, nowe logowania, Current activities > Live users, reguły oparte na użytkownikach i obciążenie systemu. Aby wycofać zmianę, należy użyć system auth max-live-users set <poprzednia-wartość> i przywrócić zapisaną wartość z dozwolonego zakresu.

Zwiększenie tej wartości nie naprawia użytkownika z wewnętrznym User ID powyżej 65535 ani nie usuwa starych obiektów użytkowników lub grup. Z kolei użytkownik poniżej granicy ID nie dowodzi, że oddzielny limit Live Users ma jeszcze wolną pojemność. Obie wartości należy sprawdzać niezależnie.

Znaczenie wewnętrznego User ID

User ID to wewnętrzne numeryczne przypisanie obiektu użytkownika lub grupy na firewallu. Nie jest to SID Active Directory ani Microsoft Entra Object ID, ani też funkcja Synchronized user ID authentication.

Prosty przykład pokazuje granicę:

• 60000 mieści się w obsługiwanym zakresie.
• 65535 to ostatni obsługiwany ID.
• 65536 znajduje się już poza obsługiwanym zakresem.

Użytkownicy Active Directory, RADIUS i innych zewnętrznych serwerów uwierzytelniania nie są w całości importowani z wyprzedzeniem. Ich lokalny rekord jest zazwyczaj tworzony przy pierwszym uwierzytelnieniu w usłudze firewalla. Grupy i istniejące obiekty użytkowników wykorzystują ten sam zakres ID.

Ręcznie utworzeni Clientless Users również należą do lokalnej struktury tożsamości. Konfiguracja Clientless Users na Sophos Firewall przedstawia bezpieczny proces konfiguracji i testowania; sama duża liczba obiektów nadal jednak nie potwierdza problemu z User ID.

Sophos zaleca usuwanie niepotrzebnych użytkowników i grup, aby zwolnione ID mogły być ponownie używane. Nie oznacza to jednak automatycznej renumeracji: Usunięcie starych obiektów nie dokumentuje ani nie gwarantuje, że istniejący użytkownik ze zbyt wysokim ID natychmiast otrzyma niższy numer.

Sprawdzanie zależności przed porządkowaniem

Porządkowanie użytkowników lub grup ingeruje w strukturę tożsamości i polityk. Przed większą zmianą powinna być dostępna aktualna kopia zapasowa firewalla. Potrzebna jest również lista usuwanych obiektów, ich User ID i znanych zastosowań.

Dla każdego użytkownika i każdej grupy należy sprawdzić co najmniej następujące zależności:

• polityki SSL VPN i IPsec Remote Access;
• polityki firewalla, web i aplikacji oparte na użytkownikach;
• przypisania MFA, OTP lub tokenów;
• Main Group i inne członkostwa w grupach;
• reguły inspekcji SSL/TLS;
• źródło katalogowe i zachowanie przy następnym logowaniu.

Obiektów nie usuwa się tylko z powodu ich wieku lub wysokiego ID. Najpierw należy zająć się wyraźnie nieaktualnymi kontami testowymi, byłymi pracownikami i nieużywanymi grupami. Tożsamości produkcyjnych nie wolno usuwać i tworzyć ponownie bez sprawdzenia.

Kontrolowane porządkowanie użytkowników AD

Dokumentowanie źródła użytkownika i obowiązujących polityk

Authentication > Users zawiera lokalnych użytkowników i administratorów oraz automatycznie utworzone rekordy użytkowników zewnętrznych. Przed porządkowaniem otworzyć nazwę i ustalić odpowiedzialne źródło:

• Dla użytkownika lokalnego hasło i grupę można zmienić na firewallu. Zarządzanie użytkownikami lokalnymi opisuje pełną procedurę utrzymania i wycofania zmian.
• Dla użytkownika zaimportowanego z AD tych dwóch danych nie można tam zmienić; tożsamość jest zarządzana w katalogu. Group pokazuje Main Group, a Other group memberships pozostałe grupy. Nie każda reguła lub polityka obsługuje te dodatkowe członkostwa.
• Jeśli Profile pokazuje Managed by Central, konto jest zarządzane w Sophos Fusion lub Sophos Central. Nie można go edytować w WebAdmin firewalla; uprawnienia dostępu wynikają z przypisanej tam roli. Konta administratorów i profile opisuje tę oddzielną ścieżkę zarządzania.

Przy dokumentowaniu zależności zapisać również faktyczny wybór w regułach i politykach: Jeśli wybrana jest tylko grupa, obowiązują ustawienia grupy; jeśli wybrano użytkownika i jego grupę, obowiązują ustawienia użytkownika. Udane logowanie nie dowodzi więc, że po porządkowaniu nadal działa ta sama polityka. Grupy użytkowników i Main Group wyjaśnia wybór, nadpisania i zależne od usługi ograniczenia obsługi wielu grup. Różne nazwy Sophos Fusion i Sophos Central w pomocy SFOS 22 i 23 nie zmieniają widocznej wartości, którą należy sprawdzić: Managed by Central.

Eksport nie zapewnia pełnego wycofania zmian użytkowników AD

Rekordy użytkowników można importować lub eksportować w Backup and firmware > Import export. Eksport konfiguracji zawiera jednak tylko użytkowników utworzonych ręcznie na firewallu, a nie użytkowników AD lub RADIUS dodawanych automatycznie podczas logowania. Pełna kopia zapasowa obejmuje wszystkich użytkowników i grupy. Przed porządkowaniem sprawdzić rzeczywisty zakres zapisanych danych, zamiast traktować eksport jako pełną kopię tożsamości.

Dla użytkowników lokalnych wskazana wyżej procedura utrzymania wyjaśnia eksport selektywny, dane wrażliwe, obiekty zależne i skutki importu. Nie używać eksportu ani kopii zapasowej jako gwarantowanej naprawy lub gwarancji ponownego przypisania zbyt wysokiego User ID. Przywracanie to zaplanowane odtworzenie konfiguracji firewalla, a nie szybkie wycofanie zmian pojedynczego użytkownika; przed usuwaniem uzgodnić ścieżkę odtworzenia zgodnie z procedurą kopii zapasowej.

Prawidłowe używanie Purge AD users

Purge AD users usuwa lokalne rekordy użytkowników AD, którzy zostali już usunięci z Active Directory. Nie trzeba wybierać poszczególnych użytkowników: Firewall porównuje rekordy z AD i usuwa wyłącznie użytkowników, którzy już tam nie istnieją.

Bezpieczna procedura:

1. Sprawdzić, czy skonfigurowany serwer AD jest osiągalny i prawidłowo obsługuje logowania.
2. Najpierw usunąć z Active Directory użytkowników, którzy nie są już potrzebni.
3. Na firewallu otworzyć Authentication > Users.
4. Uruchomić Purge AD users.
5. Sprawdzić, czy zniknęły wyłącznie oczekiwane rekordy.

Konto tylko wyłączone w AD, ale nadal tam istniejące, nie zostanie automatycznie usunięte w tym procesie. Jeśli lokalny rekord użytkownika nadal istniejącego w AD zostanie usunięty z firewalla, może powstać ponownie przy późniejszym logowaniu. Artykuł Konfiguracja Active Directory w Sophos Firewall opisuje konfigurację i import grup.

W klastrze HA funkcję Purge AD users uruchamia się na urządzeniu Primary. Firewall usuwa rekordy na urządzeniach Primary i Auxiliary; wynik należy sprawdzić na obu. Sophos dokumentuje, że porządkowanie nie przerywa zdarzeń logowania, wylogowania ani accounting. Nie gwarantuje to jednak zachowania każdej aktywnej sesji VPN. Przy bardzo dużych porządkach warto zaplanować okno serwisowe, monitorowanie uwierzytelniania i plan wycofania zmian.

Porządkowanie lokalnych użytkowników i grup

Lokalnych użytkowników, konta testowe i niepotrzebne grupy usuwa się celowo w Authentication > Users lub Authentication > Groups. Purge AD users nie porządkuje grup AD. Niepotrzebną grupę AD usuwa się najpierw w AD, a następnie osobno na firewallu.

Porządkowanie należy wykonywać w małych, możliwych do prześledzenia krokach:

1. Udokumentować wyraźnie nieaktualne obiekty i ich odwołania.
2. W kontrolowany sposób usunąć lub zastąpić odwołania w regułach, politykach VPN lub innych konfiguracjach.
3. Usunąć niewielki zestaw niepotrzebnych obiektów.
4. Przetestować logowanie produkcyjne, przypisanie grup i polityk oraz MFA.
5. Dopiero potem przejść do kolejnego kroku porządkowania.

Wyłączenie lokalnego konta nie wystarcza, jeśli jego ID ma być ponownie użyty. Szerokie importy grup należy także ograniczyć do grup rzeczywiście potrzebnych dla VPN, portali, reguł lub polityk użytkowników.

Jeśli konto lokalne ma na razie pozostać, wybrać je precyzyjnie w Authentication > Users i użyć Change status, aby przełączyć je między stanem aktywnym i nieaktywnym. Zapisać poprzedni stan, sprawdzić nowy i przetestować nowe logowanie do usługi, której dotyczy problem. Dezaktywacja nie jest usunięciem i nie dowodzi zakończenia wszystkich istniejących sesji lub tuneli VPN; sprawdzić je oddzielnie. Aby wycofać zmianę, przywrócić udokumentowany poprzedni stan i ponownie sprawdzić logowanie oraz działanie polityk. Przy nieoczekiwanych przerwach zatrzymać dalsze porządkowanie i przywrócić ostatnio zmienione odwołania lub stany; nie odtwarzać usuniętych obiektów na podstawie przypuszczeń.

Sprawdzanie wyniku

Porządkowanie nie jest udane tylko dlatego, że widocznych jest mniej obiektów. Następnie należy ponownie przetestować tę samą ścieżkę użytkownika:

1. W Authentication > Users sprawdzić, czy usunięto tylko oczekiwane rekordy AD.
2. W klastrze HA porównać wynik na urządzeniach Primary i Auxiliary.
3. Ponownie wyświetlić User ID konta, którego dotyczy problem.
4. Uwierzytelnić użytkownika w usłudze, której faktycznie dotyczył problem.
5. W Current activities > Live users i logach uwierzytelniania sprawdzić, czy logowanie zakończyło się powodzeniem.
6. Jeśli pierwotny błąd dotyczył dostępu VPN, następnie przetestować VPN Portal, pobieranie .ovpn i tunel.
7. Porównawczo sprawdzić reprezentatywne logowanie produkcyjne AD wraz z grupą, polityką i MFA.

Jeśli ID nadal przekracza 65535, problem limitu nie został rozwiązany. Usuwanie kolejnych obiektów produkcyjnych lub wielokrotne tworzenie na nowo konta, którego dotyczy problem, nie jest bezpieczną diagnostyką. Lepszym rozwiązaniem jest zgłoszenie do Sophos Support zawierające wersję firmware, źródło użytkownika, User ID, czas, log uwierzytelniania i udokumentowane kroki porządkowania.

Zapobieganie problemom z User ID

Higiena użytkowników powinna być częścią zwykłego utrzymania firewalla:

• importować tylko rzeczywiście potrzebne grupy katalogowe;
• byłych pracowników usuwać najpierw z katalogu, a następnie z firewalla;
• usuwać lokalne konta testowe i projektowe po użyciu;
• po przebudowie katalogu sprawdzać stare obiekty użytkowników i grup;
• wcześnie porównywać User ID przy nietypowych problemach z uwierzytelnianiem lub VPN Portal;
• dokumentować Main Groups oraz zależności MFA i polityk;
• większe porządki wykonywać z kopią zapasową, małym zestawem zmian i testem funkcjonalnym.

Firewall powinien znać tylko tożsamości rzeczywiście potrzebne do uwierzytelniania, polityk, portali, Remote Access i raportowania. Nie zastępuje prawidłowego cyklu życia tożsamości w usłudze katalogowej.

FAQ