OpenVPN username-as-common-name: bakit walang laman ang iyong pagsusuri ng CN
Ang script na client-connect na naghahambing ng common_name sa username ay maaaring maghambing ng pangalan sa sarili nito. Ikabit ang sertipiko sa account bago tumakbo ang pagpapalit.
Nagdadagdag ka ng script na client-connect na tumatanggi sa bawat koneksyon kung saan ang common_name ay iba sa username, at mukhang ugnayan ito sa pagitan ng sertipiko at account. Sa server na nagpapatakbo ng username-as-common-name, nawala na ang kahulugan ng paghahambing na iyon sa oras na tumakbo ang script. Pareho ang string ng dalawang halaga, kaya pumapasa ang pagsubok para sa sertipikong ibinigay sa ibang tao nang lubusan.
Hindi mali ang pagsusuri dahil masamang nakasulat ang script. Mali ito dahil ang halagang binabasa nito ay napalitan na nang mas maaga sa parehong koneksyon.
Ano ang tila pinapatunayan ng paghahambing
Ang pagpapatunay sa pamamagitan ng sertipiko at ang pagpapatunay sa pamamagitan ng password ay magkaibang patunay, at maaaring hingin ng server ang pareho nang hindi hinihinging pag-aari ng isang tao. Totoo ang agwat: ang wastong sertipiko ng device at anumang wastong account ay ibang pag-aangkin kaysa sa sertipikong iyon at isang pinangalanang account. Ang script na naghahambing ng common_name sa username ay binabasa na parang nawawalang ugnayan sa pagitan ng dalawa. Magiging ganoon ito kung ang common_name ay nangangahulugan pa rin ng sinabi ng sertipiko.
Kung gayon ba ay nakasalalay sa isang opsyon ng server, at ang opsyong iyon ay karaniwang binubuksan dahil sa walang kaugnayang dahilan, tulad ng pagpapadali ng pagbibigay ng pangalan sa mga file ng configuration ng bawat user.
Ano ang ginagawa ng username-as-common-name sa pangalan
Kapag bukas ang username-as-common-name, pinapalitan ng OpenVPN ang karaniwang pangalan ng sertipiko ng na-authenticate na username pagkatapos ma-verify ang username at password. Natatanggap pa rin ng verification hook na tumatakbo sa pagsusuring iyon ang karaniwang pangalan ng sertipiko, dahil hindi pa nangyayari ang pagpapalit. Lahat ng sumunod, kasama ang client-connect, ay nakikita ang username. Kaya ang huling callback ay tumatanggap ng isang pagkakakilanlan nang dalawang beses at hindi ito maihahambing sa sertipikong iniharap.
| Stage | What common_name holds |
|---|---|
| Username and password verification hook | The certificate common name, for example bob-device |
| After the replacement | The authenticated account, alice |
| client-connect callback | The account again, alice |
Sundan ang isang halimbawang koneksyon: sertipikong ibinigay para sa bob-device, matagumpay na pag-login sa direktoryo bilang alice, at bukas ang opsyon. Nakikita pa rin ng yugto ng verification ang dalawang magkaibang string. Nakikita ng yugto ng koneksyon ang alice at alice.
Ipinapakita ng halimbawang iyon kung bakit walang laman ang paghahambing. Hindi nito ipinapakita na tatanggapin ang koneksyon sa ibang paraan, dahil tumatakbo pa rin nang mag-isa ang validation ng sertipiko at verification ng password.
Ilagay ang ugnayan kung saan umiiral pa ang dalawang pagkakakilanlan
Dapat ipatupad ang tuntunin sa yugtong nakikita nang sabay ang pagkakakilanlan ng sertipiko at ang account, na sa praktika ay nangangahulugan ng verification hook ng username at password o isang plugin na ikinarga doon. Ang sinusuportahang plugin na gumagawa na ng verification ng password ay karaniwang tamang lugar para magdagdag ng tuntunin sa pagpapares, dahil kapag pinalitan ito ng paghahambing ng pangalan ay tuluyang mawawala ang pagsusuri ng password.
Tukuyin ang mapping bago magsulat ng code, dahil bihirang tunay na patakaran ang pagkakapantay-pantay. Madalas tinutukoy ng sertipiko ang device habang tinutukoy ng login ang tao, at maaaring legal na maglingkod ang isang device sa maraming tao. Itago ang ugnayan sa anyong kontrolado mo ang pagbibigay, at magpasiya kung ano ang nangyayari sa pagpapalit ng pangalan, sa muling pagbibigay at sa mga pangalang may kwalipikasyon ng domain. Ang pagpapaliit sa maliliit na titik o pagtanggal ng prefix ng domain nang hindi nauunawaan ang direktoryo ay maaaring pagsamahin ang dalawang account na dapat manatiling magkahiwalay.
Tandaan na binabago rin ng opsyon kung aling configuration ng bawat client ang nalalapat, dahil ang client-config-dir ay naka-key sa karaniwang pangalan.
Subukan ang pagpapares gamit ang dalawang wastong kredensyal
Magsimula sa pares na pinapayagan ng iyong patakaran at tiyakin na kumokonekta ito. Pagkatapos ay iharap ang parehong wastong sertipiko sa ibang pero wastong account: dapat mabigo ang pagtatangkang iyon, at dapat itong mabigo dahil sa tuntunin sa pagpapares at hindi dahil sa maling naipasok na password. Pinatutunayan ng maling password na gumagana ang pagsusuri ng password at wala itong sinasabi tungkol sa tuntunin sa pagitan ng sertipiko at account.
Suriin din ang mga landas na walang sertipiko at may di-wastong sertipiko, at tiyakin kung aling pagkakakilanlan ang ginagamit ng server para sa mga setting ng bawat client. Kung ang tanging paraan para gumana ang paghahambing ay patayin ang username-as-common-name, tasahin muna ang gastos ng pagbabagong iyon, dahil ibinabalik nito ang paghahanap ng configuration ng bawat client sa pangalan ng sertipiko.