1、 NTLM验证过程
1.1. 客户端选择NTLM方式
如果IE选择了NTLM验证,IE就会在发送到IIS的请求中加入一个Authorization: Negotiate头,内容为:
Authorization: Negotiate NTLMSSPXXXXXXXXXXXXXXXXX
蓝色部分在实际中是经过base64编码的,其中“NTLMSSP”表示是NTLM验证的请求,后面的“XXXXXXXX”部分是二进制的数据,告诉服务器,客户端现在选择了NTLM验证,请服务器发送质询码给客户端。
1.2. 服务端返回质询码
服务器在返回无授权访问的http回应的头部加入Authorization: Negotiate头,内容为:
Authorization: Negotiate NTLMSSPXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
服务器返回的“XXXXXXXX”部分中含有一个八字节的质询码。
1.3. 客户端加密质询码再次发送请求
客户端使用客户端帐号的密码派生出来的8字节DESkey使用DES算法加密收到的质询码。连同客户端帐号的用户名发送到服务端,形式还是这样:
Authorization: Negotiate NTLMSSPXXXXXXXXXXXXXXXXX
这里的“XXXXXXX”部分包含了加密后的质询码和客户端用户名,用户名在其中以明码形式存在。
1.4. 服务端验证客户端用户和密码
服务端收到用户名后,先查验本机是否有这个用户,如果没有直接返回没有授权的http回应。
如果有这个用户,就用这个用户的密码派生出来的8字节DESkey使用DES算法加密发给客户端的那个8字节的质询码,然后跟收到客户端发送来的加密后的质询码比较,如果不相同,表示客户端输入密码不正确看,返回没有授权的http回应;如果相同,就表示客户端输入这个用户的密码正确,验证通过,返回客户端请求的资源。
2、 Kerberos验证过程
2.1. 客户端选择Kerberos验证
如果客户端选择了Kerberos验证,客户端直接在请求头中加入Authorization: Negotiate头,内容为:
Authorization: Negotiate XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
其中“XXXXXXXXXX”包含了客户端登录用户的身份验证票(登录时域中的票据服务器发放的标识此登录用户身份的票据,其中不包含用户的密码)。
2.2. 服务端验证身份验证票
服务器验证用户验证票,如果有效的票据,服务端能据此获得用户的用户名,并验证用户的有效性。验证通过后,服务端返回客户端请求的资源。
但是客户端IE何时选择NTLM 、合适选择Kerberos呢?下面通过一系列的测试来找出答案。
分服务器和客户端在域不在域两种情况测试。