服务器返回的“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呢？下面通过一系列的测试来找出答案。
分服务器和客户端在域不在域两种情况测试。
3、 客户端和服务器都不在域中
测试环境为服务器和客户端机器在同一个局域网中，但是都不在域中。客户端IE请求服务端IIS的一个页面default.aspx。
IIS服务端设置：
l 不启用匿名访问
l 只启用集成windows身份验证
这个环境下又分为下面几种情况：
3.1.
客户端用
ip
地址访问服务
3.1.1. 客户端IE申请页面
客户端IE浏览器的地址栏上输入要访问的URL，就会向服务端发送一个GET请求：
GET /wstest/default.aspx HTTP/1.1
Accept: */*
Accept-Language: zh-cn
UA-CPU: x86
Accept-Encoding: gzip, deflate
User-Agent: Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.2; SV1; .NET CLR 1.1.4322; .NET CLR 2.0.50727; InfoPath.1; MAXTHON 2.0)
Host: 192.168.1.13:81
Connection: Keep-Alive
3.1.2. 服务端返回无授权回应
服务端设置了禁用匿名访问，只允许windows验证，所以服务端返回了无授权回应：
HTTP/1.1 401 Unauthorized
返回的http头中还包括的:
