We had an event where our main *.domain.com certificate expired which was used for ADFS and Dynamics CRM. I've since replaced the certificate, and ran through ADFS / Dynamics deployment manager multiple times, but the site doesn't work. Very little useful information either, as we are presented with a login screen (https://sts1.domain.com), followed by a very vague error. "Error: There was a problem accessing the site. Try to browse to the site again. If the problem persists, contact admin and provide reference number: fc8c6c13-96fe-4c63-9f2e-30992bdae753"
What good are these reference numbers? I don't see any information online nor anything in event viewer related to them.
This was a working environment at one point, until the cert expired and auth broke. I've since tried to re-configure many times following this MS doc: download.microsoft.com/.../crmconfigureifd.pdf
Things I have checked:
- IIS, default website as well as Dynamics CRM site both have the new cert bound to https.
-Checked with netsh http sslcert that the new cert is bound to the correct ports.
-Browsed to the URL of Relying party's federation metadata URL, which works and no ssl errors.
-Re-setup / re-deployed the ADFS relying party trust multiple times,along with accepted claim types/rules.
-Ensured new cert is installed to LOCAL MACHINES personal folder.
-Ensured service account used to setup IIS app pool has permissions to the certificate in mmc.
-IISreset and multiple server reboots.
Can somebody please have a look over my configuration to see if anything sticks out? Anywhere I can look for more clues? Event viewer does not seem to help- seems like Dynamics CRM simply isn't serving up the page after login.
Is there another way to simply gain access to CRM without ADFS? We only need it for local/legacy records access at this point.
Note** Something peculiar of note is that https for the default website in IIS is set to port 444- https for microsoft dynamics is bound to 443. I don't know why this would be. I followed the microsoft guide to reconfigure with our FQDN but I don't know why port 444 would be coming up in ADFS/login etc. When I go to Dynamics deployment manager and click "Configure claims-based auth" it auto-populates with the https://sts1.domain.com:444/FederationMetadata/.../FederationMetadata.xml URL, then afterwards tells me to set a relying party trust using https://slcrm.domain.com/.../FederationMetadata.xml .
Any tips at this point would be helpful, I feel that I've exhausted all avenues including complete re-configuration. Some of the values in IIS were present since before my time so I suspect maybe something in there could be a problem? But I've researched extensively and have checked everything I could find to pinpoint a problem here.
funny enough, 10 minutes after posting I got it up and running (after about a week of head-wall bashing).
I made a second relying party trust to include many identifiers: crm.domain.com, auth.domain.com, dev.domain.com, sts1.domain.com:444/, sts1.domain.com/, and then it worked finally.
No clue why that fixed it! Thanks for reading!
Stay up to date on forum activity by subscribing. You can also customize your in-app and email Notification settings across all subscriptions.
André Arnaud de Cal... 290,524 Super User 2024 Season 2
Martin Dráb 228,469 Most Valuable Professional
nmaenpaa 101,148