Jak logowanie VPN trafia do RADIUS i twojego dostawcy tożsamości

W zeszłym tygodniu użytkownik mógł zalogować się do VPN i mimo to trafił do sieci, w której nic się nie rozwiązywało. Klient mówił połączony, log bramy mówił Access-Accept, a zespół tożsamości mówił, że konto jest w porządku. Logowanie zadziałało; autoryzacja za nim nie. Kiedy logowanie VPN zawodzi, idę ścieżką, którą żądanie naprawdę podąża — klient, brama, serwer RADIUS, dostawca tożsamości — i zatrzymuję się na pierwszym skoku, którego odpowiedź nie zgadza się z następną.

Klient nigdy nie mówi RADIUS

Cokolwiek pokazuje aplikacja na laptopie, jej pierwszym skokiem jest protokół VPN: IKEv2, OpenVPN, WireGuard albo klient oparty na TLS. RADIUS nie pojawia się w tej wymianie. Klient uwierzytelnia się wobec bramy certyfikatem, nazwą użytkownika i hasłem albo metodą EAP przenoszoną w konfiguracji tunelu.

To ma znaczenie przy czytaniu logów, bo ogólny błąd uwierzytelniania, który widzi użytkownik, produkuje brama po tym, jak już rozmawiała z czymś innym. Jeśli klient nigdy nie dotrze do bramy, nie ma żądania RADIUS do debugowania, a godzina spędzona na serwerze RADIUS jest stracona. Potwierdź, że tunel w ogóle powstał, zanim dotkniesz backendu.

Brama jest klientem RADIUS

Gdy konfiguracja tunelu dochodzi do punktu, w którym trzeba sprawdzić dane logowania, brama staje się serwerem dostępu sieciowego. Buduje Access-Request: User-Name, hasło lub ładunek EAP, NAS-IP-Address lub NAS-Identifier, oraz Message-Authenticator, gdy metoda tego wymaga. Żądanie domyślnie trafia na UDP 1812, a rozliczanie na 1813. Starsze wdrożenia nadal używają 1645 i 1646, więc reguła firewalla napisana dla jednej pary wyjaśnia wiele cichych błędów.

Obie strony dzielą sekret, i nie jest to dane logowania użytkownika. Podpisuje on wymianę, a każda odpowiedź jest weryfikowana względem niego. Skonfiguruj sekret inaczej po obu stronach, a serwer nie odpowie złym sekretem — odrzuci żądanie albo odpowiedź nie przejdzie weryfikacji, więc brama zgłosi przekroczenie czasu. Zły sekret i martwy serwer wyglądają z bramy identycznie, dlatego testuję ten skok narzędziem klienckim, zanim obwinę katalog.

Protokół jest mały i stary — RFC 2865 definiuje wymianę uwierzytelniania — ale atrybuty, które niesie, są podstawą większości polityki VPN.

# ask the RADIUS server directly, from the gateway host
radtest alice 'test-password' 127.0.0.1 0 testing123

# watch the exchange the gateway actually sends
tcpdump -ni any -c 20 'udp port 1812'

Serwer RADIUS może być tylko frontem dostawcy tożsamości

Ludzie mówią o RADIUS i dostawcy tożsamości, jakby to była ta sama skrzynka. Często nie jest. Serwer RADIUS odbiera Access-Request, a następnie pyta o coś innego — Active Directory przez LDAP lub Kerberos, lokalny plik użytkowników albo usługę zewnętrzną — zanim odpowie. FreeRADIUS z modułem LDAP lub krb5, Windows NPS i Cisco ISE stoją wszystkie w tej pozycji.

Ta różnica decyduje, gdzie patrzeć. Odrzucone hasło to odpowiedź dostawcy tożsamości przekazana przez RADIUS. Przekroczenie czasu to zwykle odcinek RADIUS–katalog: wygasłe konto bind, nieosiągalny katalog albo żądanie skierowane do złego backendu. Jeśli nazwa użytkownika ma sufiks domeny, serwer może po nim routować, a to samo konto wysłane jako CORP\alice i [email protected] może trafić w różne miejsca. W Windows NPS log Security zapisuje 6272 przy zezwoleniu i 6273 przy odmowie, co mówi, czy decyzja w ogóle przyszła z NPS.

Czytaj błąd na tym skoku, który go wytworzył

Jeden komunikat nie można się połączyć obejmuje cztery różne błędy. Zanim cokolwiek zmienisz, dopasuj objaw do skoku, który go wytworzył.

Ostatni wiersz to ten, który wysyła ludzi do złego zespołu. Access-Accept oznacza, że dane logowania zostały przyjęte; nie oznacza, że brama umieściła użytkownika w odpowiedniej puli albo wypchnęła trasy. Atrybuty grup mają znaczenie tylko wtedy, gdy polityka bramy je czyta. Widziałem poprawne logowanie lądujące w puli gości, bo mapowanie grup było skonfigurowane po stronie RADIUS dla innego atrybutu niż ten, który sprawdza brama.

Prześledź jedno logowanie od początku do końca

Wybierz jedno konto testowe i jedną bramę, a potem obserwuj tę samą próbę we wszystkich czterech punktach. Uruchom debugowanie po stronie RADIUS — freeradius -X wypisuje żądanie i każdy moduł, którego dotknie — śledź log uwierzytelniania bramy i uruchom tcpdump dla wymiany UDP. Połącz się raz i przeczytaj cztery ślady po kolei.

Chcesz zobaczyć zgodność: brama zapytała o użytkownika, którego oczekiwałeś, serwer RADIUS wybrał backend, którego oczekiwałeś, ten backend zwrócił decyzję, a atrybuty w odpowiedzi pasują do polityki stosowanej przez bramę. Pierwsze miejsce, w którym ślady się nie zgadzają, to twoja linia błędu. Jeśli odpowiedź nie niesie atrybutu grupy, problem jest po stronie RADIUS, nie w profilu VPN; jeśli atrybut jest, a brama go ignoruje, problemem jest polityka bramy.

Jedna uwaga o bezpieczeństwie, póki tam jesteś. Wspólny sekret chroni wymianę, ale nie szyfruje większości atrybutów. Jeśli brama i serwer RADIUS są w różnych segmentach, połóż ten skok na RADIUS przez TLS albo prywatną ścieżkę. Zaszyfrowany tunel użytkownika nic nie mówi o łączu do backendu.

Zanim zamkniesz zgłoszenie, potwierdź cztery rzeczy. Brama dociera do serwera RADIUS na porcie, dla którego jest faktycznie skonfigurowana. Wspólny sekret zgadza się po obu stronach. Serwer RADIUS rozwiązuje dokładną formę nazwy użytkownika wysyłaną przez bramę. Akceptacja niesie atrybuty potrzebne polityce bramy. Gdy wszystkie cztery zachodzą, logowanie, które nadal zawodzi, jest problemem polityki bramy, a nie uwierzytelniania.