Asignar una unidad de archivos VPN con la cuenta Samba que el servidor conoce
Un inicio de sesión de Windows o VPN no crea una cuenta Samba. Asigna el recurso con una identidad que conozca el servidor de archivos y vigila los conflictos de sesión.
Conecta el túnel y el recurso compartido sigue pidiendo una contraseña que el usuario cree correcta. En una instalación Samba independiente, el inicio de sesión VPN y el inicio de sesión SMB son credenciales sin relación: uno autoriza el túnel y el otro lo comprueba el servidor de archivos. Por eso, asignar la unidad con la cuenta VPN falla aunque la contraseña sea correcta y la ruta de red sea perfecta. Esa distinción explica la mayoría de los fallos de asignación a través de una VPN.
La solución no es restablecer la cuenta VPN. Consiste en nombrar una identidad que el servidor Samba conozca de verdad y luego comprobar que esa misma identidad tiene derechos sobre el recurso compartido y el directorio.
El inicio de sesión VPN y el de SMB son identidades distintas
La puerta de enlace VPN evalúa una cuenta VPN según su propia política. Responde si este cliente puede entrar en la red privada. No dice nada sobre qué cuenta SMB existe en un servidor de archivos dentro de esa red.
Una cuenta Samba vive en el backend de autenticación del servidor, con su propia base de datos de contraseñas y su propio nombre. Dos máquinas pueden tener ambas un usuario llamado alice sin compartir un sistema de identidad, una contraseña ni un identificador de usuario. Los nombres coinciden; las cuentas, no.
Un servidor Samba integrado en el dominio cambia el panorama: la identidad procede del directorio y de Kerberos, no de una lista local de cuentas. En ese caso, usa la identidad del directorio y la configuración SMB compatible en lugar de crear duplicados locales para imitar la pertenencia al dominio. Comprueba qué modelo usa el servidor antes de crear cualquier cuenta.
Comprueba qué identidad está usando Windows realmente
Windows almacena en caché las conexiones por servidor. Si una sesión existente hacia el mismo servidor se abrió con otra cuenta, una nueva asignación puede reutilizar esa sesión o fallar con un error de autenticación que nombra al usuario equivocado. Así es como una contraseña correcta parece incorrecta. Inspecciona las conexiones actuales antes de cambiar las credenciales.
net use
cmdkey /list
klist
El primer comando muestra las unidades asignadas y las sesiones abiertas, el segundo muestra las credenciales guardadas que pueden aplicarse automáticamente, y el tercero muestra los tickets de Kerberos cuando se usa un dominio. Una credencial guardada puede anular silenciosamente la cuenta que pretendías escribir.
Elimina solo la conexión o la credencial que pertenece a este problema. Desconectar todas las unidades o sustituir el nombre del servidor por una dirección IP oculta la elección de identidad y puede romper la firma o las políticas basadas en nombres.
Asigna el recurso con la cuenta que reconoce el servidor
Indica la cuenta en la forma que el servidor espera y deja que Windows pida la contraseña, para que el secreto no acabe en el historial de comandos ni en un script:
net use Z: \\files.corp.example\team * /user:FILESERVER\alice /persistent:no
El componente de servidor antes de la barra invertida es el contexto de identidad del servidor Samba, no la puerta de enlace VPN. El asterisco solicita una petición interactiva de contraseña, y /persistent:no mantiene la asignación fuera del siguiente inicio de sesión. Elige una letra de unidad libre.
Si el servidor está integrado en el dominio, el componente de usuario puede ser en cambio un nombre de directorio o una identidad cualificada por dominio. Usa la forma que documente el administrador; inventar una cuenta local con el mismo nombre crea una segunda identidad y una segunda contraseña que mantener.
Validez de la cuenta, acceso al recurso y derechos del sistema de archivos son tres comprobaciones
Samba comprueba si la identidad se autentica, si la definición del recurso la admite, y si el sistema de archivos concede la operación solicitada. Superar la primera comprobación no implica las otras dos. Un recurso puede ser visible y aun así rechazar escrituras porque los permisos del directorio lo dicen.
Un recurso restringido con valid users solo admite las cuentas o los grupos enumerados. La cuenta puede autenticarse correctamente y aun así ser rechazada por esa línea. Comprueba la definición del recurso antes de concluir que la contraseña es incorrecta.
En el lado del sistema de archivos importan tanto el proceso Samba como la identidad asignada. Un directorio propiedad de root con modo 700 no aceptará escrituras de una cuenta normal aunque la definición del recurso lo permita. Prueba con una lectura y luego con una escritura en un directorio que la cuenta deba usar.
Despeja una sesión en conflicto sin romper la política
Cuando la causa es una sesión obsoleta, cierra esa única conexión y vuelve a asignar con la cuenta prevista. Si una credencial guardada sigue reapareciendo, elimina esa credencial en lugar de toda la lista de unidades. Luego confirma la nueva sesión con net use.
Mantén la firma SMB, el cifrado y la política de cuentas obligatorios. Un servidor que rechaza una sesión sin firmar o sin cifrar está aplicando su política, no leyendo mal la contraseña, y debilitarla para que la asignación funcione cambia seguridad por un síntoma.
Anota el nombre del servidor, la forma exacta de la cuenta y los derechos de recurso y directorio que funcionaron. De lo contrario, la siguiente persona que asigne la unidad probará primero el inicio de sesión VPN, porque son las credenciales con las que llegó a la red.