Migrar un backend de autenticación VPN sen reutilizar hashes antigos

Os nomes de usuario aparecen no novo directorio, a migración declárase rematada e os inicios de sesión seguen fallando. A pasarela aínda necesita unha ruta de autenticación compatible e un resultado de autorización correcto, e ningún dos dous se deduce dun directorio que agora contén as contas. Unha mudanza de backend é un corte con ciclo de vida, non unha tarefa de copia. O síntoma seguinte é o que adoita revelar a diferenza.

O síntoma: as contas existen e as sesións non

O novo directorio contén todos os nomes de usuario, unha vinculación de proba funciona e o cliente VPN segue devolvendo un fallo de autenticación. Esa combinación significa que a identidade existe, pero a ruta de verificación que usa a pasarela non chega a ela, ou chega cun método que non pode satisfacer. Ambas son configuración, e son problemas distintos.

A primeira é fontanería: a pasarela apunta a un backend que non responde, usa un segredo compartido que o outro lado non espera ou pide un atributo que o novo servizo non devolve. A segunda é criptográfica: o método esixe o segredo orixinal e o novo almacén só garda un hash del. O texto do erro parécese nos dous casos, por iso os dous se tratan como un só problema.

Separar eses dous antes de tocar as contas aforra unha semana. Un é unha cuestión de encamiñamento e confianza, o outro é unha decisión sobre restablecer credenciais, e mesturalos produce cambios que ninguén pode atribuír.

Traza a cadea antes de mover a ninguén

Anota seis cousas por cada perfil de cliente: o método de autenticación externo, calquera método interno, a identidade do servidor que espera o cliente, a interface entre pasarela e backend, o atributo que a pasarela asigna á pertenza a grupos e a política de recursos resultante. Lelos por orde mostra que elo non ten dono. Cada elemento ten un responsable, e o corte falla no que ninguén comprobou.

Un inicio de sesión normal no directorio percorre case nada desa cadea. Proba que a conta existe e que o contrasinal funciona, que é xustamente a parte que nunca estivo en dúbida.

Os hashes non viaxan entre métodos

A compatibilidade das credenciais ten que comprobarse unha vez, antes de mover calquera cohorte. FreeRADIUS documenta a división con claridade: unha comprobación CHAP que o servidor realiza el mesmo precisa o contrasinal real, e MS-CHAP acepta ese contrasinal ou material NT axeitado. Un hash creado para outro fin non encaixa en ningún dos dous casos, por forte que sexa.

A distinción está en quen calcula a proba. Un método que verifica vinculándose ao directorio deixa que o directorio comprobe o que pode comprobar. Un método que verifica recalculando unha resposta ao desafío precisa o propio segredo, porque o servidor ten que efectuar o mesmo cálculo.

Onde falta o material, as opcións honestas son un restablecemento compatible, unha nova inscrición, un servizo de verificación externo ou un cambio de método. Unha exportación temporal de contrasinais recuperables non está nesa lista. Crea un almacén de credenciais en texto plano durante a semana máis caótica do proxecto e normalmente sobrevive á migración.

Cohorte piloto, despois cambios de ciclo de vida

Move unha cohorte pequena de identidades aprobadas co cliente real e proba catro cousas: un inicio de sesión novo, unha credencial deliberadamente incorrecta, os recursos aos que a sesión pode chegar e os recursos aos que non debe chegar. Comproba tamén a identidade do servidor que aceptou o cliente, porque un desaxuste no nome do certificado é invisible ata que alguén le o rexistro do cliente.

Despois exercita os cambios dos que depende realmente o despregamento. Cambia un contrasinal, renova ou volve inscribir un certificado e retira o acceso a unha conta piloto. Tras cada un, confirma que verificador atendeu o intento, porque unha sesión creada antes do corte pode seguir funcionando e non demostra nada sobre o próximo inicio de sesión.

Separa a entrega de perfís do cambio de identidade. Cada cohorte necesita o seu perfil previsto, o seu estado de credencial ou inscrición, o servizo de autenticación que debe usar e un contacto de soporte, e ningún deses rexistros debe conter un segredo.

Se as rutas antiga e nova coexisten, delimítaas cunha data de fin. Un retroceso automático pode admitir unha conta cunha credencial antiga despois de que o novo propietario retirase o acceso, e iso é unha regresión de seguridade disfrazada de dispoñibilidade.

Reverter non pode restaurar unha credencial

Desfacer o corte deixa o directorio exactamente como está agora. Un contrasinal restablecido segue restablecido, un certificado revogado segue revogado e un formato de credencial cambiado segue cambiado. Son acontecementos no directorio, e a pasarela nunca foi a súa orixe. A recuperación ten que definirse por acontecemento, e nada diso pode depender de reconstruír un segredo a partir dun hash incompatible.

Mantén unha ruta administrativa que non use a conexión que se está a migrar. Cando a nova autenticación falla, pausa a cohorte e usa a súa ruta de recuperación documentada en lugar de debilitar a autenticación para todos só para cumprir un prazo.

Cando as cohortes estean cubertas, retira as credenciais, os perfís e as relacións de confianza antigos do backend a través dos seus propietarios. Confirma que a ruta antiga xa non admite usuarios e conserva a asignación de identidade a política sen segredos que o soporte aínda precisa. Unha migración termina cando o novo ciclo de vida funciona e ninguén entra xa pola ruta antiga, non cando a lista de contas parece completa.