Migrar um backend de autenticação VPN sem reutilizar hashes antigos

Os nomes de utilizador aparecem no novo diretório, a migração é declarada concluída e os inícios de sessão continuam a falhar. O gateway continua a precisar de um caminho de autenticação suportado e de um resultado de autorização correto, e nenhum dos dois decorre de um diretório que agora contém as contas. Uma mudança de backend é um corte com ciclo de vida, não uma tarefa de cópia. O sintoma abaixo é o que costuma revelar a diferença.

O sintoma: as contas existem e as sessões não

O novo diretório contém todos os nomes de utilizador, uma ligação de teste funciona e o cliente VPN continua a devolver uma falha de autenticação. Essa combinação significa que a identidade existe, mas o caminho de verificação usado pelo gateway não chega até ela, ou chega com um método que ela não consegue satisfazer. Ambas são configuração, e são problemas diferentes.

A primeira é canalização: o gateway aponta para um backend que não responde, usa um segredo partilhado que o outro lado não espera ou pede um atributo que o novo serviço não devolve. A segunda é criptográfica: o método exige o segredo original e o novo armazenamento guarda apenas um hash do mesmo. O texto do erro parece igual nos dois casos, e é por isso que os dois são tratados como um só problema.

Separar os dois antes de tocar nas contas poupa uma semana. Um é uma questão de encaminhamento e confiança, o outro é uma decisão sobre repor credenciais, e misturá-los produz alterações que ninguém consegue atribuir.

Mapeie a cadeia antes de mover alguém

Anote seis coisas por cada perfil de cliente: o método de autenticação externo, qualquer método interno, a identidade do servidor que o cliente espera, a interface entre gateway e backend, o atributo que o gateway mapeia para a pertença a grupos e a política de recursos resultante. Lê-los por ordem mostra qual elo não tem dono. Cada item tem um responsável, e o corte falha no que ninguém verificou.

Um início de sessão comum no diretório percorre quase nada dessa cadeia. Prova que a conta existe e que a palavra-passe funciona, que é justamente a parte que nunca esteve em dúvida.

Os hashes não viajam entre métodos

A compatibilidade das credenciais tem de ser verificada uma vez, antes de qualquer coorte se mover. O FreeRADIUS documenta a divisão com clareza: uma verificação CHAP que o servidor realiza ele próprio exige a palavra-passe real, e o MS-CHAP aceita essa palavra-passe ou material NT adequado. Um hash criado para outro fim não serve em nenhum dos casos, por mais forte que seja.

A distinção está em quem calcula a prova. Um método que verifica vinculando-se ao diretório deixa o diretório verificar o que consegue verificar. Um método que verifica recalculando uma resposta ao desafio precisa do próprio segredo, porque o servidor tem de efetuar o mesmo cálculo.

Onde falta o material, as opções honestas são uma reposição suportada, uma nova inscrição, um serviço de verificação externo ou uma mudança de método. Uma exportação temporária de palavras-passe recuperáveis não está nessa lista. Cria um armazém de credenciais em texto simples na semana mais caótica do projeto e normalmente sobrevive à migração.

Coorte piloto, depois alterações de ciclo de vida

Mova uma coorte pequena de identidades aprovadas com o cliente real e teste quatro coisas: um início de sessão novo, uma credencial deliberadamente errada, os recursos que a sessão pode alcançar e os recursos que não pode. Verifique também a identidade do servidor que o cliente aceitou, porque uma divergência no nome do certificado é invisível até alguém ler o registo do cliente.

Depois exercite as alterações de que a implementação realmente depende. Altere uma palavra-passe, renove ou volte a inscrever um certificado e retire o acesso a uma conta piloto. Após cada uma, confirme que verificador tratou da tentativa, porque uma sessão criada antes do corte pode continuar a funcionar e não prova nada sobre o próximo início de sessão.

Separe a entrega do perfil da mudança de identidade. Cada coorte precisa do perfil previsto, do estado da credencial ou inscrição, do serviço de autenticação que deve usar e de um contacto de suporte, e nenhum desses registos deve conter um segredo.

Se os caminhos antigo e novo coexistirem, delimite-os com uma data de fim. Um retrocesso automático pode admitir uma conta com uma credencial antiga depois de o novo proprietário ter retirado o acesso, e isso é uma regressão de segurança disfarçada de disponibilidade.

Reverter não pode restaurar uma credencial

Desfazer o corte deixa o diretório exatamente como está agora. Uma palavra-passe reposta continua reposta, um certificado revogado continua revogado e um formato de credencial alterado continua alterado. São acontecimentos no diretório, e o gateway nunca foi a sua origem. A recuperação tem de ser definida por acontecimento, e nada disso pode depender de reconstruir um segredo a partir de um hash incompatível.

Mantenha um caminho administrativo que não use a ligação que está a ser migrada. Quando a nova autenticação falhar, pause a coorte e use o caminho de recuperação documentado em vez de enfraquecer a autenticação para todos só para cumprir um prazo.

Depois de as coortes estarem cobertas, retire as credenciais, os perfis e as relações de confiança antigos do backend através dos seus proprietários. Confirme que o caminho antigo já não admite utilizadores e mantenha o mapeamento de identidade para política sem segredos de que o suporte ainda precisa. Uma migração termina quando o novo ciclo de vida funciona e ninguém entra já pelo caminho antigo, não quando a lista de contas parece completa.