EAP of kliëntsertifikate? IKEv2-verifikasie besluit

Jou poort kan sy eie identiteit met ’n sertifikaat bewys terwyl dit joune deur EAP bewys, en daardie kombinasie is algemeen eerder as teenstrydig. Die twee meganismes beantwoord verskillende vrae: is hierdie eindpunt die een wat ek verwag, en is hierdie gebruiker of toestel toegelaat. Om EAP in ’n profiel te sien skakel nie bedienerverifikasie af nie. Om die profiel as een enkele instelling te lees, is wat mense die verkeerde geloofsbrief laat herstel.

Besluit watter eis gefaal het voordat jy aan enige van die twee objekte raak. Die stadium van die faling sê dit vir jou, as jy dit in volgorde lees.

Twee geloofsbriewe, twee eise

’n Bedienersertifikaat bind ’n naam aan ’n sleutel, en die kliënt kontroleer daardie binding teen sy trust store. ’n Kliëntsertifikaat bind ’n identiteit aan ’n sleutel, en die poort kontroleer dat die aangebode sertifikaat na iets ketting wat dit vertrou. EAP dra ’n verifikasie-uitruiling waarvan die inhoud van die gekose metode afhang. Dit is drie strukture met verskillende leeftye, verskillende eienaars en verskillende falingmodusse.

’n Wagfrase wat ’n private sleutel ontsluit, is nie ’n rekeningwagwoord nie, selfs wanneer albei vrae binne sekondes van mekaar verskyn. Een is plaaslik aan die toestel se sleutelstoor, en die ander word deur ’n verifikasiebediener agter die poort gevalideer.

EAP is ’n houer, nie ’n metode nie

EAP is ’n raamwerk: die poort en die kliënt onderhandel ’n metode, en die metode bepaal of ’n wagwoord, ’n token, ’n tonnelde innerlike uitruiling of ’n sertifikaat betrokke is, soos die strongSwan IKEv2-dokumentasie uiteensit. Dit is waarom EAP-TLS heeltemal anders lyk as EAP-MSCHAPv2 van die kliënt se kant, al verskyn albei as EAP in ’n kieslys. ’n Profiel wat net EAP noem, het jou nie gesê waarvoor die gebruiker gevra sal word nie.

Lees die metode en die backend saam. Die backend bepaal rekeningformaat, uitsluitgedrag en wat ’n wagwoordherstel werklik verander, en niks daarvan is in die kliëntprofiel sigbaar nie.

Die gemengde ontplooiing is normaal

Bediener-sertifikaat plus EAP vir die gebruiker is die vorm wat die meeste afstandtoegangspoorte ontplooi, want dit gee die kliënt ’n verifieerbare eindpunt en gee die operateur ’n identiteit per gebruiker in ’n sentrale rekeningstoor. Kliëntsertifikaat-ontplooiings bestaan ook, gewoonlik waar toestelidentiteit meer as ’n wagwoord saak maak. Albei is geldig, en die fout is om te aanvaar die een wat jy verlede week gesien het, is die een voor jou.

Vra die operateur vir die gedokumenteerde metode en rekeningformaat eerder as om dit uit veldname in ’n kliënt af te lei.

Besluit op grond van die falingstadium

Orden die waarnemings. ’n Vertrouefout voor enige gebruikervraag is ’n bedienersertifikaat-probleem en geen wagwoord sal dit regmaak nie. ’n Vraag gevolg deur ’n verwerping is ’n gebruikersverifikasie-probleem, met die EAP-metode en die backend as verdagtes. ’n Suksesvolle verifikasie gevolg deur ’n child-SA-faling is nie een van die twee nie.

Nog twee onderskeidings maak saak. ’n Kliënt wat die bedienersertifikaat weier, rapporteer gewoonlik ’n naamwanpassing of ’n onbekende owerheid, wat ’n trust-store-vraag is. ’n Poort wat die gebruiker verwerp, teken dikwels die EAP-metode en ’n redekategorie aan, wat ’n rekening- of beleidsvraag is.

Die twee modelle bedryf

Vir sertifikate is die werk uitreiking, hernuwing, herroeping en verwydering van verlore toestelle, en dit gebeur volgens ’n skedule wat jy beheer. Vir EAP is die werk rekeninglewensiklus, metodeondersteuning op elke kliëntplatform, en watter tweede faktor die backend ook al vereis. Nie een model is in die abstrak goedkoper nie; hulle belas verskillende spanne. Skryf neer watter een jou ontplooiing werklik gebruik, want die ondersteuningskripte verskil meer as die konfigurasie.

Hou hulle apart in jou notas. ’n Sertifikaatverval veroorsaak ’n faling op ’n datum, ’n rekeninguitsluiting veroorsaak ’n faling ná ’n wagwoordverandering, en ’n metodewanpassing veroorsaak ’n faling op slegs een platform.

Nadat identiteit aanvaar is

Verifikasie is een hek. Die child security association, die verkeerskeurders, DNS en die toepassing se eie regte is later hekke, elk wat op sy eie terme faal. ’n Aanvaarde identiteit wat niks bereik nie, is nie ’n verifikasieprobleem nie.

Teken die metode, die rekening of sertifikaat wat gebruik is, en die stadium wat gefaal het, aan. Daardie nota maak die volgende voorval ’n naslaan eerder as ’n eksperiment.