EAP ou certificados de cliente? Decidir a autenticação IKEv2

A sua gateway pode provar a sua própria identidade com um certificado enquanto prova a sua através de EAP, e essa combinação é comum e não contraditória. Os dois mecanismos respondem a perguntas diferentes: este endpoint é o que espero, e este utilizador ou dispositivo está autorizado. Ver EAP num perfil não desativa a validação do servidor. É ler o perfil como uma única definição que leva as pessoas a redefinir a credencial errada.

Determine qual afirmação falhou antes de tocar em qualquer um dos dois objetos. A etapa da falha diz-lho, se a ler por ordem.

Duas credenciais, duas afirmações

Um certificado de servidor liga um nome a uma chave, e o cliente verifica essa ligação contra o seu repositório de confiança. Um certificado de cliente liga uma identidade a uma chave, e a gateway verifica se o certificado apresentado encadeia com algo em que confia. O EAP transporta uma troca de autenticação cujo conteúdo depende do método escolhido. São três estruturas com tempos de vida, proprietários e modos de falha diferentes.

Uma frase-passe que desbloqueia uma chave privada não é uma palavra-passe de conta, mesmo quando os dois pedidos aparecem a segundos de distância. Uma é local ao repositório de chaves do dispositivo, e a outra é validada por um servidor de autenticação atrás da gateway.

O EAP é um contentor, não um método

O EAP é um enquadramento: a gateway e o cliente negoceiam um método, e o método decide se estão envolvidos uma palavra-passe, um token, uma troca interna tunelizada ou um certificado, como expõe a documentação do strongSwan sobre IKEv2. É por isso que o EAP-TLS não se parece nada com o EAP-MSCHAPv2 do lado do cliente, embora ambos apareçam como EAP num menu. Um perfil que nomeia apenas EAP não lhe disse o que será pedido ao utilizador.

Leia o método e o backend em conjunto. O backend determina o formato da conta, o comportamento de bloqueio e o que uma redefinição de palavra-passe altera realmente, e nada disso é visível no perfil do cliente.

A implementação mista é normal

Certificado de servidor mais EAP para o utilizador é a forma que a maioria das gateways de acesso remoto implementa, porque dá ao cliente um endpoint verificável e ao operador uma identidade por utilizador num repositório de contas central. Também existem implementações com certificados de cliente, normalmente onde a identidade do dispositivo importa mais do que uma palavra-passe. Ambas são legítimas, e o erro é assumir que o que viu na semana passada é o que está à sua frente.

Peça ao operador o método e o formato de conta documentados em vez de os inferir a partir de nomes de campos num cliente.

Decidir a partir da etapa da falha

Ordene as observações. Um erro de confiança antes de qualquer pedido ao utilizador é um problema de certificado de servidor e nenhuma palavra-passe o corrige. Um pedido seguido de uma rejeição é um problema de autenticação do utilizador, com o método EAP e o backend como suspeitos. Uma autenticação bem-sucedida seguida de uma falha de child-SA não é nenhum dos dois.

Mais duas distinções contam. Um cliente que recusa o certificado do servidor relata normalmente uma incompatibilidade de nome ou uma autoridade desconhecida, o que é uma questão do repositório de confiança. Uma gateway que recusa o utilizador registra frequentemente o método EAP e uma categoria de motivo, o que é uma questão de conta ou de política.

Operar os dois modelos

Com certificados, o trabalho é emissão, renovação, revogação e remoção de dispositivos perdidos, e acontece segundo um calendário que controla. Com EAP, o trabalho é o ciclo de vida da conta, o suporte de métodos em cada plataforma cliente e o segundo fator que o backend exigir. Nenhum modelo é mais barato em abstrato; carregam equipas diferentes. Anote qual usa realmente a sua implementação, porque os scripts de suporte diferem mais do que a configuração.

Mantenha-os separados nas suas notas. Uma expiração de certificado produz uma falha numa data, um bloqueio de conta produz uma falha após uma mudança de palavra-passe, e uma incompatibilidade de método produz uma falha apenas numa plataforma.

Depois de a identidade ser aceite

A autenticação é uma porta. A associação de segurança filha, os seletores de tráfego, o DNS e as permissões da própria aplicação são portas posteriores, e cada uma falha nos seus próprios termos. Uma identidade aceite que não chega a nada não é um problema de autenticação.

Registe o método, a conta ou o certificado utilizado e a etapa que falhou. Essa nota transforma o próximo incidente numa consulta em vez de uma experiência.