为什么MS选项会破坏使用主机文件作为机器名称的SMB共享？

Question

我们已经在测试GPO上将"微软网络服务器:服务器SPN目标名称验证级别“设置为”来自客户端的要求“。

我们的测试系统在其主机文件中有一些自定义的机器别名，但是一旦打开该选项，我们就不能使用机器别名访问SMB共享。

我很难找到关于这种互动的信息，所以我希望有人能在这里解释这种互动，如果有办法补救的话？

Answer 1

这与‘主机’文件无关--它破坏通过a访问的共享，与服务器的“真实”名称不同。您的结果是正常的，因为这就是GPO的全部目的。

所讨论的GPO非常类似于一些web服务器中的TLS强制执行:客户端声明“我是来这里与服务器SRV01.EXAMPLE.COM交谈”，如果服务器不承认该名称是它服务的vhost之一，它就完全拒绝客户端。因此，在这里，如果客户机声明它想要与您的/etc/host别名之一进行对话，但服务器不知道别名，则拒绝客户机。

Kerberos已经有类似的内置执行(这就是为什么您需要注册SPN的别名使用setspn)，但是GPO使得它更严格，并将同样的保护扩展到NTLM。

(正如Docs页面中已经提到的，这应该是为了防止NTLM中继攻击，其中恶意服务器A接受NTLM身份验证，然后将完全相同的NTLM数据包转发给真正的服务器B-由于服务器B将从客户端看到“我想与服务器A对话”，因此将防止攻击。)

仍然可以使用主机别名，但它需要不断增加的注册表旋钮。官方的方法是使用netdom computername REALHOST /add:THEALIAS，就像在这个TechNet帖子中一样。我在博客上发现，即使使用严格的SPN验证，也足以使别名可用，但实际上它似乎还不够--至少有一个(如果不是两个)注册表值被它忘记了。

1. NETDOM为AD中的别名注册Kerberos SPN，允许为它们获取Kerberos票证，类似于手动发出这两个命令: setspn -S HOST/THEALIAS REALHOST$ setspn -S HOST/thealias.example.com REALHOST$这是Kerberos所必需的，在AD环境中不使用Kerberos没有任何借口，所以无论您选择使用NETDOM还是手工使用，您都应该注册别名SPN。(从技术上讲，SMB使用"cifs/“主体，但在AD中，只要注册"host/”SPN，它们就隐式存在。)
2. 然后，NETDOM在服务器注册中心的两个地方添加别名，导致服务器在adds中注册其附加名称，并通过NetBIOS Browser：宣布它们。
   • 路径：HKLM:\SYSTEM\CurrentControlSet\Services\Dnscache\Parameters名称：AlternateComputerNames类型: REG_MULTI_SZ数据：{thealias.example.com}
   • 路径：HKLM:\SYSTEM\CurrentControlSet\Services\LanmanServer\Parameters名称：OptionalNames类型: REG_MULTI_SZ数据：{THEALIAS}

它们似乎对身份验证(甚至Kerberos)没有任何影响，所以我相信，如果在DNS中使用/etc/host或创建手动CNAME记录，这两者都是完全可选的。

1. NETDOM没有创建的另一个参数是：，但我发现从服务器本身访问别名是必要的
   • 路径：HKLM:\SYSTEM\CurrentControlSet\Control\Lsa\MSV1_0名称：BackConnectionHostNames类型: REG_MULTI_SZ数据：{thealias.example.com}

这种连接仅用于“回送”连接，因此一般情况下可能并不是严格必要的，但至少在我的示例中，服务器确实需要连接到自己的别名，因此需要设置。

1. 最后，我发现"SPN目标名称验证“功能有它自己允许的名称列表，必须手动更新，否则即使在存在上述所有设置的情况下，别名也将被拒绝。
2. 路径：HKLM:\SYSTEM\CurrentControlSet\Services\LanmanServer\Parameters名称：SrvAllowedServerNames类型: REG_MULTI_SZ数据：{THEALIAS，thealias.example.com}

您需要列出每个别名的短名称和FQDNs -从我的实验来看，清单一并不自动暗示另一个别名。

在注册了Kerberos和设置了SrvAllowedServerNames注册表值之后，即使使用严格的目标验证，别名也应该能够正常工作。