Take the 2-minute tour ×
Server Fault is a question and answer site for system and network administrators. It's 100% free, no registration required.

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.

share|improve this question
    
We've had some slight change in behavior but nothing really changed. Our "AppName2" stopped working, so we created "AppName3". It failed to work from the get-go. We then created a "ScoobyDoo" version and it works. This is really strange... –  Jaxidian Jun 6 '11 at 1:33
    
Okay, now, without change /AppName/ is work is working! Seriously, what is going on here?? –  Jaxidian Jun 6 '11 at 2:07

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Browse other questions tagged or ask your own question.