Prawidłowe zarządzanie grupami użytkowników i grupą główną w Sophos Firewall

Grupy użytkowników pozwalają stosować wspólne zasady do uwierzytelnionych użytkowników. Przed zmianą grupy ustal dwie rzeczy: skąd pochodzi tożsamość oraz czy dana funkcja uwzględnia wyłącznie Main Group, czy także inne grupy AD. Dopiero wtedy można określić, czy należy zmienić kolejność grup, przypisanie polityki, czy samą regułę zapory lub VPN.

Skrócona procedura:

Określ źródło użytkownika i cel grupy.
Utwórz grupę lokalną lub celowo zaimportuj potrzebną grupę katalogową.
W Authentication > Services sprawdź obowiązującą Default group, a na serwerze Entra — Fallback user group.
W przypadku AD udokumentuj kolejność w Authentication > Groups > Reorder i oczekiwaną grupę główną.
Wyloguj użytkownika pilotażowego i zaloguj go ponownie. Następnie w Authentication > Users > użytkownik > Policies sprawdź pola Group i Other group memberships.
Przetestuj odpowiednią funkcję z użytkownikiem mającym uprawnienia i z użytkownikiem bez uprawnień. W przypadku ruchu sieciowego dodatkowo sprawdź oczekiwany Firewall Rule ID.

⚠️ Reorder nie jest niewinną funkcją sortowania. W przypadku użytkowników AD przesunięcie może zmienić grupę główną, a wraz z nią ustawienia MFA, limity, godziny dostępu, dostęp zdalny i inne zasady dla wielu użytkowników. Zapisz wcześniej kolejność, polityki grup i sposób wycofania zmian.

Zrozumienie modelu grup

Grupa zawiera wspólne polityki i ustawienia. Nie zastępuje ani uwierzytelniania, ani reguły zapory. Użytkownik może więc należeć do odpowiedniej grupy, a mimo to nie uzyskać dostępu, jeśli brakuje oczekiwanej reguły, polityki VPN, strefy, trasy lub drogi powrotnej.

Podczas diagnozowania błędu odpowiedz na cztery niezależne pytania:

Czy tożsamość pochodzi z lokalnej bazy danych, Active Directory, LDAP, RADIUS, Microsoft Entra ID, czy z przypisania bezklientowego?
Która grupa jest grupą główną?
Czy dana funkcja obsługuje dodatkowe członkostwa w grupach AD?
Która reguła lub polityka przetwarza rzeczywisty ruch danych?

Rozróżnianie grup lokalnych, importowanych i bezklientowych

Normal i Clientless są typami grup. Importowana opisuje natomiast pochodzenie grupy i nie stanowi odrębnego Group type.

Lokalna grupa typu Normal nadaje się dla użytkowników, którzy się logują. Użytkownikom lokalnym przypisuje się grupę w obiekcie użytkownika. W przypadku zewnętrznego źródła użytkowników lokalne rekordy użytkowników powstają zazwyczaj dopiero przy pierwszym udanym logowaniu.

Konta użytkowników gościnnych mają odrębny, ograniczony czasowo cykl życia. Tworzenie i bezpieczna obsługa użytkowników gościnnych na Sophos Firewall wyjaśnia grupę domyślną, ważność, captive portal i czyszczenie.

Grupy AD i Entra są importowane za pomocą kreatora odpowiedniego serwera. Katalog pozostaje źródłem członkostwa. W przypadku AD Sophos dokumentuje również alternatywę polegającą na ręcznym utworzeniu grupy zarówno w AD, jak i na zaporze. Także wtedy należy sprawdzić przypisanie do grupy i uprawnienia po ponownym zalogowaniu. Pełną procedurę konfiguracji AD, LDAPS i importu opisano w artykule Łączenie Active Directory z Sophos Firewall.

W przypadku ogólnego serwera LDAP ustawienia Base DN, Authentication attribute, Group name attribute, kolejność serwerów i Default group muszą być ze sobą spójne. Sophos zaleca memberOf jako atrybut grupy. Łączenie serwera LDAP z Sophos Firewall prowadzi przez tę konfigurację.

Grupa typu Clientless grupuje użytkowników bezklientowych i ich wspólne ustawienia. Ci użytkownicy nie logują się za pomocą klienta; zapora kontroluje ich dostęp na podstawie adresu IP. Stały adres IP jest przypisany do pojedynczego użytkownika bezklientowego, a nie do obiektu grupy. Konfiguracja użytkowników bezklientowych na Sophos Firewall opisuje przypisanie IP, regułę i test negatywny.

Nie utożsamiaj grupy domyślnej z zapasową grupą Entra

