In our development environment, we're having a problem with our configured Relying Parties in ADFS 2.0 that is baffling me. It's acting as though there is a blacklist of identifiers.
We have 3 developers developing against this right now (new configuration on Win2kR2 for ADFS, Win7 Pro/VS2010/MVC2/C# for devs). ADFS is on
Domain2 while all dev boxes are on
Domain1 but not the other way around (not that this matters). I created 3 trusts, one for each developer. The trust endpoint and identifiers are the same for each developer (
https://DevBoxFQDN/AppName/). When initially setting this up, I was just using
DevA as a test case until I got it to work. Once it worked for
DevA, I then added
DevB but did it incorrectly by adding
DevB's identifier to the
DevA RP. The end result was when you tried to authenticate on
DevB's web app, when redirected back to the app, it went to
DevA's box. Messed up configuration, but I would call that a success test case for the
DevB box. Once I realized this, I removed
DevB's identifier from the
DevA RP and created both the
DevC RPs (pointing to
https://DevC.FQDN/AppName/ for both endpoints and identifiers).
At this point, something strange happened. This worked for
DevC just fine, like it does for
DevB gets the Event IDs 184/364 indicating that the
DevB identifier is incorrect. Much debugging and googling of possible problems resulted in nothing useful. As a blind stab, we simply created a new Virtual Directory on the
DevB box for
https://DevB.FQDN/AppName2/ (we literally just added a
2 to the end of the virtual directory/application name - points to the same location as the other one and has the same settings) and made the same change to the web.config file for the app. In ADFS, I edited the endpoint and identifier to add the
2 as well. This change and this change alone causes
DevB to function properly. So this debunks most of the possibilities that we have suspected don't apply to us (firewalls, screwed up certificates/SPNs, etc.) that the forum posts left for us. If we change this back to remove the
2, then it breaks again. Nothing Else Changes!
And just to be thorough, we reverted the
DevB machine back to an imaged-based backup from the time when it was "working" but under the
DevA RP - no change. So this says to me that the problem is somewhere on the configuration of the ADFS server or something in between, but not the web server.
So, what's the deal? Why won't ADFS work with a specific identifier/endpoint (simply a string URL for as much as I can tell) but if I simply add a
2 to it in all cases, it works? Is there a blacklist/cache or something that I need to clear?
Two events are logged: 184 and 364. The 364 is of no interest as it simply says "something went wrong" but the 184 is of interest. The event log details of the error (Event 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.
And lastly, I have double/triple/quintuple-checked the identifier. It IS correct with no typos or anything.
PS: This is a cross-post from Microsoft's Forums for this problem.