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

Question

提问by Chris S

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.

更新：
如果你刚遇到这个问题，一般的要点是我试图通过代理创建一个 HttpWebRequest，我从我们奇怪的代理服务器得到了一个 407。IE、Firefox、Chrome 都设法成功协商代理，Adobe Air 应用程序也是如此。谷歌浏览器网络安装程序实际上失败可能很重要，我们必须使用离线安装程序。

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.

多亏了 Ian 的链接，我才能进入下一阶段。它现在将令牌发送回代理，但是第三阶段没有通过，因此 .NET 没有发送带有用户名/密码哈希的请求，因此没有返回 HTML。

I am using:

我在用：

IE6 user-agent
Windows 7
Scansafe proxy
.NET 3.5

IE6 用户代理
Windows 7的
扫描安全代理
.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.

WebException (407) 需要身份验证。

The proxy being used

正在使用的代理

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

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

System.Net tracing output

System.Net 跟踪输出

Here's the trace output

这是跟踪输出

IE sucessfully negotiating the proxy

IE 成功协商代理

Fidder output

提琴输出

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.

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

Answer 1

采纳答案by EricLaw

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

如果要为代理设置凭据，是否应该在 request.Proxy 对象而不是请求对象上设置凭据？

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.

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

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

（Fiddler 的“Auth”检查器将为您分解 NTLM 身份验证 blob，如果您还没有看过它。）

Answer 2

回答by Ian Kemp

I was having a similar issue and used the tips in the following blog post to solve the problem:

我遇到了类似的问题，并使用以下博客文章中的提示来解决问题：

http://blogs.msdn.com/jpsanders/archive/2009/03/24/httpwebrequest-webexcepton-the-remote-server-returned-an-error-407-proxy-authentication-required.aspx

Answer 3

回答by feroze

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

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

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

有时，如果用户代理不是他们所期望的，服务器将不会正确挑战。

hope this helps.

希望这可以帮助。

Answer 4

回答by CRice

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:

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

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

在 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>

Answer 5

回答by Shiraz Bhaiji

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

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

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

Answer 6

回答by lod3n

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();

Answer 7

回答by feroze

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

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

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

当我查看 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

Here is the dump from IE:

这是来自 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.

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

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

以下链接讨论了另一个人遇到的类似问题。 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)

IE 工作而不是托管应用程序的原因是 IE 并没有实际请求 NTLMSSP_NEGOTIATE_SEAL | NTLMSSP_NEGOTIATE_SIGN，最终需要加密。但是，HttpWebRequest 确实请求 SEAL|SIGN。这需要 128 位加密，而 IE 初始化 NTLMSSP 的方式（没有 SEAL & SIGN），它不需要加密。因此 IE 有效，而 HttpWebRequest 则无效。（见上面的链接）

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.

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

Hope this helps.

希望这可以帮助。

Answer 8

回答by SomeRandomGuy

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

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

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

Set to:

设置：

require 128 only for client.

enter image description here

在此处输入图片说明

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

提问by Chris S

The proxy being used

正在使用的代理

System.Net tracing output

System.Net 跟踪输出

IE sucessfully negotiating the proxy

IE 成功协商代理

The solution

解决方案

采纳答案by EricLaw

回答by Ian Kemp

回答by feroze

回答by CRice

回答by Shiraz Bhaiji

回答by lod3n

回答by feroze

回答by SomeRandomGuy

相关推荐

最近更新

标签

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

提问by Chris S

The proxy being used

正在使用的代理

System.Net tracing output

System.Net 跟踪输出

IE sucessfully negotiating the proxy

IE 成功协商代理

The solution

解决方案

采纳答案by EricLaw

回答by Ian Kemp

回答by feroze

回答by CRice

回答by Shiraz Bhaiji

回答by lod3n

回答by feroze

回答by SomeRandomGuy

相关推荐

C# 如何锁定文件

C# 如何读取包含特殊字符的 ANSI 编码文件

C# 复制网络共享驱动器上的文件

在 C# 中以编程方式添加元标记

相关推荐

最近更新

标签