Saan napupunta ang static challenge code sa pag-login sa OpenVPN

Nagpapakita ang kliyente ng ikalawang kahon pagkatapos ng field ng password, itinatype mo ang code mula sa hardware token, at nabibigo pa rin ang pag-login na may error sa pagpapatotoo. Umiiral ang kahon na iyon, kaya hiningi ito ng profile. Kung natanggap ng server ang halaga sa anyong naiintindihan nito ay ibang tanong, at iyon ang dapat sagutin muna.

Magsimula sa prompt na talagang ipinapakita ng iyong kliyente

Maaaring magdala ang profile ng direktiba ng static challenge na may prompt string at flag na kumokontrol kung ipinapakita ang sagot habang nagtatype ka. Ang prompt ang nakikita mo sa dialog; ang flag ay kagustuhan sa pagpapakita para sa parehong input. Wala sa dalawa ang nagsasabi sa server kung paano i-verify ang anuman.

Bilangin ang mga field na talagang ibinigay sa iyo. Isang field para sa username at isang nakatakip na field ay ordinaryong pag-login gamit ang password na walang anumang challenge. Ang ikalawang field na lumilitaw pagkatapos ng password, na may sariling label, ay ang kliyenteng nagpapatupad ng interaksyon ng challenge.

Kung hindi kailanman lumilitaw ang ikalawang kahon sa kliyenteng ginagamit mo, maaaring hindi ipinatupad ng kliyenteng iyon ang interaksyon, o ipinatupad lamang ito sa ibang front end tulad ng interface ng pamamahala. Mas mura ang suriin ang kliyente kaysa muling isulat ang profile, at doon karaniwang matatagpuan ang hindi pagkakatugma.

Ano ang dapat na sinusuportahan na ng server

Inilalarawan ng profile kung ano ang dapat kolektahin ng kliyente. Hindi nito binubuksan ang pag-verify sa server, at ang server na walang katumbas na integrasyon ng pagpapatotoo ay makakatanggap lamang ng password na hindi nito nakikilala. Iyon ang dahilan kung bakit may mga deployment na nagpapakita ng prompt at tinatanggihan ang bawat code, at iyon ang dahilan kung bakit ang sagot ng operator kung aling mekanismo ang gumagawa ng pagsusuri ang mahalaga.

Tanungin ang operator kung aling mekanismo ang gumagawa ng pagsusuri. Maaaring isang plugin na nakikipag-usap sa PAM, isang script hook na nagpapatunay ng sagot laban sa isang serbisyo ng token, o isang integrasyong nakabatay sa pamamahala na siyang nag-aanalisa ng naka-package na halaga. Bawat isa sa kanila ay umaasa ng bahagyang ibang input.

Dito rin kailangang i-calibrate ang mga inaasahan. Ang ikalawang prompt ay mekanismo ng input, hindi patunay na ipinapatupad ang ikalawang salik, dahil nangyayari ang pagpapatupad sa panig ng server at lumilitaw lamang kapag sinubukan mo ang maling code.

Ang naka-encode na field na ipinapadala ng interface ng pamamahala

Kapag pinapatakbo ng front end ang koneksyon sa pamamagitan ng interface ng pamamahala, ang password at sagot sa challenge ay pinagsasama sa isang halaga bago ipadala. Idinodokumento ng sanggunian ng interface ng pamamahala ang format: isang prefix, pagkatapos ang password at ang sagot bilang magkahiwalay na bahagi ng Base64.

Ang Base64 ay encoding, hindi proteksyon. Wala itong itinatago sa sinumang makababasa ng field, at hindi nito ginagawang magagamit muli ang isang beses gamiting code. Ang naka-package na halaga ay karapat-dapat sa parehong pagtrato ng password: labas sa mga shared na profile, labas sa mga command line at labas sa mga diagnostic log.

Ang encoding na iyon din ang pinakakaraniwang pinagmumulan ng kalituhan, dahil may tatlong anyo na ngayong magkamukha at hindi mapagpapalit. Ang simpleng credential file ay may password. Ang literal na pagsasama ng password at code ay may ibang string. Ang naka-package na sagot ng management client ay may pangatlo. Kumpirmahin kung alin ang inaasahan ng iyong verification path bago baguhin ang isang field dahil lang nawala ang isang error.

Static laban sa dynamic: magkaibang oras

Ang static challenge ay alam bago isumite ang unang credential, kaya maaaring hilingin ito ng kliyente nang maaga. Ang dynamic challenge ay dumarating mamaya, ipinapadala ng authentication workflow pagkatapos magsimula ang palitan, at nangangailangan ito ng kliyenteng kayang humawak ng kahilingan sa gitna ng usapan.

Ang suporta sa isa ay hindi nagbibigay ng isa pa. Ang direktiba ng profile na nagse-set ng static prompt ay hindi nagpapatupad ng challenge na sinimulan ng server, at ang front end na humahawak ng dynamic na kahilingan ay maaaring hindi pa rin magpakita ng static. Ang pagbasa kung aling panig ang nagsimula ng kahilingan ang pinakamabilis na paraan upang makilala sila.

Ang operasyong walang nagmamatyag ang lugar kung saan ito nagiging tanong ng disenyo at hindi ng interface. Ang naka-save na code ay hindi matibay na credential sa oras ng boot, at ang muling pagkonekta pagkalipas ng mga oras ay mangangailangan ng sariwang input maliban kung sinusuportahan ng deployment ang isang kaayusan ng token na sadyang pinagana ng operator.

Subukan ang tagumpay at pagkabigo, hindi lamang ang dialog

Patakbuhin ang dalawang kalahati ng pagsubok. Ang tamang credential na may wastong sagot ay dapat magtagumpay; ang tamang credential na may sadyang maling sagot ay dapat tanggihan. Kung pareho silang nagtagumpay, ang kliyente ay nangongolekta ng input na walang nagbe-verify, at ang dialog ay napagkamalang kontrol. Ang nag-iisang pagsubok na iyon ay humuhuli ng mas maraming deployment kaysa sa anumang pagsusuri ng profile.

Pagkatapos ulitin ang koneksyon pagkatapos ng muling pagkonekta, gamit ang account na hindi naka-enroll, at sa pamamagitan ng kliyenteng aktwal na pinapatakbo ng iyong mga user. Ang paglitaw ng prompt ay pag-uugali ng kliyente; ang pagtanggi sa maling code ay ang server na nagpapatupad ng isang bagay.