EAP ou certificados de cliente? Decidir a autenticación IKEv2

A súa pasarela pode demostrar a súa propia identidade cun certificado mentres demostra a súa mediante EAP, e esa combinación é habitual, non contraditoria. Os dous mecanismos responden preguntas distintas: é este extremo o que espero, e está permitido este usuario ou dispositivo. Ver EAP nun perfil non desactiva a validación do servidor. Ler o perfil como un único axuste é o que leva a xente a restablecer a credencial equivocada.

Determine que afirmación fallou antes de tocar calquera dos dous obxectos. A etapa do fallo dío, se a le en orde.

Dúas credenciais, dúas afirmacións

Un certificado de servidor liga un nome a unha chave, e o cliente comproba esa ligazón contra o seu almacén de confianza. Un certificado de cliente liga unha identidade a unha chave, e a pasarela comproba que o certificado presentado encadea con algo no que confía. EAP transporta un intercambio de autenticación cuxo contido depende do método escollido. Son tres estruturas con vidas útiles distintas, propietarios distintos e modos de fallo distintos.

Unha frase de paso que desbloquea unha chave privada non é un contrasinal de conta, mesmo cando os dous avisos aparecen en cuestión de segundos. Un é local no almacén de chaves do dispositivo, e o outro valídao un servidor de autenticación detrás da pasarela.

EAP é un contedor, non un método

EAP é un marco: a pasarela e o cliente negocian un método, e o método decide se interveñen un contrasinal, un token, un intercambio interno tunelizado ou un certificado, como expón a documentación de strongSwan sobre IKEv2. Por iso EAP-TLS non se parece en nada a EAP-MSCHAPv2 desde o lado do cliente, aínda que ambos aparecen como EAP nun menú. Un perfil que só nomea EAP non lle dixo que se lle pedirá ao usuario.

Lea o método e o backend xuntos. O backend determina o formato da conta, o comportamento de bloqueo e que cambia realmente un restablecemento de contrasinal, e nada diso é visible no perfil do cliente.

O despregamento mixto é normal

Certificado de servidor máis EAP para o usuario é a forma que despregam a maioría das pasarelas de acceso remoto, porque dá ao cliente un extremo verificable e ao operador unha identidade por usuario nun almacén de contas central. Tamén existen despregamentos con certificados de cliente, normalmente onde a identidade do dispositivo importa máis que un contrasinal. Ambos son lexítimos, e o erro é supoñer que o que viu a semana pasada é o que ten diante.

Pida ao operador o método e o formato de conta documentados en lugar de inferilos dos nomes de campo dun cliente.

Decidir a partir da etapa do fallo

Ordene as observacións. Un erro de confianza antes de calquera aviso ao usuario é un problema de certificado de servidor e ningún contrasinal o arranxará. Un aviso seguido dun rexeitamento é un problema de autenticación de usuario, co método EAP e o backend como sospeitosos. Unha autenticación correcta seguida dun fallo de child-SA non é ningún dos dous.

Importan dúas distincións máis. Un cliente que rexeita o certificado do servidor adoita informar dunha discrepancia de nome ou dunha autoridade descoñecida, que é unha cuestión do almacén de confianza. Unha pasarela que rexeita o usuario a miúdo rexistra o método EAP e unha categoría de motivo, que é unha cuestión de conta ou de política.

Operar os dous modelos

Cos certificados o traballo é a emisión, a renovación, a revogación e a retirada de dispositivos perdidos, e ocorre segundo un calendario que vostede controla. Con EAP o traballo é o ciclo de vida da conta, a compatibilidade de métodos en cada plataforma cliente e o segundo factor que exixa o backend. Ningún modelo é máis barato en abstracto; cargan equipos distintos. Anote cal usa realmente o seu despregamento, porque os scripts de soporte difiren máis que a configuración.

Manteñaos separados nas súas notas. Unha caducidade de certificado produce un fallo nunha data, un bloqueo de conta produce un fallo tras un cambio de contrasinal, e unha discrepancia de método produce un fallo só nunha plataforma.

Despois de aceptar a identidade

A autenticación é unha porta. A asociación de seguridade filla, os selectores de tráfico, o DNS e os permisos propios da aplicación son portas posteriores, e cada unha falla coas súas condicións. Unha identidade aceptada que non chega a nada non é un problema de autenticación.

Rexiste o método, a conta ou o certificado utilizado e a etapa que fallou. Esa nota converte o seguinte incidente nunha consulta en lugar dun experimento.