抓包分析AD多站点下Windows加域过程

Posted 史振宁的技术博客

tags:

篇首语:本文由小常识网(cha138.com)小编为大家整理,主要介绍了抓包分析AD多站点下Windows加域过程相关的知识,希望对你有一定的参考价值。

背景

海南分公司有一套Linux DNS Server负责内部解析,将公司域名immomo.com的解析则递归到办公区的域控制器解析。

遇到的问题

收到组内同学转来的一个故障,说是海南办公区加域有问题。可以和成都IT同学了解详情。
和成都IT同学沟通后了解到,海南IT同学跟他反馈,Windows客户端DNS指向Linux DNS时加域失败 , 有如下图中的报错。如果DNS指向域控制器则正常加域。 怀疑Linux DNS缺少配置。IDC同学、系统运维也在帮着跟进这个问题了,目前还没解决。

问题定位过程

因掌握的信息有限,所以想复现一下实际报错。于是在海南的服务器上部署了一台虚拟机,安装好wireshark ,将DNS指向Linux DNS。

  • 将客户端加域,同时启动wireshark进行抓包,这样加域失败,就可以通过抓包工具分析出原因了。 结果顺利完成加域。停止抓包。

  • 将测试结果反馈给成都IT同学。成都IT同学进一步反馈,服务器网段没有策略限制,是guest网段加不了域。

  • 进一步掌握了这个信息后,可以确定2个事情了。一、 Linux DNS没有问题。二、 网络策略限制了。

  • 联系成都IT,让对方将海南办公区Guest网络的ACL策略发一下,进一步定位哪条规则。 对方反馈得找IDC同学查看下。
  • 联系IDC同学,查看相关配置,看到ACL里只开放了Linux DNS的UDP 53。修改该规则,改为放开这个IP。
  • 让海南同学再次测试加域问题,恢复正常了。[如果新增一条TCP 53,应该也是可以的]

分析加域过程

  • 客户端通过DNS,查询SRV记录 "_ldap._tcp.dc._msdcs.immomo.com"

从图中可以到看,客户端查询了两次,第一次并没有查到结果,第二次才查询到。仔细看了下两次的区别,原来第一次使用的udp 53, 第二次使用的是tcp 53。 这也许就是为什么只开放udp 53时,客户端加域失败的原因。

第一次查询:

第二次查询:

  • DNS将域内所有的DC列表返回

  • 客户端获取到DC列表之后,会根据优先级和权重等从中选取一个,解析出IP,然后发起CLDAP连接,目标端口为UDP的389,发出searchRequest请求。

第一次抓包选的是172.x.x.88:

第二次抓包选的是10.x.x.9:

  • CLDAP searchRequest 返回的结果是什么呢?

    • 客户端的站点
    • 当前域控制器所在的站点
    • Closest Flags标识位 (0或者1,0为不同站点,1位同一站点),用于指示当前DC是否位于相同的站点中。
      通过抓的包来看看:
  • 客户端查询到自己对应的站点后,开始向DNS服务器查找该站点内的SRV记录 "_ldap._tcp.站点名._sites.dc._msdcs.immomo.com"

  • 这次DNS服务器返回的是该站点内的所有DC列表

  • 根据优先级和权重,选取站点内的一台DC,并向DNS查询该DC的IP地址

  • 向选中的DC发起CLDAP请求,响应结果如图示:

  • 之后就是通过smb、kerberos进行复杂的认证过程了。 之后完成加域。

以上是关于抓包分析AD多站点下Windows加域过程的主要内容,如果未能解决你的问题,请参考以下文章

如何实现windows7系统的批量退域及加域

Windows Server 2012 (单林多树多站点)AD 部署系列创建辅助域控

Windows Server 2012(单林多树多站点)AD 部署系列创建树域

Windows Server 2012(单林多树多站点)AD 部署系列创建子域

Windows Server 2012 AD 站点和域部署系列部署准备工作

客户端加域AD需要开放的端口