非常沮丧所有这一切，希望有人可以提供协助。
我有一个Silverlight应用程序和WCF一起工作没有问题一年。为了让他们工作，我最初有一些痛苦，但最终在帮助下完成了它。所有的痛苦都来自配置/安全，401，跨域地狱等等。
我拥有一切设置的方式是我有一个WCF服务，它驻留在它自己的应用程序/目录中，并在自己的应用程序池中运行。
在同一个Web服务器（IIS7）上，我有另一个带有指向上述服务的Silverlight应用程序的应用程序/目录。
服务器名称（本练习）是WEBSERVER1。我们为WEB1创建了一个CNAME。过去，如果用户转到http://WEB1/MyApp/或http://WEBSERVER1/MyApp/，则可以使用。昨天突然开始表现得很糟糕。普通用户开始获得Windows质询/响应提示（即使他们输入了信息，他们也会收到401错误）。
我的WCF服务在一个启用匿名访问的站点中运行（这一直有效）。 我的Silverlight应用程序在一个集成了Windows的站点中运行（这一直有效），因为我在连接时捕获了Windows用户名。
为了记录，我昨天创建了一个新的应用程序池，其中包含一个运行在其中的ASP.NET应用程序。这似乎工作正常，但有可能创建这个新的应用程序池和应用程序/目录已导致一些改变。
我的wwwroot文件夹中有一个clientaccesspolicy.xml，以及上面两个应用程序中的每个应用程序的文件夹（以防万一）。我试图通过Negotiate推广NTLM作为提供者（因为这适用于我在另一台服务器上遇到的另一个问题）。
在尝试一些更改之后，我甚至无法在每次调用时使用相同的操作。有时它会提示我提供证书。其他时候它会工作，但后来说它无法使用＆＃34;未找到＆＃34;连接到WCF服务。其他时候它实际上可以正常工作，但前提是我使用的是实际的服务器名称，而不是CNAME。使用CNAME时，我总是会收到跨域错误，即使我在每个目录根目录中都有跨域xml文件。
这是一场噩梦，相比之下，高级算法分析看起来既有趣又简单。微软是否意识到他们将这种组合（IIS7 / WCF / Silverlight / providers / permissions /神秘或缺失的错误消息）组合起来有多困难？
答案 0 :(得分：0)
我找到了似乎有效的解决方案。
在这种情况下，我必须将默认网站（托管clientaccesspolicy.xml文件）的身份验证模式从匿名访问更改为Windows Integrated。我不明白为什么这个工作了一年左右然后停了下来，但似乎已经解决了。
我昨天部署的新应用程序是一个标准的ASP.NET Web应用程序，我将它放在它自己的应用程序目录和它自己的应用程序池中，以确保它不会导致这个有点问题。我还不确定是不是。
我解决它的方法是尝试从我的PC导航到实际的http://servername/clientaccesspolicy.xml文件，这给了我401错误。我从匿名切换到集成在该默认网站上的Windows（除了该xml文件之外没有任何内容）并解决了权限问题。然后，我必须允许实际的AD组具有对该文件夹的读取权限（如果不是，他们得到了用户/ pw提示并且无法通过）。