nginx代理NTLM认证过程分析

  • nginx代理NTLM认证过程分析已关闭评论
  • 115,260 views
  • A+
所属分类:nginx 系统运维

前一段时间,在通过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 …

nginx代理NTLM认证过程分析

客户端发请求访问

 

2: C <– S 401 Unauthorized

WWW-Authenticate: NTLM

nginx代理NTLM认证过程分析

服务器拒绝,返回401.2,提示不可匿名访问,需要认证,并声明是NTLM认证

 

3: C –> S POST …

Authorization: NTLM

nginx代理NTLM认证过程分析

客户端将自己的NTLM代码发给服务器,其中代码中包含加密的用户名和密码

 

4: C <– S 401 Unauthorized

WWW-Authenticate: NTLM

nginx代理NTLM认证过程分析

服务器返回401.1,发起Chanllenge,使用保存在服务器端的用户名密码生成加密的代码发给客户端,请求客户端解析

 

5: C –> S GET …

Authorization: NTLM

nginx代理NTLM认证过程分析

客户端使用服务器发起的Chanllenge代码与自己的认证信息进行回应(如果回应正确则认证通过)

 

6: C <– S Ok

nginx代理NTLM认证过程分析

认证通过,服务器返回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 …

nginx代理NTLM认证过程分析

客户端发请求访问

2: C <– S 401 Unauthorized

WWW-Authenticate: NTLM

nginx代理NTLM认证过程分析

服务器拒绝,返回401.2,提示不可匿名访问,需要认证,并声明是NTLM认证

3: C –> S GET …

Authorization: NTLM

nginx代理NTLM认证过程分析

客户端将自己的NTLM代码发给服务器,其中代码中包含加密的用户名和密码

4: C <– S 401 Unauthorized

WWW-Authenticate: NTLM

nginx代理NTLM认证过程分析

服务器返回401.1,发起Chanllenge,使用保存在服务器端的用户名密码生成加密的代码发给客户端,请求客户端解析

5: C –> S GET …

Authorization: NTLM

nginx代理NTLM认证过程分析

客户端使用服务器发起的Chanllenge代码与自己的认证信息进行回应(如果回应正确则认证通过)

6: C <– S

nginx代理NTLM认证过程分析

认证失败!

 

整个流程,直通和代理都没有区别。

唯一的几点区别以及NTLM的特性:

1、 网上的资料说,NTLM认证的关键在于“Connection: Keep-Alive”。每次会话生成的认证信息都是不同的。

即:第三步,客户端生成的均为“NTLM TlRMTVNTUAABAAAAB4IIogAAAAAAAAAAAAAAAAAAAAAFASgKAAAADw==”,每次都相同

服务器则是:

“TlRMTVNTUAACAAAAEAAQADgAAAAFgomi2NVi54k850UAAAAAAAAAAIoAigBIAAAABQLODgAAAA9DAE4ATwBPAEMARwBBAFMAAgAQAEMATgBPAE8AQwBHAEEAUwABAAwATQBPAFMAUwAtADEABAAYAGMAbgBvAG8AYwBnAGEAcwAuAGMAbwBtAAMAJgBNAE8AUwBTAC0AMQAuAGMAbgBvAG8AYwBnAGEAcwAuAGMAbwBtAAUAGABjAG4AbwBvAGMAZwBhAHMALgBjAG8AbQAAAAAA”

“TlRMTVNTUAACAAAAEAAQADgAAAAFgomiEMrdcmTWLkwAAAAAAAAAAIoAigBIAAAABQLODgAAAA9DAE4ATwBPAEMARwBBAFMAAgAQAEMATgBPAE8AQwBHAEEAUwABAAwATQBPAFMAUwAtADEABAAYAGMAbgBvAG8AYwBnAGEAcwAuAGMAbwBtAAMAJgBNAE8AUwBTAC0AMQAuAGMAbgBvAG8AYwBnAGEAcwAuAGMAbwBtAAUAGABjAG4AbwBvAGMAZwBhAHMALgBjAG8AbQAAAAAA”

“TlRMTVNTUAACAAAAEAAQADgAAAAFgomieRl6vsRLLukAAAAAAAAAAIoAigBIAAAABQLODgAAAA9DAE4ATwBPAEMARwBBAFMAAgAQAEMATgBPAE8AQwBHAEEAUwABAAwATQBPAFMAUwAtADEABAAYAGMAbgBvAG8AYwBnAGEAcwAuAGMAbwBtAAMAJgBNAE8AUwBTAC0AMQAuAGMAbgBvAG8AYwBnAGEAcwAuAGMAbwBtAAUAGABjAG4AbwBvAGMAZwBhAHMALgBjAG8AbQAAAAAA”

每次都不同,也就是说不同的会话有不同的认证信息。(微软的认证系统靠抓包回放是攻不破了)

2、 不经过代理的时候,整个认证过程只有一条连接:

nginx代理NTLM认证过程分析

这条连接一直持续到整个认证过程结束都没有断。

而经过代理时,整个过程被分成了很多条连接:

nginx代理NTLM认证过程分析

每一条连接都仅完成一次POST,即12、34、56。整个流程从正常的一段,被分解成了3段。

虽然我们的请求里都包含“keep-alive”(不过是小写的!),但是每条连接之后都被reset了

nginx代理NTLM认证过程分析

 

分析:

首先由于NTLM的认证需要Keep-Alive,所以如果在第4步被reset了,就会导致第四步由服务器生成的WWW-Authenticate失效,这样第五步发出的Authorization就是过期的,进而导致认证失败。

那么,代理的会话被reset就是罪魁祸首,如果代理能和pc直通一样,与服务器保持Keep-Alive,问题就能解决。

 

检查了代理引擎关于NTLM的代码,发现这个代理引擎在访问需要NTLM认证服务器的时候,会自己把链接断开,也就是说上面的分析是正确的。

改写了代码让代理引擎保证Keep-Alive,问题修复。

  • 安卓客户端下载
  • 微信扫一扫
  • weinxin
  • 微信公众号
  • 微信公众号扫一扫
  • weinxin
avatar