☰

Active Directory 成员服务器无法找到域控制器

tag-icon • tag-icon active-directory domain-controller
Active Directory 成员服务器无法找到域控制器

几个小时前，我们的一些成员服务器无法通过它们应该使用的两个域控制器进行身份验证。成员服务器和 DC 位于同一个数据中心，并且位于 AD 中的单独“站点”上。运行 DCDiag 未显示任何问题，并且我们已确认服务器和 DC 彼此之间具有网络连接。在成员服务器上运行 nslookup 时，在每种情况下都会显示正确的 DC 被列为名称服务器。

LDAP 身份验证似乎正在工作，但是 Kerberos 身份验证已停止工作。基本上，所有关键的内部服务都已停止。

以下是我们在成员服务器上遇到的一些问题的具体情况：

Exchange - 拓扑服务找不到任何域控制器。因此，Exchange 信息存储无法启动。

SharePoint - IIS 级别以及 IIS 与 SQL 之间的身份验证失败（该服务器场已运行多年）。

其他故障排除：

NLTEST /DCLIST:domainname - 找不到 DC 以获取 DC 列表

NLTEST /Server:Servername – 两个 DC 均成功完成。

NLTEST /DSGetDC：Domain-命令成功完成。

NLTEST /dsgetsite — 成功完成。

GPUpdate - 找不到用户。不存在域

nslookup -type=SRV _kerberos._tcp.dc._msdcs.subdomain.mydomain.comExchange 服务器上的输出：

Server:  colo-dc-001.subdomain.mydomain.com
Address:  10.11.2.20

_kerberos._tcp.dc._msdcs.subdomain.mydomain.com SRV service location:
      priority       = 0
      weight         = 100
      port           = 88
      svr hostname   = branchf-dc-001.subdomain.mydomain.com
_kerberos._tcp.dc._msdcs.subdomain.mydomain.com SRV service location:
      priority       = 0
      weight         = 100
      port           = 88
      svr hostname   = colo-dc-001.subdomain.mydomain.com
_kerberos._tcp.dc._msdcs.subdomain.mydomain.com SRV service location:
      priority       = 0
      weight         = 100
      port           = 88
      svr hostname   = hq-dc-003.subdomain.mydomain.com
_kerberos._tcp.dc._msdcs.subdomain.mydomain.com SRV service location:
      priority       = 0
      weight         = 100
      port           = 88
      svr hostname   = colo-dc-002.subdomain.mydomain.com
_kerberos._tcp.dc._msdcs.subdomain.mydomain.com SRV service location:
      priority       = 0
      weight         = 100
      port           = 88
      svr hostname   = hq-dc-004.subdomain.mydomain.com
_kerberos._tcp.dc._msdcs.subdomain.mydomain.com SRV service location:
      priority       = 0
      weight         = 100
      port           = 88
      svr hostname   = branchc-dc-002.subdomain.mydomain.com
_kerberos._tcp.dc._msdcs.subdomain.mydomain.com SRV service location:
      priority       = 0
      weight         = 100
      port           = 88
      svr hostname   = branchm-dc-001.subdomain.mydomain.com
_kerberos._tcp.dc._msdcs.subdomain.mydomain.com SRV service location:
      priority       = 0
      weight         = 100
      port           = 88
      svr hostname   = branchs-dc-001.subdomain.mydomain.com
branchf-dc-001.subdomain.mydomain.com   internet address = 10.10.2.22
colo-dc-001.subdomain.mydomain.com  internet address = 10.11.2.20
hq-dc-003.subdomain.mydomain.com    internet address = 10.1.2.20
colo-dc-002.subdomain.mydomain.com  internet address = 10.11.2.21
hq-dc-004.subdomain.mydomain.com    internet address = 10.1.2.21
branchc-dc-002.subdomain.mydomain.com   internet address = 10.5.2.21
branchm-dc-001.subdomain.mydomain.com   internet address = 10.6.2.21
branchs-dc-001.subdomain.mydomain.com   internet address = 10.7.2.22

我们可以通过 RDP 连接到任何托管上述服务的服务器，但服务将无法运行。

成员服务器上的系统日志包含一些有关无法找到 DC 的错误消息。

因此，基本上，网络似乎已启动，DC 似乎已启动，但同一网段上的成员服务器无法找到它们。我们应该在哪里查找问题？

答案1

我会开始查看 DNS。对我来说，这确实像是 DNS。

_msdcs.domain.com前向查找区域是否看上去缺少了一些东西？

如果您运行nslookup -type=SRV _kerberos._tcp.dc._msdcs.domain.com您将获得什么输出？

当您运行失败的诊断命令时，请嗅探 DC 或成员服务器上的流量，如果问题不明显，请在此处发布输出。NLTEST /DCLIST:domain.com例如，该命令应导致客户端发出一些 DNS 来查找其站点中的 LDAP 服务器，然后进行几次 RPC 绑定。

答案2

此问题是由组策略更改引起的，该更改原本适用于最终用户工作站，但被错误地应用于某些成员服务器。组策略更改启用了 DirectAccess。

对于托管设施中的服务器，应用此策略会导致这些服务器认为它们处于不受信任的网络上。因此，它们启用了 Windows 防火墙，从而阻止它们定位或与我们的域控制器通信。

我们回滚了组策略应用的更改，从域中删除了成员服务器，然后将它们添加回域，从而解决了该问题。

相关内容