NTLM验证过程

2011-05-11 13:31 305人阅读 评论(0) 收藏 举报

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呢？下面通过一系列的测试来找出答案。

 

分服务器和客户端在域不在域两种情况测试。

上一篇>>   IIS的各种身份验证详细测试(一)     下一篇>>   IS的各种身份验证详细测试(三)