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通过子网进行划分，客户端通过所在的子网找到本子网的站点。

3. 客户端上的netlogon服务收集信息并查找DNS中的SRV记录，包括上面表中提到的各个SRV记录。
4. DNS服务器返回客户端所请求的记录列表给客户端，并且按照优先级别和权重进行排序。然后客户端使用LDAP协议连接上返回的第一个服务器的UDP389端口，请求建立一个LADP连接。当请求包发送完后，客户端等待0.1秒后如果没有收到回应，那么发送请求到下一个Domain server地址，直到接到回应或者尝试完所有地址。
5. 当DC向客户端发送回应后，客户端检查Dc是否有其需要的相关信息。如果有，客户端开始登陆。哪个DC先响应请求，客户端就找其做身份验证。
6. 客户端检查DC上是否有其需要的相关信息，即检查该DC是否包含该用户的身份验证信息能否为其做身份验证。例如由于复制延迟，某用户没有被复制到该DC上，该DC无法为其做身份验证，客户端就会继续找下一个DC做身份验证。
7. 客户端缓存DC的相关信息，以便在下次登录的时候直接使用。

2. 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服务启动后才能启用。

6. KDC接收到数据后，利用自己的密钥对请求中的标记进行解密，通过解密的标记是否正确，就可以判断用户是否有效。
7. 如果用户有效，KDC将向用户发送一个TGT(Ticket Granting Ticket)响应用户请求（KRB_AS_REP）。该TGT将用户的密钥进行解密，其中包含会话密钥，该会话密钥指向的用户名称，该票据的最大生命期及其他一些可能需要的数据和设置等。在TGT的授权数据部分包含户帐号的SID以及该用户所属的全局组和通用组的SID。
8. LSA向域控制器上的KDC的票据验证服务请求服务票据（KRB_TGS_REQ），其中包含要登陆的机器名，域名，用户的TGT及会话密钥。
9. KDC返回会话密钥和会话票据给LAS（KRB_TGS_REP）。
10. LSA收到票据信息后，对其进行解密，然后查询本地SAM数据库（local Security Account Manager database），看该用户是否隶属于本地某个安全组及其它用户权限，并将其组SID加到从票据数据中得到的列表。
11. 系统通过这个列表生成访问令牌（access token）,并为改用户创建桌面对象，系统一些列子进程也将继承这个安全访问令牌。用户的身份验证信息也将会缓存到本地。

3. 总结

以上是AD域用户在登录域的时候，客户端如何找到域控制器，以及找到之后，与KDC之间进行身份验证的过程。然后事实上，第二部分介绍的使用kerberos协议进行验证身份的过程只是一个大概的过程，具体的要比这复杂的多，可以参考此链接的内容：http://blog.csdn.net/chlaws/article/details/8480304。