locked
IFD 404 Error on Auth.domain.com with CRM 2011 RRS feed

  • Question

  • I have CRM 2011 depolyed with claims and IFD. ADFS is on a separate server from CRM 2011. We are accessing CRM from externally through Forefront TMG as our firewall.

     

    When I browse to org.domain.com I get redirected to ADFS. I log in with my credentials and I am redirected to auth.domain.com (which is my external end point for 2011 as configured in the IFD setup).

     

    Auth.domain.com give a 404 error that appears to be a custom 404 from CRM. So I am successfully getting past ADFS but then get stuck on auth.domain.com. 

     

    If I then re-enter the original url (org.domain.com), I can successfully get it to the CRM Deployment without logging in again or getting any problems with auth.422g.com

     

    Also, we have an identical development setup also going through the firewall with the same settings and we aren't having any problems with it.

     

    Any idea why we're getting stuck on auth.domain.com?

    Wednesday, April 20, 2011 9:10 PM

Answers

  • Did you expose this auth.contoso.com and add the proper dns entries for it?
    • Marked as answer by Jim Glass Jr Thursday, June 9, 2011 7:16 PM
    Wednesday, June 8, 2011 8:26 PM

All replies

  • Same problem here, did you find any solutions ?
    Friday, April 29, 2011 4:03 AM
  • Do you have https://auth.domain.com added as a subdomain for your domain?
    Monday, May 16, 2011 7:15 PM
  • Hi,

    Did you resolve this issue?

     


    Khaja Mohiddin
    Wednesday, May 18, 2011 7:49 PM
  • you need to expose the following endpoints to have your IFD work Sucessfully.

    auth.contoso.com

    orgxx.contoso.com

    dev.contoso.com (discovery wsdl)

    sts.contoso.com (adfs service url)

    • Proposed as answer by Jim Glass Jr Friday, May 20, 2011 3:37 PM
    Friday, May 20, 2011 4:04 AM
  • All urls work fine! But auth.contoso.com doesn't work yet. Anyone?
    Wednesday, June 8, 2011 8:16 PM
  • Did you expose this auth.contoso.com and add the proper dns entries for it?
    • Marked as answer by Jim Glass Jr Thursday, June 9, 2011 7:16 PM
    Wednesday, June 8, 2011 8:26 PM
  • Did you expose this auth.contoso.com and add the proper dns entries for it?
    My mistake! I configured Claims Provider Trust's rules again and it works fine! Resolved it!
    Wednesday, June 8, 2011 8:51 PM
  • Hi Marcio,

    we actually have the same problem. What did configure again in detail?


    Thanks
    Tobias

     

    Thursday, June 9, 2011 1:37 PM
  • I found the solution: the CRM site was in the trusted site zone in IE and tried to logon automatically with Windows auth. This does not work as the computer is in another domain.

     

    I am running now in 2 more problems:

    1. The first time, the site opens, the dashboard shows an 404 error. I have to click on Dashboard and the dashboard loads. CRM 2011 RU2 is already installed.
    2. The performance with IFD is slow, The average load time is 3 seconds and internal I have an average page load time of 0.7 - 1 second.

    Do you have any ideas?

    THanks
    Tobias

    Thursday, June 9, 2011 2:00 PM
  • Are you guys using the same *.domain.com wild card certificate on the ADFS, CRM 2011 and ISA server? When I connect to the ISA the default rule applied causing the connection to not even get to the CRM 2011/ADFS server. Forefront says the source and target domain are the same. Forefront is not my specialty and I have 4 rules on forefront asdfs.domain.com; crm2011.domain.com (org), dev.domain,com (CRM); crm2.domain.com (CRM). Any ideas what I am doing wrong? I currently created a local host file on the PC connecting to the server with all the entries and CRM/ADFS server also have the same host file point to the external IP of the Forefront server.
    Saturday, June 11, 2011 2:08 PM
  • Tobi K,

     

    Sorry my late response, did you resolve the problem? If not, I can help you!

    Thursday, August 25, 2011 2:34 PM
  • I have CRM 2011 depolyed with claims and IFD. ADFS is on a separate server from CRM 2011. We are accessing CRM from externally through Forefront TMG as our firewall.

     

    When I browse to org.domain.com I get redirected to ADFS. I log in with my credentials and I am redirected to auth.domain.com (which is my external end point for 2011 as configured in the IFD setup).

     

    Auth.domain.com give a 404 error that appears to be a custom 404 from CRM. So I am successfully getting past ADFS but then get stuck on auth.domain.com. 

     

    If I then re-enter the original url (org.domain.com), I can successfully get it to the CRM Deployment without logging in again or getting any problems with auth.422g.com

     

    Also, we have an identical development setup also going through the firewall with the same settings and we aren't having any problems with it.

     

    Any idea why we're getting stuck on auth.domain.com?


    Having a similar problem except for two points.

    1) One of my orgs works perfectly, getting 404 on a second I use for testing.

    2) entering the original url does not get me past 404

     

    I have updated the federation metadata on the ADFS, the org shows up in the list of URLS on the ADFS server, I have DNS configured correctly.

    This whole setup seems really buggy, lots of posts out there with strikingly similar issues, hopefully rollups will start addressing IFD issues.

     

    Friday, September 30, 2011 1:41 AM
  • I have solved my problem by doing the following Steps:

    1- Go to CRM server and open Deployment Manager - then right click Microsoft Dynamics CRM and click on Configure Internet Facing Deployment - > then Click Next -- Keep the Web App server domain, OWS and DWS as it is. click Next and change the Fqdn from auth.yourdomain.com to your actual external name domain e.g. crm.mydomain.com

    Go to ADFS server and delete the "External" Relaying Party trust then re-create it with the following metadata link:

    https://crm.yourdomain.com/FederationMetadata/2007-06/federationmetadata.xml

    The claims that you need to configure there are

    1- Pass Primary SID = Primary SID

    2- Pass UPN = UPN

    3- Transform Windows account name to Name = use *Name not Name

    Hit apply and OK  then try again.

    this has worked for me.


    Mohammed JH

    Friday, October 12, 2012 11:06 AM