Relying Party Trusts Stopped Running

All replies

• 

  

  0

  Sign in to vote

  Hi,

  Can you reconfigure ADFS 2.0 and try to add the relying parties again.

  You dont need to add port 80 and 81 for Default Web Site(ADFS). Just add https(444) for ADFS and https(443) for CRM. Make sure to add certificate for both of the bindings.

  You can use FsConfigWizard.exe for re configuring ADFS from this location C:\Program Files\Active Directory Federation Services 2.0.

  Regards,

  ---

  Khaja Mohiddin
  http://www.dynamicsexchange.com
  http://about.me/KhajaMohiddin

  Thursday, March 8, 2012 4:33 PM
• 

  

  0

  Sign in to vote

  Thanks, I tried that, i.e. I removed 80 from CRM (only 443 left) and 81 from ADFS (only 444 left on default web site). I then ran the tool again. I did not install IFD yet but already ran into problems. In the IE I navigated to https://internalcrm.[domain].com. This did bring me to the CRM login screen at URL https://sts.[domain].com:444/adfs/ls/?wa=wsignin1.0&wtrealm=https%3a%2f%2finternalcrm.[domain].com... When I try to login I get an "error sts.[domain].com. There was a problem accessing the site..." If I look at the event viewer I see an event ID 184 and 364 as a result of this. 184 (the first entry timewise) says "A token request was received for a relying party identified by the key https://internalcrm.[domain].com, but the request could not be fulfilled because the key does not identify any known relying party trust.". I did already setup the party trust according to the claims based documentation. Now if I go to the properties of the party trust I see the "relying party identifiers" https://auth.[domain].com, https://dev.[domain].com and https://[orgname].[domain].com. I guess I should also see https://internalcrm.[domain].com here but I don't. It looks like it picks this values up from the wrong place which I assume is https://internalcrm.[domain].com/FederationMetadata/2007-06/FederationMetadata.xml The URL tests out ok but the entity ID is https://auth.[domain].com. Not sure why it points to auth rather than internalcrm

  Thursday, March 8, 2012 5:35 PM
• 

  

  0

  Sign in to vote

  Hi,

  The internal relay party trust does not contains https://auth, https://dev and https://orgname identifiers.

  How did you configure Relying party trust for internal access?

  I think you are not using your Internal URL. You have to use https://internalcrm.[domain].com/FederationMetadata/2007-06/FederationMetadata.xml

  to configure IFD for internal access.

  And in this you will get only one identifier which is https://internalcrm.[domain].com.

  Regards,
  
  

  ---

  Khaja Mohiddin
  http://www.dynamicsexchange.com
  http://about.me/KhajaMohiddin

  Thursday, March 8, 2012 5:54 PM
• 

  

  0

  Sign in to vote

  Actually, after runnign the wizard again I have not setup party trust for IFD yet. Here is what I did

  * Run FsConfigWizard with Fed Service name = sts.[domain].com (showed port 444), delete old database.
  * In CRM Mgr run claim based auth again. URL is https://sts.[domain].com:444/federationmetadata/2007-06/federationmetadata.xml
  * Run ADFS2 Mgr. Add a relying party trust with URL
  * In ADFS verify that claims provider trusts for Active Directory has rule "Send LDAP Atttribute as Claims", Attribute = User-principal-name, outgoing claim type = UPN
  * Add relying party trust with URL https://internalcrm.[domain].com/FederationMetadata/2007-06/FederationMetadata.xml. Then add claim rules for UPN (pass through), Primary SID (pass through), and Windows account name -> Name (transform).

  The issue I think is that the link above for adding the relying party trust has an entity ID of https://quth.[domain].com. I think it should be https://internalcrm.[domain].com, no? If so why does it resolve to https://quth.[domain].com instead? I wonder if it's somewhere in the DNS settings where I added

  sts, sts.[domain].com, [servername].[domain].local
  crm, crm.[domain].com, [servername].[domain].local
  internalcrm, internalcrm.[domain].com, [servername].[domain].local 
  auth, auth.[domain].com, [servername].[domain].local
  dev, dev.[domain].com, [servername].[domain].local

  Note that Federation Service Propertice has the Federation Service identifier as http://sts.[domain].com/adfs/services/trust, i.e. it misses the port 444. With all of the above I am getting the 3 identifiers listed before, i.e. https://auth/dev/orgname.[domain].com

  Thursday, March 8, 2012 6:43 PM
• 

  

  0

  Sign in to vote

  Hi,

  After configuring Claims with Deployment Manager, is https://internalcrm.[domain].com/FederationMetadata/2007-06/FederationMetadata.xml accessible? If so, you should see the following (and ONLY the following) towards the end of the xml:

  <fed:TargetScopes>

  - <EndpointReference xmlns="http://www.w3.org/2005/08/addressing">

  <<Address>https://internalcrm.[domain].com/</Address>

  </EndpointReference>
  </fed:TargetScopes>

  - <fed:ApplicationServiceEndpoint>

  - <EndpointReference xmlns="http://www.w3.org/2005/08/addressing">

  <<Address>https://internalcrm.[domain].com/</Address>

  </EndpointReference>

  </fed:ApplicationServiceEndpoint>

  - <fed:PassiveRequestorEndpoint>

  - <EndpointReference xmlns="http://www.w3.org/2005/08/addressing">

  <<Address>https://internalcrm.[domain].com/</Address>

  </EndpointReference>

  </fed:PassiveRequestorEndpoint>

  If you see anything else, then you have a DNS issue and are probably accessing the metadata of another service (possibly ADFS itself). Note that the IFD metadata (i.e. https://crm.[domain].com) would list all your org, discovery service and auth URLs.

  Also note that for internal access you need to configure the Relying Party using https://internalcrm.[domain].com (as you did) and for external, you need a second Relying Party using https://crm.[domain].com.

  Friday, March 9, 2012 9:29 PM