几个小时前，我们的一些成员服务器变得无法对他们应该使用的两个域控制器进行身份validation。 成员服务器和DC位于同一个数据中心，位于AD的单独“站点”。 运行DCDiag显示没有问题，我们已经确认服务器和数据中心之间具有networking连接。 在成员服务器上运行nslookup会在每种情况下显示列出的名称服务器。
LDAP身份validation似乎正在工作，但Kerberos身份validation已停止工作。 基本上，所有关键的内部服务已经停止。
以下是关于成员服务器所遇到的一些问题的具体情况：
Exchange – 拓扑服务找不到任何域控制器。 因此，Exchange信息存储无法启动。
- 强制拆分2003 Active Directory域
- 审计政策被“某事”
- 我想要replace现有的域控制器，但保持广告等
- 当第一个DC不再可用时，如何为所有angular色提供另一个DC
- 运行域控制器的风险是什么，以便可以从互联网访问？
SharePoint – 身份validation在IIS级别和IIS与SQL之间失败（此服务器场已连续多年）。
其他疑难解答
NLTEST / DCLIST：域名 – 没有DC可以findDC列表
NLTEST /服务器：Servername – 两个DC完成成功。
NLTEST / DSGetDC：域 – 命令成功完成。
NLTEST / dsgetsite – 成功完成。
GPUpdate – 用户无法find。 没有域名存在
交换服务器上的nslookup -type=SRV _kerberos._tcp.dc._msdcs.subdomain.mydomain.com输出：
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发送到任何托pipe上述服务的服务器，但服务将不起作用。
成员服务器上的系统日志包含一些关于无法findDC的错误消息。
所以基本上这个networking似乎已经起来了，DC似乎已经起来了，但是同一个网段上的成员服务器找不到它们。 我们应该在哪里寻找问题？
我会开始看DNS。 这真的闻起来像DNS给我。
它看起来像_msdcs.domain.com正向查找区域中缺less的东西？
如果你运行nslookup -type=SRV _kerberos._tcp.dc._msdcs.domain.com你会得到什么输出？
当运行失败的诊断命令时，嗅探数据中心或成员服务器上的stream量，如果问题不明显，则在此输出。 例如， NLTEST /DCLIST:domain.com命令应该导致客户端发出一些DNS，在其站点中寻找LDAP服务器，接着是几个RPC绑定。
此问题是由最终用户工作站的组策略更改引起的，但被错误地应用于某些成员服务器。 组策略更改启用了DirectAccess。
对于我们在托pipe机构的服务器，应用这个策略导致这些服务器得出结论，他们是在一个不受信任的networking上。 因此，他们启用Windows防火墙，阻止他们定位或与我们的域控制器通信。
我们回滚了组策略所应用的更改，从域中删除成员服务器，并将它们添加回域，并解决了问题。