Asked by:
CRM 2011 claims-based authentication problem adding Relying Party Trust to ADFS - federationdata.xml not served by CRM server (503 error)

Question
-
Steps taken so far:
Installed ADFS on default web site using port 444 and wildcard certificate for *.mydomain.com
Installed CRM on same server, new web site using port 5555. Added binding to port 443 and used same wildcard certificate
(This is a new deployment which will then be used to do a swing migration and upgrade from CRM4 by importing restored databases, but for the testing below this is just using a new empty organisation created during installation. Installed using slipstreamed UR6, build 1992. Problem not fixed by adding UR7)
Published split DNS domain names for crm.mydomain.com, dev... and auth...
CRM can be accessed through https://crm.mydomain.com
Configure claims based authentication, all seems fine. ADFS.mydomain.com/fed..../federationmetadata.xml found and used just fine
Added ADFS Claims Provider Trust for User Principal Name to UPN
Start to add relying party trust. When I enter the URL https://auth.mydomain.com/federationmetadata/2007-06/federationmetadata.xml I get an error "an error occurred during an attempt to read the federation metadata. Verify that the specified URL or host name is a valid federation metadata endpoint". It also advises to check proxy server settings which I have done (proxy server is definitely not being used. Error message: The remote server returned an error: (503) Server unavailable
Putting the same URL into a browser window (on the CRM server) also gives a 503 "service unavailable" error, so it seems like ADFS is not at fault, but CRM is not serving up the xml file it should.
I followed the steps in this article: http://blogs.msdn.com/b/emeadcrmsupport/archive/2011/05/13/we-receive-http-errors-while-accessing-the-crm-federationmetadata-url.aspx to remove the url-rewrite module and reinstall. No joy. Also checked for reserved URLs but none were found (and this server is a brand new install, only ADFS and CRM on there, nothing else).
Can anyone please give any pointers what to try next? Seems like a total impasse at the moment.
Hope this helps. Adam Vero, MCT
- Edited by Adam Vero Wednesday, March 28, 2012 7:58 AM
Tuesday, March 27, 2012 7:10 PM
All replies
-
Adam:
I am having this exact same issue, did you resolve it? If so, how did you resolve it?
Thank you,
Stangride
Friday, June 8, 2012 3:52 AM -
I am also interested in the resolution for this problem.
Thank you
Nancy
Nancy Kazee
Wednesday, June 20, 2012 6:49 PM -
I did manage to sort this out but it took a few steps. I keep hoping to find time to get round to writing up how I did it as a blog post as it does seem to be an often-asked question to get both CRM and ADFS on the same server on two IP addresses but both using default https port 443.
in short, you need to do some netsh commands to remove the reserved URLs and re-add them.
I'll update here when I have written this up properly as a step-by-step.
Hope this helps. Adam Vero, MCT
Wednesday, June 20, 2012 7:35 PM -
Hi Adam,
Try this URL for ADFS,
https://ADFS.mydomain.com/handlers/FederationMetadata.ashx
And for auth use this URL,
https://auth.mydomain.com/handlers/FederationMetadata.ashx
Regards,
Khaja Mohiddin
http://www.dynamicsexchange.com
http://about.me/KhajaMohiddinWednesday, June 20, 2012 8:12 PM -
Here was the resolution for this issue:
Action: Access to FederationMetadata.xml while adding CRM to ADFS2.0
Result: 503 error.
Cause: The URL was reserved by ADFS service.
Resolution: Removed the unnecessary reserved URLs.
Use this command via the command prompt on the servers to determine the reserved URLs:
netsh show http urlaclUse the delete command to remove any unnecessary reserved URLs.
Thursday, June 21, 2012 3:18 AM -
ADFS does seem to need to use reserved URLs but the ones it sets up by default contain wildcards so they match not only the ADFS federationmetadata path, but the CRM one as well. So having removed them they also need to be re-added without the wildcards so they are specific to ADFS only and don't 'get in the way' of CRM.
Hope this helps. Adam Vero, MCT
Thursday, June 21, 2012 6:05 AM -
Installing the IIS url rewrite module was the other thing we have done to correct this issue:
http://www.microsoft.com/en-us/download/details.aspx?id=7435
Thursday, June 21, 2012 3:13 PM -
@stangride As I stated in my original question, I followed the advice in an article which included re-installing the URL rewrite module as well as looking for any URLacls which had errors. Neither of these things resolved the problem since the URLrewrite module was not faulty (and not even being used since the request did not get as far as that due to being 'trapped' by the reserved URL for the ADFS service) and there were no URLacls with errors. So this is unfortunately not the answer to my question, although it may or may not help others to fix theirs.
The resolution to the problem for me was to delete and re-instate the URLacls without a wildcard so they were specifically 'listening' to the requests for federationmetedata from ADFS only, not all such requests to the server. Background details and steps to resolve (with commands) can be found in the blog post I have now had time to write on a long train journey:
Configure CRM 2011 and ADFS 2.0 on a single server on port 443
Hope this helps. Adam Vero, MCT
Thursday, June 21, 2012 8:24 PM