EAP eller klientcertifikat? Att avgöra IKEv2-autentisering

Din gateway kan bevisa sin egen identitet med ett certifikat medan den bevisar din via EAP, och den kombinationen är vanlig snarare än motsägelsefull. De två mekanismerna svarar på olika frågor: är den här slutpunkten den jag förväntar mig, och är den här användaren eller enheten tillåten. Att se EAP i en profil stänger inte av servervalideringen. Det är läsningen av profilen som en enda inställning som får folk att återställa fel inloggningsuppgift.

Avgör vilket påstående som misslyckades innan du rör något av de två objekten. Feletsteget berättar det, om du läser det i ordning.

Två inloggningsuppgifter, två påståenden

Ett servercertifikat binder ett namn till en nyckel, och klienten kontrollerar den bindningen mot sitt trust store. Ett klientcertifikat binder en identitet till en nyckel, och gatewayen kontrollerar att det presenterade certifikatet kedjar till något den litar på. EAP bär ett autentiseringsutbyte vars innehåll beror på den valda metoden. Det är tre strukturer med olika livslängd, olika ägare och olika fellägen.

En lösenfras som låser upp en privat nyckel är inte ett kontolösenord, även när båda frågorna dyker upp inom sekunder från varandra. Den ena är lokal i enhetens nyckellager, och den andra valideras av en autentiseringsserver bakom gatewayen.

EAP är en behållare, inte en metod

EAP är ett ramverk: gatewayen och klienten förhandlar om en metod, och metoden avgör om ett lösenord, en token, ett tunnlat inre utbyte eller ett certifikat är inblandat, som strongSwan-dokumentationen om IKEv2 beskriver. Därför liknar EAP-TLS inte alls EAP-MSCHAPv2 från klientsidan, även om båda visas som EAP i en meny. En profil som bara nämner EAP har inte talat om vad användaren kommer att tillfrågas om.

Läs metoden och backend tillsammans. Backend bestämmer kontoformat, låsbeteende och vad en lösenordsåterställning faktiskt ändrar, och inget av det syns i klientprofilen.

Den blandade utrullningen är normal

Servercertifikat plus EAP för användaren är den form som de flesta fjärråtkomst-gatewayer rullar ut, eftersom den ger klienten en verifierbar slutpunkt och operatören en identitet per användare i ett centralt kontoarkiv. Det finns också utrullningar med klientcertifikat, vanligtvis där enhetsidentitet betyder mer än ett lösenord. Båda är legitima, och felet är att anta att det du såg förra veckan är det som ligger framför dig.

Fråga operatören om den dokumenterade metoden och kontoformatet i stället för att härleda dem från fältnamn i en klient.

Beslut utifrån feletsteget

Ordna observationerna. Ett förtroendefel före någon användarfråga är ett servercertifikatproblem och inget lösenord åtgärdar det. En fråga som följs av ett avslag är ett användarautentiseringsproblem, med EAP-metoden och backend som misstänkta. En lyckad autentisering som följs av ett child-SA-fel är inget av dem.

Ytterligare två skillnader spelar roll. En klient som avvisar servercertifikatet rapporterar oftast ett namnmissförhållande eller en okänd utfärdare, vilket är en fråga om trust store. En gateway som avvisar användaren loggar ofta EAP-metoden och en orsakskategori, vilket är en fråga om konto eller policy.

Drift av de två modellerna

För certifikat består arbetet av utfärdande, förnyelse, återkallande och borttagning av förlorade enheter, och det sker enligt ett schema du styr. För EAP består arbetet av kontots livscykel, metodstöd på varje klientplattform och den andra faktor som backend kräver. Ingen av modellerna är billigare i abstrakt mening; de belastar olika team. Skriv ned vilken din utrullning faktiskt använder, eftersom supportskripten skiljer sig mer än konfigurationen.

Håll dem åtskilda i dina anteckningar. Ett certifikatutgång ger ett fel på ett datum, en kontolåsning ger ett fel efter ett lösenordsbyte, och en metodskillnad ger ett fel på bara en plattform.

När identiteten har accepterats

Autentisering är en port. Den underordnade säkerhetsassociationen, trafikväljarna, DNS och applikationens egna behörigheter är senare portar, och var och en misslyckas på sina egna villkor. En accepterad identitet som inte når något är inte ett autentiseringsproblem.

Anteckna metoden, kontot eller certifikatet som användes och steget som misslyckades. Den anteckningen gör nästa incident till ett uppslag i stället för ett experiment.