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. Domain2 trusts 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 DevB and DevC RPs (pointing to https://DevB.FQDN/AppName/ and 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 DevA. However, 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.
0 Answers