在我们的开发环境中，我们在ADFS 2.0中configuration的依赖方遇到问题，这让我感到困惑。 这就好像有一个标识符黑名单一样。
我们现在有3个开发者正在开发这个function（在Win2kR2 for ADFS，Win7 Pro / VS2010 / MVC2 / C＃for devs上的新configuration）。 ADFS在Domain2而所有的开发盒在Domain1 。 Domain2信任Domain1但不是相反的（不是这个问题）。 我创build了3个信任，每个开发人员一个。 每个开发人员的信任端点和标识符都是相同的（ https://DevBoxFQDN/AppName/ ）。 最初设置时，我只是使用DevA作为testing案例，直到我开始工作。 一旦DevA ，我就添加了DevB但是通过将DevB's标识符添加到DevA RP DevB's了不正确的DevA 。 最终的结果是，当你试图在DevB's web应用上进行身份validation时，redirect到应用程序，它到了DevA's盒子。 混淆了configuration，但是我会称这是DevB框的成功testing案例。 一旦我意识到这一点，我从DevA RP中删除了DevB's标识符，并创build了DevB和DevC RP（针对端点和标识符指向https://DevB.FQDN/AppName/和https://DevC.FQDN/AppName/ ）。
在这一点上，奇怪的事情发生了。 这适用于DevC ，就像DevA 。 但是， DevB获取事件ID 184/364，指示DevB标识符不正确。 大量的debugging和search可能的问题导致没有用。 作为一个盲目的刺，我们简单地在DevB框上为https://DevB.FQDN/AppName2/创build一个新的虚拟目录（我们简单地在虚拟目录/应用程序名的末尾添加了一个2 ，指向相同的位置作为另一个，并具有相同的设置），并对应用程序的web.config文件进行了相同的更改。 在ADFS中，我编辑了端点和标识符以添加2 。 这种变化和这种变化本身会导致DevB正常工作。 所以这个洞察力大部分的可能性，我们怀疑不适用于我们（防火墙，搞砸证书/ SPNs等），论坛post留给我们。 如果我们改回来删除2 ，那么它又会破坏。 没有其他变化！
为了彻底，我们将DevB机器恢复为基于映像的备份，从“正常工作”的时间开始，但在DevA RP之下 – 没有任何变化。 所以这对我说，这个问题是在ADFS服务器的configuration或其他之间的某个地方，而不是Web服务器。
那么，交易是什么？ 为什么ADFS不能使用特定的标识符/端点（尽可能多地只是一个stringURL），但是如果我在所有情况下只添加一个2 ，它就可以工作？ 是否有黑名单/caching或我需要清除的东西？
logging了两个事件：184和364. 364是没有意义的，因为它只是说“出了什么问题”，但是184有趣。 错误的事件日志详细信息（事件ID：184）：
A token request was received for a relying party identified by the key 'https://DevB.FQDN/AppName/', but the request could not be fulfilled because the key does not identify any known relying party trust. Key: https://DevB.FQDN/AppName/ This request failed. User Action If this key represents a URI for which a token should be issued, verify that its prefix matches the relying party trust that is configured in the AD FS configuration database.
最后，我有双重/三重/五重检查标识符。 这是正确的，没有错别字或任何东西。
PS：这是微软公司针对这个问题的一个交叉post 。