W Authentication > Services > Firewall authentication methods ustawienie Default group określa, jaką grupę otrzymuje użytkownik z zewnętrznego serwera uwierzytelniania, gdy żadna z jego grup katalogowych nie istnieje jako grupa lokalna. W ustawieniach fabrycznych jest to Open group. Sprawdź aktualną wartość, zamiast zakładać, że obowiązuje wartość domyślna. W środowisku produkcyjnym Avanet zaleca osobną, restrykcyjną grupę zapasową, która nie przyznaje niezamierzonych uprawnień do VPN, korzystania z limitów ani logowania.

Rozbieżne opisy AD dotyczące pierwszego logowania: Instrukcja konfiguracji AD opisuje automatyczne przypisanie do Default Group przy pierwszym logowaniu; natomiast FAQ dotyczące AD wskazuje Default Group tylko w sytuacji, gdy żadna z grup AD użytkownika nie istnieje na zaporze. Przegląd serwerów AD wyraźnie wskazuje Open group dla użytkowników, którzy należą wyłącznie do OU, a nie do żadnej grupy katalogowej, podczas gdy przegląd grup i FAQ odwołują się do skonfigurowanej Default group. Opisy te są ze sobą sprzeczne i nie potwierdzają istnienia szczególnej, powszechnie obowiązującej grupy przypisywanej przy pierwszym logowaniu ani jej pierwszeństwa. Skonfigurowaną Default group należy odróżniać od ustawienia fabrycznego Open group.

Przed wdrożeniem sprawdź rzeczywistą wartość Default group oraz uprawnienia dziedziczone z tej grupy. Sprawdź pierwsze logowanie osobno na dwóch nowych kontach pilotażowych przeznaczonych do tego celu: jednym należącym do grupy AD już zaimportowanej na zaporę i drugim, którego grupy AD nie zostały tam zaimportowane. Dla obu kont sprawdź w Policies pola Group i Other group memberships, a także dostęp, który powinien być dozwolony, oraz dostęp, który celowo nie powinien być dozwolony. W przypadku nieoczekiwanego przypisania wstrzymaj wdrożenie i wyjaśnij przyczynę. Nie usuwaj w tym celu grup produkcyjnych ani nie rozszerzaj uprawnień grupy zapasowej. Są to ograniczone czynności kontrolne przed wdrożeniem, a nie raport z testu przeprowadzonego na urządzeniu.

Microsoft Entra ID SSO używa oddzielnego ustawienia Fallback user group w konfiguracji serwera Entra. Ma ono zastosowanie również wtedy, gdy serwer Entra jest wybrany w Firewall authentication methods. W tym przypadku ogólna grupa domyślna nie obowiązuje.

Kolejność serwerów uwierzytelniania jest również istotna. Sophos Firewall pozwala na maksymalnie 20 serwerów dla każdej metody uwierzytelniania i przekazuje żądania w wyświetlonej kolejności. Nie zmieniaj tej kolejności w celu obejścia problemu z grupą, dopóki nie sprawdzisz odpowiedniego serwera i jego mapowania.

Zaplanuj przykład i stan początkowy

W przykładzie zastosowano trzy grupy o odrębnych zadaniach:

Local_Contractors: lokalna grupa pilotażowa dla kilku zewnętrznych pracowników;
SFOS_Internet_Standard: zaimportowana grupa AD dla normalnego dostępu do Internetu;
SFOS_SSLVPN: zaimportowana grupa AD dla polityki SSL-VPN.

auth-pilot@example.com służy jako konto testowe, a reguła LAN-Users-to-WAN z włączonym rejestrowaniem — do testowania ruchu. example.com jest zarezerwowaną domeną dokumentacyjną. Zastąp nazwy i użytkowników zgodnie z własną konwencją nazewnictwa. Nazwa związana z funkcją, taka jak SFOS_SSLVPN, pozostaje zrozumiała nawet po reorganizacji.

Zanotuj przed zmianą:

aktualną kolejność grup;
Default group i ewentualnie Fallback user group;
polityki grupowe i nadpisania specyficzne dla użytkownika;
usługi uwierzytelniania objęte zmianą i polityki VPN;
sprawdzony dostęp administratora i dodatkową ścieżkę zarządzania na wypadek, gdyby zmiana wpłynęła na grupę główną, MFA lub ograniczenia logowania;
użytkownika pilotażowego, oczekiwaną grupę główną oraz test pozytywny i negatywny.

Utwórz lokalną grupę użytkowników

Przejdź do Authentication > Groups i kliknij Add:

