Kā VPN pieteikšanās nonāk līdz RADIUS un jūsu identitātes nodrošinātājam

Pagājušajā nedēļā lietotājs varēja pieteikties VPN un tomēr nonāca tīklā, kur nekas netika atrisināts. Klients teica savienots, vārtejas žurnāls teica Access-Accept, un identitātes komanda teica, ka konts ir kārtībā. Pieteikšanās bija izdevusies; autorizācija aiz tās ne. Kad VPN pieteikšanās neizdodas, es eju pa ceļu, ko pieprasījums patiešām veic — klients, vārteja, RADIUS serveris, identitātes nodrošinātājs — un apstājos pie pirmā lēciena, kura atbilde nesaskan ar nākamo.

Klients nekad nerunā RADIUS

Lai ko rādītu klēpjdatora lietotne, tās pirmais lēciens ir VPN protokols: IKEv2, OpenVPN, WireGuard vai uz TLS balstīts klients. RADIUS šajā apmaiņā neparādās. Klients autentificējas pie vārtejas ar sertifikātu, lietotājvārdu un paroli vai EAP metodi, kas tiek pārnesta tuneļa iestatījumos.

Tas ir svarīgi, lasot žurnālus, jo vispārīgo autentifikācijas kļūdu, ko lietotājs redz, rada vārteja pēc tam, kad tā jau ir runājusi ar kaut ko citu. Ja klients nekad nesasniedz vārteju, nav RADIUS pieprasījuma, ko atkļūdot, un stunda, kas pavadīta pie RADIUS servera, ir izšķiesta. Pirms pieskaraties backend, pārliecinieties, ka tunelis vispār ir pacēlies.

Vārteja ir RADIUS klients

Tiklīdz tuneļa iestatīšana sasniedz punktu, kur jāpārbauda pieteikšanās dati, vārteja kļūst par tīkla piekļuves serveri. Tā veido Access-Request: User-Name, paroli vai EAP kravu, NAS-IP-Address vai NAS-Identifier, un Message-Authenticator, kad metode to prasa. Pieprasījums pēc noklusējuma dodas uz UDP 1812, bet uzskaite — uz 1813. Vecāki izvietojumi joprojām izmanto 1645 un 1646, tāpēc vienam pārim rakstīts ugunsmūra noteikums izskaidro daudzas klusas neveiksmes.

Abas puses dala noslēpumu, un tas nav lietotāja pieteikšanās dati. Tas paraksta apmaiņu, un katra atbilde tiek pārbaudīta pret to. Iestatiet noslēpumu atšķirīgi abās pusēs, un serveris neatbildēs ar sliktu noslēpumu — tas izmet pieprasījumu vai atbilde neiztur pārbaudi, tāpēc vārteja ziņo par taimautu. Nepareizs noslēpums un miris serveris no vārtejas izskatās vienādi, tāpēc lēcienu pārbaudu ar klienta rīku, pirms vainoju direktoriju.

Protokols ir mazs un vecs — RFC 2865 definē autentifikācijas apmaiņu —, bet atribūti, ko tas pārnes, ir pamats, uz kura būvēta lielākā daļa VPN politikas.

# 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 serveris var būt tikai identitātes nodrošinātāja priekšpuse

Cilvēki runā par RADIUS un identitātes nodrošinātāju tā, it kā tie būtu viena un tā pati kaste. Bieži vien nav. RADIUS serveris saņem Access-Request un pēc tam pirms atbildes pajautā kaut ko citu — Active Directory caur LDAP vai Kerberos, vietēju lietotāju failu vai ārēju pakalpojumu. FreeRADIUS ar LDAP vai krb5 moduli, Windows NPS un Cisco ISE visi atrodas šajā pozīcijā.

Atšķirība nosaka, kur skatīties. Noraidīta parole ir identitātes nodrošinātāja atbilde, ko pārsūta RADIUS. Taimauts parasti ir posms no RADIUS līdz direktorijai: beidzies bind konts, nesasniedzama direktorija vai pieprasījums, kas novirzīts uz nepareizu backend. Ja lietotājvārdā ir domēna sufikss, serveris var maršrutēt pēc tā, un viens un tas pats konts, kas nosūtīts kā CORP\alice un [email protected], var nonākt dažādās vietās. Windows NPS Security žurnālā tiek ierakstīts 6272 par piešķiršanu un 6273 par atteikumu, kas pasaka, vai lēmums vispār nāca no NPS.

Lasiet neveiksmi tajā lēcienā, kas to radīja

Viens ziņojums par neiespējamu savienojumu aptver četras dažādas neveiksmes. Pirms kaut ko maināt, saskaņojiet simptomu ar lēcienu, kas to radīja.

Pēdējā rinda ir tā, kas sūta cilvēkus pie nepareizās komandas. Access-Accept nozīmē, ka pieteikšanās dati tika pieņemti; tas nenozīmē, ka vārteja ir ievietojusi lietotāju pareizajā baseinā vai iespiedusi maršrutus. Grupas atribūti ir svarīgi tikai tad, ja vārtejas politika tos lasa. Esmu redzējis, kā pareiza pieteikšanās nonāk viesu baseinā, jo grupu kartēšana RADIUS pusē bija iestatīta citam atribūtam nekā tam, ko pārbauda vārteja.

Izsekojiet vienu pieteikšanos no sākuma līdz beigām

Izvēlieties vienu testa kontu un vienu vārteju, pēc tam novērojiet to pašu mēģinājumu visos četros punktos. RADIUS pusē sāciet atkļūdošanas palaišanu — freeradius -X izdrukā pieprasījumu un katru moduli, kam tas pieskaras — sekojiet vārtejas autentifikācijas žurnālam un palaidiet tcpdump UDP apmaiņai. Savienojieties vienreiz un izlasiet četras pēdas pēc kārtas.

To, ko vēlaties redzēt, ir saskaņa: vārteja jautāja par lietotāju, kuru gaidījāt, RADIUS serveris izvēlējās backend, kuru gaidījāt, tas backend atgrieza lēmumu, un atbildes atribūti atbilst politikai, ko piemēro vārteja. Pirmā vieta, kur pēdas nesaskan, ir jūsu bojājuma līnija. Ja atbildē nav grupas atribūta, problēma ir RADIUS pusē, nevis VPN profilā; ja atribūts ir un vārteja to ignorē, problēma ir vārtejas politika.

Viena drošības piezīme, kamēr esat tur. Koplietotais noslēpums aizsargā apmaiņu, bet tas nešifrē lielāko daļu atribūtu. Ja vārteja un RADIUS serveris atrodas dažādos segmentos, novietojiet šo lēcienu uz RADIUS caur TLS vai privātu ceļu. Šifrēts lietotāja tunelis neko nepasaka par backend saiti.

Pirms aizverat biļeti, apstipriniet četras lietas. Vārteja sasniedz RADIUS serveri tajā portā, kuram tā patiešām ir konfigurēta. Koplietotais noslēpums sakrīt abās pusēs. RADIUS serveris atrisina precīzo lietotājvārda formu, ko sūta vārteja. Pieņemšana pārnes atribūtus, kas nepieciešami vārtejas politikai. Kad visi četri ir spēkā, pieteikšanās, kas joprojām neizdodas, ir vārtejas politikas, nevis autentifikācijas problēma.