Você adiciona um script client-connect que rejeita toda conexão em que common_name difere de username, e ele parece um vínculo entre um certificado e uma conta. Num servidor que executa username-as-common-name, essa comparação já perdeu o sentido quando o script é executado. Os dois valores são a mesma string, então o teste passa para um certificado emitido a outra pessoa completamente diferente.

A verificação não está errada porque o script foi mal escrito. Ela está errada porque o valor que ele lê foi substituído antes na mesma conexão.

O que a comparação parece provar

A autenticação por certificado e a autenticação por senha são provas separadas, e um servidor pode exigir ambas sem exigir que pertençam à mesma pessoa. A lacuna é real: um certificado de dispositivo válido mais qualquer conta válida é uma afirmação diferente daquele certificado mais uma única conta nomeada. Um script que compara common_name com username lê-se como o elo perdido entre os dois. Seria, se common_name ainda significasse o que o certificado dizia.

Se é o caso depende de uma opção do servidor, e essa opção costuma ser ativada por um motivo não relacionado, como tornar os arquivos de configuração por usuário mais fáceis de nomear.

O que username-as-common-name faz com o nome

Com username-as-common-name habilitado, o OpenVPN substitui o nome comum do certificado pelo nome de usuário autenticado depois que o nome de usuário e a senha são verificados. O gancho de verificação que roda durante essa checagem ainda recebe o nome comum do certificado, porque a substituição ainda não aconteceu. Tudo depois disso, incluindo client-connect, vê o nome de usuário. Assim, o retorno de chamada posterior recebe uma identidade duas vezes e não pode compará-la com o certificado apresentado.

StageWhat common_name holds
Username and password verification hookThe certificate common name, for example bob-device
After the replacementThe authenticated account, alice
client-connect callbackThe account again, alice

Acompanhe uma conexão ilustrativa: um certificado emitido para bob-device, um login de diretório bem-sucedido como alice e a opção habilitada. A fase de verificação ainda pode ver duas strings diferentes. A fase de conexão vê alice e alice.

Esse exemplo mostra por que a comparação está vazia. Ele não mostra que a conexão seria aceita de outra forma, já que a validação do certificado e a verificação da senha ainda rodam por conta própria.

Coloque o vínculo onde ambas as identidades ainda existem

A regra deve ser aplicada numa fase que veja a identidade do certificado e a conta ao mesmo tempo, o que na prática significa o gancho de verificação de nome de usuário e senha ou um plugin carregado ali. Um plugin suportado que já realiza a verificação de senha costuma ser o lugar certo para adicionar uma regra de pareamento, porque substituí-lo por uma comparação de nomes eliminaria a checagem de senha por completo.

Defina o mapeamento antes de escrever código, já que a igualdade raramente é a política real. Um certificado muitas vezes identifica um dispositivo enquanto o login identifica uma pessoa, e um dispositivo pode legitimamente atender várias pessoas. Armazene a relação numa forma cuja emissão você controla, e decida o que acontece na renomeação, na reemissão e com nomes qualificados por domínio. Converter para minúsculas ou remover um prefixo de domínio sem entender o diretório pode fundir duas contas que deveriam permanecer distintas.

Lembre-se de que a opção também muda qual configuração por cliente se aplica, porque client-config-dir é indexado pelo nome comum.

Teste o pareamento com duas credenciais válidas

Comece com o par que sua política permite e confirme que ele conecta. Depois apresente o mesmo certificado válido com uma conta diferente, mas igualmente válida: essa tentativa deve falhar, e deve falhar pela regra de pareamento e não por uma senha digitada errado. Uma senha errada prova que a checagem de senha funciona e não diz nada sobre a regra entre certificado e conta.

Verifique também os caminhos sem certificado e com certificado inválido, e confirme qual identidade o servidor usa para as configurações por cliente. Se o único jeito de a comparação funcionar é desativar username-as-common-name, calcule primeiro o custo dessa mudança, porque ela devolve a busca de configuração de cada cliente ao nome do certificado.

Artigos relacionados