我们有一个 Nexenta 文件服务器，它使用域身份验证来对用户进行身份验证。我们网络上的所有 Windows 7 计算机都可以连接并使用其上的共享，无论是使用 \XX.YY.ZZ.AA\share 还是 \fileserver\share，都不会出现任何问题。
我们在域中添加了一台新的 Windows 7 计算机，但出于某种原因，我无法使用 \XX.YY.ZZ.AA\share 或 \fileserver\share 访问文件服务器。我可以从新计算机 ping 并连接到文件服务器的 Web 界面，但即使使用可以从其他正常运行的 Windows 7 计算机访问共享的用户帐户登录到这台新计算机，也无法连接到共享。
当我尝试通过 IP 地址连接时收到错误：
检查名称的拼写。否则，您的网络可能有问题。要尝试识别和解决网络问题，请单击“诊断”。
当我尝试通过机器名称连接时出现错误：
\fileserver\share 无法访问。您可能没有权限使用此网络资源。请联系此服务器的管理员，了解您是否有访问权限。
无法通过 IP 号码连接到共享对我来说似乎非常奇怪。
新信息 (1) 另一条信息。当我从 Windows 7 机器进行连接时，我运行了 ipconfig /flushdns，但它突然停止工作了。现在无法通过 IP 或名称连接到它。
新信息 (2) 澄清新信息 (1)，文件服务器有两个 IP 号，一个用于连接其 SAN，另一个用于连接一般网络。当我无法连接它时，我可以毫无问题地 ping 它：即我看到：
ping 文件服务器 正在 Ping fileserver.domain.com XXX.XXX.XXX.XX，数据为 32 字节：来自 XXX.XXX.XXX.XXX 的回复：字节=32 时间<1ms TTL=254
如果我运行 ipconfig /flushdns，它偶尔会获取该名称的 SAN 接口 IP。现在，当我 ping 文件服务器时，我无法访问它（正如预期的那样）
ping 文件服务器 正在 Ping fileserver.domain.com YYY.YYY.YYY.YYY 带有 32 字节数据：超时
但是，奇怪的是，我现在可以连接到共享 \fileserver。
我真的希望 MS 能为您提供一种更好的方法来打开操作系统中的日志记录。我感觉发生的事情与客户端尝试使用 DNS 查找服务器名称并尝试连接有关，并且当它无法连接时（因为 DNS 返回了我无法访问的 SAN 接口的 IP），它会返回到 NETBIOS，这出于某种原因使其工作。
答案1
我首先比较一下LM兼容性级别非工作机器和工作机器之间的设置。我感觉客户端和服务器之间的 NTLM 协议协商有些问题。
如果可以，请针对您描述的每次尝试捕获客户端和服务器之间的流量数据包。没有什么比实际看到线路上的比特发生了什么更好的了。
编辑：
我很难想出 DNS 是问题所在。这无法解释您在尝试通过 IP 地址访问计算机时看到的消息，这肯定看起来像是 TCP 连接没有建立。如果看起来 TCP 连接正在建立但身份验证失败，我可以看到 DNS（特别是 Kerberos 和 SPN 中的域名）参与其中。
捕获一些流量。数据包想告诉你发生了什么事...>微笑<