用服务器已知的 Samba 账户映射 VPN 文件共享

连上隧道后，共享仍然询问一个用户自认为正确的密码。在独立部署的 Samba 中，VPN 登录与 SMB 登录是彼此无关的凭据：前者批准隧道，后者由文件服务器校验。因此，即使密码正确、网络路径无误，用 VPN 账户映射驱动器仍会失败。这一区别解释了大多数通过 VPN 映射的故障。

解决办法不是重置 VPN 账户。正确的做法是指定一个 Samba 服务器真正认识的身份，然后确认同一身份拥有共享和目录的权限。

VPN 登录与 SMB 登录是不同的身份

VPN 账户由 VPN 网关按自己的策略评估。它回答的是该客户端能否进入专用网络。它并不说明该网络内文件服务器上存在哪个 SMB 账户。

Samba 账户位于服务器的认证后端，有自己的密码数据库和名称。两台机器都可以有名为 alice 的用户，却并不共享身份系统、密码或用户标识符。名字相同，账户不同。

加入域的 Samba 服务器会改变情况：身份来自目录和 Kerberos，而不是本地账户列表。此时应使用目录身份和受支持的 SMB 配置，而不是创建本地副本来模仿域成员资格。创建任何账户之前，先确认服务器采用哪种模型。

Windows 按服务器缓存连接。如果指向同一服务器的现有会话是用另一个账户打开的，新映射可能复用该会话，或以指名错误用户的认证错误失败。正确的密码就是这样显得不正确。更改凭据前先检查当前连接。

net use
cmdkey /list
klist

第一条命令显示已映射的驱动器和打开的会话，第二条显示可能被自动应用的已存凭据，第三条在使用域时显示 Kerberos 票据。已存的凭据可能悄悄覆盖你打算输入的账户。

只删除属于该问题的那一个连接或凭据。断开所有驱动器或用 IP 地址替换服务器名，会掩盖身份选择，并可能破坏签名或基于名称的策略。

按服务器期望的形式提供账户，并让 Windows 提示输入密码，这样密码就不会落入命令历史或脚本：

net use Z: \\files.corp.example\team * /user:FILESERVER\alice /persistent:no

反斜杠前的服务器部分是 Samba 服务器的身份上下文，而不是 VPN 网关。星号要求交互式密码提示，/persistent:no 则使该映射不进入下次登录。选择一个空闲的驱动器盘符。

如果服务器已加入域，用户部分也可以是目录名或带域限定的身份。使用管理员记录的写法；凭空创建同名本地账户会造出第二个身份和第二个需要维护的密码。

Samba 会检查身份能否通过认证、共享定义是否接纳它，以及文件系统是否授予所请求的操作。通过第一项检查并不意味着另外两项也通过。共享可能可见，却仍然拒绝写入，因为目录权限如此规定。

用 valid users 限制的共享只接纳列出的账户或组。账户可以正确认证，却仍会被该行拒绝。在断定密码错误之前，先检查共享定义。

在文件系统一侧，Samba 进程和映射身份都很重要。归 root 所有、权限为 700 的目录不会接受普通账户写入，即使共享定义允许。请在账户应当使用的目录里先读后写进行测试。

如果是陈旧会话导致的，只关闭那一个连接，再用预期账户重新映射。如果已存凭据反复出现，删除该凭据，而不是整个驱动器列表。然后用 net use 确认新会话。

保留必需的 SMB 签名、加密和账户策略。拒绝未签名或未加密会话的服务器是在执行策略，而不是读错了密码；为了让映射成功而削弱它，是用安全换一个症状。

记录服务器名、确切的账户形式以及奏效的共享和目录权限。否则下一位映射驱动器的人会先尝试 VPN 登录，因为那正是他用来接入网络的凭据。