Asked by:
Relying Party Trusts Stopped Running

Question
-
After setting up IFD my other Relying Party Trust stopped working. So I have
Stop, CRM Claims Relying Party, https://internalcrm.[domain].com/
CRM IFD Relying Party, https://crm.[domain].com/For the first one under properties on the tab Monitoring it says "This relying party is out of date due to monitoring errors. Please check the event log for details." When I go to the Event Viewer -> Applications and Services Logs -> AD FS 2.0->Admin I only see some information entries but no warnings or errors. Any tips why the service stopped would be appreciated.
On another note, it also lists http://sts.[domain].com:80/adfs/services/policystoretransfer. However, I have ADFS on port 81/444 (default website was set to this before installing ADFS). So shouldn't the above be on :81? Same goes for http://localhost:80/adfs/services/trust/mexsoap which I think should also be on port 81, no?
Thursday, March 8, 2012 4:20 AM
All replies
-
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/KhajaMohiddinThursday, March 8, 2012 4:33 PM -
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 -
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.
Khaja Mohiddin
http://www.dynamicsexchange.com
http://about.me/KhajaMohiddinThursday, March 8, 2012 5:54 PM -
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].localNote 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 -
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><<Address>https://internalcrm.[domain].com/</Address></EndpointReference>
</fed:TargetScopes><<Address>https://internalcrm.[domain].com/</Address></EndpointReference></fed:ApplicationServiceEndpoint><<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