407 需要身份验证 - 未发送质询

发布于 2024-08-04 16:23:59 字数 1677 浏览 7 评论 0原文

更新:
如果您刚刚提出这个问题,一般要点是我正在尝试通过代理创建 HttpWebRequest,并且我从我们奇怪的代理服务器收到 407。 IE、Firefox、Chrome 都能够成功协商代理,Adobe Air 应用程序也是如此。重要的是,Google Chrome 网络安装程序实际上失败了,我们必须使用离线安装程序。

感谢 Ian 的链接,我已经进入下一阶段。现在它正在将令牌发送回代理,但是第三阶段没有通过,因此带有用户名/密码哈希的请求不会由.NET 发送,因此不会返回 HTML。

我正在使用:

  • IE6 用户代理
  • Windows 7
  • Scansafe 代理
  • .NET 3.5

这是相当于以下日志的最新代码:

HttpWebRequest request = HttpWebRequest.Create("http://www.yahoo.com") as HttpWebRequest;
IWebProxy proxy = request.Proxy;
// Print the Proxy Url to the console.
if (proxy != null)
{
    // Use the default credentials of the logged on user.
    proxy.Credentials = CredentialCache.DefaultCredentials;
}
request.UserAgent = "Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.2; .NET CLR 1.0.3705;)";
request.Accept = "*/*";

HttpWebResponse response = request.GetResponse() as HttpWebResponse;
Stream stream = response.GetResponseStream();

异常

WebException (407) 需要身份验证。

使用的代理

代理客户端是我们服务器机房中的 Scansafe 硬件设备,(一旦经过身份验证) NTLM)然后将您的 HTTP 流量定向到其服务器以过滤流量。

System.Net 跟踪输出

IE 成功协商代理

  • < a href="http://pastebin.com/m7ac60835" rel="noreferrer">Fidder 输出

解决方案

我还没有真正找到解决方案,但感谢 Feroze 和 Eric 我找到了一个解决方法并发现实际的代理(而不是其配置)是主要问题。这可能是一个涉及 3 个变量的模糊问题:.NET HttpWebRequest 的实现、Windows 7,当然还有我们机架中的 Scansafe 硬件客户端;但如果没有 MSDN 支持请求,我将无法找到答案。

Update:
If you've just arrived at this question, the general gist is that I'm trying to make a HttpWebRequest via a proxy, and I'm getting a 407 from our strange proxy server. IE,Firefox,Chrome all manage to negotiate the proxy sucessfully, as do Adobe Air applications. It may be important that the Google Chrome web installer actually fails and we have to use an offline installer.

Thanks to Ian's link I've got it getting through to the next stage. It is now sending a token back to the proxy, however the 3rd stage isn't getting through, so the request with the username/password hash isn't being sent by .NET and consequently no HTML is returned.

I am using:

  • IE6 user-agent
  • Windows 7
  • Scansafe proxy
  • .NET 3.5

Here's the latest code that equates to the logs below:

HttpWebRequest request = HttpWebRequest.Create("http://www.yahoo.com") as HttpWebRequest;
IWebProxy proxy = request.Proxy;
// Print the Proxy Url to the console.
if (proxy != null)
{
    // Use the default credentials of the logged on user.
    proxy.Credentials = CredentialCache.DefaultCredentials;
}
request.UserAgent = "Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.2; .NET CLR 1.0.3705;)";
request.Accept = "*/*";

HttpWebResponse response = request.GetResponse() as HttpWebResponse;
Stream stream = response.GetResponseStream();

The exception

WebException (407) Authentication Required.

The proxy being used

The proxy client is a Scansafe hardware device in our server room, which (once authenticated with NTLM) then directs your HTTP traffic to its servers to filter the traffic.

System.Net tracing output

IE sucessfully negotiating the proxy

The solution

I haven't really found a solution but thanks to Feroze and Eric I have found a workaround and discovered that the actual proxy (and not its configuration) is the main issue. It may be an obscure issue with 3 variables: .NET HttpWebRequest's implementation, Windows 7 and of course the Scansafe hardware client that sits in our rack; but without an MSDN support request I won't find out.

如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。

扫码二维码加入Web技术交流群

发布评论

