使用 ISA Server 2006 SP1 访问未编译页面时出错

发布于 2024-07-14 13:32:00 字数 655 浏览 5 评论 0原文

我们正在配置门户以使用 ISA Server 作为我们的前端安全提供程序。
因此我们使用 ISA Server 2006 SP1。

不幸的是,当我们通过 ISA Server 访问 .net 应用程序时,它们是第一次访问。
即尚未编译,出现以下错误:
错误代码:500 内部服务器错误。 参数不正确。 (87)

在 ISA 监控日志中,显示:

连接尝试失败
日志类型:Web 代理(反向)
状态:87 参数不正确。

一旦编译应用程序,错误就不会出现。
有谁知道如何解决这个问题,以便网站第一次可以正常工作?

一些附加信息:

  • 访问的网站在 Windows Server 2008 64 位 - 标准版上运行,并且出现在 Sharepoint 以及标准 .net 网站上。
  • ISA Server 运行在Windows Server 2003 R2 SP2 Standard eidtion
  • Windows Server 2008 盒子上的防火墙允许所有访问。 (排除这种情况。)
  • IIS 日志或防火墙日志中没有出现任何奇怪的情况。

We are in the processing of configuring a portal to use ISA Server as our front end security provider.
So we are using ISA Server 2006 SP1.

Unfortunately when we access .net applications through ISA Server, the first time they are accessed.
i.e. They are not compiled yet, the following error appears:
Error Code: 500 Internal Server Error. The parameter is incorrect. (87)

In the ISA Monitoring logs, this shows:

Failed Connection Attempt
Log type: Web Proxy (Reverse)
Status: 87 The parameter is incorrect.

Once the application is compiled, the error never appears.
Does anyone know how to resolve this, so the site works correctly the first time?

Some additional information:

  • The websites accessed are running on windows server 2008 64 bit - standard edition, and occurs for Sharepoint as well as standard .net websites.
  • ISA Server is running on Windows server 2003 R2 SP2 Standard eidtion
  • The firewall on the windows server 2008 box allows all access. (To rule this out.)
  • Nothing odd appears in the IIS logs or firewall logs.

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

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

发布评论

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

评论(3

薄荷→糖丶微凉 2024-07-21 13:32:00

您可以预编译该网站。 这更像是一种解决方法。

您是否尝试过清除 ASP.NET 的编译输出目录? 你们可能会在那里发生一些冲突。

%SystemRoot%\Microsoft.NET\Framework\versionNumber\Temporary ASP.NET Files

You could pre-complie the web site. That's more of a work around.

Have you tried clearing out compilation output directory for ASP.NET? You might have some conflict there.

%SystemRoot%\Microsoft.NET\Framework\versionNumber\Temporary ASP.NET Files
站稳脚跟 2024-07-21 13:32:00

此问题是由于 ISA 服务器中的身份验证委派值设置为 NTLM 而 IIS 设置为接受 Windows 身份验证而导致的。
这种组合在我的环境中似乎是一个问题。

将其更改为基本身份验证或任何其他有效组合都可以正常工作,因此我将使用不同的身份验证委托设置。

This problem was caused by the Authentication Delegation value in ISA Server being set to NTLM while IIS was setup to accept Windows Authentication.
This combination appears to be a problem in my environment.

Changing it to basic authentication, or any other valid combination works correctly, thus I'm going with a different authentication delegation setting.

北城孤痞 2024-07-21 13:32:00

我今天遇到了同样的问题(ISA 2006/sp1 通过 ISA HTML 表单身份验证发布 SharePoint,通过 NTLM 身份验证)并花了几个小时对其进行调试。 你是对的,需要编译触发它的页面,只有 IISRESET 才会导致问题; 应用程序池回收则不然。 基本身份验证有效,但 NTLM 无效。 请继续阅读以了解修复方法。

如果您查看 IIS 日志,您会发现有一些奇怪的东西,即 IIS 针对特定 HTTP 请求的 401 回复,并带有一些提示:

... GET /auth.aspx - 80 - ... Mozilla/4.0+(compatible;...) 401 1 2148074254 734

请注意错误代码 2148074254 ( 0x8009030e SEC_E_NO_CREDENTIALS )。 在常规的质询/响应交换中,该值应为“5”。

这让我走上了一些更加曲折的调试路径,最终我发现问题出在 IIS 7 的内核模式身份验证默认启用的情况下。 如果您将其关闭:

%windir%\system32\inetsrv\appcmd set config -section:windowsAuthentication -useKernelMode:false

...问题就会消失。 这篇文章中有足够的信息供任何人挖掘其技术原因,所以我不会在这里重复它。

-奥辛

I had the same problem today (ISA 2006/sp1 publishing SharePoint via ISA HTML Form Auth, passing through NTLM auth) and spent several hours debugging it. You are right, it's the neccessity to compile the page that triggers it and only an IISRESET causes the problem; App pool recycling does not. Basic authentication works, but NTLM does not. Read on for the fix.

If you look in your IIS log, you'll see that there is something odd there, namely a 401 reply from IIS for the particular HTTP request with a little hint:

... GET /auth.aspx - 80 - ... Mozilla/4.0+(compatible;...) 401 1 2148074254 734

Note the error code 2148074254 ( 0x8009030e SEC_E_NO_CREDENTIALS ). In a regular challenge/response exchange this should be "5."

This led me down some more winding debugging paths and eventually I discovered the problem is down to IIS 7's kernel-mode authentication being enabled by default. If you turn it off:

%windir%\system32\inetsrv\appcmd set config -section:windowsAuthentication -useKernelMode:false

...the problem goes away. There's enough information in this post for anyone to dig up the technical reasons for this, so I'll not bother regurgitating it here.

-Oisin

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