Wpisz Local_Contractors jako nazwę grupy.
W polu Group type wybierz Normal.
Wybierz tylko wymagane wspólne polityki:
- Surfing quota ogranicza czas korzystania według okresu i cyklu.
- Access time zezwala na dostęp w powtarzających się przedziałach czasu lub go blokuje.
- Network traffic ogranicza ilość przesyłanych danych.
- Traffic shaping przypisuje politykę QoS z priorytetem i limitami przepustowości.
Ustaw SSL VPN policy, Clientless SSL VPN policy, L2TP, PPTP i IPsec remote access tylko dla faktycznie planowanego dostępu. PPTP nie nadaje się do nowych wdrożeń; L2TP pozostaje ograniczoną opcją zgodności opisaną w artykule Dostęp zdalny L2TP w Sophos Firewall.
Jeśli to możliwe, ogranicz Sign-in restriction do wymaganych źródeł za pomocą Selected nodes lub Node range. Selected nodes zezwala na logowanie tylko z podanych adresów IP; Node range zezwala na logowanie z adresów w podanym zakresie IP. Any node umożliwia logowanie z dowolnej sieci.
Włącz Quarantine digest i MAC binding tylko wtedy, gdy grupa potrzebuje tych funkcji. Quarantine digest wysyła do skrzynki pocztowej użytkownika podsumowanie wiadomości e-mail zatrzymanych w kwarantannie. MAC binding ogranicza logowanie do przewidzianych urządzeń.
Kliknij Save, aby zapisać zmiany.

Nazwy pól i ich działanie są określone przez produkt; wybór zależy od środowiska. Grupa internetowa nie potrzebuje automatycznie VPN, limitu ani wiązania MAC. Grupy z wyraźnie określonym zadaniem są łatwiejsze do przetestowania i wycofania.

Przypisywanie lokalnych użytkowników i rozpoznawanie nadpisań

Tworzenie i zarządzanie zwykłymi użytkownikami lokalnymi szczegółowo opisuje nazwę użytkownika, hasło, dziedziczenie ustawień grupy i testy odbiorcze. Użytkowników lokalnych można przypisać do grupy w Authentication > Users. W edycji grupy Show group members pokazuje członków; przez Add member(s) można dodać odpowiednich lokalnych użytkowników. W przypadku tożsamości zarządzanych zewnętrznie katalog pozostaje źródłem członkostwa.

To, czy reguła lub polityka używa ustawień użytkownika czy grupy, zależy od faktycznego wyboru użytkowników i grup. Sprawdź u użytkownika w Policies, czy wybrano własną wartość zamiast ustawienia grupy. Jeśli polityka grupowa ma znów obowiązywać, przywróć celowo wcześniej udokumentowany stan dziedziczenia i ponownie przetestuj tylko odpowiednią funkcję. Nadpisanie pozostaje uzasadnione, jeśli wyjątek ma wyraźnie udokumentowane uzasadnienie.

Sophos rozróżnia dwa przypadki wyboru w danej regule lub polityce:

Wybrana tylko grupa: Zapora używa ustawień grupy, a nie automatycznie nadpisania użytkownika.
Wybrany użytkownik i jego grupa: Zapora używa ustawień użytkownika.

Ograniczony test pilotażowy pokazuje różnicę: dla auth-pilot@example.com w Local_Contractors zapisz wartość grupy A i inną wartość użytkownika B dla tego samego obsługiwanego ustawienia. A i B to symbole zastępcze dwóch świadomie zaplanowanych wartości testowych we własnym środowisku. W odizolowanej regule lub polityce testowej z wyborem użytkowników i grup najpierw sprawdź faktyczny wybór: samo Local_Contractors oznacza A; auth-pilot@example.com wraz z Local_Contractors oznacza B. W każdym przypadku przetestuj daną usługę lub ścieżkę danych po ponownym zalogowaniu; dla ruchu zapory sprawdź także Firewall Rule ID. Następnie przywróć wcześniej zapisany wybór i oba ustawienia oraz ponownie wykonaj test. Nie rozszerzaj w tym celu reguły produkcyjnej ani nie zmieniaj kolejności grup.

Ten wybór nie jest kolejnością Main Group. Nadal obowiązują opisane poniżej ograniczenia obsługi wielu grup i łączenie pasujących polityk SSL-VPN; nie oznacza to uniwersalnego pierwszeństwa polityki użytkownika w każdej usłudze.

Pełną procedurę tworzenia polityk czasu dostępu, limitów przeglądania i ruchu sieciowego oraz MFA w Sophos Firewall wyjaśniają odpowiednie artykuły specjalistyczne. W obiekcie grupy przypisywana jest tylko już zaplanowana polityka.

Interpretacja pól grup w XML API

Osoby automatyzujące zarządzanie grupami znajdą w modelu XML UserGroup jako obiekt grupy, GroupDetail jako treść konfiguracji oraz GroupMembers z GroupName i UserName jako dane członkostwa. Nie jest to import członkostwa z AD; w przypadku użytkowników katalogowych katalog pozostaje źródłem nadrzędnym. Uwierzytelnianie, jawne struktury otaczające operacje oraz analizę odpowiedzi XML opisano w artykule Bezpieczne korzystanie z XML API.

Poniższy fragment pokazuje wyłącznie udokumentowaną strukturę dla istniejących przykładów pilotażowych. Nie jest to kompletne ani przetestowane na urządzeniu żądanie Add/Edit; w szczególności brakuje struktury otaczającej operację oraz innych wymaganych pól konfiguracji. Pominięcie pól nie oznacza, że zmiana zachowa istniejące wartości.

