Dar de alta a un usuario de VPN: primero encuentre al dueño de la identidad

Alguien pide acceso a la VPN y el primer instinto es ejecutar adduser en el servidor. Ese instinto solo es correcto en un conjunto estrecho de despliegues. Antes de crear nada, abra la configuración del servidor y averigüe qué producto se ejecuta allí y dónde valida las credenciales, porque la cuenta puede vivir en una base de datos del producto, en un proveedor de identidad o en la pila de autenticación propia del host. Crear el tipo de cuenta equivocado deja a la persona con un inicio de sesión que funciona y sin túnel.

Un perfil de cliente que dice OpenVPN describe el protocolo, no el sistema de identidad que hay detrás.

Empiece por el servidor, no por adduser

Identifique primero el producto. Community OpenVPN es el demonio más cualquier autenticación que haya conectado a él, mientras que Access Server es un producto con su propia capa de usuarios. Pida la configuración, el nombre de la unidad y la lista de paquetes, y compruebe si existe una interfaz web para gestionar usuarios. Después mire cómo el perfil desplegado espera que los clientes demuestren quiénes son: un certificado, un nombre de usuario y una contraseña, o ambos. Esa respuesta nombra el sistema que posee la cuenta.

Solo después de eso la frase crear al usuario significa algo. En un despliegue solo con certificados significa emitir una identidad de dispositivo mediante el proceso aprobado, y un inicio de sesión de Unix no cambia nada. En un despliegue con contraseña significa el backend que realmente valida la contraseña.

Cuatro backends, cuatro lugares donde crear la cuenta

La autenticación local de Access Server guarda las cuentas en su propia base de datos, así que la interfaz para crearlas pertenece al producto y no al host. PAM delega la validación en la pila del sistema operativo, y por eso una cuenta Unix local puede formar parte del alta cuando esa pila es la que el servicio eligió. LDAP, RADIUS y SAML trasladan la validación a un servicio externo, donde viven el aprovisionamiento, la política de contraseñas y el MFA. Access Server todavía puede mantener certificados y permisos por usuario en los cuatro casos, y eso es lo que hace confusa la separación.

Compruebe el método efectivo para este usuario concreto en lugar del valor predeterminado global. Access Server 2.10 y posteriores pueden aplicar métodos de autenticación distintos por grupo o por usuario, así que un valor predeterminado local no demuestra que la cuenta que tiene delante se valide localmente.

El derecho es una decisión aparte

La autenticación responde quién es la persona; el derecho responde a qué puede llegar. Mantenga ambos como dos pasos, porque un inicio de sesión correcto no es una concesión. Asigne deliberadamente las rutas previstas, los permisos de recursos y los derechos administrativos, y confirme que el acceso no relacionado sigue denegado. Donde el despliegue admite identidades individuales, emita una por persona en lugar de reenviar el perfil de otra, porque un perfil compartido no se puede retirar para una sola persona.

El material del cliente también importa. Un perfil de inicio automático y un inicio de sesión interactivo de usuario representan relaciones de autenticación distintas, e intercambiar uno por otro cambia qué verifica realmente el servidor.

Retirar el acceso forma parte del alta

Anote tres propietarios mientras se crea el usuario: quién valida la cuenta, quién autoriza el acceso a la VPN y qué dispositivo o perfil representa la conexión. Pueden ser tres sistemas distintos, y un plan de revocación que solo nombre uno deja un camino abierto. Cuando la persona se marcha, quite el derecho de su propietario y retire cada credencial emitida bajo su propietario. Borrar un archivo descargado no es revocar, y tampoco lo es borrar una entrada local si una identidad externa todavía se autentica.

Después pruebe el alta como lo haría un atacante: conéctese una vez con la identidad nueva, confirme el acceso al recurso previsto y confirme que un recurso no relacionado sigue rechazando. Una primera conexión que funciona más una prueba negativa es un alta completada.

Guarde el registro con el perfil al que pertenece. El siguiente auditor preguntará quién podía conectarse durante un mes determinado, y la respuesta vive en esos tres propietarios.