Bakit hindi kayang i-on ng pag-edit ng .ovpn file ang MFA sa server

Nagdadagdag ka ng auth-user-pass sa isang profile, kumokonekta muli, at humihingi ang kliyente ng username at password. Mukhang naka-on ang MFA. Pagkatapos i-type mo ang code mula sa maling account, o code na nag-expire sampung minuto na ang nakalipas, at umaakyat pa rin ang tunnel. Iyon ang sintomas: nagbago ang kliyente, hindi ang server. Ang one-time password ay isang factor lamang kapag ang isang verifier sa server ang nagpapasya kung valid ito para sa pagkakakilanlang nag-aangkin nito.

Pinapatunayan lamang ng prompt na nagtanong ang kliyente, wala nang iba

Ang .ovpn file ay isang dokumento sa panig ng kliyente. Maaari nitong sabihin sa kliyente na humingi ng mga kredensyal, i-cache ang mga ito, o itigil ang paggawa nito. Hindi nito mairehistro ang isang user, makapag-install ng PAM module, o mapilit ang server na humingi ng pangalawang factor na hindi nito sinisiyasat sa ngayon.

Ang pag-install ng authentication app sa telepono ay hindi rin lumilikha ng ugnayang iyon. Ang Google Authenticator PAM project ay isang bahagi ng pag-verify ng OTP na maaaring tumayo sa likod ng OpenVPN; hindi ito paraan upang idikit ang pag-login sa Google account sa isang na-import na profile.

Ang pagpaparehistro ang bahaging hindi kayang gawin ng isang profile

Ang TOTP ay nangangailangan ng materyal sa pagpaparehistro na ibinabahagi sa pagitan ng authentication app at ng verifier nito. Ang anim na digit sa telepono ay output; ang seed sa likod ng mga ito ay ang sikreto, at kabilang ito sa isang pagkakakilanlan.

Kaya kailangan ng operator ng proseso ng pagpaparehistro na nag-uugnay ng tamang seed sa tamang pagkakakilanlang VPN, kasama pa ang isang na-verify na landas ng pagpapalit para sa nawalang telepono. Ang pagpayag sa mga user na mag-upload ng file na pinangalanan sa kanila ay ginagawang pagkakataon ng pag-agaw ng account ang pagpaparehistro, at hindi iyon binabago ng pag-encrypt sa upload.

Ang disenyong nakabatay sa PAM ay hindi kailangang lumikha ng hiwalay na Unix account para sa bawat VPN user. Ang dokumentasyon ng module ay sumusuporta sa mga alternatibong landas ng sikreto at isang dedikadong account para sa pag-access ng file, na isang pagkakakilanlan ng file system at hindi ang pagkakakilanlan sa pag-login na vine-verify.

Ang karaniwang pagkakamali ay isang nakapirming landas ng sikreto na nagtatapos sa isang username, kinopya mula sa halimbawa ng isang user. Iyon ay demonstrasyon ng isang pagkakakilanlan, hindi paghahanap sa bawat user, at ang paggamit nito sa bawat kahilingan ay hindi nagbibigay kaninuman ng independiyenteng nakarehistrong authentication app. Isulat ang pagmamapa ng pagkakakilanlan, protektahan ang mga seed file, at panatilihin ang mga pagsusuri sa password, certificate at account sa parehong authentication stack.

Basahin ang PAM stack upang makita kung ano talaga ang kailangan

Ang linyang tulad ng account required pam_permit.so ay hindi nagpapatupad ng pagiging karapat-dapat ng account at hindi nagdadagdag ng factor. Pinapayagan nito ang yugto ng pamamahala ng account ng PAM, na isang pahayag tungkol sa isang yugto at hindi tungkol sa iyong mga user.

Ganoon din sa mga permissive na opsyon sa pagpaparehistro. Ang pagtanggap ng mga user na walang nakarehistrong sikreto ay maaaring sadyang desisyon sa pag-deploy, ngunit hindi ito patunay na mandatory ang MFA, at dapat itong isulat bilang pansamantalang pagbubukod na may petsa ng pagtatapos.

Itugma ang interaksyon ng kliyente sa disenyo ng server

auth-user-pass

Ang direktibang iyon ay humihingi ng input ng username at password. Hindi ito nag-configure ng PAM, hindi lumilikha ng talaan ng pagpaparehistro, at hindi sinasabi sa server na ang field ng password ay naglalaman ng halagang TOTP. Dapat magkasundo ang integrasyon sa server at ang kliyente sa isang interaksyon na talagang sinusuportahan ng deployment: isang hamon, isang dokumentadong pinagsamang format ng kredensyal, o isang flow na partikular sa produkto.

Huwag magdagdag ng code sa password dahil lang nagpapakita ang kliyente ng isang field. Gumagana lamang iyon kung saan eksaktong inaasahan ng plugin ng server ang format na iyon, at nabibigo ito nang nakalilito sa lahat ng ibang lugar.

Itago ang mga seed at QR material mula sa mga pinagsasaluhang profile at karaniwang diagnostic log. Ang code na isinumite sa authenticated na channel ng pag-login ay hindi kaparehong bagay sa seed na ibinigay sa kontroladong pagpaparehistro, at ang paghahalo sa kanila sa isang support ticket ang paraan ng pagtakas ng mga sikreto.

Mga muling pagkonekta, token at ang pagsubok na magpapasya

Planuhin ang mangyayari pagkatapos ng unang matagumpay na pag-login. Ang dating tinanggap na code ay maaaring nag-expire o tinanggihan bilang replay sa susunod na authentication. Kinokontrol ng auth-nocache ang pagpapanatili ng kredensyal at hindi nag-i-install ng MFA, at ang reneg-sec 0 ay hindi depinisyon ng suporta sa TOTP, gaano man kadalas itong lumitaw sa mga thread ng forum.

Ang ilang deployment ay naglalabas ng authentication token pagkatapos ng paunang pagsusuri upang hindi na muling magtanong ang mga muling pagkonekta. Iyon ay desisyon sa disenyo na may sariling window ng validity at sariling kuwento ng pagpapawalang-bisa, hindi isang default na namamana mo.

Pagkatapos ay subukan ang patakaran sa pagtanggap sa kliyenteng talagang ginagamit ng mga tao. Ang nakarehistrong user na may tamang password, certificate at kasalukuyang code ay dapat makakonekta. Ang maling code, user na walang pagpaparehistro, at ipinagbabawal na account ay dapat mabigo ang bawat isa, at ang dahilan ay dapat makita sa log ng server. Hanggang hindi mo pa nakita ang mga pagtanggi na iyon, may prompt ka, hindi patakaran.