<UserGroup>
  <GroupDetail>
    <Name>Local_Contractors</Name>
    <LoginRestriction>SelectedNodes</LoginRestriction>
    <NodeList>
      <IPAddress>192.0.2.10</IPAddress>
    </NodeList>
  </GroupDetail>
  <GroupMembers>
    <GroupName>Local_Contractors</GroupName>
    <UserName>auth-pilot@example.com</UserName>
  </GroupMembers>
</UserGroup>

Nazwę grupy i użytkownika należy zastąpić wartościami odpowiadającymi dokładnie zaplanowanemu celowi lokalnemu. 192.0.2.10 jest adresem IPv4 przeznaczonym do dokumentacji i należy go zastąpić rzeczywiście potrzebnym, dozwolonym źródłem logowania. Nazwy pól XML pozostają niezmienione. Powiązanie z polami interfejsu użytkownika jest następujące:

SurfingQuotaPolicy: Surfing quota; AccessTimePolicy: Access time.
DataTransferPolicy: Network traffic; QoSPolicy: Traffic shaping.
SSLVPNPolicy: SSL VPN policy; ClientlessPolicy: Clientless SSL VPN policy, a nie typ grupy Clientless.
SophosConnectClient: IPsec remote access za pośrednictwem klienta Sophos Connect.

Dla LoginRestriction przykład referencyjny rozróżnia AnyNode, SelectedNodes i NodeRange. AnyNode odpowiada Any node i nie ogranicza źródła logowania; nie jest wartością domyślną do rozwiązywania problemów. SelectedNodes używa NodeList z poszczególnymi wpisami IPAddress. NodeRange używa zamiast tego FromIP i ToIP, na przykład od 192.0.2.10 do 192.0.2.20. Obie granice zakresu również są wartościami dokumentacyjnymi i należy je zastąpić najmniejszym wymaganym zakresem IPv4, bez rozszerzania istniejących ograniczeń. Chociaż tabela oznacza FromIP i ToIP jako pola wymagane, ich opis ogranicza je do Node range; nie wynika z tego ogólny obowiązek ich stosowania w pozostałych wariantach.

Dokumentacja referencyjna API podaje dla QuarantineDigest, MACBinding, L2TP, PPTP i SophosConnectClient wartości Enable lub Disable oraz dokumentuje Disable jako wartość domyślną. Jest to informacja referencyjna, a nie potwierdzenie aktualnie zapisanego stanu grupy. Przy aktywnym QuarantineDigest podsumowanie kwarantanny jest wysyłane codziennie pocztą elektroniczną. PPTP pozostaje wykluczone z nowych projektów; L2TP nadal stanowi wyłącznie ograniczoną opcję zgodności opisaną powyżej.

Ograniczenia przykładu referencyjnego: Oddziela on ustawienia grup typu Normal od gałęzi Clientless, która pokazuje QoSPolicy. W przypadku GroupType jest jednak sprzeczny: wzorzec zawiera Normal/Clienless, opis wymienia Normal lub Clientless i określa typ danych jako INTEGER. Ponadto wzorzec zawiera symbole zastępcze w postaci dwukropków zamiast pełnej treści XML. Nie wolno na tej podstawie wyprowadzać ani poprawionego sposobu kodowania Clientless, ani mapowania na wartości liczbowe. Do operacji zapisu należy użyć odczytanej lub wyeksportowanej wartości z zainstalowanej wersji, której mapowanie jest już ustalone; w przeciwnym razie należy skorzystać z bezpiecznej procedury w interfejsie użytkownika. Alternatywy rozdzielone ukośnikiem, takie jak Enable/Disable, nie są pojedynczymi wartościami do zastosowania.

Wzorzec pokazuje również After z zagnieżdżonym w nim Name jako wskazanie pozycji. Drugi wiersz tabeli dotyczący Name wspomina o moveto, ale nie potwierdza istnienia samodzielnie wykonywalnej operacji. Zmianę pozycji należy traktować tak samo jak Reorder: może ona zmienić grupę główną. Wcześniej należy zabezpieczyć kolejność, członkostwa, aktualny i zamierzony stan polityk oraz sposób wycofania zmian; następnie sprawdzić działanie z użytkownikiem pilotażowym i w przypadku nieoczekiwanych skutków przywrócić zapisaną kolejność. Wzorzec nie potwierdza ani zastępowania lub scalania danych GroupMembers, ani semantyki aktualizacji After lub pominiętych pól.

Przed ściśle ograniczoną operacją zapisu Add/Edit należy zapisać nazwę obiektu docelowego i stan docelowy. Następnie należy przeanalizować rzeczywisty wynik operacji XML, ponownie odczytać dokładnie wskazaną grupę i wykonać opisane powyżej testy pozytywne i negatywne dla usługi objętej zmianą. Dokumentacja referencyjna przypisuje w przypadku Add i Edit 502 do klucza UserGroupRecordExists, a 503 do klucza UserGroupDuplicateIPInLoginRestriction. W przypadku takiego wyniku należy najpierw sprawdzić zamierzoną nazwę istniejącej grupy albo zduplikowane adresy w SelectedNodes. Nie należy ponownie wysyłać żądania w ciemno ani rozszerzać LoginRestriction. Te przypisania potwierdzają klucze referencyjne, a nie zaobserwowane tutaj komunikaty wyświetlane podczas działania.

