AD域登录过程详解


您现在的位置: 首页 > 嘉为原创 > 系统技术 > 详情

AD域登录过程详解

赵海兵 IT咨询顾问
 
网络及系统技术工程师、IT系统服务工程师、微软系统技术工程师、企业服务咨询顾问。

  1. 客户端查找DC过程
    1. 用户在加入域的客户端计算机上登录的时候,计算机会向本机的netLogon 服务发送RPC请求,请求包括域名,站点,计算机名称等信息。
    2. 本地客户端上的netlogon服务使用domainlocator服务调用DsGetDcName接口,向其传递以下列表中的参数。
 
列表中列出的是DsGetDcName API的部分参数,对应着DNS服务器相应区域中的PDC、GC、KDC、LDAP server记录。Netlogon会调用DsGetDcName API收集所有可能会需要的信息,比如收集PDC信息是因为当找本地DC做身份验证失败时,就会需要找PDC做身份验证。收集GC信息是因为GC上存储着林中所有对象的一部分属性,比如用户邮箱地址。
 
登录过程是需要查找Kerberos记录来找到提供Kerberos验证服务的DC进行验证。域用户登录过程中,Kerberos验证程序向KDC发送用户信息和验证服务请求后,就需要通过kerberos记录来找到Kerberos Key Distribution Center服务进行验证。
 
除了在查找PDC的情况下,DsGetDcName都会使用site参数。如果使用site参数的时候,请求得不到DNS服务器的回应,那么DsGetDcName会使用不带site参数再次请求。举个例子,在使用DS_KDC_REQUIRED 参数并且添加了site参数的时候,如果请求得不到Dns服务器的响应,那么DsGetDcName会请求下面的DNS记录:_kdc._tcp.dc._msdcs.forestrootdomain。site通过子网进行划分,客户端通过所在的子网找到本子网的站点。

  1. 客户端上的netlogon服务收集信息并查找DNS中的SRV记录,包括上面表中提到的各个SRV记录。
  2. DNS服务器返回客户端所请求的记录列表给客户端,并且按照优先级别和权重进行排序。然后客户端使用LDAP协议连接上返回的第一个服务器的UDP389端口,请求建立一个LADP连接。当请求包发送完后,客户端等待0.1秒后如果没有收到回应,那么发送请求到下一个Domain server地址,直到接到回应或者尝试完所有地址。
  3. 当DC向客户端发送回应后,客户端检查Dc是否有其需要的相关信息。如果有,客户端开始登陆。哪个DC先响应请求,客户端就找其做身份验证。
  4. 客户端检查DC上是否有其需要的相关信息,即检查该DC是否包含该用户的身份验证信息能否为其做身份验证。例如由于复制延迟,某用户没有被复制到该DC上,该DC无法为其做身份验证,客户端就会继续找下一个DC做身份验证。
  5. 客户端缓存DC的相关信息,以便在下次登录的时候直接使用。
  1. AD域用户身份验证过程
  1. 当客户端通过上述步骤最终找到可以帮助域用户做身份验证的DC后,接下来就会进入与DC间进行验证身份的过程。
  2. 当用户按下Ctrl+Alt+Del,即SAS。Winlogon检测到这个动作,就调用GINA,显示帐号验证窗口,以便输入用户名和密码。GINA的全称为“Graphical Identification and Authentication”——图形化识别和验证。它是几个动态数据库文件,被winlogon.exe所调用,为其提供能够对用户身份进行识别和验证的函数,并将用户的帐号和密码反馈给winlogon.exe。在登录过程中,“欢迎屏幕”和“登录对话框”就是GINA显示的。
  3. 用户输入域名、账号和密码,确定后,GINA把信息发送给LSA进行验证。LSA的全称为“Local Security Authority”——本地安全授权,Windows系统中一个相当重要的服务,所有安全认证相关的处理都要通过这个服务。
  4. LSA将请求发送给Kerberos验证程序包。通过散列算法,根据用户信息生成一个密钥,并将密钥存储在证书缓存区域中。
  5. Kerberos验证程序向KDC(Key Distribution Center)发送一个包含用户身份信息和验证预处理数据的验证服务请求(KRB_AS_REQ),其中包含用户证书和散列算法加密的标记。
 
KDC(Kerberos Key Distribution Center——Kerberos密钥发布中心)服务主要同Kerberos认证协议协同使用,用于在整个活动目录范围内对用户的登录进行验证。如果你确保整个域中没有Windows NT计算机,可以只使用Kerberos协议,以确保最大的安全性。该服务要在Active Directory服务启动后才能启用。

  1. KDC接收到数据后,利用自己的密钥对请求中的标记进行解密,通过解密的标记是否正确,就可以判断用户是否有效。
  2. 如果用户有效,KDC将向用户发送一个TGT(Ticket Granting Ticket)响应用户请求(KRB_AS_REP)。该TGT将用户的密钥进行解密,其中包含会话密钥,该会话密钥指向的用户名称,该票据的最大生命期及其他一些可能需要的数据和设置等。在TGT的授权数据部分包含户帐号的SID以及该用户所属的全局组和通用组的SID。
  3. LSA向域控制器上的KDC的票据验证服务请求服务票据(KRB_TGS_REQ),其中包含要登陆的机器名,域名,用户的TGT及会话密钥。
  4. KDC返回会话密钥和会话票据给LAS(KRB_TGS_REP)。
  5. LSA收到票据信息后,对其进行解密,然后查询本地SAM数据库(local Security Account Manager database),看该用户是否隶属于本地某个安全组及其它用户权限,并将其组SID加到从票据数据中得到的列表。
  6. 系统通过这个列表生成访问令牌(access token),并为改用户创建桌面对象,系统一些列子进程也将继承这个安全访问令牌。用户的身份验证信息也将会缓存到本地。
  1. 总结
以上是AD域用户在登录域的时候,客户端如何找到域控制器,以及找到之后,与KDC之间进行身份验证的过程。然后事实上,第二部分介绍的使用kerberos协议进行验证身份的过程只是一个大概的过程,具体的要比这复杂的多,可以参考此链接的内容:http://blog.csdn.net/chlaws/article/details/8480304。

你可能感兴趣的:(AD域登录过程详解)