☰

通过别名访问 Windows 文件服务器

tag-icon • tag-icon windows network-share kerberos cname-record file-sharing
通过别名访问 Windows 文件服务器

使用 DNS CNAME 而不是实际计算机名称访问 Windows 文件服务器共享可能存在哪些问题？文件服务器已加入 Active Directory 域，但不是域控制器。

例如，假设有一台计算机名为 的文件服务器SERVER1已加入 Active Directory 域branch.company.com。并且有一条files.company.com指向 的DNS CNAME 记录server1.branch.company.com。连接到 时可能出现哪些潜在问题\\files.company.com\sharename？

我目前知道的事情（但尚未证实）：

  1. HKLM\SYSTEM\CurrentControlSet\Services\LanmanServer\Parameters\SrvAllowedServerNames如果“Microsoft 网络服务器：服务器 SPN 目标名称验证级别”组策略设置未关闭（HKLM\SYSTEM\CurrentControlSet\Services\LanmanServer\Parameters\SmbServerNameHardeningLevel注册表值不为 0），则需要将别名添加到REG_MULTI_SZ 注册表值中。
  2. 需要将别名添加到HKLM\SYSTEM\CurrentControlSet\Control\Lsa\MSV1_0\BackConnectionHostNamesREG_MULTI_SZ 注册表值中（以使从服务器本身到别名的连接能够正常工作）。
  3. 可能需要使用如下命令在 Active Directory 中添加 SPN setspn -A host/files.company.com SERVER1（我不确定是否/何时需要这样做，以及如果没有这个命令，身份验证是否会从 Kerberos 降级到 NTLM）。

答案1

看起来 OP/问题中提到的三件事是重要的。

有关 Kerberos SPN 的更多信息（第 3 点）：

3.1. 看起来如果不存在 SPN，访问文件共享仍然有效（至少在许多情况/配置中），但将恢复使用 NTLM 身份验证。

3.2. 如果存在另一个 SPN 将别名与另一个 AD（计算机）帐户关联，则该别名将无法访问。

即，如果在 OP 示例中，files.company.com是旧的且已退役的文件服务器的名称，并且该文件服务器的 AD 计算机帐户（具有默认 SPN）仍然存在，则尽管 DNS CNAME 记录files.company.com指向server1.branch.company.com，\\files.company.com\sharename也将无法访问，因为客户端会尝试使用带有旧 SPN（files.company.com与已退役的文件服务器的 AD 帐户相关联）的 Kerberos 身份验证并失败。

3.3. 创建 SPNsetspn -S host/files.company.com SERVER1时应使用 而不是setspn -A host/files.company.com SERVER1，因为-S会检查是否存在重复的 SPN（在当前和未来版本的 Windows 上，-A选项可能既可以作为-S选项工作，也可以被完全删除）。

答案2

嗯，一个可能的问题可能是您的环境中存在多个 DNS 服务器，并且当前客户端将从正确的服务器获取 DNS 信息。
Windows 客户端设置

相关内容