Kontrolowane importowanie grup katalogowych

Grupy Active Directory

Przejdź do Authentication > Servers i uruchom kreatora importu dla skonfigurowanego serwera AD. W klastrze HA import musi zostać wykonany na Primary. Kreator importuje tylko wybrane grupy. Grupa utworzona później w AD nie pojawia się więc automatycznie i musi zostać ponownie zaimportowana.

Przed importem musi działać odpytywanie AD: serwer wymaga poprawnych wartości NetBIOS domain i Domain name, konta ADS username z uprawnieniami do wyszukiwania, odczytu i odpytywania o członkostwo w grupach oraz jego hasła Password. Konto administratora domeny nie jest potrzebne do importu grup. Connection security oferuje SSL/TLS jako opcję domyślną i STARTTLS jako szyfrowaną alternatywę; Plaintext przesyła dane logowania bez szyfrowania i nie jest bezpiecznym rozwiązaniem produkcyjnym. Port musi odpowiadać wybranemu rodzajowi połączenia. Przy użyciu Validate server certificate certyfikat serwera AD należy przesłać w Certificates > Certificates > Add > Upload certificate; Server IP/domain musi używać nazwy CNAME podanej w certyfikacie. Jeśli zapora nie może rozwiązać tej nazwy, sprawdź wewnętrzne rozwiązywanie nazw DNS lub Network > DNS > DNS host entry. Pełna konfiguracja serwera pozostaje opisana w podlinkowanym wyżej artykule o AD.

Search queries ograniczają zakres uwzględnianych użytkowników. Na przykład OU=VPN_Users,DC=example,DC=com wyszukuje w jednostce organizacyjnej VPN_Users domeny dokumentacyjnej example.com; jednostkę organizacyjną i składniki domeny należy zastąpić rzeczywistą nazwą wyróżniającą (Distinguished Name). Węższa baza wyszukiwania ułatwia kontrolę zakresu użytkowników, ale nie może wykluczać użytkowników, którzy mają być uwzględnieni. Tylko uwzględnieni użytkownicy mogą pojawić się jako Live Users za pośrednictwem tego serwera. Test connection sprawdza połączenie i dane logowania, ale nie potwierdza jeszcze prawidłowego przypisania grupy zwykłemu użytkownikowi. Ściśle wymuszane LDAP Channel Binding i LDAP Signing nie są obsługiwane; zgodność z takimi wymaganiami bezpieczeństwa AD należy wyjaśnić przed integracją, a nie obchodzić je jako problem z grupami.

Właściwy import przebiega następująco:

Przy odpowiednim serwerze AD kliknij Import, a następnie w Import group wizard kliknij Start.
Wybierz odpowiednią Base DN do wyszukiwania grup. Musi ona obejmować potrzebne grupy i należy ją odróżnić od podstawy wyszukiwania użytkowników.
Zaznacz tylko przewidziane grupy AD, na przykład SFOS_Internet_Standard i SFOS_SSLVPN.
Wybierz wspólne zasady grup, a następnie sprawdź wybór i wyniki.
W Authentication > Groups sprawdź obie grupy i ich zasady. Kreator importuje grupy, a nie od razu wszystkie rekordy użytkowników lub ich członkostwa.
W Authentication > Services > Firewall authentication methods sprawdź, czy serwer AD jest wybrany dla planowanej usługi. Jeśli w tej procedurze konfiguracji AD ma być odpytywane jako pierwsze, przesuń serwer na pierwszą pozycję i kliknij Apply. W istniejącym środowisku zachowaj wcześniej zaplanowaną kolejność serwerów, zamiast zmieniać ją bez uwzględnienia kontekstu.

Zagnieżdżone grupy AD nie są uwzględniane. Jeśli podgrupa ma obowiązywać dla reguły zapory lub polityki VPN, należy zaimportować dokładnie tę podgrupę. Grupa podstawowa użytkownika w AD również nie jest traktowana jako zwykłe członkostwo. Dlatego do polityk lepiej nadają się jawnie zdefiniowane grupy zabezpieczeń niż standardowa grupa AD Domain Users.

Nie dotyczy to wyłącznie Domain Users: jeśli na przykład SFOS_Internet_Standard stanie się grupą podstawową użytkownika w AD, właśnie to członkostwo nie zostanie uwzględnione jak zwykłe członkostwo w AD. W rezultacie następna pasująca zaimportowana grupa może stać się grupą główną zapory. Grupa główna zapory jest ustalana na podstawie jej własnej listy grup i nie jest grupą podstawową w AD.

