在 UNC 路径内传递 UNC 用户名和密码

Question 1

在 Windows 上，你不能将凭据放在 UNC 路径中。您必须在 Windows 要求时使用net use、或提供它们。runas /netonly

您还可以使用将密码存储为“域凭据” cmdkey /add:，或者使用 C 中的 CredWrite() 函数，这两种方法都相当于选中 Windows 中的“记住密码”框。

在 Linux 上，这取决于程序。

GNOME 的 Gvfs 接受该user@host语法，但似乎完全忽略了密码。（但是，您可以事先将其存储在 GNOME Keyring 中。）
smbclient使用与 Windows 相同的 UNC 语法；但是，它有一个--authentication-file可以从中读取凭据的选项。
上述两个程序都使用库，并且可以使用 Kerberos 身份验证代替密码：运行并使用。这比密码身份验证更安全。kinit [email protected]smbclient -k //host/share

请注意，将密码放入 URI 中的做法已被弃用，你不应该依赖它得到支持任何地方。

Answer

在 Windows 上，你不能将凭据放在 UNC 路径中。您必须在 Windows 要求时使用net use、或提供它们。runas /netonly

您还可以使用将密码存储为“域凭据” cmdkey /add:，或者使用 C 中的 CredWrite() 函数，这两种方法都相当于选中 Windows 中的“记住密码”框。

在 Linux 上，这取决于程序。

GNOME 的 Gvfs 接受该user@host语法，但似乎完全忽略了密码。（但是，您可以事先将其存储在 GNOME Keyring 中。）
smbclient使用与 Windows 相同的 UNC 语法；但是，它有一个--authentication-file可以从中读取凭据的选项。
上述两个程序都使用库，并且可以使用 Kerberos 身份验证代替密码：运行并使用。这比密码身份验证更安全。kinit [email protected]smbclient -k //host/share

请注意，将密码放入 URI 中的做法已被弃用，你不应该依赖它得到支持任何地方。

Question 2

您可以使用将“驱动器”映射到 UNC 路径net use。未来的访问应共享现有连接

Net Use \\yourUNC\path /user:uname password

注意：您不需要指定驱动器号

Answer

您可以使用将“驱动器”映射到 UNC 路径net use。未来的访问应共享现有连接

Net Use \\yourUNC\path /user:uname password

注意：您不需要指定驱动器号

Question 3

我认为必须先将用户名和密码传递给服务器进行身份验证，然后才能进行任何文件访问，因此处理 SMB 连接的代码必须能够从 URL 中解析并提取用户名和密码。您必须检查该代码是否支持这种格式。

如果没有，您可以通过 SAMBA 挂载该 SMB 共享并指示您的程序使用该“本地”路径。您可以将挂载放入fstabSAMBA 密码文件中并使用该文件来提供用户凭据。请记住为密码文件设置正确的权限，以便普通用户无法读取它。

请注意，在配置文件中以明文形式存储密码是不好的做法，因此即使您的程序可以处理 URL 中的密码，您也应该考虑使用 mounted 共享方法。

Answer

我认为必须先将用户名和密码传递给服务器进行身份验证，然后才能进行任何文件访问，因此处理 SMB 连接的代码必须能够从 URL 中解析并提取用户名和密码。您必须检查该代码是否支持这种格式。

如果没有，您可以通过 SAMBA 挂载该 SMB 共享并指示您的程序使用该“本地”路径。您可以将挂载放入fstabSAMBA 密码文件中并使用该文件来提供用户凭据。请记住为密码文件设置正确的权限，以便普通用户无法读取它。

请注意，在配置文件中以明文形式存储密码是不好的做法，因此即使您的程序可以处理 URL 中的密码，您也应该考虑使用 mounted 共享方法。

Question 4

非域 PC 不应真正关心它未订阅或直接参与的 DFS。它只需要查看共享路径（即服务器/共享名）。共享名消除了所有主机文件服务器路径考虑。

说实话，登录共享有比 UNC URI 更安全的方法。UNC 和 URI 本身就是明文通信协议。
如果这是可以接受的安全性……为什么不直接开放共享而不需要任何用户或密码呢？

最简单的直接解决方案是让服务凭证直接访问共享（例如匹配用户/密码）。长期来看，这种不太明显的匹配可能会使记住在情况发生变化时更新权限变得困难。这也是 MS 可能再次改变安全性传递凭证的方式并破坏现状的领域。

从长远来看，最简单的方法可能是将本地驱动器号永久映射到网络共享。仅对服务（和适当的管理员等）使用权限保护映射驱动器，并且共享名称可能以前导 & 隐藏。

但是 DFS 为更优雅的解决方案提供了线索。Linux 要求首先安装网络共享...通常作为根文件系统中的目录，方式与 DFS 非常相似。Linux mount 命令允许指定用户名和密码的凭据文件，从而使它们比命令行脚本或 fstab（即文件系统表）更容易更新和更安全。我很确定 Windows 命令 shell 和 DFS 可以做同样的事情（已经有一段时间了）。它只是一个不同的 DFS 系统，专用于目标 PC，使用由 SMB 和登录服务传递的存储凭据来合并安装的网络共享，而不是硬编码在脚本中并以明文 UNC 发送。

还要考虑该非域 PC 是否会长期保持非域 PC 身份。*NIX 域中的 Kerberos 登录服务器可以链接到 Windows AD 域。对于涉及多人的长期严肃项目，这可能是您想要做的。另一方面，对于大多数家庭网络情况，它可能有点过头了。不过，如果您使用 DFS 是出于任何好的理由，而不是业余爱好者的自我挑战，那么它可能是最好的选择。

Answer