Sign in
Microsoft.com
 
Microsoft
 
 
 

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

 > 

  • Question

  • Question
    Sign in to vote
    0
    Sign in to vote

    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

  • Question
    Sign in to vote
    0
    Sign in to vote

    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
  • Question
    Sign in to vote
    0
    Sign in to vote

    I am also interested in the resolution for this problem. 

    Thank you

    Nancy

    Nancy Kazee

    Wednesday, June 20, 2012 6:49 PM
  • Question
    Sign in to vote
    0
    Sign in to vote

    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
  • Question
    Sign in to vote
    0
    Sign in to vote

    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/KhajaMohiddin

    Wednesday, June 20, 2012 8:12 PM
  • Question
    Sign in to vote
    0
    Sign in to vote
    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 urlacl

    Use the delete command to remove any unnecessary reserved URLs.

    • Proposed as answer by stangride Thursday, June 21, 2012 3:19 AM
    • Unproposed as answer by Adam Vero Thursday, June 21, 2012 6:01 AM
    • Proposed as answer by stangride Thursday, June 21, 2012 3:13 PM
    Thursday, June 21, 2012 3:18 AM
  • Question
    Sign in to vote
    0
    Sign in to vote

    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
  • Question
    Sign in to vote
    0
    Sign in to vote

    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

    • Proposed as answer by stangride Thursday, June 21, 2012 3:13 PM
    • Unproposed as answer by Adam Vero Thursday, June 21, 2012 8:25 PM
    Thursday, June 21, 2012 3:13 PM
  • Question
    Sign in to vote
    0
    Sign in to vote

    @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