Po zmianach w członkostwie w AD, zaimportowanych grupach lub kolejności grup użytkownik musi się ponownie zalogować. Dopiero wtedy zapora ponownie ocenia grupy i aktualizuje obiekt użytkownika.

Jeśli STAS i Synchronized User ID są skonfigurowane jednocześnie, serwer uwierzytelniania korzysta z mechanizmu, od którego żądanie logowania dotrze jako pierwsze. Dlatego w przypadku rozbieżnych wyników testów pilotażowych sprawdź dodatkowo Client Type, zamiast od razu zmieniać kolejność grup lub serwerów.

Grupy Entra

Do importu grup Entra rejestracja aplikacji w Microsoft Graph wymaga uprawnienia aplikacji Group.Read.All ze zgodą administratora (Admin Consent). Zegary zapory i Microsoft Entra ID muszą być zsynchronizowane; w przeciwnym razie połączenie może się nie powieść.

Następnie przejdź do Authentication > Servers i przy serwerze Microsoft Entra ID kliknij kreator importu grup. Można zaimportować wszystkie grupy lub tylko grupy, których Display name lub Description pasują do filtra. Surfing quota, Access time, Network traffic i Traffic shaping można przypisać do wszystkich lub wybranych zaimportowanych grup. Nowo zaimportowane grupy muszą być dodatkowo uwzględnione w używanych politykach zdalnego dostępu IPsec lub SSL VPN; sam import nie zapewnia dostępu do VPN.

Poprawna ocena grupy głównej i członkostwa w wielu grupach

Otwórz użytkownika w Authentication > Users i przewiń do Policies:

Group pokazuje pierwszą pasującą grupę na liście zapory, czyli grupę główną.
Other group memberships pokazuje inne zaimportowane grupy AD użytkownika.

Dwa dodatkowe pola pojawiają się w Policies tylko wtedy, gdy dla każdego z nich spełnione są oba warunki:

Group SSL VPN policies: Użytkownik należy do kilku grup AD, a co najmniej dwie z tych grup są uwzględnione w politykach zdalnego dostępu SSL VPN.
Group clientless SSL VPN policies: Użytkownik należy do kilku grup AD, a co najmniej dwie z tych grup są uwzględnione w politykach bezklientowego SSL VPN.

Jeśli brakuje jednego z tych pól, najpierw sprawdź członkostwa w AD, zaimportowane grupy i ich uwzględnienie w odpowiedniej polityce VPN. Samo członkostwo w kilku grupach AD nie wystarcza do wyświetlenia pola. Nie rozszerzaj uprawnień VPN w środowisku produkcyjnym tylko po to, aby pole stało się widoczne. Wyświetlenie pola nie jest też testem dostępu; rzeczywiste łączenie uprawnień omówiono poniżej.

W Authentication > Groups > Reorder można zmieniać kolejność metodą przeciągnij i upuść. Kliknij Close, aby zamknąć okno dialogowe. Jeśli auth-pilot@example.com należy do SFOS_Internet_Standard i SFOS_SSLVPN, pasująca grupa znajdująca się wyżej przy następnym logowaniu stanie się grupą główną.

Ta kolejność wpływa nie tylko na obecnie analizowany błąd. Przed zmianą sprawdź, czy dana funkcja obsługuje inne grupy. W przeciwnym razie przesunięcie może rozwiązać problem z VPN, a jednocześnie zmienić MFA, limit lub czas dostępu dla innych użytkowników.

Funkcje z obsługą wielu grup AD

Poniższa macierz dotyczy wyłącznie Active Directory. Nie należy bez sprawdzenia zakładać, że dotyczy również LDAP, RADIUS lub Microsoft Entra ID.

Kilka grup AD może być uwzględnianych w przypadku:

Firewall rules i SSL/TLS inspection rules;
SD-WAN routes;
Web policies;
IPS i Application control policies;
Policy test;
Remote access SSL VPN;
Clientless SSL VPN.

W Remote access SSL VPN łączone są uprawnienia pasujących polityk użytkowników i grup. Jeśli zastosowanie ma choć jedna pasująca polityka pełnego tunelu, wynikiem jest pełny tunel. Sprawdź to połączenie w rzeczywistym teście z użyciem klienta.

W Clientless SSL VPN uwzględniane są uprawnienia wszystkich polityk, do których należy którakolwiek z grup AD użytkownika. Dlatego sprawdź nie tylko oczekiwaną politykę, ale także dodatkowe udostępnione zakładki lub zasoby wynikające z innych grup.

Hotspots uwzględniają wyłącznie grupę główną (Main Group).

Tylko grupa główna lub jawne przypisanie użytkownika jest uwzględniane w przypadku:

WAF rules, My policy overrides;
Remote access IPsec VPN, L2TP i PPTP;
Surfing quota, Access time, Network traffic i Traffic shaping;
Quarantine digest, MAC binding i Sign-in restriction;
MFA.

