EAP o mga sertipiko ng kliyente? Pagpapasya sa IKEv2 authentication

Ang iyong gateway ay maaaring magpatunay ng sarili nitong pagkakakilanlan sa pamamagitan ng sertipiko habang pinapatunayan ang sa iyo sa pamamagitan ng EAP, at ang kombinasyong iyon ay karaniwan sa halip na magkasalungat. Ang dalawang mekanismo ay sumasagot sa magkaibang tanong: ito ba ang endpoint na inaasahan ko, at pinapayagan ba ang user o device na ito. Ang makita ang EAP sa isang profile ay hindi nagpapatay ng validation ng server. Ang pagbasa sa profile bilang isang setting lamang ang nagtutulak sa mga tao na i-reset ang maling kredensyal.

Tukuyin kung aling claim ang nabigo bago hawakan ang alinman sa dalawang bagay. Sasabihin ito ng yugto ng pagpalya, kung babasahin mo ito nang sunod-sunod.

Dalawang kredensyal, dalawang claim

Ang sertipiko ng server ay nagbibigkis ng pangalan sa isang key, at sinusuri ng kliyente ang bigkis na iyon laban sa sarili nitong trust store. Ang sertipiko ng kliyente ay nagbibigkis ng pagkakakilanlan sa isang key, at sinusuri ng gateway kung ang iniharap na sertipiko ay naka-chain sa isang bagay na pinagkakatiwalaan nito. Ang EAP ay nagdadala ng palitan ng authentication na ang nilalaman ay nakasalalay sa napiling paraan. Ito ay tatlong istrukturang may magkaibang habang-buhay, may-ari at paraan ng pagpalya.

Ang passphrase na nagbubukas ng pribadong key ay hindi password ng account, kahit na ang dalawang prompt ay lumitaw sa loob ng ilang segundo ng isa’t isa. Ang isa ay lokal sa key store ng device, at ang isa ay pinapatunayan ng authentication server sa likod ng gateway.

Ang EAP ay isang lalagyan, hindi isang paraan

Ang EAP ay isang balangkas: ang gateway at kliyente ay nag-uusap tungkol sa isang paraan, at ang paraan ang nagpapasya kung may password, token, panloob na palitan na naka-tunnel o sertipiko na kasangkot, gaya ng dokumentasyon ng strongSwan tungkol sa IKEv2 na inilalahad. Kaya nga ang EAP-TLS ay hindi talaga kamukha ng EAP-MSCHAPv2 mula sa panig ng kliyente, kahit pareho silang lumalabas bilang EAP sa isang menu. Ang profile na nagpapangalan lamang ng EAP ay hindi nagsabi sa iyo kung ano ang itatanong sa user.

Basahin ang paraan at backend nang magkasama. Tinutukoy ng backend ang format ng account, pag-uugali ng lockout at kung ano talaga ang binabago ng pag-reset ng password, at wala sa mga iyon ang nakikita sa profile ng kliyente.

Ang pinaghalong deployment ay normal

Sertipiko ng server at EAP para sa user ang anyo na ipinapakilala ng karamihan ng gateway ng malayuang pag-access, dahil binibigyan nito ang kliyente ng mapapatunayang endpoint at ang operator ng pagkakakilanlan ng bawat user sa isang sentral na imbakan ng account. Mayroon ding mga deployment na may mga sertipiko ng kliyente, kadalasan kung saan mas mahalaga ang pagkakakilanlan ng device kaysa password. Pareho silang lehitimo, at ang pagkakamali ay ipagpalagay na ang nakita mo noong nakaraang linggo ang siyang nasa harap mo.

Itanong sa operator ang dokumentadong paraan at format ng account sa halip na hinuha ito mula sa mga pangalan ng field sa isang kliyente.

Pagpapasya mula sa yugto ng pagpalya

Ayusin ang mga obserbasyon. Ang error sa pagtitiwala bago ang anumang prompt ng user ay problema sa sertipiko ng server at walang password ang makakatama nito. Ang prompt na sinusundan ng pagtanggi ay problema sa authentication ng user, na ang paraan ng EAP at backend ang pinaghihinalaan. Ang matagumpay na authentication na sinusundan ng pagpalya ng child-SA ay wala sa dalawa.

Dalawang pagkakaiba pa ang mahalaga. Ang kliyenteng tumatanggi sa sertipiko ng server ay kadalasang nag-uulat ng hindi pagtutugma ng pangalan o hindi kilalang awtoridad, na isang usapin ng trust store. Ang gateway na tumatanggi sa user ay madalas nagtatala ng paraan ng EAP at kategorya ng dahilan, na isang usapin ng account o patakaran.

Pamamahala ng dalawang modelo

Para sa mga sertipiko, ang gawain ay pag-isyu, pag-renew, pagbawi at pagtanggal ng mga nawawalang device, at nangyayari ito ayon sa iskedyul na kinokontrol mo. Para sa EAP, ang gawain ay ang lifecycle ng account, suporta sa paraan sa bawat platform ng kliyente at anumang ikalawang salik na kailangan ng backend. Walang modelong mas mura sa abstrak; nagpapabigat sila sa magkaibang team. Isulat kung alin ang talagang ginagamit ng iyong deployment, dahil mas nagkakaiba ang mga support script kaysa sa configuration.

Panatilihin silang magkahiwalay sa iyong mga tala. Ang pag-expire ng sertipiko ay gumagawa ng pagpalya sa isang petsa, ang lockout ng account ay gumagawa ng pagpalya pagkatapos ng pagbabago ng password, at ang hindi pagtutugma ng paraan ay gumagawa ng pagpalya sa isang platform lamang.

Pagkatapos tanggapin ang pagkakakilanlan

Ang authentication ay isang pintuan. Ang child security association, ang mga traffic selector, DNS at ang sariling mga pahintulot ng application ay mga susunod na pintuan, at bawat isa ay nabibigo sa sarili nitong mga kondisyon. Ang tinanggap na pagkakakilanlang hindi umaabot saanman ay hindi problema sa authentication.

Itala ang paraan, ang account o sertipikong ginamit at ang yugtong nabigo. Ang talang iyon ay ginagawang paghahanap ang susunod na insidente sa halip na eksperimento.