一、 DNS在AD中的作用
微软域中，域控及域客户端使用DNS定位DC的位置，并使用DNS作为AD林和域的体系架构的一个mirror。
AD对DNS的依赖体现在以下3个方面：
l Domain controller locator (Locator)
l Active Directory domain names in DNS
l Active Directory DNS objects
1. Domain controller locator (Locator)
这部分功能在netlogon service中实现，客户端可以通过此功能定位到域中的DC的位置
2. Active Directory domain names in DNS
域中的所有客户端包括DC有一个DNS domain name，比如win2kserver.contoso.com。
在微软域架构中，DNS domain和AD domain有共同的domain name，但是这2个namespace保存着不同的数据，管理不同的对象：
l DNS存储zones和resource记录，AD存储domains objects（如用户和计算机账号），他们使用各自的database去解析记录或对象。
l DNS根据客户端的请求，将domain names或computer name解析成DNS database中对应的记录
l AD根据DC或者LDAP search的请求将domain object解析成object record，或者根据修改请求修改AD database
3. Active Directory DNS objects
当DNS数据存储在AD中，每个DNS zone会被当做是一个AD容器(class dnsZone)对象，dnsZone对象包含zone中每个唯一记录对应的DNS node 对象(class dnsNode)
二、 Netlogon service在AD中的功能
安装ADDS服务的操作系统启动之后，netlogon service会使用DNS dynamic update protocol自动注册相关的SRV和A记录(AD和DNS集成部署的情况下)，如果srv记录丢失，会导致域客户端无法定位到DC的地址
三、 加域具体流程
1. 本地Netlogon service初始化一个RPC客户端作为Locator
2. Locator收集选择DC所需信息并传递给Netlogon（DsGetDcName API实现）
3. Netlogon使用第2步的信息查找DC：Netlogon查询DNS中的SRV记录（SRV记录是Netlogon拼接固定字符串和域名_ldap._tcp.dc._msdcs.DomainName）和A记录，DNS返回SRV查询响应(DC IP和PORT 389/UDP)
4. netlogon使用UDP发送LDAP数据报文到第3步查询到的所有域控
5. 可用的域控响应第4步中的请求，指示local netlogon域控可用并返回信息，优先选择client同网段DC
6. netlogon service缓存dc信息，之后和域控的请求不用在进行1-5步的发现步骤，也会确保netlogon会和同一个域控交互，一定程度确保信息一致
四、 加域过程中的网络数据流
域客户端加域大概流程如下：
1. 在DNS上查询srv记录：_ldap._tcp.dc._msdcs.DomainName，查询类型为srv。
客户端加域过程中，要通过查询此SRV记录查找DC地址，本文档中domain为lab.huawei.com。此过程需要保证客户端解析域名正常，并且解析DNS上的SRV记录正常。
DNS查询_ldap._tcp.dc._msdcs.lab.huawei.com，正常结果会返回所有的域控的FQDN及域控IP，以及LDAP端口389/udp
2. 客户端通过389/udp向上面查询到的所有DC地址发送LDAP消息
响应中包含了可提供服务的DC的基本信息
3. 通过ldap/udp协议查询所有域控状态结束之后，客户端通过smb2协议(445/tcp端口)和离自己最近的DC建立smb2连接，并进行身份验证。
l 客户端先发送smb Negotiate Protocal Request请求，请求中包含了客户端支持的各种smb Dialects，smb中协议版本用dialect表示。
l server返回SMB2 Negotiate Protocol Response，内容包括使用SMB2协议，具体的Dialect返回0x02ff，根据报文格式，server返回0x02ff，表示server实现了smb2.1及以上的版本，希望客户端再发送smb2 Negotiate Protocol Request到server再次协商具体的smb2协议版本，参考连接：https://msdn.microsoft.com/en-us/library/cc246561.aspx
l client再次发送smb2 Negotiate Protocol Request到server，因为第一次的Negotiate Protocol Request报文响应中server端已经决定使用smb2，所有此次的Request报文中的Dialect只包含客户端支持的具体的smb2版本的协议：0x0202（smb2.0.2），0x0210 (smb2.1)
l server端根据client提供的smb2 dialect列表，选择一个最终版本进行后续通信，此次通信选择了版本0x0210（smb2.1）。同时server返回支持的身份认证算法列表
l 根据smb2 Negotiate Protocol Response提供的身份认证算法，client会向DNS查询SRV记录中的_kerberos记录，从中选择一个kerberos服务器建立kerberos连接(88/tcp)。
Kerberos工作大致流程如下图：
在client向KDC请求session Ticket之前，client需要向KDC请求TGT（Ticket Granting Ticket）,有了此ticket，client才能向KDC申请访问其他server的Ticket。申请TGT的流程和上图类似，此时server为KDC自己。当client有TGT，之后再向KDC申请ticket时，只需要使用session认证就可以请求其他server的ticket，不需要再使用自己的master key。client可以使用同一个TGT向KDC申请不同server的ticket。Kerberos整个认证过程通过3个sub-protocol来完成。这个3个Sub-Protocol分别完成上面的3个子过程。这3个sub-protocol分别为：
u Authentication Service Exchange
u Ticket Granting Service Exchange
u Client/Server Exchange
n Authentication Service Exchange
通过这个Sub-protocol，KDC（确切地说是KDC中的Authentication Service）实现对Client身份的确认，并颁发给该Client一个TGT。
Client向KDC的Authentication Service发送Authentication Service Request（KRB_AS_REQ）, 为了确保KRB_AS_REQ仅限于自己和KDC知道，Client使用自己的Master Key对KRB_AS_REQ的主体部分进行加密（KDC可以通过Domain 的Account Database获得该Client的Master Key）。KRB_AS_REQ的大体包含以下的内容：
Ø Pre-authentication data：包含用以证明自己身份的信息。说白了，就是证明自己知道自己声称的那个account的Password。一般地，它的内容是一个被Client的Master key加密过的Timestamp。
Ø Client name & realm: 简单地说就是Domain name\Client
Ø Server Name：注意这里的Server Name并不是Client真正要访问的Server的名称，这里的Server Name实际上是KDC的Ticket Granting Service的Server Name。
AS（Authentication Service）通过它接收到的KRB_AS_REQ验证发送方的是否是在Client name & realm中声称的那个人，也就是说要验证发送放是否知道Client的Password。所以AS只需从Account Database中提取Client对应的Master Key对Pre-authentication data进行解密，如果是一个合法的Timestamp，则可以证明发送放提供的是正确无误的密码。验证通过之后，AS将一份Authentication Service Response（KRB_AS_RES）发送给Client。KRB_AS_RES主要包含两个部分：本Client的Master Key加密过的Session Key和被自己（KDC）加密的TGT。而TGT大体又包含以下的内容：
² Session Key: SKDC-Client：Logon Session Key
² Client name & realm: 简单地说就是Domain name\Client
² End time: TGT到期的时间。
n TGS（Ticket Granting Service）Exchange
TGS（Ticket Granting Service）Exchange通过Client向KDC中的TGS（Ticket Granting Service）发送Ticket Granting Service Request（KRB_TGS_REQ）开始。KRB_TGS_REQ大体包含以下的内容：
² TGT：Client通过AS Exchange获得的Ticket Granting Ticket，TGT被KDC的Master Key进行加密。
² Authenticator：用以证明当初TGT的拥有者是否就是自己，所以它必须以TGT的Master key和自己的Session Key（SKDC-Client：Logon Session Key）来进行加密。
² Client name & realm: 简单地说就是Domain name\Client。
Server name & realm: 简单地说就是Domain name\Server，这回是Client试图访问的那个Server。
Kerberos原理参考：https://blog.csdn.net/wulantian/article/details/42418231
l Kerberos验证完成之后SMB2继续Session Setup Request，客户端和服务器建立一个session，在客户端发送的Session Setup Request里，包含了身份验证请求（如Kerberos的AP_REQ）
服务器回复Session Setup Response，包含了验证结果(如Kerberos的AP_REP)
Session Setup通过后，客户端就成功的连上了服务器。客户端发送的Tree Connect Request来访问具体的共享，如果前面没有指定共享名（\服务器名），客户端访问的是命名管道$IPC
服务器在检查过用户对该路径的权限后，回复Tree Connect Response。检查用户权限是这样进行的：服务器从Session Setup Request中已经得到用户所属的组，再通过和该路径上的ACL对比，即可得到用户权限
4. 客户端使用SMB2再次查询域控上的基础信息，此时用户已经经过认证，对域控有更多权限，可以查询到更多信息
5. 客户端通过RPC协议(135/tcp)连接之前绑定的DC服务器，根据RPC的响应连接DC上的RPC动态端口，动态端口值可以在RPC的MAP response中看到。如下图为49157，然后Client连接49157端口，通信过程中都包含kerberos认证(ticket)
最终客户端通过RPC协议完成正常的加域过程
五、 加域失败问题定位思路
要确保成功加域，要确保加域的客户端能给正常连接到域，加域客户端和域的DC直接满足加域需要的网络及端口矩阵，加域失败的情况下，可以按照以下步骤排查：
1. 检查客户端是否有正确的IP地址及DNS地址
Ø 使用ipconfig /all命令或其他方法检查客户端的网卡配置，检查虚拟机的IP地址和DNS是否配置正确
加域客户端网卡上配置的DNS地址建议只配置为客户端所要加入域的权威DNS，不要包含其他DNS地址，否则会导致域解析异常。如果IP地址和DNS配置错误，请先修正此配置。
Ø 在网卡上配置有正确的IP地址及正确的DNS的情况下，通过以下方法检查客户端解析域名是否正常，检查虚拟机和域控之间通信是否正常
使用nslookup命令测试域名解析，如果最终无法解析到域名，请排查以下方面：
² IP及DNS地址配置是否正常，特别是DNS地址配置
² 客户端能否和DNS正常通信，特别是DNS 53/tcp、53/udp
² DNS服务器是否正常，特别是DNS上的SRV记录是否丢失。参考案例：https://forum.huawei.com/enterprise/zh/forum.php?mod=viewthread&tid=312435
² 请参考微软support上的案例处理其他情况
客户端和DC之间未禁止ping的情况下，输出结果如下;如果禁止ping，无法ping通属正常现象。
如果未开启telnet客户端，按照以下方法开启telnet客户端：
通过域名或者IP测试和DNS的53/tcp端口是否能通，如果端口不通请排查端口不通的原因：
² DNS服务异常，未监听53端口
² DNS服务器防火墙或网络中间安全设备禁用了53端口
2. 之后在加域过程中失败，可以手动加域并抓包，参照第四步的过程分析。
发表评论 取消回复