W przypadku WAF, L2TP, PPTP i Remote access IPsec polityka użytkownika może wyświetlać Enable, chociaż uprawnienie wynika wyłącznie z Other group memberships i dlatego dostęp nie jest dozwolony. Oceń te usługi na podstawie grupy głównej lub bezpośredniego przypisania użytkownika, a nie tylko na podstawie widocznego stanu.

W przypadku funkcji obsługujących wiele grup nadal decyduje kolejność poszczególnych reguł lub polityk. Reguła zapory może zostać zastosowana za pośrednictwem SFOS_SSLVPN, chociaż SFOS_Internet_Standard jest grupą główną. Nie oznacza to, że MFA lub limit również korzystają z SFOS_SSLVPN.

W przypadku Web policies są to dwie odrębne decyzje: najpierw pasująca reguła zapory określa politykę WWW. W tej polityce stosowana jest pierwsza reguła pasująca zarówno do użytkownika, jak i do witryny. Jeśli użytkownik pilotażowy należy do obu przykładowych grup, a pierwsza reguła WWW blokuje witryny sportowe dla SFOS_SSLVPN, witryna sportowa zostanie zablokowana, nawet jeśli SFOS_Internet_Standard jest jego grupą główną, a późniejsza reguła zezwala tej grupie na dostęp do wiadomości. IPS i Application control korzystają natomiast z polityki pasującej reguły zapory; kolejność grup nie powoduje dodatkowego łączenia tych polityk.

W przypadku MFA zamiast wyboru grup można jawnie uwzględnić użytkownika lub zastosować MFA do wszystkich użytkowników. Przypisanie wyłącznie przez Other group memberships nie wystarcza. Hotspoty w User Portal zależą wyłącznie od grupy głównej; dodatkowa grupa AD nie rozszerza tej listy.

Sprawdzanie działania grupy

Zapisana grupa i widoczny użytkownik nie potwierdzają jeszcze powodzenia konfiguracji:

Zakończ bieżącą sesję użytkownika pilotażowego i ponownie go zaloguj.
W Authentication > Users > użytkownik > Policies zanotuj stan, Group, Other group memberships oraz możliwe nadpisania ustawień.
W Current activities > Live users sprawdź nazwę użytkownika, źródłowy adres IP oraz Client Type.
W przypadku reguły zapory opartej na użytkowniku wygeneruj przewidziany ruch i sprawdź Firewall Rule ID w Log Viewer.
Przetestuj czas dostępu, limity, MFA i dostęp zdalny, każdorazowo korzystając z usługi, której faktycznie dotyczy problem.
Powtórz tę samą próbę z użytkownikiem spoza grupy pilotażowej jako test negatywny.

Aby sprawdzić limit, otwórz Authentication > Users > użytkownik > View usage. Dane o wykorzystaniu są dostępne tylko wtedy, gdy reguła zapory oparta na użytkowniku przetwarza ruch i włączono Log firewall traffic.

Sprawdzanie reguł zapory za pomocą Log Viewer, Policy Test i Packet Capture przedstawia pełny test ruchu. Jeśli już wybór usługi, tożsamość lub grupa główna są niejasne, Systematyczne rozwiązywanie problemów z uwierzytelnianiem w Sophos Firewall prowadzi przez cały proces diagnostyczny.

Wycofywanie zmian i porządkowanie grup

Zmieniaj zawsze tylko jedną politykę grupy lub jedną pozycję w kolejności. Jeśli test pilotażowy wykaże nieoczekiwane działanie, przywróć zanotowaną kolejność i przypisanie polityki, ponownie zaloguj użytkownika i powtórz testy pozytywny i negatywny.

Grupy AD są najpierw usuwane w katalogu, a następnie osobno na zaporze w Authentication > Groups. Purge AD users nie usuwa grup.

Dla użytkowników AD obowiązuje następująca procedura:

Najpierw usuń użytkownika w AD. Dopóki tam istnieje, zapora może utworzyć go ponownie przy późniejszym logowaniu.
W Authentication > Users kliknij Purge AD users. Nie trzeba wcześniej wybierać użytkowników; zapora sprawdza serwer AD i usuwa tylko użytkowników już tam usuniętych.
W HA rozpocznij operację na Primary. Rekordy zostaną usunięte na Primary i Auxiliary. Czyszczenie nie przerywa logowania, wylogowywania ani rozliczania użytkowników.

Eksport konfiguracji zawiera zaimportowane i lokalnie utworzone grupy AD, ale nie użytkowników z zewnętrznych serwerów uwierzytelniania. Pełna kopia zapasowa obejmuje natomiast wszystkich użytkowników i grupy. Uwzględnij to ograniczenie, jeśli procedura wycofania obejmuje więcej niż jedną zmianę polityki.

Bezpieczne usuwanie wskazanej grupy przez API

