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的各种身份验证详细测试(三)
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呢？下面通过一系列的测试来找出答案。
分服务器和客户端在域不在域两种情况测试。
