EAP ali odjemalski certifikati? Odločitev o avtentikaciji IKEv2
Dve poverilnici, dve nalogi: ena dokazuje končno točko, druga uporabnika. Ugotovite, katera faza je spodletela, preden ponastavite geslo ali znova izdate certifikat.
Vaš prehod lahko dokaže lastno identiteto s certifikatom, vašo pa prek EAP, in ta kombinacija je običajna, ne protislovna. Dva mehanizma odgovarjata na različna vprašanja: ali je ta končna točka tista, ki jo pričakujem, in ali je ta uporabnik ali naprava dovoljena. Če v profilu vidite EAP, to ne izklopi preverjanja strežnika. Prav branje profila kot ene same nastavitve vodi ljudi k ponastavitvi napačne poverilnice.
Ugotovite, katera trditev je spodletela, preden se dotaknete katerega od dveh objektov. Faza napake vam to pove, če jo berete po vrsti.
Dve poverilnici, dve trditvi
Strežniški certifikat veže ime na ključ, odjemalec pa to vez preveri v svojem hrambu zaupanja. Odjemalski certifikat veže identiteto na ključ, prehod pa preveri, ali se predloženi certifikat verižno poveže z nečim, čemur zaupa. EAP prenaša avtentikacijsko izmenjavo, katere vsebina je odvisna od izbrane metode. To so tri strukture z različno življenjsko dobo, različnimi lastniki in različnimi načini odpovedi.
Geselska fraza, ki odklene zasebni ključ, ni geslo računa, tudi ko se oba poziva pojavita v nekaj sekundah. Ena je lokalna v shrambi ključev naprave, drugo pa preveri avtentikacijski strežnik za prehodom.
EAP je vsebnik, ne metoda
EAP je okvir: prehod in odjemalec se pogajata o metodi, metoda pa odloči, ali sodelujejo geslo, žeton, tunelirana notranja izmenjava ali certifikat, kot razlaga dokumentacija strongSwan o IKEv2. Zato EAP-TLS z odjemalske strani nič ne spominja na EAP-MSCHAPv2, čeprav se oba v meniju prikažeta kot EAP. Profil, ki navaja samo EAP, vam ni povedal, kaj bodo uporabnika vprašali.
Berite metodo in backend skupaj. Backend določa obliko računa, vedenje pri zaklepu in kaj ponastavitev gesla v resnici spremeni, in nič od tega ni vidno v odjemalskem profilu.
Mešana namestitev je običajna
Strežniški certifikat plus EAP za uporabnika je oblika, ki jo uvaja večina prehodov za oddaljeni dostop, ker daje odjemalcu preverljivo končno točko, operaterju pa identiteto vsakega uporabnika v osrednji shrambi računov. Obstajajo tudi namestitve z odjemalskimi certifikati, običajno tam, kjer je identiteta naprave pomembnejša od gesla. Obe sta legitimni, napaka pa je domnevati, da je to, kar ste videli prejšnji teden, to, kar je pred vami.
Vprašajte operaterja za dokumentirano metodo in obliko računa, namesto da ju sklepate iz imen polj v odjemalcu.
Odločitev po fazi napake
Uredite opažanja. Napaka zaupanja pred katerim koli uporabniškim pozivom je težava strežniškega certifikata in nobeno geslo je ne odpravi. Poziv, ki mu sledi zavrnitev, je težava avtentikacije uporabnika, pri čemer sta osumljenca metoda EAP in backend. Uspešna avtentikacija, ki ji sledi napaka child-SA, ni niti eno niti drugo.
Pomembni sta še dve razliki. Odjemalec, ki zavrne strežniški certifikat, običajno poroča o neujemanju imena ali neznanem izdajatelju, kar je vprašanje hrambe zaupanja. Prehod, ki zavrne uporabnika, pogosto zabeleži metodo EAP in kategorijo razloga, kar je vprašanje računa ali pravilnika.
Upravljanje obeh modelov
Pri certifikatih je delo izdajanje, obnavljanje, preklic in odstranitev izgubljenih naprav, in poteka po urniku, ki ga nadzorujete. Pri EAP je delo življenjski cikel računa, podpora metodam na vsaki odjemalski platformi in kateri koli drugi dejavnik, ki ga zahteva backend. Noben model ni abstraktno cenejši; obremenjujeta različne ekipe. Zapišite, katerega vaša namestitev v resnici uporablja, ker se skripti za podporo razlikujejo bolj kot konfiguracija.
Hranite ju ločeno v svojih zapiskih. Pretek certifikata povzroči napako na določen datum, zaklep računa povzroči napako po spremembi gesla, neujemanje metode pa povzroči napako le na eni platformi.
Ko je identiteta sprejeta
Avtentikacija so ena vrata. Podrejena varnostna povezava, izbirniki prometa, DNS in lastna dovoljenja aplikacije so poznejša vrata in vsaka spodletijo po svojih pogojih. Sprejeta identiteta, ki nikamor ne pride, ni težava avtentikacije.
Zabeležite metodo, uporabljeni račun ali certifikat in fazo, ki je spodletela. Ta zapisek spremeni naslednji incident v iskanje namesto v poskus.