EAP of clientcertificaten? IKEv2-authenticatie beslissen

Uw gateway kan zijn eigen identiteit met een certificaat bewijzen en de uwe via EAP, en die combinatie is gebruikelijk in plaats van tegenstrijdig. De twee mechanismen beantwoorden verschillende vragen: is dit eindpunt het verwachte, en is deze gebruiker of dit apparaat toegestaan. EAP in een profiel zien schakelt servervalidatie niet uit. Het profiel als één instelling lezen is wat mensen het verkeerde inloggegeven laat resetten.

Bepaal welk claim is mislukt voordat u een van beide objecten aanraakt. De faalfase vertelt het u, als u die op volgorde leest.

Twee inloggegevens, twee claims

Een servercertificaat bindt een naam aan een sleutel, en de client controleert die binding tegen zijn truststore. Een clientcertificaat bindt een identiteit aan een sleutel, en de gateway controleert of het voorgelegde certificaat aaneenschakelt naar iets dat hij vertrouwt. EAP draagt een authenticatie-uitwisseling waarvan de inhoud afhangt van de gekozen methode. Dat zijn drie structuren met verschillende levensduur, verschillende eigenaren en verschillende faalmodi.

Een wachtwoordzin die een privésleutel ontgrendelt is geen accountwachtwoord, zelfs niet wanneer beide prompts binnen enkele seconden van elkaar verschijnen. De ene is lokaal in de sleutelopslag van het apparaat, en de andere wordt gevalideerd door een authenticatieserver achter de gateway.

EAP is een container, geen methode

EAP is een raamwerk: de gateway en de client onderhandelen een methode, en de methode bepaalt of een wachtwoord, een token, een getunnelde interne uitwisseling of een certificaat meespeelt, zoals de strongSwan-documentatie over IKEv2 uiteenzet. Daarom lijkt EAP-TLS vanaf de clientkant totaal niet op EAP-MSCHAPv2, ook al verschijnen beide als EAP in een menu. Een profiel dat alleen EAP noemt, heeft u niet verteld waarnaar de gebruiker wordt gevraagd.

Lees de methode en de backend samen. De backend bepaalt het accountformaat, het vergrendelgedrag en wat een wachtwoordreset werkelijk verandert, en niets daarvan is zichtbaar in het clientprofiel.

De gemengde uitrol is normaal

Servercertificaat plus EAP voor de gebruiker is de vorm die de meeste gateways voor toegang op afstand uitrollen, omdat die de client een verifieerbaar eindpunt geeft en de operator een identiteit per gebruiker in een centrale accountopslag. Er bestaan ook uitrollingen met clientcertificaten, meestal waar apparaatidentiteit belangrijker is dan een wachtwoord. Beide zijn legitiem, en de fout is aannemen dat wat u vorige week zag hetzelfde is als wat voor u staat.

Vraag de operator naar de gedocumenteerde methode en het accountformaat in plaats van die af te leiden uit veldnamen in een client.

Beslissen op basis van de faalfase

Orden de waarnemingen. Een vertrouwensfout vóór enige gebruikersprompt is een servercertificaatprobleem en geen wachtwoord lost dat op. Een prompt gevolgd door een afwijzing is een probleem met gebruikersauthenticatie, met de EAP-methode en de backend als verdachten. Een geslaagde authenticatie gevolgd door een child-SA-fout is geen van beide.

Nog twee onderscheidingen tellen. Een client die het servercertificaat weigert, meldt meestal een naamverschil of een onbekende autoriteit, wat een kwestie van de truststore is. Een gateway die de gebruiker weigert, logt vaak de EAP-methode en een redencategorie, wat een kwestie van account of beleid is.

De twee modellen beheren

Bij certificaten bestaat het werk uit uitgifte, vernieuwing, intrekking en het verwijderen van verloren apparaten, en het gebeurt volgens een schema dat u beheert. Bij EAP bestaat het werk uit de levenscyclus van het account, methodeondersteuning op elk clientplatform en welke tweede factor de backend ook vereist. Geen van beide modellen is abstract goedkoper; ze belasten verschillende teams. Schrijf op welke uw uitrol werkelijk gebruikt, want de supportscripts verschillen meer dan de configuratie.

Houd ze gescheiden in uw notities. Een certificaatverval produceert een fout op een datum, een accountvergrendeling produceert een fout na een wachtwoordwijziging, en een methodeverschil produceert een fout op slechts één platform.

Nadat de identiteit is geaccepteerd

Authenticatie is één poort. De ondergeschikte beveiligingsassociatie, de verkeersselectors, DNS en de eigen rechten van de applicatie zijn latere poorten, en elk faalt op zijn eigen voorwaarden. Een geaccepteerde identiteit die niets bereikt is geen authenticatieprobleem.

Noteer de methode, het gebruikte account of certificaat en de fase die faalde. Die notitie maakt het volgende incident een opzoekactie in plaats van een experiment.