Registrar um usuário de VPN: primeiro encontre o dono da identidade
Adicionar um usuário de VPN começa pelo sistema de identidade, não pelo shell. Descubra qual backend valida a conta, conceda o direito e planeje a revogação.
Alguém pede acesso à VPN, e o primeiro instinto é executar adduser no servidor. Esse instinto só está correto num conjunto estreito de implantações. Antes de criar qualquer coisa, abra a configuração do servidor e descubra qual produto roda ali e onde ele valida credenciais, porque a conta pode viver num banco de dados do produto, num provedor de identidade ou na própria pilha de autenticação do host. Criar o tipo errado de conta deixa a pessoa com um login que funciona e sem túnel.
Um perfil de cliente que diz OpenVPN descreve o protocolo, não o sistema de identidade por trás dele.
Comece pelo servidor, não pelo adduser
Identifique o produto primeiro. Community OpenVPN é o daemon mais qualquer autenticação que você tenha conectado a ele, enquanto Access Server é um produto com sua própria camada de usuários. Peça a configuração, o nome da unidade e a lista de pacotes, e verifique se existe uma interface web para gerenciar usuários. Depois veja como o perfil implantado espera que os clientes provem quem são: um certificado, um nome de usuário e senha, ou ambos. Essa resposta nomeia o sistema que possui a conta.
Só depois disso a frase criar o usuário significa algo. Numa implantação apenas com certificados, isso significa emitir uma identidade de dispositivo pelo processo aprovado, e um login Unix não muda nada. Numa implantação com senha, isso significa o backend que realmente valida a senha.
Quatro backends, quatro lugares para criar a conta
A autenticação local do Access Server mantém as contas em seu próprio banco de dados, então a interface para criá-las pertence ao produto e não ao host. O PAM delega a validação à pilha do sistema operacional, e é por isso que uma conta Unix local pode fazer parte do registro quando esse é o stack que o serviço escolheu. LDAP, RADIUS e SAML movem a validação para um serviço externo, onde vivem o provisionamento, a política de senhas e o MFA. O Access Server ainda pode manter certificados e permissões por usuário nos quatro casos, e é isso que torna a separação confusa.
Verifique o método efetivo para este usuário específico em vez do padrão global. O Access Server 2.10 e posteriores podem aplicar métodos de autenticação diferentes por grupo ou por usuário, então um padrão local não prova que a conta à sua frente seja validada localmente.
O direito é uma decisão separada
A autenticação responde quem é a pessoa; o direito responde a que ela pode chegar. Mantenha os dois como duas etapas, porque um login bem-sucedido não é uma concessão. Atribua deliberadamente as rotas pretendidas, as permissões de recursos e os direitos administrativos, e confirme que o acesso não relacionado continua negado. Onde a implantação suporta identidades individuais, emita uma por pessoa em vez de encaminhar o perfil de outra, porque um perfil compartilhado não pode ser revogado para uma única pessoa.
O material do cliente também importa. Um perfil de login automático e um login interativo de usuário representam relações de autenticação diferentes, e trocar um pelo outro muda o que o servidor realmente verifica.
Revogar o acesso faz parte do registro
Anote três proprietários enquanto o usuário é criado: quem valida a conta, quem autoriza o acesso à VPN e qual dispositivo ou perfil representa a conexão. Podem ser três sistemas diferentes, e um plano de revogação que nomeia apenas um deles deixa um caminho aberto. Quando a pessoa sai, remova o direito do seu proprietário e revogue cada credencial emitida sob seu proprietário. Apagar um arquivo baixado não é revogar, e apagar uma entrada local também não é se uma identidade externa ainda se autentica.
Depois teste o registro como um atacante faria: conecte uma vez com a nova identidade, confirme o acesso ao recurso pretendido e confirme que um recurso não relacionado ainda recusa. Uma primeira conexão que funciona mais um teste negativo é um registro concluído.
Guarde o registro com o perfil ao qual pertence. O próximo auditor perguntará quem podia se conectar durante um determinado mês, e a resposta vive nesses três proprietários.