ADFS 表现得好像它有一个依赖方标识符黑名单?

ADFS 表现得好像它有一个依赖方标识符黑名单?

在我们的开发环境中,我们在配置依赖方时遇到了问题ADFS 2.0这让我很困惑。它的行为就像是有一个标识符黑名单一样。

我们现在有 3 位开发人员正在针对此进行开发(Win2kR2 上为 ADFS 的新配置,开发人员的 Win7 Pro/VS2010/MVC2/C#)。Domain2当所有开发箱都处于Domain1.Domain2信任状态时,ADFS 处于开启Domain1状态,但反之则不然(这并不重要)。我创建了 3 个信任,每个开发人员一个。每个开发人员的信任端点和标识符都是相同的(https://DevBoxFQDN/AppName/)。最初设置时,我只是将其用作DevA测试用例,直到我让它正常工作。一旦它为 工作DevA,我便添加DevB,但操作错误,将DevB's标识符添加到DevARP。最终结果是,当您尝试在DevB'sWeb 应用程序上进行身份验证时,当重定向回应用程序时,它会转到DevA's箱体。配置搞砸了,但我会将其称为箱体的成功测试用例DevB。意识到这一点后,我DevB's从 RP 中删除了标识符DevA,并创建了DevBDevCRP(指向https://DevB.FQDN/AppName/https://DevC.FQDN/AppName/端点和标识符)。

此时,发生了一些奇怪的事情。 这对 来说运行得DevC很好,就像对 一样DevA。但是,DevB获取事件 ID 184/364,表示DevB标识符不正确。 大量调试和对可能的问题的谷歌搜索均无济于事。 盲目尝试,我们只是在 的DevB框上创建了一个新的虚拟目录https://DevB.FQDN/AppName2/(我们实际上只是2在虚拟目录/应用程序名称的末尾添加了 - 指向与另一个相同的位置并具有相同的设置)并对应用程序的 web.config 文件进行了相同的更改。 在 ADFS 中,我编辑了端点和标识符以添加2。 此更改和仅此更改即可DevB正常运行。 因此,这推翻了论坛帖子留给我们的大多数我们怀疑不适用于我们的可能性(防火墙、搞砸的证书/SPN 等)。 如果我们将其改回以删除2,那么它又会中断。其他都沒有改變!

为了彻底检查,我们将DevB机器恢复到基于映像的备份,当时它“工作”但在DevARP 下 - 没有变化。所以这告诉我问题出在 ADFS 服务器的配置上或两者之间的某个地方,而不是 Web 服务器。

那么,这是怎么回事?为什么 ADFS 不能使用特定的标识符/端点(据我所知只是一个字符串 URL),但如果我2在所有情况下都向其添加一个,它就可以工作?是否有黑名单/缓存或我需要清除的东西?

记录了两个事件: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.

最后,我已对标识符进行了两次/三次/五次检查。它是正确的,没有任何拼写错误。

附言:这是一个来自微软论坛的交叉发布对于这个问题。

相关内容