背景

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

遇到的问题

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

image.png

问题定位过程

因掌握的信息有限，所以想复现一下实际报错。于是在海南的服务器上部署了一台虚拟机，安装好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" image.png

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

第一次查询： image.png 第二次查询： image.png

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

image.png

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

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

image.png

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

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

    • 客户端的站点
    • 当前域控制器所在的站点
    • Closest Flags标识位 (0或者1,0为不同站点，1位同一站点)，用于指示当前DC是否位于相同的站点中。 通过抓的包来看看： image.png

  • 客户端查询到自己对应的站点后，开始向DNS服务器查找该站点内的SRV记录 "_ldap._tcp.站点名._sites.dc._msdcs.immomo.com"

image.png

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

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

  • 向选中的DC发起CLDAP请求，响应结果如图示： image.png

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