Kuhu läheb staatilise väljakutse kood OpenVPN-i sisselogimisel

Klient näitab paroolivälja järel teist kasti, te sisestate koodi riistvara tokenist ja sisselogimine ebaõnnestub ikkagi autentimisveaga. See kast on olemas, seega profiil küsis seda. Kas server sai väärtuse kunagi sellisel kujul, millest ta aru saab, on teine küsimus, ja just sellele tasub esimesena vastata.

Alustage viipest, mida teie klient tegelikult näitab

Profiil võib kanda staatilise väljakutse direktiivi koos viibeteksti ja lipuga, mis juhib, kas vastus kuvatakse tippimise ajal. Viide on see, mida te dialoogis näete; lipp on sama sisestuse kuvaeelistus. Kumbki neist ei ütle serverile, kuidas midagi kontrollida.

Loendage väljad, mis teile tegelikult anti. Üks väli kasutajanime jaoks pluss üks maskeeritud väli on tavaline parooliga sisselogimine ilma igasuguse väljakutsetseta. Teine väli, mis ilmub pärast parooli ja millel on oma silt, on klient, kes rakendab väljakutse interaktsiooni.

Kui teine kast ei ilmu kunagi kliendis, mida te kasutate, ei pruugi see klient interaktsiooni rakendada või rakendab seda ainult teise esiliidese, näiteks haldusliidese kaudu. Kliendi kontrollimine on odavam kui profiili ümberkirjutamine, ja tavaliselt asubki lahknevus just seal.

Mida server peab juba toetama

Profiil kirjeldab, mida klient peaks koguma. See ei luba serveris kontrollimist, ja server, millel puudub vastav autentimislõimis, saab lihtsalt parooli, mida ta ei tunne ära. Seetõttu näitavad mõned juurutused viidet ja lükkavad tagasi iga koodi, ja seetõttu on operaatori vastus selle kohta, milline mehhanism kontrolli teeb, see vastus, mis loeb.

Küsige operaatorilt, milline mehhanism kontrolli teeb. See võib olla pistikprogramm, mis räägib PAM-iga, skriptikonks, mis valideerib vastuse tokeniteenuse vastu, või halduspõhine lõimis, mis sõelub pakitud väärtust ise. Igaüks neist ootab veidi erinevat sisendit.

Siin tuleb ka ootusi kalibreerida. Teine viide on sisestusmehhanism, mitte tõestus, et teist faktorit rakendatakse, sest rakendamine toimub serveri poolel ja ilmneb alles siis, kui testite vale koodi.

Kodeeritud väli, mille haldusliides saadab

Kui esiliides juhib ühendust haldusliidese kaudu, pakitakse parool ja väljakutse vastus enne esitamist ühte väärtusesse. Haldusliidese viide kirjeldab vormingut: eesliide, seejärel parool ja vastus eraldi Base64 komponentidena.

Base64 on kodeering, mitte kaitse. See ei varja midagi kellegi eest, kes suudab välja lugeda, ega muuda ühekordset koodi millegiks korduvkasutatavaks. Pakitud väärtus väärib sama kohtlemist nagu parool: välja jagatud profiilidest, välja käsuridadest ja välja diagnostikalogidest.

See kodeering on ka kõige tavalisem segaduse allikas, sest nüüd on kolm kuju, mis näevad sarnased välja ja ei ole vahetatavad. Tavaline volituste fail sisaldab parooli. Parooli ja koodi sõnasõnaline ühend sisaldab teistsugust stringi. Halduskliendi pakitud vastus sisaldab kolmandat. Kinnitage, millist teie kontrollitee ootab, enne kui muudate välja ainult sellepärast, et viga kadus.

Staatiline versus dünaamiline: erinev ajastus

Staatiline väljakutse on teada enne esimese volituse esitamist, seega saab klient seda ette küsida. Dünaamiline väljakutse saabub hiljem, selle saadab autentimisvoog pärast seda, kui vahetus on juba alanud, ja see vajab klienti, mis suudab käsitleda päringut keset vestlust.

Ühe toetamine ei anna teile teist. Staatilise viibe seadistav profiilidirektiiv ei rakenda serveri algatatud väljakutset, ja dünaamilisi päringuid käsitlev esiliides ei pruugi ikkagi staatilist näidata. Lugemine, kumb pool päringu algatas, on kiireim viis neid eristada.

Järelevalveta töö on koht, kus sellest saab disainiküsimus, mitte liidese küsimus. Salvestatud kood ei ole vastupidav alglaadimisvolitus, ja tunde hiljem toimuv uuestiühendamine vajab värsket sisendit, kui juurutus ei toeta tokenikorraldust, mille operaator on teadlikult lubanud.

Testige õnnestumist ja ebaõnnestumist, mitte ainult dialoogi

Viige läbi mõlemad testi pooled. Õiged volitused kehtiva vastusega peaksid õnnestuma; õiged volitused teadlikult vale vastusega tuleks tagasi lükata. Kui mõlemad õnnestuvad, kogub klient sisendit, mida miski ei kontrolli, ja dialoogi on peetud juhtimisvahendiks. See üks test püüab rohkem juurutusi kui ükskõik milline profiili ülevaatus.

Seejärel korrake ühendust pärast uuestiühendamist, kontoga, mis ei ole registreeritud, ja läbi selle kliendi, mida teie kasutajad tegelikult kasutavad. Viibe ilmumine on kliendi käitumine; vale koodi tagasilükkamine on server, mis midagi rakendab.