EAP eller klientcertifikater? Sådan afgøres IKEv2-godkendelse

Din gateway kan bevise sin egen identitet med et certifikat, mens den beviser din via EAP, og den kombination er almindelig snarere end selvmodsigende. De to mekanismer besvarer forskellige spørgsmål: er dette endepunkt det, jeg forventer, og har denne bruger eller enhed tilladelse. At se EAP i en profil slår ikke servervalidering fra. Det er læsningen af profilen som én enkelt indstilling, der sender folk til at nulstille den forkerte legitimationsoplysning.

Afgør, hvilket krav der fejlede, før du rører nogen af de to objekter. Fejltrinnet fortæller dig det, hvis du læser det i rækkefølge.

To legitimationsoplysninger, to krav

Et servercertifikat binder et navn til en nøgle, og klienten kontrollerer den binding mod sit trust store. Et klientcertifikat binder en identitet til en nøgle, og gatewayen kontrollerer, at det fremlagte certifikat kæder til noget, den stoler på. EAP bærer en godkendelsesudveksling, hvis indhold afhænger af den valgte metode. Det er tre strukturer med forskellige levetider, forskellige ejere og forskellige fejltilstande.

En adgangsfrase, der låser en privat nøgle op, er ikke en kontoadgangskode, selv når begge prompts vises inden for sekunder af hinanden. Den ene er lokal i enhedens nøgledepot, og den anden valideres af en godkendelsesserver bag gatewayen.

EAP er en beholder, ikke en metode

EAP er en ramme: gatewayen og klienten forhandler en metode, og metoden afgør, om en adgangskode, et token, en tunnelbaseret indre udveksling eller et certifikat indgår, som strongSwan-dokumentationen om IKEv2 beskriver. Derfor ligner EAP-TLS slet ikke EAP-MSCHAPv2 fra klientens side, selv om begge vises som EAP i en menu. En profil, der kun nævner EAP, har ikke fortalt dig, hvad brugeren bliver spurgt om.

Læs metoden og backenden sammen. Backenden bestemmer kontoformat, lockout-adfærd og hvad en nulstilling af adgangskoden faktisk ændrer, og intet af det er synligt i klientprofilen.

Den blandede udrulning er normal

Servercertifikat plus EAP til brugeren er den form, de fleste fjernadgangsgateways udruller, fordi den giver klienten et verificerbart endepunkt og operatøren en identitet pr. bruger i et centralt kontodepot. Der findes også udrulninger med klientcertifikater, normalt hvor enhedsidentitet betyder mere end en adgangskode. Begge er legitime, og fejlen er at antage, at det, du så i sidste uge, er det, der ligger foran dig.

Spørg operatøren om den dokumenterede metode og kontoformat i stedet for at udlede det af feltnavne i en klient.

Afgørelse ud fra fejltrinnet

Sæt observationerne i rækkefølge. En tillidsfejl før nogen brugerprompt er et servercertifikatproblem, og ingen adgangskode retter det. En prompt efterfulgt af en afvisning er et brugergodkendelsesproblem, med EAP-metoden og backenden som mistænkte. En vellykket godkendelse efterfulgt af en child-SA-fejl er ingen af dem.

To skel mere betyder noget. En klient, der afviser servercertifikatet, rapporterer normalt et navnemismatch eller en ukendt myndighed, hvilket er et spørgsmål om trust store. En gateway, der afviser brugeren, logger ofte EAP-metoden og en årsagskategori, hvilket er et spørgsmål om konto eller politik.

Drift af de to modeller

For certifikater er arbejdet udstedelse, fornyelse, tilbagekaldelse og fjernelse af tabte enheder, og det sker efter en tidsplan, du styrer. For EAP er arbejdet kontoens livscyklus, metodestøtte på hver klientplatform og den anden faktor, backenden kræver. Ingen af modellerne er billigere i abstrakt forstand; de belaster forskellige teams. Skriv ned, hvilken din udrulning faktisk bruger, fordi supportscriptene adskiller sig mere end konfigurationen.

Hold dem adskilt i dine noter. Et certifikatudløb giver en fejl på en dato, en kontolåsning giver en fejl efter en adgangskodeændring, og et metodemismatch giver en fejl på kun én platform.

Når identiteten er accepteret

Godkendelse er én port. Den underordnede sikkerhedsassociation, trafikvælgerne, DNS og applikationens egne rettigheder er senere porte, og hver især fejler på sine egne betingelser. En accepteret identitet, der ikke når noget, er ikke et godkendelsesproblem.

Notér metoden, den anvendte konto eller det anvendte certifikat og det trin, der fejlede. Den note gør den næste hændelse til et opslag i stedet for et eksperiment.