需要 登录 才能够评论, 你可以免费 注册 一个本站的账号。

评论(8

灵芸 2024-08-11 16:23:59

如果您想为代理设置凭据,是否不应该在 request.Proxy 对象而不是 request 对象上设置凭据?

http://msdn.microsoft.com/en-us /library/system.net.webproxy.credentials.aspx

另外,请记住,您需要发出 HTTP/1.1 请求(或者从技术上讲,任何带有 Keep-Alive 的请求)才能成功使用 NTLM/Negotiate 身份验证。

(如果您还没有看过的话,Fiddler 的“Auth”检查器将为您分解 NTLM 身份验证 blob。)

If you want to set credentials for the proxy, shouldn't you set credentials on the request.Proxy object rather than the request object?

http://msdn.microsoft.com/en-us/library/system.net.webproxy.credentials.aspx

Also, keep in mind that you need to be making a HTTP/1.1 request (or technically, any request with Keep-Alive) to successfully use NTLM/Negotiate authentication.

(Fiddler's "Auth" inspector will decompose the NTLM authentication blobs for you, if you haven't taken a look at that yet.)

凹づ凸ル 2024-08-11 16:23:59

我编写了一个实用程序来解码在 IE 和 HttpWebRequest 会话中发送的 NTLM blob。

当我查看 HttpWebRequest 和 IE 时,它们都向服务器请求 56 位和 128 位加密。这是使用 HttpWebRequest 的会话转储

==== Type1 ----
Signature: NTLMSSP
Type: 1
Flags: E20882B7
NTLMSSP_NEGOTIATE_56
NTLMSSP_NEGOTIATE_KEY_EXCH
NTLMSSP_NEGOTIATE_128
RESERVED2
RESERVED3
RESERVED4
NTLMSSP_REQUEST_NON_NT_SESSION_KEY
NTLMSSP_TARGET_TYPE_DOMAIN
NTLMSSP_NEGOTIATE_OEM_DOMAIN_SUPPLIED
NTLMSSP_NEGOTIATE_DATAGRAM
NTLMSSP_REQUEST_TARGET
NTLM_NEGOTIATE_OEM
NTLMSSP_NEGOTIATE_UNICODE)
Domain :
Workstation:
==== Type2 ----
Signature: NTLMSSP
Type: 2
Flags: 201
NTLMSSP_NEGOTIATE_56
NTLMSSP_REQUEST_NON_NT_SESSION_KEY)
Context: D32FDDCB:63507CFA

这是来自 IE 的转储:

==== Type1 ----
Signature: NTLMSSP
Type: 1
Flags: A208B207
NTLMSSP_NEGOTIATE_56
NTLMSSP_NEGOTIATE_KEY_EXCH
NTLMSSP_NEGOTIATE_128
NTLMSSP_REQUEST_NON_NT_SESSION_KEY
NTLMSSP_NEGOTIATE_EXTENDED_SESSIONSECURITY
NTLMSSP_TARGET_TYPE_SHARE
NTLMSSP_TARGET_TYPE_DOMAIN
NTLMSSP_NEGOTIATE_OEM_DOMAIN_SUPPLIED
NTLMSSP_NEGOTIATE_DATAGRAM
NTLMSSP_REQUEST_TARGET
NTLMSSP_NEGOTIATE_UNICODE)
Domain : XXXX.UK
Workstation: XXX-X31
==== Type2 ----
Signature: NTLMSSP
Type: 2
Flags: 201
NTLMSSP_NEGOTIATE_56
NTLMSSP_REQUEST_NON_NT_SESSION_KEY)
Context: D32FDDCB:63507CFA

在 IE/HttpWebRequest 中,它们都请求 64 和 64 位。 128位安全。但是,对于 windows7,NTLM 的 128 位安全性已默认设置,否则身份验证将失败。从服务器响应中可以看出,服务器仅支持 64 位加密。

以下链接有关于另一个人遇到的类似问题的讨论。
http://social.msdn .microsoft.com/Forums/en-US/ncl/thread/f68e8878-53e9-4208-b589-9dbedf851198

