- A+
前一段时间,在通过nginx代理tfs的时候,发现tfs登录不了,tfs用的是公司域账户,此过程也就是NTLM认证问题
正常情况下NTLM的认证过程:
1: C –> S GET/POST …
2: C <– S 401 Unauthorized
WWW-Authenticate: NTLM
3: C –> S GET/POST …
Authorization: NTLM
4: C <– S 401 Unauthorized
WWW-Authenticate: NTLM
5: C –> S GET/POST …
Authorization: NTLM
6: C <—S Ok
以下以一台PC直接登陆,且成功登陆为例:
1: C –> S POST …
客户端发请求访问
2: C <– S 401 Unauthorized
WWW-Authenticate: NTLM
服务器拒绝,返回401.2,提示不可匿名访问,需要认证,并声明是NTLM认证
3: C –> S POST …
Authorization: NTLM
客户端将自己的NTLM代码发给服务器,其中代码中包含加密的用户名和密码
4: C <– S 401 Unauthorized
WWW-Authenticate: NTLM
服务器返回401.1,发起Chanllenge,使用保存在服务器端的用户名密码生成加密的代码发给客户端,请求客户端解析
5: C –> S GET …
Authorization: NTLM
客户端使用服务器发起的Chanllenge代码与自己的认证信息进行回应(如果回应正确则认证通过)
6: C <– S Ok
认证通过,服务器返回302跳转,页面跳转至网站内部,整个认证过程结束。
按照服务器的提示,整个流程为:
1: C –> S POST …
2: C <– S 401.2 Unauthorized
WWW-Authenticate: NTLM
3: C –> S POST…
Authorization: NTLM
4: C <– S 401.1 Unauthorized
WWW-Authenticate: NTLM
5: C –> S POST…
Authorization: NTLM
6: C <—S 302
我在工作中遇到的问题是,过代理之后无法通过服务器的NTLM认证。
也就是说,我在PC上配置了一个代理,通过代理访问一个需要NTLM认证的网站。
首先,按照正常情况下NTLM的认证过程模板
1: C –> S GET …
2: C <– S 401 Unauthorized
WWW-Authenticate: NTLM
3: C –> S GET …
Authorization: NTLM
4: C <– S 401 Unauthorized
WWW-Authenticate: NTLM
5: C –> S GET …
Authorization: NTLM
6: C <– S Ok(出错就在这一步)
从抓包分析(以下仅分析从代理到服务器的数据包,未分析PC到代理的数据包):
1: C –> S GET …
客户端发请求访问
2: C <– S 401 Unauthorized
WWW-Authenticate: NTLM
服务器拒绝,返回401.2,提示不可匿名访问,需要认证,并声明是NTLM认证
3: C –> S GET …
Authorization: NTLM
客户端将自己的NTLM代码发给服务器,其中代码中包含加密的用户名和密码
4: C <– S 401 Unauthorized
WWW-Authenticate: NTLM
服务器返回401.1,发起Chanllenge,使用保存在服务器端的用户名密码生成加密的代码发给客户端,请求客户端解析
5: C –> S GET …
Authorization: NTLM
客户端使用服务器发起的Chanllenge代码与自己的认证信息进行回应(如果回应正确则认证通过)
6: C <– S
认证失败!
整个流程,直通和代理都没有区别。
唯一的几点区别以及NTLM的特性:
1、 网上的资料说,NTLM认证的关键在于“Connection: Keep-Alive”。每次会话生成的认证信息都是不同的。
即:第三步,客户端生成的均为“NTLM TlRMTVNTUAABAAAAB4IIogAAAAAAAAAAAAAAAAAAAAAFASgKAAAADw==”,每次都相同
服务器则是:
“TlRMTVNTUAACAAAAEAAQADgAAAAFgomi2NVi54k850UAAAAAAAAAAIoAigBIAAAABQLODgAAAA9DAE4ATwBPAEMARwBBAFMAAgAQAEMATgBPAE8AQwBHAEEAUwABAAwATQBPAFMAUwAtADEABAAYAGMAbgBvAG8AYwBnAGEAcwAuAGMAbwBtAAMAJgBNAE8AUwBTAC0AMQAuAGMAbgBvAG8AYwBnAGEAcwAuAGMAbwBtAAUAGABjAG4AbwBvAGMAZwBhAHMALgBjAG8AbQAAAAAA”
“TlRMTVNTUAACAAAAEAAQADgAAAAFgomiEMrdcmTWLkwAAAAAAAAAAIoAigBIAAAABQLODgAAAA9DAE4ATwBPAEMARwBBAFMAAgAQAEMATgBPAE8AQwBHAEEAUwABAAwATQBPAFMAUwAtADEABAAYAGMAbgBvAG8AYwBnAGEAcwAuAGMAbwBtAAMAJgBNAE8AUwBTAC0AMQAuAGMAbgBvAG8AYwBnAGEAcwAuAGMAbwBtAAUAGABjAG4AbwBvAGMAZwBhAHMALgBjAG8AbQAAAAAA”
“TlRMTVNTUAACAAAAEAAQADgAAAAFgomieRl6vsRLLukAAAAAAAAAAIoAigBIAAAABQLODgAAAA9DAE4ATwBPAEMARwBBAFMAAgAQAEMATgBPAE8AQwBHAEEAUwABAAwATQBPAFMAUwAtADEABAAYAGMAbgBvAG8AYwBnAGEAcwAuAGMAbwBtAAMAJgBNAE8AUwBTAC0AMQAuAGMAbgBvAG8AYwBnAGEAcwAuAGMAbwBtAAUAGABjAG4AbwBvAGMAZwBhAHMALgBjAG8AbQAAAAAA”
每次都不同,也就是说不同的会话有不同的认证信息。(微软的认证系统靠抓包回放是攻不破了)
2、 不经过代理的时候,整个认证过程只有一条连接:
这条连接一直持续到整个认证过程结束都没有断。
而经过代理时,整个过程被分成了很多条连接:
每一条连接都仅完成一次POST,即12、34、56。整个流程从正常的一段,被分解成了3段。
虽然我们的请求里都包含“keep-alive”(不过是小写的!),但是每条连接之后都被reset了
分析:
首先由于NTLM的认证需要Keep-Alive,所以如果在第4步被reset了,就会导致第四步由服务器生成的WWW-Authenticate失效,这样第五步发出的Authorization就是过期的,进而导致认证失败。
那么,代理的会话被reset就是罪魁祸首,如果代理能和pc直通一样,与服务器保持Keep-Alive,问题就能解决。
检查了代理引擎关于NTLM的代码,发现这个代理引擎在访问需要NTLM认证服务器的时候,会自己把链接断开,也就是说上面的分析是正确的。
改写了代码让代理引擎保证Keep-Alive,问题修复。
- 安卓客户端下载
- 微信扫一扫
- 微信公众号
- 微信公众号扫一扫