Kako prijava v VPN doseže RADIUS in vašega ponudnika identitete

Prejšnji teden se je uporabnik lahko prijavil v VPN in vseeno pristal v omrežju, kjer se nič ni razrešilo. Odjemalec je rekel povezano, dnevnik prehoda je rekel Access-Accept, ekipa za identiteto pa je rekla, da je račun v redu. Prijava je delovala; avtorizacija za njo ne. Ko prijava v VPN ne uspe, grem po poti, ki jo zahteva dejansko opravi — odjemalec, prehod, strežnik RADIUS, ponudnik identitete — in se ustavim pri prvem skoku, katerega odgovor se ne ujema z naslednjim.

Odjemalec nikoli ne govori RADIUS

Karkoli prikazuje aplikacija na prenosniku, njen prvi skok je protokol VPN: IKEv2, OpenVPN, WireGuard ali odjemalec na osnovi TLS. RADIUS se v tej izmenjavi ne pojavi. Odjemalec se overi pri prehodu s potrdilom, uporabniškim imenom in geslom ali metodo EAP, ki se prenaša v nastavitvi tunela.

To je pomembno pri branju dnevnikov, ker splošno napako overjanja, ki jo vidi uporabnik, ustvari prehod po tem, ko je že govoril z nečim drugim. Če odjemalec nikoli ne doseže prehoda, ni zahteve RADIUS za razhroščevanje in ura, porabljena na strežniku RADIUS, je izgubljena. Preden se dotaknete zaledja, potrdite, da se je tunel sploh dvignil.

Prehod je odjemalec RADIUS

Ko nastavitev tunela doseže točko, na kateri je treba preveriti poverilnice, prehod postane strežnik za dostop do omrežja. Sestavi Access-Request: User-Name, geslo ali EAP tovor, NAS-IP-Address ali NAS-Identifier in Message-Authenticator, ko metoda to zahteva. Zahteva privzeto gre na UDP 1812, obračun pa na 1813. Starejše namestitve še vedno uporabljajo 1645 in 1646, zato pravilo požarnega zidu, napisano za en par, pojasni veliko tihih napak.

Obe strani si delita skrivnost in ta ni uporabniška poverilnica. Podpisuje izmenjavo in vsak odgovor se preveri glede na njo. Nastavite skrivnost različno na obeh straneh in strežnik ne bo odgovoril z napačno skrivnostjo — zahtevo zavrže ali odgovor ne prestane preverjanja, zato prehod sporoči časovno prekoračitev. Napačna skrivnost in mrtev strežnik sta s prehoda videti enako, zato skok preizkusim z odjemalskim orodjem, preden obtožim imenik.

Protokol je majhen in star — RFC 2865 opredeljuje izmenjavo overjanja — a atributi, ki jih nosi, so osnova, na kateri je zgrajena večina pravilnikov 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'

Strežnik RADIUS je morda le sprednja stran ponudnika identitete

Ljudje govorijo o RADIUS in ponudniku identitete, kot da bi bila ista škatla. Pogosto nista. Strežnik RADIUS prejme Access-Request in nato pred odgovorom vpraša nekaj drugega — Active Directory prek LDAP ali Kerberos, krajevno datoteko uporabnikov ali zunanjo storitev. FreeRADIUS z modulom LDAP ali krb5, Windows NPS in Cisco ISE vsi stojijo na tem položaju.

Razlika odloča, kam gledati. Zavrnjeno geslo je odgovor ponudnika identitete, ki ga RADIUS posreduje. Časovna prekoračitev je običajno odsek RADIUS–imenik: potekel račun za vezavo, nedosegljiv imenik ali zahteva, usmerjena na napačno zaledje. Če ima uporabniško ime pripono domene, lahko strežnik usmerja po njej, in isti račun, poslan kot CORP\alice in [email protected], lahko pristane na različnih mestih. V Windows NPS dnevnik Security zapiše 6272 ob odobritvi in 6273 ob zavrnitvi, kar pove, ali je odločitev sploh prišla iz NPS.

Napako preberite pri skoku, ki jo je povzročil

Eno sporočilo o nezmožnosti povezave pokriva štiri različne napake. Preden karkoli spremenite, uskladite simptom s skokom, ki ga je povzročil.

Zadnja vrstica je tista, ki pošlje ljudi k napačni ekipi. Access-Accept pomeni, da so bile poverilnice sprejete; ne pomeni, da je prehod uporabnika postavil v pravi bazen ali potisnil poti. Atributi skupine so pomembni le, če jih pravilnik prehoda bere. Videl sem pravilno prijavo pristati v gostinskem bazenu, ker je bilo preslikavanje skupin na strani RADIUS nastavljeno za drug atribut, kot je tisti, ki ga prehod pregleda.

Sledite eni prijavi od začetka do konca

Izberite en testni račun in en prehod, nato opazujte isti poskus na vseh štirih točkah. Zaženite razhroščevanje na strani RADIUS — freeradius -X izpiše zahtevo in vsak modul, ki se ga dotakne — sledite dnevniku overjanja prehoda in zaženite tcpdump za izmenjavo UDP. Povežite se enkrat in preberite štiri sledi po vrsti.

Želite videti soglasje: prehod je vprašal o uporabniku, ki ste ga pričakovali, strežnik RADIUS je izbral zaledje, ki ste ga pričakovali, to zaledje je vrnilo odločitev in atributi v odgovoru ustrezajo pravilniku, ki ga prehod uporablja. Prvo mesto, kjer se sledi ne ujemajo, je vaša meja napake. Če odgovor ne nosi atributa skupine, je težava na strani RADIUS, ne v profilu VPN; če je atribut tam in ga prehod ignorira, je težava pravilnik prehoda.

Ena varnostna opomba, medtem ko ste tam. Skupna skrivnost ščiti izmenjavo, vendar ne šifrira večine atributov. Če sta prehod in strežnik RADIUS v različnih segmentih, postavite ta skok na RADIUS prek TLS ali zasebne poti. Šifriran uporabniški tunel ne pove ničesar o povezavi do zaledja.

Preden zaprete zahtevek, potrdite štiri stvari. Prehod doseže strežnik RADIUS na vratih, za katera je dejansko nastavljen. Skupna skrivnost se ujema na obeh straneh. Strežnik RADIUS razreši natančno obliko uporabniškega imena, ki jo pošlje prehod. Sprejetje nosi atribute, ki jih pravilnik prehoda potrebuje. Ko veljajo vsi štirje, je prijava, ki še vedno ne uspe, težava pravilnika prehoda, ne overjanja.