IE 工作而不是托管应用程序的原因是 IE 实际上并不请求 NTLMSSP_NEGOTIATE_SEAL | NTLMSSP_NEGOTIATE_SIGN,最终需要加密。但是,HttpWebRequest 确实请求 SEAL|SIGN。这需要128位加密,而IE初始化NTLMSSP的方式(没有SEAL & SIGN),不需要加密。因此 IE 可以工作,而 HttpWebRequest 则不能。 (请参阅上面的链接)

我认为,如果您更改安全策略以允许 NTLM 的 64 位加密,您的托管代码应用程序将正常工作。或者,要求代理供应商支持 NTLM 的 128 位加密。

希望这有帮助。

I wrote a utility to decode the NTLM blobs that were sent in the IE and HttpWebRequest sessions.

When I look at the HttpWebRequest and IE, they both request 56bit and 128bit encryption from the server. Here is the dump of the session using HttpWebRequest

==== Type1 ----
Signature: NTLMSSP
Type: 1
Flags: E20882B7
NTLMSSP_NEGOTIATE_56
NTLMSSP_NEGOTIATE_KEY_EXCH
NTLMSSP_NEGOTIATE_128
RESERVED2
RESERVED3
RESERVED4
NTLMSSP_REQUEST_NON_NT_SESSION_KEY
NTLMSSP_TARGET_TYPE_DOMAIN
NTLMSSP_NEGOTIATE_OEM_DOMAIN_SUPPLIED
NTLMSSP_NEGOTIATE_DATAGRAM
NTLMSSP_REQUEST_TARGET
NTLM_NEGOTIATE_OEM
NTLMSSP_NEGOTIATE_UNICODE)
Domain :
Workstation:
==== Type2 ----
Signature: NTLMSSP
Type: 2
Flags: 201
NTLMSSP_NEGOTIATE_56
NTLMSSP_REQUEST_NON_NT_SESSION_KEY)
Context: D32FDDCB:63507CFA

Here is the dump from IE:

==== Type1 ----
Signature: NTLMSSP
Type: 1
Flags: A208B207
NTLMSSP_NEGOTIATE_56
NTLMSSP_NEGOTIATE_KEY_EXCH
NTLMSSP_NEGOTIATE_128
NTLMSSP_REQUEST_NON_NT_SESSION_KEY
NTLMSSP_NEGOTIATE_EXTENDED_SESSIONSECURITY
NTLMSSP_TARGET_TYPE_SHARE
NTLMSSP_TARGET_TYPE_DOMAIN
NTLMSSP_NEGOTIATE_OEM_DOMAIN_SUPPLIED
NTLMSSP_NEGOTIATE_DATAGRAM
NTLMSSP_REQUEST_TARGET
NTLMSSP_NEGOTIATE_UNICODE)
Domain : XXXX.UK
Workstation: XXX-X31
==== Type2 ----
Signature: NTLMSSP
Type: 2
Flags: 201
NTLMSSP_NEGOTIATE_56
NTLMSSP_REQUEST_NON_NT_SESSION_KEY)
Context: D32FDDCB:63507CFA

In both IE/HttpWebRequest, they are requesting both 64 & 128bit security. However, for windows7, 128bit security for NTLM has been made the default, and without that, authentication will fail. As you can see from the server response, the server is only supporting 64bit encryption.

The following link has a discussion on a similar problem encountered by another person.
http://social.msdn.microsoft.com/Forums/en-US/ncl/thread/f68e8878-53e9-4208-b589-9dbedf851198

The reason that IE works, instead of the managed app, is that IE does not actually request NTLMSSP_NEGOTIATE_SEAL | NTLMSSP_NEGOTIATE_SIGN, which end up requiring encryption. However, HttpWebRequest does request both SEAL|SIGN. This requires 128bit encryption, whereas the way IE initializes the NTLMSSP (without SEAL & SIGN), it does not require encryption. Hence IE works, whereas HttpWebRequest does not. (see the link above)

I think that if you change your security policy to allow 64bit encryption for NTLM, your managed code app will work. Or alternately, ask the proxy vendor to support 128bit encryption for NTLM.

Hope this helps.

挽你眉间 2024-08-11 16:23:59

验证 secpol.msc 中的以下设置。它解决了我们的问题。

