EAP eller klientcertifikater? Å avgjøre IKEv2-autentisering
To legitimasjoner, to oppgaver: én beviser endepunktet, én beviser brukeren. Avgjør hvilket trinn som feilet før du tilbakestiller et passord eller utsteder et sertifikat på nytt.
Gatewayen din kan bevise sin egen identitet med et sertifikat mens den beviser din via EAP, og den kombinasjonen er vanlig snarere enn selvmotsigende. De to mekanismene svarer på ulike spørsmål: er dette endepunktet det jeg forventer, og er denne brukeren eller enheten tillatt. Å se EAP i en profil slår ikke av servervalidering. Det er lesingen av profilen som én enkelt innstilling som sender folk til å tilbakestille feil legitimasjon.
Avgjør hvilket krav som feilet før du rører noen av de to objektene. Feiltrinnet forteller deg det, hvis du leser det i rekkefølge.
To legitimasjoner, to krav
Et serversertifikat binder et navn til en nøkkel, og klienten kontrollerer den bindingen mot sitt tillitslager. Et klientcertifikat binder en identitet til en nøkkel, og gatewayen kontrollerer at det fremlagte sertifikatet kjeder til noe den stoler på. EAP bærer en autentiseringsutveksling hvis innhold avhenger av metoden som er valgt. Det er tre strukturer med ulik levetid, ulike eiere og ulike feilmoduser.
En passfrase som låser opp en privat nøkkel er ikke et kontopassord, selv når begge ledetekstene vises innen sekunder av hverandre. Den ene er lokal i enhetens nøkkellager, og den andre valideres av en autentiseringsserver bak gatewayen.
EAP er en beholder, ikke en metode
EAP er et rammeverk: gatewayen og klienten forhandler om en metode, og metoden avgjør om et passord, et token, en tunnelert indre utveksling eller et sertifikat er involvert, slik strongSwan-dokumentasjonen om IKEv2 legger det fram. Derfor ligner EAP-TLS slett ikke på EAP-MSCHAPv2 fra klientsiden, selv om begge vises som EAP i en meny. En profil som bare nevner EAP har ikke fortalt deg hva brukeren blir spurt om.
Les metoden og backend-en sammen. Backend-en bestemmer kontformat, låseadferd og hva en tilbakestilling av passord faktisk endrer, og ingenting av det er synlig i klientprofilen.
Den blandede utrullingen er normal
Serversertifikat pluss EAP for brukeren er formen de fleste fjernakses-gatewayer ruller ut, fordi den gir klienten et verifiserbart endepunkt og operatøren en identitet per bruker i et sentralt kontolager. Det finnes også utrullinger med klientcertifikater, vanligvis der enhetsidentitet betyr mer enn et passord. Begge er legitime, og feilen er å anta at det du så i forrige uke er det som ligger foran deg.
Spør operatøren om den dokumenterte metoden og kontformatet i stedet for å utlede det fra feltnavn i en klient.
Avgjørelse ut fra feiltrinnet
Sorter observasjonene. En tillitsfeil før noen brukerledetekst er et serversertifikatproblem, og ingen passord retter det. En ledetekst som etterfølges av en avvisning er et brukerautentiseringsproblem, med EAP-metoden og backend-en som mistenkte. En vellykket autentisering som etterfølges av en child-SA-feil er ingen av dem.
To skiller til betyr noe. En klient som avviser serversertifikatet rapporterer vanligvis navnemismatch eller en ukjent myndighet, som er et spørsmål om tillitslageret. En gateway som avviser brukeren logger ofte EAP-metoden og en årsakskategori, som er et spørsmål om konto eller policy.
Drift av de to modellene
For sertifikater er arbeidet utstedelse, fornyelse, tilbakekalling og fjerning av tapte enheter, og det skjer etter en tidsplan du kontrollerer. For EAP er arbeidet kontolivssyklus, metdestøtte på hver klientplattform og den andre faktoren backend-en krever. Ingen av modellene er billigere i abstrakt forstand; de belaster ulike team. Skriv ned hvilken utrullingen din faktisk bruker, fordi støtteskriptene skiller seg mer enn konfigurasjonen.
Hold dem atskilt i notatene dine. Et sertifikatutløp gir en feil på en dato, en kontolåsing gir en feil etter en passordendring, og en metodemismatch gir en feil på bare én plattform.
Når identiteten er akseptert
Autentisering er én port. Den underordnede sikkerhetsassosiasjonen, trafikkvelgerne, DNS og applikasjonens egne tillatelser er senere porter, og hver av dem feiler på egne vilkår. En akseptert identitet som ikke når noe, er ikke et autentiseringsproblem.
Noter metoden, kontoen eller sertifikatet som ble brukt, og trinnet som feilet. Det notatet gjør neste hendelse til et oppslag i stedet for et eksperiment.