我正在尝试使用 net use 在脚本中挂载网络文件夹，但一直收到密码错误。我使用以下语法：
use \\server\share password /User:serviceaccount
这样做会返回错误密码错误。如果我将 * 作为密码，并在提示符下输入，则一切正常。
我还尝试将密码括在双引号“”中，但没有效果。这个特定的密码是随机生成的，由 14 个字符组成，包括大写字母、小写字母、数字和特殊字符（在本例中，唯一的特殊字符是 $）。
该脚本在 Windows Server 2008 R2 上运行，并连接到 Server 2003。
通过命令行参数传递给 net use 的密码类型是否有任何限制？
编辑：这是在 PowerShell 中运行的。
答案1
事实证明，虽然旧的 net use 文档表明您需要使用双引号，但在 PowerShell 中您应该使用单引号括住密码。
答案2
在“工作组环境”（没有适当的 NT 域）中从 Win2012R2 连接到 Samba 3.6.6 时，我遇到了这种不当行为。
以下两个版本均无法可靠运行：
NET USE X: \\server\share password /User:username
NET USE X: \\server\share /User:username password
奇怪的是，有 10% 的可能性会可以工作！而且，如果我尝试在命令行参数中跳过密码，并让“NET USE”提示我，那么成功率就有 95% 了。
我在另一台服务器（具有不同升级历史和配置的 Linux）上有另一个共享，运行良好。
最初我怀疑是“特殊字符”，因为我的新密码“更强”。我尝试在密码周围使用单引号或双引号，但无济于事。我尝试设置一个非常简单（且弱）的密码 - 但无济于事。
然后我发现建议首先使用 cmdkey 在本地保存正确的登录凭据。以前从未要求这样做，但我还是尝试了：
cmdkey /add:<machine> /user:<username> /pass:<password>
这样，我确实保存了客户端计算机上登录用户的凭据，但并没有解决 NET USE 的神秘登录失败问题。
然后我开始摸索 Samba 配置和日志。
调试 Samba 身份验证时，以下 smb.conf 选项可能会派上用场：
log level = 3 passdb:10 auth:10
默认值可能是log level = 2，甚至不记录失败的登录尝试。
Samba 在 /var/log/samba/ 中创建有用的日志文件。对于每台传入的客户端计算机，它会创建两个文件：
log.<ip_address>
log.<netbios_name>
随着日志级别的提升，可以清楚地看到基于 IP 的日志在 smbd 了解机器的 NetBios 名称的地方结束 - 并在第二个文件中继续。
并且还清楚地看到，“密码验证”实际上是一个相当复杂的过程 :-) CIFS 网络握手都有几次数据交换，而 Samba 服务器对凭据的处理也并非微不足道。在成功和失败的尝试中，在上述log level 10（选择 auth 和 passdb）中，您都会得到两页密集的日志列表，其中 Samba 提示它如何尝试添加域以及如何尝试通过映射用户username map，最后尝试检查凭据（至少两次）。奇怪的是，对于NET USE客户端上的两种不同使用风格，该过程略有不同：在命令行上使用密码（语法没有区别）与使用密码提示。确切的过程可能还取决于auth backend您在 Samba 服务器上选择的。我的是简单的旧 passdb（/etc/samba/smbpasswd）。
对我来说，罪魁祸首可能是该username map功能。Samba 服务器上的 smb.conf 不是我自己的宝贝，我是一路走来才了解到这个功能的。我发现其他人警告说它可能会咬人。它甚至可以用于将多个 Windows 用户映射到单个本地 UNIX 用户，或者只是 1:1 - 无论哪种方式，请注意，Samba 将尝试使用“重新映射”的用户名而不是原始 Windows 用户名（您也可以在 smbpasswd 中输入）来查找（验证）登录凭据。这可能是我的问题。一旦我从 /etc/samba/smbusers 中删除“罪魁祸首用户名”，我的NET USE行就开始工作了，在命令行中使用两种格式中的一种，并使用密码。
不确定为什么 Samba 有时会尝试 Windows 用户名，而有时又尝试重新映射的用户名。这可能是特定于 smbd 和 passdb 的特定历史版本的“功能”。或者客户端和服务器上不同 CIFS 实现的特定交互。
然后我遇到了一个后续问题（在身份验证之后），其中security = user结合组可访问的底层目录和 /etc/passwd（和 /etc/group）中配置错误的组意味着我的客户端登录了，但被拒绝访问此类 CIFS 目录...请注意，在某些发行版或配置样式中，所有 UNIX 用户共享一个“用户”默认组，而在其他发行版中，他们被分配了一个为每个新用户新创建的单独的默认组...
对于服务器是 Windows 2003 计算机的情况，这个答案有什么用？除了一般背景之外，可能没什么用，CIFS 有着悠久的历史/发展，并且各种 Windows CIFS 代可能具有与开源 Samba 实现类似的“交叉兼容性怪癖”。从允许或拒绝旧版本身份验证协议的策略开始：LanMan 和 NTLM1，出于安全原因（旧协议的主要缺陷），它们通常会在更现代的客户端或服务器上被管理禁止。我特别记得 Windows 7（或者是 Windows 8？）开始在默认配置中坚持使用 NTLMv2 的情况。