Dodanie użytkownika do grupy VPN samo nie daje dostępu
Członkostwo w grupie to jeden warunek, nie uprawnienie. Sprawdź, co brama faktycznie dopasowała, przeczytaj zapis akceptacji lub odmowy i przetestuj oba wyniki.
Konto jest w dobrej grupie, logowanie się udało, a połączenie nadal jest odrzucane albo nic nie osiąga. Zwykle dodaje się kolejne grupy, aż coś ustąpi, i tak organizacje dają znacznie więcej, niż prosił ticket. Członkostwo to jedno wejście decyzji autoryzacyjnej, nigdy sama decyzja: brama zbiera fakty o sesji, dopasowuje je do uporządkowanej polityki i dopiero wtedy decyduje. Jeśli zawiódł inny warunek, zmiana grupy zmienia tylko ekspozycję.
Członkostwo w grupie to warunek, nie uprawnienie
W RADIUS grupa przychodzi jako atrybut autoryzacji, a atrybuty opisują sesję, nie udzielają jej. Serwer odpowiada Access-Accept lub Access-Reject; przy akceptacji może dołączyć Filter-Id, Class lub atrybuty tunelu z RFC 2868, a sprzęt po drugiej stronie interpretuje je po swojemu. Nic w protokole nie mapuje grupy na pełny dostęp; to mapowanie pisze ten, kto ustawił politykę.
Dlatego ta sama nazwa grupy zachowuje się różnie w dwóch systemach. Microsoft NPS składa polityki z warunków, ograniczeń i ustawień i ocenia je w ustalonej kolejności. OpenVPN Access Server ma własny model grup i reguł, a serwer społecznościowy często oddaje całość skryptowi client-connect lub plikowi client-config-dir.
Decyduje reguła, która pasowała, nie grupa, której oczekiwano
Większość silników zatrzymuje się na pierwszej pasującej polityce lub najkonkretniejszej. Jeśli polityka 3 odmawia, a polityka 7 pozwala, sesja może zawieść, nie docierając do reguły, która by ją przepuściła. Kolejność to realne ustawienie w NPS i większości produktów kontroli dostępu.
Warunki towarzyszące grupie to druga połowa: stan urządzenia, metoda uwierzytelniania, ukończone MFA, sieć źródłowa, podmiot certyfikatu lub okno czasowe. Gdy jednego brak, polityka nie pasuje, silnik spada i działa domyślna odmowa.
Szczegóły katalogu tworzą tę samą iluzję. Polityka oparta na członkostwie w grupach Windows czyta SID-y w tokenie, gdzie są tylko grupy zabezpieczeń; grupa dystrybucyjna nigdy się nie pojawia. Grupa podstawowa jest w osobnym polu, więc polityka do niej przypięta może cicho zawieść.
Przeczytaj zapis akceptacji lub odmowy, zanim dotkniesz grupy
Najpierw jedno pytanie: czy żądanie dotarło do etapu autoryzacji? W NPS odpowiedź jest w dzienniku zdarzeń, gdzie 6272 oznacza dostęp, 6273 odmowę, a 6274 żądanie odrzucone przed oceną polityki. Te trzy liczby dzielą problem na trzy śledztwa, a tylko jedno dotyczy grup.
| What the record shows | What it means | Where to look next |
|---|---|---|
| 6272, access granted | Authentication and authorization both succeeded | Routes, split tunnel, DNS, per-resource rules |
| 6273, access denied | A policy matched and denied, or nothing matched and the default denied | The conditions of the policy that fired, in order |
| 6274, request discarded | The request never reached authorization | Shared secret, NAS client entry, proxy chain, malformed attributes |
Gdy dziennik jest niedostępny, zapytaj serwer wprost i przeczytaj odpowiedź. Brak Filter-Id i atrybutów tunelu oznacza, że serwer uważa sesję za zwykłą, a brama stosuje własne reguły. Odpowiedź z atrybutami, których punkt egzekwowania nie implementuje, to inna usterka: autoryzacja przeszła, a urządzenie ją zignorowało.
radtest alice 'password' 10.0.0.5 0 testing123Porównaj zwrócone atrybuty z tymi, które dokumentuje brama, a nie z tym, co sugeruje nazwa grupy. To zwykle oddziela problem polityki od problemu egzekwowania.
Zmiana grupy nie działa wstecz
Atrybuty autoryzacji są zwracane raz, przy uwierzytelnieniu sesji. Brama trzyma je na sesji i nie czyta katalogu dla każdego pakietu, dlatego istniejąca sesja działa dalej po usunięciu kogoś z grupy.
Aby zmiana zadziałała, potrzebna jest nowa decyzja autoryzacyjna, nie tylko nowe klucze. Gdy serwer wspiera RFC 5176, Disconnect-Request lub CoA-Request na UDP 3799 wymusza ponowną ocenę; inaczej rozłącz klienta i pozwól mu wrócić.
Napraw warunek, nie grupę
Gdy wiesz, która polityka zadziałała, naprawa jest zwykle mała: przestaw odmowę, która zasłania zamierzone zezwolenie, dodaj brakujący warunek urządzenia lub MFA, albo napisz wąską regułę dla jednego zasobu zamiast podnosić użytkownika do grupy z dziesięcioma innymi.
Krótka pętla utrzymuje zmianę uczciwą:
- Odtwórz odmowę na pierwotnym koncie i zapisz ID zdarzenia, zanim cokolwiek zmienisz.
- Zmień jeden obiekt, kolejność polityk, jeden warunek lub jedną grupę, i zapisz który.
- Otwórz nową sesję, potwierdź, że zezwolenie widać w dzienniku i że zasób naprawdę się otwiera.
- Przetestuj użytkownika, który nadal ma być odrzucany, żeby naprawa nie poszerzyła polityki.
Jeśli zezwolenie jest poprawne, a zasób się nie otwiera, problem przeniósł się na routing lub rozwiązywanie nazw w chwili przejścia autoryzacji. Trzymaj te dwie usterki osobno, a następny ticket zajmie minuty.