Alias grupy w ASA a adres URL grupy: jak wybierany jest profil
Alias grupy to wpis na liście logowania, a nie mapowanie adresu URL. Prześledź, jak ASA wybiera profil, a potem przeczytaj politykę, którą sesja faktycznie otrzymuje.
Profil połączenia rządzi sesją dopiero po tym, jak ASA go wybierze. To zdanie to cały model diagnostyki dla starego portalu bez klienta. Nieużywany profil może mieć doskonałe reguły dostępu i mimo to nie dotyczyć nikogo. Prześledź punkt wejścia logowania, zanim zmienisz jakąkolwiek politykę.
Poniższe rozróżnienia opierają się na dokumentacji 9.16; bezklienckie SSL VPN zostało usunięte w 9.17(1) i później.
Alias to wpis na liście, nie adres URL
group-alias dostarcza etykietę, którą użytkownik wybiera z listy grup na stronie logowania. Wyświetlanie tej listy to osobne ustawienie, tunnel-group-list enable. Alias to tylko nazwa wyboru i nic więcej. Skonfigurowanie aliasu o nazwie staff nie tworzy adresu /staff, który wybierałby profil.
Ludzie oczekują, że alias będzie pełnił podwójną rolę, bo z przeglądarki lista i adres URL wyglądają jak ten sam wybór.
Co group-url faktycznie dopasowuje
group-url wiąże przychodzący adres URL z profilem połączenia. Gdy ten włączony adres się zgadza, ASA wybiera profil, nie prosząc użytkownika o wybór z listy. Adres musi być pełnym zamierzonym adresem, w składni obsługiwanej przez Twoją wersję. Jego rekord DNS i certyfikat muszą zgadzać się z tym, co wpisują użytkownicy, inaczej dopasowanie nigdy nie nastąpi.
Skopiowany przyrostek adresu URL niczego nie dowodzi w kwestii konfiguracji. Sprawdź profil, a nie pasek adresu.
Prześledź wybór aż do polityki, która się wykonuje
Po wybraniu grupy tuneli urządzenie ustala metodę uwierzytelniania i domyślną politykę grupy, która jest z nią związana. Następnie atrybuty specyficzne dla użytkownika, wartości zwracane przez uwierzytelnianie i autoryzacja dynamiczna mogą nadpisać części tej podstawy. Sprawdź, co sesja faktycznie otrzymała. Czytanie samej nazwanej polityki daje podstawę, a nie wynik.
Różnica między jednym a drugim jest źródłem większości zgłoszeń „reguła jest poprawna, ale dostęp jest błędny”.
Dziedziczenie nie jest izolacją
Atrybuty pozostawione bez określenia mogą być dziedziczone z domyślnej polityki grupy. Nowa nazwana polityka nie jest więc odizolowana od współdzielonych wartości domyślnych, a ich edycja dociera do każdego profilu, który je dziedziczy. Porównaj faktyczny dostęp do zasobów, ustawienia DNS i ograniczenia sesji dla każdego profilu. Zrób to, zanim zmienisz cokolwiek współdzielonego.
Egzekwowanie dostępu trzymaj też osobno od wyboru.
Dla sesji bez klienta właściwym filtrem jest lista ACL webtype. Filtr VPN dla klienta tunelowego nie jest zamiennikiem tylko dlatego, że oba leżą blisko tego samego bloku polityki w konfiguracji.
Rozstrzygnij przypadek bez dopasowania, a potem przetestuj każdą ścieżkę
Ustal, co powinno się dziać pod ogólnym adresem URL portalu i w innych punktach wejścia bez dopasowania. Przyjrzyj się rzeczywistej ścieżce domyślnego profilu i jej autoryzacji, zamiast edytować współdzieloną wartość domyślną, żeby przeszedł jeden testowy login. Potem otwórz trzy nowe sesje: jawny adres URL, włączony wpis listy i ogólny punkt wejścia. Zapisz wybrany profil i faktyczną politykę dla każdej z nich.
Ponowne użycie karty przeglądarki z wcześniejszego logowania psuje porównanie, bo ta sesja jest już związana z profilem.
Ten zapis zamienia „portal się otwiera” w mapowanie od logowania do polityki, które możesz później audytować, i to jest jedyna trwała odpowiedź, gdy profil wygląda poprawnie i nikim nie rządzi.