Local Security Policy 
    Local Policies
        Security Options
            Network security: Minimum session security

设置为:

require 128 only for client. 

在此处输入图像描述

Verify the following setting in secpol.msc. It fixed our issue.

Local Security Policy 
    Local Policies
        Security Options
            Network security: Minimum session security

Set to:

require 128 only for client. 

enter image description here

还在原地等你 2024-08-11 16:23:59

您可以尝试将 HttpWebRequest 上的 User-Agent 标头设置为 IE8 设置的相同值吗?

有时,如果用户代理不是他们所期望的,服务器将无法正确质询。

希望这有帮助。

Can you try setting the User-Agent header on your HttpWebRequest, to the same value that IE8 is setting?

Sometimes, servers will not challenge correctly if the user-agent is not what they expect.

hope this helps.

土豪 2024-08-11 16:23:59

这是代理分配的方式吗?

proxy.Credentials = CredentialCache.DefaultCredentials;

当我上次使用 HttpWebRequest 的代理时,它是这样分配的:

将代理分配给请求:

request.Proxy.Credentials = Credentials.GetProxyCredentials();

调用方法:

    public static ICredentials GetProxyCredentials()
    {
        return new NetworkCredential(AppConstants.Proxy_username, AppConstants.Proxy_password);
    }

在 web.config 中配置代理

<system.net>
  <defaultProxy enabled="true">
    <proxy
      autoDetect="False"
      bypassonlocal="True"
      scriptLocation="http://www.proxy.pac"
      proxyaddress="http://proxy1.blah.com" />
  </defaultProxy>
</system.net>

Is it the way the proxy is assigned?

proxy.Credentials = CredentialCache.DefaultCredentials;

When I last used proxy with the HttpWebRequest it was assigned like this:

Assign proxy to request:

request.Proxy.Credentials = Credentials.GetProxyCredentials();

Calls method:

    public static ICredentials GetProxyCredentials()
    {
        return new NetworkCredential(AppConstants.Proxy_username, AppConstants.Proxy_password);
    }

Configure proxy in web.config

<system.net>
  <defaultProxy enabled="true">
    <proxy
      autoDetect="False"
      bypassonlocal="True"
      scriptLocation="http://www.proxy.pac"
      proxyaddress="http://proxy1.blah.com" />
  </defaultProxy>
</system.net>
缺⑴份安定 2024-08-11 16:23:59

它可能与您的“CredentialCache”中的内容有关。试试这个:

proxy.Credentials = new NetworkCredential("username", "pwd", "domain"); 

It could be related to what is in your "CredentialCache". Try this instead:

proxy.Credentials = new NetworkCredential("username", "pwd", "domain"); 
是伱的 2024-08-11 16:23:59

这个怎么样:

        HttpWebRequest request = HttpWebRequest.Create("http://www.yahoo.com") as HttpWebRequest;
        WebProxy proxyObject = new System.Net.WebProxy("http://10.0.0.1:8080/", true); //whatever your proxy address is

        proxyObject.Credentials = CredentialCache.DefaultCredentials;
        request.Proxy = proxyObject;

        request.UserAgent = "Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.2; .NET CLR 1.0.3705;)";
        request.Accept = "*/*";

        HttpWebResponse response = request.GetResponse() as HttpWebResponse;
        Stream stream = response.GetResponseStream();

How about this:

        HttpWebRequest request = HttpWebRequest.Create("http://www.yahoo.com") as HttpWebRequest;
        WebProxy proxyObject = new System.Net.WebProxy("http://10.0.0.1:8080/", true); //whatever your proxy address is

        proxyObject.Credentials = CredentialCache.DefaultCredentials;
        request.Proxy = proxyObject;

        request.UserAgent = "Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.2; .NET CLR 1.0.3705;)";
        request.Accept = "*/*";

        HttpWebResponse response = request.GetResponse() as HttpWebResponse;
        Stream stream = response.GetResponseStream();
~没有更多了~
我们使用 Cookies 和其他技术来定制您的体验包括您的登录状态等。通过阅读我们的 隐私政策 了解更多相关信息。 单击 接受 或继续使用网站,即表示您同意使用 Cookies 和您的相关数据。
原文