抓包分析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加域过程的主要内容,如果未能解决你的问题,请参考以下文章
Windows Server 2012 (单林多树多站点)AD 部署系列创建辅助域控
Windows Server 2012(单林多树多站点)AD 部署系列创建树域
Windows Server 2012(单林多树多站点)AD 部署系列创建子域