Migrar un backend de autenticación VPN sin reutilizar hashes antiguos

Los nombres de usuario aparecen en el nuevo directorio, la migración se declara terminada y los inicios de sesión siguen fallando. La pasarela aún necesita una ruta de autenticación compatible y un resultado de autorización correcto, y ninguno de los dos se deduce de un directorio que ahora contiene las cuentas. Una mudanza de backend es un corte con ciclo de vida, no una tarea de copia. El síntoma siguiente es el que suele revelar la diferencia.

El síntoma: las cuentas existen y las sesiones no

El nuevo directorio contiene todos los nombres de usuario, una vinculación de prueba funciona y el cliente VPN sigue devolviendo un fallo de autenticación. Esa combinación significa que la identidad existe, pero la ruta de verificación que usa la pasarela no llega a ella, o llega con un método que no puede satisfacer. Ambas cosas son configuración, y son problemas distintos.

La primera es fontanería: la pasarela apunta a un backend que no responde, usa un secreto compartido que el otro lado no espera o pide un atributo que el nuevo servicio no devuelve. La segunda es criptográfica: el método exige el secreto original y el nuevo almacén solo guarda un hash del mismo. El texto del error se parece en ambos casos, por eso los dos se tratan como un solo problema.

Separar esos dos antes de tocar las cuentas ahorra una semana. Uno es una cuestión de enrutamiento y confianza, el otro una decisión sobre restablecer credenciales, y mezclarlos produce cambios que nadie puede atribuir.

Traza la cadena antes de mover a nadie

Anota seis cosas por cada perfil de cliente: el método de autenticación externo, cualquier método interno, la identidad del servidor que espera el cliente, la interfaz entre pasarela y backend, el atributo que la pasarela asigna a la pertenencia a grupos y la política de recursos resultante. Leerlos en orden muestra qué eslabón no tiene dueño. Cada elemento tiene un responsable, y el corte falla en el que nadie comprobó.

Un inicio de sesión normal en el directorio apenas recorre esa cadena. Demuestra que la cuenta existe y que la contraseña funciona, que es justo la parte que nunca estuvo en duda.

Los hashes no viajan entre métodos

La compatibilidad de credenciales debe comprobarse una vez, antes de mover ninguna cohorte. FreeRADIUS documenta bien la división: una comprobación CHAP que el servidor realiza por sí mismo necesita la contraseña real, y MS-CHAP acepta esa contraseña o material NT adecuado. Un hash generado para otro propósito no encaja en ninguno de los dos casos, por fuerte que sea.

La distinción está en quién calcula la prueba. Un método que verifica vinculándose al directorio deja que el directorio compruebe lo que puede comprobar. Un método que verifica recalculando una respuesta al desafío necesita el secreto mismo, porque el servidor debe efectuar el mismo cálculo.

Donde falta el material, las opciones honestas son un restablecimiento compatible, una nueva inscripción, un servicio de verificación externo o un cambio de método. Una exportación temporal de contraseñas recuperables no está en esa lista. Crea un almacén de credenciales en texto plano durante la semana más caótica del proyecto y normalmente sobrevive a la migración.

Cohorte piloto, después cambios de ciclo de vida

Mueve una cohorte pequeña de identidades aprobadas con el cliente real y prueba cuatro cosas: un inicio de sesión nuevo, una credencial deliberadamente incorrecta, los recursos a los que la sesión puede llegar y los recursos a los que no debe llegar. Comprueba también la identidad del servidor que aceptó el cliente, porque un desajuste en el nombre del certificado es invisible hasta que alguien lee el registro del cliente.

Después ejercita los cambios de los que depende realmente el despliegue. Cambia una contraseña, renueva o vuelve a inscribir un certificado y retira el acceso a una cuenta piloto. Tras cada uno, confirma qué verificador atendió el intento, porque una sesión creada antes del corte puede seguir funcionando y no demuestra nada sobre el próximo inicio de sesión.

Separa la entrega de perfiles del cambio de identidad. Cada cohorte necesita su perfil previsto, su estado de credencial o inscripción, el servicio de autenticación que debe usar y un contacto de soporte, y ninguno de esos registros debe contener un secreto.

Si las rutas antigua y nueva coexisten, delimítalas con una fecha de fin. Un retroceso automático puede admitir una cuenta con una credencial antigua después de que el nuevo propietario haya retirado el acceso, y eso es una regresión de seguridad disfrazada de disponibilidad.

Revertir no puede restaurar una credencial

Deshacer el corte deja el directorio exactamente como está ahora. Una contraseña restablecida sigue restablecida, un certificado revocado sigue revocado y un formato de credencial cambiado sigue cambiado. Son eventos del directorio, y la pasarela nunca fue su origen. La recuperación debe definirse por evento, y nada de ello puede depender de reconstruir un secreto a partir de un hash incompatible.

Mantén una ruta administrativa que no use la conexión que se migra. Cuando la nueva autenticación falla, pausa la cohorte y usa su ruta de recuperación documentada en lugar de debilitar la autenticación para todos con tal de cumplir un plazo.

Cuando las cohortes estén cubiertas, retira las credenciales, los perfiles y las relaciones de confianza antiguos del backend a través de sus propietarios. Confirma que la ruta antigua ya no admite usuarios y conserva la asignación de identidad a política sin secretos que soporte aún necesita. Una migración termina cuando el nuevo ciclo de vida funciona y nadie entra ya por la ruta antigua, no cuando la lista de cuentas parece completa.