EAP o certificats de client? Decidir l’autenticació IKEv2

La vostra passarel·la pot demostrar la seva pròpia identitat amb un certificat mentre demostra la vostra mitjançant EAP, i aquesta combinació és habitual, no contradictòria. Els dos mecanismes responen preguntes diferents: aquest extrem és el que espero, i aquest usuari o dispositiu té permís. Veure EAP en un perfil no desactiva la validació del servidor. Llegir el perfil com una única opció és el que porta la gent a restablir la credencial equivocada.

Decidiu quina afirmació ha fallat abans de tocar cap dels dos objectes. L’etapa de fallada us ho diu, si la llegiu per ordre.

Dues credencials, dues afirmacions

Un certificat de servidor lliga un nom a una clau, i el client comprova aquest lligam contra el seu magatzem de confiança. Un certificat de client lliga una identitat a una clau, i la passarel·la comprova que el certificat presentat encadeni amb alguna cosa en què confia. EAP transporta un intercanvi d’autenticació el contingut del qual depèn del mètode triat. Són tres estructures amb vides útils diferents, propietaris diferents i modes de fallada diferents.

Una frase de pas que desbloqueja una clau privada no és una contrasenya de compte, fins i tot quan els dos avisos apareixen en qüestió de segons. Un és local al magatzem de claus del dispositiu, i l’altre el valida un servidor d’autenticació darrere de la passarel·la.

EAP és un contenidor, no un mètode

EAP és un marc: la passarel·la i el client negocien un mètode, i el mètode decideix si hi intervenen una contrasenya, un testimoni, un intercanvi intern tunelitzat o un certificat, tal com exposa la documentació de strongSwan sobre IKEv2. Per això EAP-TLS no s’assembla gens a EAP-MSCHAPv2 des del costat del client, tot i que tots dos apareixen com a EAP en un menú. Un perfil que només anomena EAP no us ha dit què es demanarà a l’usuari.

Llegiu el mètode i el backend junts. El backend determina el format del compte, el comportament de bloqueig i què canvia realment un restabliment de contrasenya, i res d’això no és visible al perfil del client.

El desplegament mixt és normal

Certificat de servidor més EAP per a l’usuari és la forma que despleguen la majoria de passarel·les d’accés remot, perquè dona al client un extrem verificable i a l’operador una identitat per usuari en un magatzem de comptes central. També existeixen desplegaments amb certificats de client, normalment on la identitat del dispositiu importa més que una contrasenya. Tots dos són legítims, i l’error és suposar que el que vau veure la setmana passada és el que teniu al davant.

Demaneu a l’operador el mètode i el format de compte documentats en lloc d’inferir-los dels noms de camp d’un client.

Decidir a partir de l’etapa de fallada

Ordeneu les observacions. Un error de confiança abans de qualsevol avís d’usuari és un problema de certificat de servidor i cap contrasenya l’arreglarà. Un avís seguit d’un rebuig és un problema d’autenticació d’usuari, amb el mètode EAP i el backend com a sospitosos. Una autenticació correcta seguida d’una fallada de child-SA no és cap de les dues.

Dues distincions més importen. Un client que rebutja el certificat del servidor sol informar d’una discrepància de nom o d’una autoritat desconeguda, que és una qüestió del magatzem de confiança. Una passarel·la que rebutja l’usuari sovint registra el mètode EAP i una categoria de motiu, que és una qüestió de compte o de política.

Operar els dos models

Amb els certificats la feina és l’emissió, la renovació, la revocació i la retirada de dispositius perduts, i passa segons un calendari que controleu. Amb EAP la feina és el cicle de vida del compte, el suport de mètodes a cada plataforma client i el segon factor que requereixi el backend. Cap model no és més barat en abstracte; carreguen equips diferents. Anoteu quin fa servir realment el vostre desplegament, perquè els scripts de suport difereixen més que la configuració.

Manteniu-los separats a les vostres notes. Una caducitat de certificat produeix una fallada en una data, un bloqueig de compte produeix una fallada després d’un canvi de contrasenya, i una discrepància de mètode produeix una fallada només en una plataforma.

Després que la identitat sigui acceptada

L’autenticació és una porta. L’associació de seguretat filla, els selectors de trànsit, el DNS i els permisos propis de l’aplicació són portes posteriors, i cadascuna falla amb les seves condicions. Una identitat acceptada que no arriba enlloc no és un problema d’autenticació.

Registreu el mètode, el compte o certificat utilitzat i l’etapa que ha fallat. Aquesta nota converteix el proper incident en una consulta en lloc d’un experiment.