VPN pieteikšanās iestrēgst pēc RADIUS Access-Challenge

Jūsu parole ir pareiza, VPN pieteikšanās tomēr neizdodas, un RADIUS serveris, iespējams, ir izdarījis tieši to, kas tam tika likts. Vārteja, visticamāk, saņēma Access-Challenge, neparādīja neko noderīgu un pēc tam vai nu beidzās taimauts, vai arī tā šo atbildi uzskatīja par noraidījumu. No klienta puses tas izskatās kā nepareizi pieteikšanās dati vai salauzts tunelis. Cēlonis parasti atrodas sarunas vidū, kuru neviens nav ierakstījis.

Viena pieteikšanās, divas RADIUS apmaiņas

Kad aizmugursistēma vēlas otru faktoru, tā uz pirmo pieprasījumu neatbild ar pieņemšanu vai noraidījumu. Tā atbild ar kodu 11 un gaida lietotāja nākamo atbildi, kas vārtejai jānosūta atpakaļ turpinājuma pieprasījumā. Šis turpinājuma pieprasījums pieder tai pašai autentifikācijas sarunai, nevis jaunam pieteikšanās mēģinājumam.

Strādājošā konfigurācijā lietotājs redz otru uzvedni: vispirms paroli, pēc tam vienreizēju kodu, vai vienu apvienotu uzvedni, ja operators tādu ir dokumentējis. Bojātā konfigurācijā otrā uzvedne nekad neparādās un pieteikšanās vienkārši neizdodas.

Šis ir simptoms, kas jāmeklē, un to ir viegli apstiprināt tikai no klienta puses: ja VPN klients pieprasa tieši vienu noslēpumu un pēc tam noraida paroli, par kuru jūs zināt, ka tā ir derīga, apmaiņa, iespējams, beidzās pie izaicinājuma.

Ko izaicinājums patiesībā nes

RADIUS specifikācija apraksta kodu 11 sadaļā 4.4 un atļauj divus atribūtus, kas šeit ir svarīgi. Reply-Message satur lietotājam paredzētu tekstu, un State satur necaurredzamu vērtību, kuru serveris vēlas saņemt atpakaļ. NAS nedrīkst interpretēt State, tikai atgriezt to nemainītu.

Turpinājuma pieprasījums izmanto jaunu Identifier un jaunu Request Authenticator, un tam jānes tā pati State vērtība plus lietotāja atbilde. Serveris to sasaista ar gaidāmo izaicinājumu tieši caur šo State, tāpēc vārteja, kas atribūtu no jauna ģenerē vai izmet, nevar pabeigt ceremoniju. Arī response authenticator katrā atbildē ir jāvalidē, citādi NAS ir jāizmet pakete.

Sadaļa 4.4 pievieno detaļu, kas izskaidro lielāko daļu kluso kļūdu: NAS, kas nevar atbalstīt izaicinājumus, Access-Challenge uzskata par noraidījumu. Ja jūsu vārtejas VPN pakalpojums ir vecāks par šo atbalstu vai to izlaiž, aizmugursistēmas pieprasījums par otru faktoru kļūst par tūlītēju «autentifikācija neizdevās» bez jebkādas uzvednes.

Kur pazūd ķēdes pieprasījums

Pirmais aizdomās turamais ir uzvednes ceļš, nevis pieteikšanās dati. Portāls, kas tīmekļa pieteikšanās reizēm rāda OTP lauku, to automātiski nedara VPN pakalpojumam, un dažas vārtejas izaicinājumu nodod tikai tiem klientiem, kuri paziņo par šo iespēju. Pārbaudiet to pašu kontu abās ieejās; ja portāls strādā un VPN ne, jūs skatāties uz nodošanu, nevis uz tokenu.

Ievades formāts ir otrais aizdomās turamais. Paroles un koda savienošana bez piegādātāja dokumentētā atdalītāja vai ļaušana saglabātiem datiem atkārtot vecu kodu neizdodas tā, ka izskatās identiski nepareizai parolei. Izmantojiet operatora dokumentēto atsevišķo uzvedni vai apvienoto formātu un nekad neizgudrojiet atdalītāju.

Izlaidumam raksturīgi defekti pastāv, taču pirms gadiem labotu versiju saraksts nav šodienas izvietošanas diagnoze. Lasiet tās programmatūras izlaiduma piezīmes, kuru jūs patiešām darbināt, un saglabājiet novēroto apmaiņas posmu kā savu pierādījumu.

Izsekojiet vienam mēģinājumam no sākuma līdz beigām

Reproducējiet to vienreiz ar ieslēgtu servera puses atkļūdošanu un turiet visas pārējās sesijas ārpus uztveršanas loga:

$ sudo radsniff -i eth0 -x -f 'udp port 1812'
$ sudo freeradius -X
$ radtest alice 'password' 127.0.0.1 0 testing123

Izvadē meklējiet sarunas formu, nevis vienu rindu. Pirmais Access-Request ar Identifier 3, State nesošs Access-Challenge, tad otrais Access-Request ar Identifier 4, kas atkārto šo State un ietver lietotāja atbildi. Ja otrais pieprasījums trūkst, vārteja nekad nav turpinājusi. Ja tas pienāk bez State, serveris nevar to sasaistīt ar gaidāmo izaicinājumu un parasti noraidīs.

Kad kopīgojat pēdas, aizsedziet pieteikšanās datus, tokenus un nevajadzīgos identitātes datus, un korelējiet notikumus no viena mēģinājuma, nevis sajaucot atkārtojumus no vairākām pārlūka cilnēm. Laika zīmogi šeit ir jūsu draugs; izaicinājums, kas pienāk pēc tam, kad klients ir padevies, lietotājam izskatās kā noraidījums, bet žurnālā kā lēna atbilde.

Vēlamais galīgais stāvoklis ir pabeigta, autorizēta saruna un pēc tās paredzētā piekļuve pakalpojumam. Atbilde, kas pienāk no RADIUS servera, pierāda daudz mazāk.