Kako VPN prijava stiže do RADIUS-a i vašeg pružatelja identiteta

Prošle sedmice korisnik se mogao prijaviti na VPN i ipak završiti na mreži na kojoj se ništa nije razrješavalo. Klijent je rekao povezan, dnevnik prolaza je rekao Access-Accept, a tim za identitet je rekao da je račun u redu. Prijava je uspjela; autorizacija iza nje nije. Kada VPN prijava ne uspije, prolazim putem kojim zahtjev zaista ide — klijent, prolaz, RADIUS server, pružatelj identiteta — i zaustavljam se na prvom koraku čiji se odgovor ne slaže sa sljedećim.

Klijent nikada ne govori RADIUS

Šta god aplikacija na laptopu pokazuje, njen prvi korak je VPN protokol: IKEv2, OpenVPN, WireGuard ili klijent zasnovan na TLS-u. RADIUS se u toj razmjeni ne pojavljuje. Klijent se autentifikuje na prolazu certifikatom, korisničkim imenom i lozinkom ili EAP metodom koja se prenosi unutar postavljanja tunela.

To je važno kada čitate dnevnike, jer opću grešku autentifikacije koju korisnik vidi proizvodi prolaz nakon što je već razgovarao s nečim drugim. Ako klijent nikada ne stigne do prolaza, nema RADIUS zahtjeva za otklanjanje grešaka i sat proveden na RADIUS serveru je izgubljen. Potvrdite da je tunel uopšte podignut prije nego što dodirnete pozadinu.

Prolaz je RADIUS klijent

Kada postavljanje tunela dođe do tačke u kojoj se moraju provjeriti akreditivi, prolaz postaje server za mrežni pristup. Gradi Access-Request: User-Name, lozinku ili EAP sadržaj, NAS-IP-Address ili NAS-Identifier i Message-Authenticator kada metoda to zahtijeva. Zahtjev po pravilu ide na UDP 1812, a računovodstvo na 1813. Starije instalacije još koriste 1645 i 1646, pa pravilo firewall-a napisano za jedan par objašnjava mnogo tihih neuspjeha.

Obje strane dijele tajnu i ona nije korisnički akreditiv. Ona potpisuje razmjenu i svaki odgovor se provjerava prema njoj. Postavite tajnu različito na dvije strane i server ne odgovara lošom tajnom — on odbacuje zahtjev ili odgovor ne prođe provjeru, pa prolaz prijavi istek vremena. Pogrešna tajna i mrtav server izgledaju isto s prolaza, zato taj korak testiram klijentskim alatom prije nego optužim direktorij.

Protokol je mali i star — RFC 2865 definiše razmjenu autentifikacije — ali atributi koje nosi su ono na čemu je izgrađena većina VPN politike.

# 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'

RADIUS server može samo stajati ispred pružatelja identiteta

Ljudi govore o RADIUS-u i pružaocu identiteta kao da su ista kutija. Često nisu. RADIUS server primi Access-Request i zatim pita nešto drugo — Active Directory preko LDAP-a ili Kerberosa, lokalnu datoteku korisnika ili vanjsku uslugu — prije nego što odgovori. FreeRADIUS s modulom LDAP ili krb5, Windows NPS i Cisco ISE svi stoje na ovoj poziciji.

Ta razlika odlučuje gdje ćete gledati. Odbijena lozinka je odgovor pružatelja identiteta koji RADIUS prenosi. Istek vremena obično je dionica RADIUS–direktorij: istekao račun za vezivanje, nedostupan direktorij ili zahtjev usmjeren na pogrešnu pozadinu. Ako korisničko ime nosi sufiks domene, server može usmjeravati po njemu, a isti račun poslan kao CORP\alice i [email protected] može završiti na različitim mjestima. Na Windows NPS-u Security dnevnik bilježi 6272 za odobrenje i 6273 za odbijanje, što vam kaže da li je odluka uopšte došla od NPS-a.

Čitajte neuspjeh na koraku koji ga je proizveo

Jedna poruka o nemogućnosti povezivanja pokriva četiri različita neuspjeha. Prije nego što bilo šta promijenite, uskladite simptom s korakom koji ga je proizveo.

Posljednji red je onaj koji šalje ljude pogrešnom timu. Access-Accept znači da su akreditivi prihvaćeni; ne znači da je prolaz smjestio korisnika u pravi pool ili gurnuo rute. Atributi grupe važni su samo ako ih politika prolaza čita. Vidio sam ispravnu prijavu kako pada u gostinjski pool jer je mapiranje grupa na strani RADIUS-a bilo postavljeno za drugi atribut od onoga koji prolaz provjerava.

Pratite jednu prijavu od početka do kraja

Odaberite jedan testni račun i jedan prolaz, pa gledajte isti pokušaj na sve četiri tačke. Pokrenite otklanjanje grešaka na strani RADIUS-a — freeradius -X ispisuje zahtjev i svaki modul koji dotakne — pratite dnevnik autentifikacije prolaza i pokrenite tcpdump za UDP razmjenu. Povežite se jednom i pročitajte četiri traga po redu.

Ono što želite vidjeti je slaganje: prolaz je pitao za korisnika kojeg ste očekivali, RADIUS server je odabrao pozadinu koju ste očekivali, ta pozadina je vratila odluku i atributi u odgovoru odgovaraju politici koju prolaz primjenjuje. Prvo mjesto gdje se tragovi razilaze je vaša linija kvara. Ako odgovor ne nosi atribut grupe, problem je na strani RADIUS-a, ne u VPN profilu; ako atribut postoji i prolaz ga ignorira, problem je u politici prolaza.

Jedna sigurnosna napomena dok ste tamo. Zajednička tajna štiti razmjenu, ali ne šifrira većinu atributa. Ako su prolaz i RADIUS server na različitim segmentima, stavite tu dionicu na RADIUS preko TLS-a ili privatnog puta. Šifrirani korisnički tunel ne govori ništa o vezi prema pozadini.

Prije nego zatvorite tiket, potvrdite četiri stvari. Prolaz može dosegnuti RADIUS server na portu za koji je zaista konfigurisan. Zajednička tajna se podudara na obje strane. RADIUS server razrješava tačan oblik korisničkog imena koji prolaz šalje. Prihvatanje nosi atribute koje politika prolaza treba. Kada sva četiri vrijede, prijava koja i dalje ne uspijeva je problem politike prolaza, a ne autentifikacije.