一、            DNSAD中的作用

微软域中,域控及域客户端使用DNS定位DC的位置,并使用DNS作为AD林和域的体系架构的一个mirror

ADDNS的依赖体现在以下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 domainAD domain有共同的domain name,但是这2namespace保存着不同的数据,管理不同的对象:

l  DNS存储zonesresource记录,AD存储domains objects(如用户和计算机账号),他们使用各自的database去解析记录或对象。

l  DNS根据客户端的请求,将domain namescomputer 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 serviceAD中的功能

安装ADDS服务的操作系统启动之后,netlogon service会使用DNS dynamic update protocol自动注册相关的SRVA记录(ADDNS集成部署的情况下),如果srv记录丢失,会导致域客户端无法定位到DC的地址

参考文档:https://docs.microsoft.com/en-us/previous-versions/windows/it-pro/windows-server-2003/cc759550(v=ws.10)

三、            加域具体流程

1. 本地Netlogon service初始化一个RPC客户端作为Locator

2. Locator收集选择DC所需信息并传递给NetlogonDsGetDcName API实现)

3. Netlogon使用第2步的信息查找DCNetlogon查询DNS中的SRV记录(SRV记录是Netlogon拼接固定字符串和域名_ldap._tcp.dc._msdcs.DomainName)和A记录,DNS返回SRV查询响应(DC IPPORT 389/UDP)

4. netlogon使用UDP发送LDAP数据报文到第3步查询到的所有域控

5. 可用的域控响应第4步中的请求,指示local netlogon域控可用并返回信息,优先选择client同网段DC

6. netlogon service缓存dc信息,之后和域控的请求不用在进行1-5步的发现步骤,也会确保netlogon会和同一个域控交互,一定程度确保信息一致

 

四、            加域过程中的网络数据流

域客户端加域大概流程如下:

170747wdtpde5jpdtpzoje.png

1.       DNS上查询srv记录:_ldap._tcp.dc._msdcs.DomainName,查询类型为srv

客户端加域过程中,要通过查询此SRV记录查找DC地址,本文档中domainlab.huawei.com。此过程需要保证客户端解析域名正常,并且解析DNS上的SRV记录正常。

170748lhd6h7f7ow79do2h.png

DNS查询_ldap._tcp.dc._msdcs.lab.huawei.com,正常结果会返回所有的域控的FQDN及域控IP,以及LDAP端口389/udp

170749mzy6rrfg7q7wggyu.png

2.       客户端通过389/udp向上面查询到的所有DC地址发送LDAP消息

170750f55put5nqqwdthtt.png

响应中包含了可提供服务的DC的基本信息

170751ijuacc5x36wwj97t.png

3.       通过ldap/udp协议查询所有域控状态结束之后,客户端通过smb2协议(445/tcp端口)和离自己最近的DC建立smb2连接,并进行身份验证。

l  客户端先发送smb Negotiate Protocal Request请求,请求中包含了客户端支持的各种smb Dialectssmb中协议版本用dialect表示。

170752i00mvr0itr70ymvm.png

l  server返回SMB2 Negotiate Protocol Response,内容包括使用SMB2协议,具体的Dialect返回0x02ff,根据报文格式,server返回0x02ff,表示server实现了smb2.1及以上的版本,希望客户端再发送smb2 Negotiate Protocol Requestserver再次协商具体的smb2协议版本,参考连接:https://msdn.microsoft.com/en-us/library/cc246561.aspx

 

170753wd4zf2jmyp4upfb9.png

170754b7d87h6f97ooj00f.png

l  client再次发送smb2 Negotiate Protocol Requestserver,因为第一次的Negotiate Protocol Request报文响应中server端已经决定使用smb2,所有此次的Request报文中的Dialect只包含客户端支持的具体的smb2版本的协议:0x0202smb2.0.2),0x0210 (smb2.1)

170756zan479ddbtab4cst.png

l  server端根据client提供的smb2 dialect列表,选择一个最终版本进行后续通信,此次通信选择了版本0x0210smb2.1)。同时server返回支持的身份认证算法列表

170757t2xyiqz2mz355kic.png

l  根据smb2 Negotiate Protocol Response提供的身份认证算法,client会向DNS查询SRV记录中的_kerberos记录,从中选择一个kerberos服务器建立kerberos连接(88/tcp)

Kerberos工作大致流程如下图:

170758os5zecrkzhh97np7.png

clientKDC请求session Ticket之前,client需要向KDC请求TGTTicket Granting Ticket,有了此ticketclient才能向KDC申请访问其他serverTicket。申请TGT的流程和上图类似,此时serverKDC自己。当clientTGT,之后再向KDC申请ticket时,只需要使用session认证就可以请求其他serverticket,不需要再使用自己的master keyclient可以使用同一个TGTKDC申请不同serverticketKerberos整个认证过程通过3sub-protocol来完成。这个3Sub-Protocol分别完成上面的3个子过程。这3sub-protocol分别为:

u  Authentication Service Exchange

u  Ticket Granting Service Exchange

u  Client/Server Exchange

170759d95yr5mfo1t5kr5o.png

n  Authentication Service Exchange

通过这个Sub-protocolKDC(确切地说是KDC中的Authentication Service)实现对Client身份的确认,并颁发给该Client一个TGT

ClientKDCAuthentication Service发送Authentication Service RequestKRB_AS_REQ为了确保KRB_AS_REQ仅限于自己和KDC知道,Client使用自己的Master KeyKRB_AS_REQ的主体部分进行加密(KDC可以通过Domain Account Database获得该ClientMaster Key)。KRB_AS_REQ的大体包含以下的内容:

Ø  Pre-authentication data:包含用以证明自己身份的信息。说白了,就是证明自己知道自己声称的那个accountPassword。一般地,它的内容是一个被ClientMaster key加密过的Timestamp

