NetExtender loguje się, ale brak dostępu: SonicWall lokalny + LDAP

Logowanie się udaje, tunel wstaje, a nic za zaporą nie odpowiada. Ten wzorzec na SonicWallu SSL VPN zwykle oznacza, że konto przeszło uwierzytelnianie i zatrzymało się na jednym z dwóch późniejszych uprawnień: dopuszczeniu do usługi SSL VPN albo pozwoleniu na dotarcie do zasobu. Mieszane konta lokalne i LDAP pogarszają sprawę, bo oba magazyny osiągają te uprawnienia różnymi ścieżkami. Objaw jest identyczny po stronie klienta, dlatego warstwy trzeba rozdzielić świadomie.

Objaw i trzy uprawnienia za nim

Trzy niezależne decyzje stoją między nazwą użytkownika a osiągalnym serwerem. Metoda uwierzytelniania decyduje, czy poświadczenie zostanie przyjęte i przez który magazyn. Członkostwo w usłudze SSL VPN decyduje, czy ta tożsamość może w ogóle korzystać z SSL VPN. Lista dostępu VPN decyduje, do których prywatnych celów sesja może dotrzeć. Zaliczenie jednego nic nie mówi o dwóch następnych.

Użytkownik, który się uwierzytelnia, ale nie jest w grupie usługi SSL VPN, widzi połączenie, które się nawiązuje, a potem nic nie przenosi, a dziennik zapory pokazuje zaakceptowane logowanie zamiast błędu. To przypadek wart szybkiego rozpoznania, bo rozwiązaniem jest członkostwo w grupie, a nie reset hasła.

Użytkownik dopuszczony, ale bez zasobów, widzi sesję, która się łączy i nigdzie użytecznie nie trasuje. Oba przypadki wyglądają z helpdesku jak zepsuty tunel, a oba są konfiguracją, a nie łącznością.

Pole domeny to nie katalog

NetExtender pyta o domenę, a to pole nie jest bazą wyszukiwania dla Active Directory. W układzie domyślnym pole musi być równe domenie użytkownika SSL VPN skonfigurowanej na zaporze, a udokumentowana wartość domyślna to LocalDomain. Porównanie rozróżnia wielkość liter, więc wartość wpisana inną wielkością liter zawodzi nawet przy poprawnym koncie.

Gdy skonfigurowano partycjonowanie uwierzytelniania, nazwy partycji wybierają zewnętrzny kontekst uwierzytelniania, a skonfigurowana wartość domyślna zachowuje własną rolę. W obu układach etykieta domeny po stronie klienta nie jest przekazywana do LDAP ani RADIUS jako część nazwy użytkownika, więc nie może kierować wyszukiwaniem w katalogu.

Trzymaj trzy ciągi osobno w notatkach: sufiks DNS firmy, bazę wyszukiwania LDAP i etykietę domeny NetExtender. Wyglądają podobnie i żaden nie zastępuje innego. Skopiuj wartość operatora dla tej instalacji, a nie wartość z postu na forum o innej wersji oprogramowania układowego.

Dopuszczenie i dostęp do zasobów to osobne uprawnienia

Konta lokalne potrzebują członkostwa w grupie usługi SSL VPN, zanim usługa je przyjmie. Konta katalogowe docierają do tej samej grupy przez obsługiwany przepływ mapowania grup, co oznacza, że relację grupy LDAP trzeba skonfigurować, a następnie zweryfikować jako skuteczne członkostwo, a nie założyć po stronie katalogu.

Dostęp do zasobów przychodzi później, w sekcji dostęp VPN na użytkowniku lub grupie. Przyznaj konkretne podsieci i usługi, których wymaga rola, i oprzyj się skrótowi przyznania całej sieci LAN, bo potrzebna jest jedna aplikacja. Trasy sesji, reguły dostępu i uprawnienia usługi docelowej muszą wszystkie zgadzać się z tym zakresem.

Trasa na kliencie czyni cel wybieralnym i nie autoryzuje go. Członkostwo w grupie SSL VPN nie czyni też konta administratorem zapory i nie należy go traktować jako ogólnego nadania uprawnień.

Dwie tożsamości, po cztery kontrole

Testuj z jednym kontem lokalnym i jednym kontem katalogowym, oba wąsko uprawnione i oba udokumentowane jako konta testowe. Dla każdego zapisz źródło uwierzytelnienia, które przyjęło logowanie, efektywne grupy, przydzielony dostęp do zasobów i jedną dozwoloną operację aplikacji. Cztery kontrole, dwa magazyny i pisemny wynik dla każdej kombinacji.

Następnie przetestuj przypadki negatywne: zasób, do którego konto nie powinno dotrzeć, oraz konto, które powinno zostać odrzucone od razu. Projekt, który dowodzi tylko ścieżki pozytywnej, zwykle zostawia otwarte drugie wejście, zwłaszcza gdy ta sama krótka nazwa użytkownika istnieje w obu magazynach. Wyłącz konto katalogowe i potwierdź, że lokalne nie działa dalej po cichu.

Przejrzyj zduplikowane nazwy jako część wdrożenia, a nie po incydencie. Ta sama osoba w dwóch magazynach jest jednocześnie udogodnieniem wsparcia i problemem audytowym, a zapora chętnie uwierzytelni to, które skonfigurowałeś.

Utrzymaj wąską ścieżkę odzyskiwania

Zachowaj politykę MFA dla każdej klasy kont, zamiast zwalniać z niej konta lokalne. Jeśli konta lokalne zapewniają zatwierdzoną ścieżkę odzyskiwania na wypadek awarii katalogu, ogranicz tę ścieżkę do wskazanych administratorów i obsługuj ją świadomie, bo lokalne konto awaryjne dla każdego pracownika to drugi system uwierzytelniania ze słabszym nadzorem.

Zapisz domenę klienta, źródło uwierzytelnienia i efektywny dostęp w tym samym rekordzie. Następny administrator może wtedy odtworzyć działający projekt kont mieszanych zamiast próbować ciągów domen, aż logowanie się uda.