EAP eller klientcertifikat? Å avgjere IKEv2-autentisering
To legitimasjonar, to oppgåver: éin provar endepunktet, éin provar brukaren. Avgjer kva trinn som feila før du nullstiller eit passord eller gjev ut eit sertifikat på nytt.
Gatewayen din kan prova sin eigen identitet med eit sertifikat medan han provar din via EAP, og den kombinasjonen er vanleg snarare enn sjølvmotseiande. Dei to mekanismane svarar på ulike spørsmål: er dette endepunktet det eg ventar, og er denne brukaren eller eininga tillaten. Å sjå EAP i ein profil slår ikkje av servervalidering. Det er lesinga av profilen som éi enkel innstilling som sender folk til å nullstille feil legitimasjon.
Avgjer kva krav som feila før du rører nokon av dei to objekta. Feiltrinnet fortel deg det, om du les det i rekkjefølgje.
To legitimasjonar, to krav
Eit serversertifikat bind eit namn til ein nøkkel, og klienten kontrollerer den bindinga mot sitt tillitslager. Eit klientcertifikat bind ein identitet til ein nøkkel, og gatewayen kontrollerer at det framlagde sertifikatet kjeder til noko han stolar på. EAP ber ein autentiseringsutveksling der innhaldet avheng av metoden som er vald. Det er tre strukturar med ulik levetid, ulike eigarar og ulike feilmodus.
Ein passfrase som låser opp ein privat nøkkel er ikkje eit kontopassord, sjølv når begge ledetekstane kjem innan sekund av kvarandre. Den eine er lokal i nøkkellageret til eininga, og den andre blir validert av ein autentiseringsserver bak gatewayen.
EAP er ein behaldar, ikkje ein metode
EAP er eit rammeverk: gatewayen og klienten forhandlar om ein metode, og metoden avgjer om eit passord, eit token, ein tunnelert indre utveksling eller eit sertifikat er involvert, slik strongSwan-dokumentasjonen om IKEv2 legg det fram. Derfor liknar EAP-TLS slett ikkje på EAP-MSCHAPv2 frå klientsida, sjølv om begge viser seg som EAP i ei meny. Ein profil som berre nemner EAP har ikkje fortalt deg kva brukaren blir spurd om.
Les metoden og backend-en saman. Backend-en avgjer kontformat, låseåtferd og kva ein nullstilling av passord faktisk endrar, og ingenting av det er synleg i klientprofilen.
Den blanda utrullinga er normal
Serversertifikat pluss EAP for brukaren er forma dei fleste fjernåtkomst-gatewayar rullar ut, fordi ho gjev klienten eit verifiserbart endepunkt og operatøren ein identitet per brukar i eit sentralt kontolager. Det finst òg utrullingar med klientcertifikat, vanlegvis der einingidentitet tyder meir enn eit passord. Begge er legitime, og feilen er å tru at det du såg førre veke er det som ligg framfor deg.
Spør operatøren om den dokumenterte metoden og kontformatet i staden for å utleie det frå feltnamn i ein klient.
Avgjerd ut frå feiltrinnet
Sorter observasjonane. Ein tillitsfeil før noka brukarledetekst er eit serversertifikatproblem, og ingen passord rettar det. Ei ledetekst som blir følgd av ei avvising er eit brukarautentiseringsproblem, med EAP-metoden og backend-en som mistenkte. Ein vellukka autentisering som blir følgd av ein child-SA-feil er ingen av dei.
To skil til tel. Ein klient som avviser serversertifikatet rapporterer vanlegvis namnemismatch eller ei ukjend styresmakt, som er eit spørsmål om tillitslageret. Ein gateway som avviser brukaren loggar ofte EAP-metoden og ein årsakskategori, som er eit spørsmål om konto eller policy.
Drift av dei to modellane
For sertifikat er arbeidet utgiving, fornying, tilbakekalling og fjerning av tapte einingar, og det skjer etter ein tidsplan du kontrollerer. For EAP er arbeidet kontolivssyklus, metdestøtte på kvar klientplattform og den andre faktoren backend-en krev. Ingen av modellane er billegare i abstrakt forstand; dei belastar ulike team. Skriv ned kva utrullinga di faktisk brukar, fordi støttescripta skil seg meir enn konfigurasjonen.
Hald dei fråskilde i notata dine. Eit sertifikatutløp gjev ein feil på ein dato, ei kontolåsing gjev ein feil etter ei passordendring, og ein metodemismatch gjev ein feil på berre éin plattform.
Når identiteten er godteken
Autentisering er éi port. Den underordna tryggingsassosiasjonen, trafikkveljarane, DNS og dei eigne løyva til applikasjonen er seinare porter, og kvar av dei feilar på eigne vilkår. Ein godteken identitet som ikkje når noko, er ikkje eit autentiseringsproblem.
Noter metoden, kontoen eller sertifikatet som vart brukt, og trinnet som feila. Det notatet gjer neste hending til eit oppslag i staden for eit eksperiment.