Przed każdym usunięciem należy ustalić dokładny Name grupy docelowej i zabezpieczyć polityki, kolejność, członków oraz miejsca wykorzystania grupy. To, że starsza tabela API oznacza Name jako niewymagane, nie jest przyzwoleniem na usunięcie bez wskazania nazwy: opis wymaga nazwy do identyfikacji obiektu. Wcześniej należy sprawdzić rzeczywistych użytkowników grupy, przypisania VPN, w tym L2TP/IPsec, wybór do uwierzytelniania zewnętrznego, odwołania w regułach zapory oraz wykorzystanie jako domyślnej grupy gości. Jeśli grupa jest nadal potrzebna, należy przeprowadzić wyraźnie zaplanowaną, ściśle ograniczoną migrację albo zatrzymać operację. Nie należy wymuszać usunięcia, usuwać użytkowników ani łagodzić ograniczeń dostępu tylko po to, aby usunięcie się powiodło. Opisana powyżej kolejność działań dla AD oraz rozdzielenie od Purge AD users pozostają w mocy.

Dokumentacja referencyjna usuwania wiąże wiersze wyników z kluczami komunikatów JavaScript dotyczącymi takich zależności. Potwierdza to te kategorie kontroli, a nie brakujące teksty wyświetlanych komunikatów ani zaobserwowany tutaj błąd urządzenia. W zakresie budowy żądania i obsługi wyniku XML obowiązuje artykuł Bezpieczne korzystanie z XML API; dokumentacja referencyjna usuwania grup nie zawiera przykładu danych żądania, dlatego nie tworzymy tutaj wymyślonej struktury otaczającej operację Delete. W przypadku odrzucenia należy zachować grupę i dokładnie sprawdzić odwołanie wskazane w wyniku. Również po wyniku oznaczającym powodzenie należy ponownie odczytać dokładnie wskazany obiekt docelowy, potwierdzić jego brak i powtórzyć zaplanowane testy usług i dostępu.

Użytkownicy i grupy współdzielą wewnętrzny zakres identyfikatorów do 65535. Sama duża liczba widocznych obiektów nie dowodzi problemu z limitem. Jeśli użytkownik ma User ID powyżej 65535 i nie pojawia się jako aktywny użytkownik, odpowiada to sytuacji opisanej w artykule Limit identyfikatorów użytkowników w Sophos Firewall.

Zawężanie błędów według objawu

Po każdej korekcie ponownie zaloguj użytkownika, którego dotyczy problem, i sprawdź Group oraz Other group memberships. Następnie dla każdego objawu wystarczy jeden ukierunkowany kolejny krok.

Nowa grupa AD nie pojawia się

Uruchom ponownie kreator importu serwera AD, a w HA wykonaj import na Primary. Następnie sprawdź w Authentication > Groups, czy znajduje się tam dokładnie potrzebna grupa. Nie twórz grupy zastępczej o szerokich uprawnieniach tylko po to, aby logowanie działało.

Użytkownik LDAP trafia do grupy domyślnej

Sprawdź na serwerze LDAP Base DN, Authentication attribute i Group name attribute, a następnie w Authentication > Services kolejność serwerów i Default group. Uruchom Test connection dla serwera LDAP. Kreator importu AD nie odpowiada za to mapowanie.

Użytkownik Entra trafia do grupy zapasowej

Sprawdź, czy grupa Entra została zaimportowana i czy token zwraca oczekiwaną grupę. Następnie sprawdź Fallback user group bezpośrednio na serwerze Entra. Ogólna Default group w Authentication > Services nie jest używana do tego mapowania.

Użytkownik ma niewłaściwą grupę główną

Porównaj członkostwa w AD, zaimportowane grupy i aktualną kolejność. Sprawdź nową kolejność dopiero po następnym logowaniu i z kilkoma reprezentatywnymi użytkownikami.

Reguła zapory działa, ale MFA lub limit nie

Reguły zapory obsługują dodatkowe grupy AD, natomiast MFA i limity nie. Sprawdź w Authentication > Users > użytkownik > Policies grupę główną, możliwe nadpisania ustawień oraz faktyczne przypisanie polityki. Działanie reguły nie dowodzi, że MFA lub limit uwzględniają tę samą grupę.

Zmiana grupy nie działa tylko dla jednego użytkownika

Porównaj pola polityki specyficzne dla użytkownika i faktyczny wybór użytkowników oraz grup w danej regule lub polityce: wybór samej grupy oznacza użycie wartości grupy; wybór użytkownika i jego grupy oznacza użycie wartości użytkownika. Sprawdź także ograniczenia funkcji dotyczące grupy głównej i obsługi wielu grup. Przywróć wartość grupy tylko wtedy, gdy udokumentowany wyjątek nie jest już potrzebny.

Zagnieżdżona grupa AD nie działa

Zaimportuj samą potrzebną podgrupę i dodaj do niej użytkownika bezpośrednio. Samo zaimportowanie grupy nadrzędnej nie wystarczy.