Para onde vai o código do desafio estático num login OpenVPN

O cliente mostra uma segunda caixa depois do campo da palavra-passe, introduz o código do token de hardware, e o login continua a falhar com um erro de autenticação. Essa caixa existe, por isso o perfil pediu-a. Se o servidor chegou a receber o valor numa forma que compreende é outra questão, e é ela que vale a pena responder primeiro.

Comece pelo pedido que o seu cliente mostra de facto

Um perfil pode transportar uma diretiva de desafio estático com uma cadeia de pedido e um sinalizador que controla se a resposta é mostrada enquanto escreve. O pedido é o que vê na caixa de diálogo; o sinalizador é uma preferência de visualização para essa mesma entrada. Nenhum deles diz ao servidor como verificar o que quer que seja.

Conte os campos que realmente lhe foram dados. Um campo para um nome de utilizador mais um campo mascarado é um login normal por palavra-passe sem qualquer desafio. Um segundo campo que aparece depois da palavra-passe, com o seu próprio rótulo, é o cliente a implementar a interação do desafio.

Se a segunda caixa nunca aparece no cliente que utiliza, talvez esse cliente não implemente a interação, ou só a implemente através de outra interface, como uma interface de gestão. Verificar o cliente é mais barato do que reescrever o perfil, e é normalmente onde a discrepância realmente está.

O que o servidor já tem de suportar

O perfil descreve o que o cliente deve recolher. Não ativa a verificação no servidor, e um servidor sem a integração de autenticação correspondente receberá simplesmente uma palavra-passe que não reconhece. É por isso que algumas instalações mostram o pedido e rejeitam todos os códigos, e é por isso que a resposta do operador sobre que mecanismo faz a verificação é a que importa.

Pergunte ao operador que mecanismo faz a verificação. Pode ser um módulo que fala com o PAM, um gancho de script que valida a resposta contra um serviço de tokens, ou uma integração baseada na gestão que analisa ela própria o valor empacotado. Cada um espera uma entrada ligeiramente diferente.

Aqui também é preciso calibrar as expectativas. Um segundo pedido é um mecanismo de entrada, não a prova de que um segundo fator é aplicado, porque a aplicação acontece do lado do servidor e só se nota quando testa um código errado.

O campo codificado que a interface de gestão envia

Quando uma interface conduz a ligação através da interface de gestão, a palavra-passe e a resposta ao desafio são empacotadas num único valor antes do envio. A referência da interface de gestão documenta o formato: um prefixo e depois a palavra-passe e a resposta como componentes Base64 separados.

Base64 é uma codificação, não uma proteção. Não esconde nada de quem consiga ler o campo, e não transforma um código de uso único em algo reutilizável. O valor empacotado merece o mesmo tratamento que uma palavra-passe: fora dos perfis partilhados, fora das linhas de comando e fora dos registos de diagnóstico.

Essa codificação é também a fonte de confusão mais comum, porque há agora três formas que se parecem e não são intermutáveis. Um ficheiro de credenciais simples contém uma palavra-passe. Uma concatenação literal da palavra-passe e do código contém outra cadeia. A resposta empacotada de um cliente de gestão contém uma terceira. Confirme qual delas o seu caminho de verificação espera antes de alterar um campo só porque um erro desapareceu.

Estático versus dinâmico: momento diferente

Um desafio estático é conhecido antes de a primeira credencial ser submetida, por isso o cliente pode pedi-lo antecipadamente. Um desafio dinâmico chega mais tarde, enviado pelo fluxo de autenticação depois de uma troca já ter começado, e precisa de um cliente capaz de lidar com um pedido a meio da conversa.

O suporte de um não lhe dá o outro. Uma diretiva de perfil que configura um pedido estático não implementa um desafio iniciado pelo servidor, e uma interface que trata pedidos dinâmicos pode continuar a não mostrar um estático. Ler que lado iniciou o pedido é a forma mais rápida de os distinguir.

O funcionamento sem supervisão é onde isto se torna uma questão de conceção e não de interface. Um código guardado não é uma credencial duradoura de arranque, e uma reconexão horas depois exigirá uma entrada nova, a menos que a instalação suporte um arranjo de tokens que o operador tenha ativado deliberadamente.

Teste o êxito e a falha, não apenas a caixa de diálogo

Execute as duas metades do teste. Credenciais corretas com uma resposta válida devem ter êxito; credenciais corretas com uma resposta deliberadamente errada devem ser rejeitadas. Se ambas tiverem êxito, o cliente está a recolher uma entrada que nada verifica, e a caixa de diálogo foi tomada por um controlo. Esse único teste apanha mais instalações do que qualquer revisão de perfil.

Depois repita a ligação após uma reconexão, com uma conta que não esteja inscrita, e através do cliente que os seus utilizadores realmente executam. O aparecimento do pedido é um comportamento do cliente; a rejeição de um código errado é o servidor a aplicar algo.