Classic asp“验证消息的安全性时出错。”iis7传输层安全性

Question

在II7上，我们托管了一个基于WCF/asp.net的应用程序接口。为了允许经典asp应用程序的用户连接到API，我们必须发布一个我们称为“传输”的版本。这个传输版本也是用asp.net编写的，它指向相同的程序集，只是安全层不同，允许经典的asp进行身份验证。传输层安全性与基于消息的安全性相反。

当使用浏览器加载服务引用时，我可以加载svcutil.exe ...WDSL页面。

当使用我的测试asp页面从这个引用中调用一个web方法时，我得到了以下返回：

已完成Web服务的调用。Status =内部服务器错误ResponseText =a:InvalidSecurity验证邮件安全性时出错。

这表明身份验证失败。当使用asp.net或应用程序WCF storm联系正常的API进行测试时，一切都运行得很好。

API是最近迁移的，似乎有一些设置不正确，但我不知道是什么原因。

我可以浏览到svcutil.exe ...WDSL服务引用，当通过浏览器选择它时，我得到expect XML响应。

当使用使用基于消息的安全性的API的非经典asp发布时，使用的用户名和密码工作。

是否可以发布一些故障排除提示，以帮助诊断问题，特别是关于传输层安全性、故障查找和设置？

谢谢你，斯科特

已编辑以添加以下更新：

尝试使用默认应用程序池和新的应用程序池，但同样的问题仍然存在。

我的测试页错误: ResponseText = a:InvalidSecurityAn错误发生在验证消息的安全性时。

IIS日志显示: v3/transport/testclassicasptransportwcfservice.asp ( 200 0 0) (即iis 200) /V3/Transport/DeviceService.svc/DeviceService (500 0 0)(即iis错误500)

注意:在TRANSPORT和V3上定义虚拟目录。与传统的asp进行身份验证相比，V3使用.net可以正常工作。

事件日志:由于以下错误，应用程序池‘传输’的模板永久缓存初始化失败:无法为应用程序池创建磁盘缓存子目录。数据可能有其他错误代码。

此引用似乎建议修复，但"appcmd“中的许多DIR路径和引用并不存在。

_http://theether.net/kb/100127

Answer 1

参考http://theether.net/kb/100127

显示以下路径: c:\inetpub\conf\temp\ASP编译的templates

• check路径存在(确实存在)

• 检查网络服务是否有权限访问"ASP编译的模板“如果不是从appcmd执行的，检查网络服务是否有权限访问”ASP编译的模板“

• CD to C:\Windows\System32\inetsrv

• enter: appcmd list config -section:system.webServer/asp

• the显示以下路径:C：\inetpub\

\\ASP已编译的模板路径存在(确实存在)

1. 检查网络服务是否有权限访问”ASP已编译的模板“；

icacls "c:\inetpub\conf\temp\ASP编译的模板“/grant”网络服务：(OI)(CI)(M)“

应为“已成功处理%1个文件”

已重新启动应用程序池。

“验证消息的安全性时出现InvalidSecurityAn错误”问题仍然存在，但“无法创建磁盘缓存子目录...”事件日志中的错误不再发生。

抱歉，又更新了一次。网络服务权限更改未解决此问题，更改为默认应用程序池解决了此问题。

终于有线索了。已检查：

在服务行为中设置的

1. ServiceSecurityAudit。参考故障日志(仅显示非特定错误500)。启用
2. 故障跟踪(也显示错误500)。
3. 自定义错误关闭
4. 友好的IE消息关闭
5. Asp客户端和服务器端调试运行，no errors.
6. Web.config httpErrors errorMode="Detailed“/> +

ServiceSecurityAudit给我发现了一个“未设置为对象实例的对象引用”，因此听起来我们的应用程序有一个bug。

跟进(17/08/11)：

此处记录的服务安全审计：

http://intrepiddeveloper.wordpress.com/2008/08/07/security-event-logging-auditing/

是我们解决这个问题的关键。揭示了对象引用错误，该错误表明业务对象和数据访问dll不一致。使用传统的ASP使用传输身份验证联系WCF直到在WCF.NET部署中的behaviour.config文件中包含服务安全审计之前，绝对没有这个错误的迹象。