如何从WWW-Authenticate:Negotiate标头中查找是否使用NTLM或Kerberos

IT *_*DAV 21 .net ntlm kerberos www-authenticate negotiate

我正在编写.Net中的客户端应用程序,它通过HTTP与服务器通信.

在NTLM和Kerberos授权的情况下,我需要设置不同的请求缓冲选项.

如何确定是否使用NTLM或Kerberos?有可能以某种方式解码'WWW-Authenticate:Negotiate'标题?

Tar*_*ski 35

你会在这里找到答案.

简短的回答是:

1.Capture some successfully authorized request using Fiddler tool.
2.Choose "Inspectors" -> "Headers" tab.
3.Pay attention at "Cookies / Login" section, "Authorization" header.
Run Code Online (Sandbox Code Playgroud)

如果授权令牌以"YII"开头,则使用Kerberos,但如果它以"TlR"开头,则不使用Kerberos.

例如Kerberos:

Authorization: Negotiate YIIVDAYGKwYBE...
Run Code Online (Sandbox Code Playgroud)

不是Kerberos:

Authorization: Negotiate TlRMTVNTUA...
Run Code Online (Sandbox Code Playgroud)

  • 如果以"oY"开头怎么办?http://stackoverflow.com/q/24454777/498298 (3认同)
  • 同样在Inspectors/Auth选项卡上,它会说'授权标题(Negotiate)似乎包含Kerberos票' (2认同)
  • 如果以“oS”开头怎么办? (2认同)
  • Fiddler 将自己设置为代理,并且在某些情况下可能导致 kerberos 失败,这将导致大多数协商情况下的 NTLM 回退。微软过去曾在支持票中告诉我这一点,当时我认为我已经证明 kerberos 不适用于特定应用程序。最好使用侵入性较小的日志记录方法来检查授权标头,例如“netsh trace”:http://blogs.msdn.com/b/canberrapfe/archive/2012/03/31/capture-a-network-跟踪而无需安装任何东西都可以关闭并重新启动too.aspx (2认同)

Edw*_*son 5

解析Negotiate标题是一种繁琐的练习,因为它是使用ASN.1 DER构建的.

也就是说,您可能不一定需要对此进行解码,以便对有效负载做出良好的假设.虽然GSSAPI中有一个用于NTLM的机制(以下更多内容),根据我的经验,客户端实际上并没有使用它,它们只是发送NTLM头.在我(公认严格控制)的环境中,如果我看到,Authorization: NTLM ...那么这肯定是NTLM.如果我看到Authorization: Negotiate ...那么这肯定是Kerberos.

严格来说,您应该查看标头中的机制列表,以确定该机制是NTLM还是Kerberos.我建议使用现成的ASN.1解码器,或者查看微软的解码示例.您将要查找SPNEGO OID(1.3.6.1.5.5.2),然后查找其中的机制类型序列.序列中的第一个机制对应于响应令牌有效负载,因此您可以查看该OID以确定机制.一些已知的Kerberos OID是:

1.2.840.113554.1.2.2 (Kerberos 5)
1.2.840.48018.1.2.2 (Microsoft Kerberos 5)
1.3.5.1.5.2 (Kerberos 5 OID 2)
Run Code Online (Sandbox Code Playgroud)

据我所知,NTLM唯一的OID是(从这个博客引用):

1.3.6.1.4.1.311.2.2.10 (NLMP NTLM)
Run Code Online (Sandbox Code Playgroud)

  • 在Negotiate中使用NTLM是绝对合法和可能的,根据我的经验,它很常见.如果您只是对标头进行base64解码,则应该明白哪个SSP正在使用中.比如看看Fiddler的AUTH标签. (3认同)