Ø  Client name & realm: 简单地说就是Domain name\Client

Ø  Server Name:注意这里的Server Name并不是Client真正要访问的Server的名称,这里的Server Name实际上是KDCTicket Granting ServiceServer Name

170800g3arq78z38348p7z.png

ASAuthentication Service)通过它接收到的KRB_AS_REQ验证发送方的是否是在Client name & realm中声称的那个人,也就是说要验证发送放是否知道ClientPassword。所以AS只需从Account Database中提取Client对应的Master KeyPre-authentication data进行解密,如果是一个合法的Timestamp,则可以证明发送放提供的是正确无误的密码。验证通过之后,AS将一份Authentication Service ResponseKRB_AS_RES)发送给ClientKRB_AS_RES主要包含两个部分:本ClientMaster Key加密过的Session Key和被自己(KDC)加密的TGT。而TGT大体又包含以下的内容:

²  Session Key: SKDC-ClientLogon Session Key

²  Client name & realm: 简单地说就是Domain name\Client

²  End time: TGT到期的时间。

170801c6hxyyga3sx6lf8h.png

 

n  TGSTicket Granting ServiceExchange

TGSTicket Granting ServiceExchange通过ClientKDC中的TGSTicket Granting Service)发送Ticket Granting Service RequestKRB_TGS_REQ)开始。KRB_TGS_REQ大体包含以下的内容:

²  TGTClient通过AS Exchange获得的Ticket Granting TicketTGTKDCMaster Key进行加密。

²  Authenticator:用以证明当初TGT的拥有者是否就是自己,所以它必须以TGTMaster key和自己的Session KeySKDC-ClientLogon Session Key)来进行加密。

²  Client name & realm: 简单地说就是Domain name\Client

Server name & realm: 简单地说就是Domain name\Server,这回是Client试图访问的那个Server

170802cmgmrm3meb6q1q1g.png

170803xapkan8tt58tk5a7.png

Kerberos原理参考:https://blog.csdn.net/wulantian/article/details/42418231

l  Kerberos验证完成之后SMB2继续Session Setup Request,客户端和服务器建立一个session,在客户端发送的Session Setup Request里,包含了身份验证请求(如KerberosAP_REQ

170805oyhnfmtmh4m5nnej.png

服务器回复Session Setup Response,包含了验证结果(KerberosAP_REP)

170806rvxvtov337wvowe9.png

Session Setup通过后,客户端就成功的连上了服务器。客户端发送的Tree Connect Request来访问具体的共享,如果前面没有指定共享名(\服务器名),客户端访问的是命名管道$IPC

170807btnuxnkntlkattm0.png

服务器在检查过用户对该路径的权限后,回复Tree Connect Response。检查用户权限是这样进行的:服务器从Session Setup Request中已经得到用户所属的组,再通过和该路径上的ACL对比,即可得到用户权限

170808xwewzwkwyfk7xffw.png

4.       客户端使用SMB2再次查询域控上的基础信息,此时用户已经经过认证,对域控有更多权限,可以查询到更多信息

170809cz1lu5tt3xlizxty.png

5.       客户端通过RPC协议(135/tcp)连接之前绑定的DC服务器,根据RPC的响应连接DC上的RPC动态端口,动态端口值可以在RPCMAP response中看到。如下图为49157,然后Client连接49157端口,通信过程中都包含kerberos认证(ticket)

170810crr7e2r52zqc05sm.png

最终客户端通过RPC协议完成正常的加域过程

170811ut8r5yw54r49djdn.jpg

五、            加域失败问题定位思路

要确保成功加域,要确保加域的客户端能给正常连接到域,加域客户端和域的DC直接满足加域需要的网络及端口矩阵,加域失败的情况下,可以按照以下步骤排查:

1.       检查客户端是否有正确的IP地址及DNS地址

Ø  使用ipconfig /all命令或其他方法检查客户端的网卡配置,检查虚拟机的IP地址和DNS是否配置正确

170812kmo566cv8q5vqfio.png

加域客户端网卡上配置的DNS地址建议只配置为客户端所要加入域的权威DNS,不要包含其他DNS地址,否则会导致域解析异常。如果IP地址和DNS配置错误,请先修正此配置。

Ø  在网卡上配置有正确的IP地址及正确的DNS的情况下,通过以下方法检查客户端解析域名是否正常,检查虚拟机和域控之间通信是否正常

使用nslookup命令测试域名解析,如果最终无法解析到域名,请排查以下方面:

²  IPDNS地址配置是否正常,特别是DNS地址配置

²  客户端能否和DNS正常通信,特别是DNS 53/tcp53/udp

²  DNS服务器是否正常,特别是DNS上的SRV记录是否丢失。参考案例:https://forum.huawei.com/enterprise/zh/forum.php?mod=viewthread&tid=312435

²  请参考微软support上的案例处理其他情况

170813revkohoo6komdm00.png

客户端和DC之间未禁止ping的情况下,输出结果如下;如果禁止ping,无法ping通属正常现象。

170814hk4y65x9a2ca1z11.png

如果未开启telnet客户端,按照以下方法开启telnet客户端:

170815rah9h952462zt2ta.png

通过域名或者IP测试和DNS53/tcp端口是否能通,如果端口不通请排查端口不通的原因:

²  DNS服务异常,未监听53端口

²  DNS服务器防火墙或网络中间安全设备禁用了53端口

170816qmampga78pjg74mv.png

2.       之后在加域过程中失败,可以手动加域并抓包,参照第四步的过程分析。

 

点赞(0) 打赏

评论列表 共有 0 条评论

暂无评论
立即
投稿

微信公众账号

微信扫一扫加关注

发表
评论
返回
顶部