Last week we were setting up an on-premise Dynamics CRM 2016 at one of our clients. The server had to be configured to accept internal and external clients in order to be able to work with mobile CRM clients. The client already had an ADFS 2.2 server running on a Windows 2012R2 server.
Once we installed CRM, it was time to setup IFD (Internet Facing Deployment) and the trust relationship with the ADFS server. On the internet there are quite a few very solid articles on performing this job, e.g.
We followed the exact steps as desribed in the articles. And then the moment came we had to test our configuration.
Test 1. Use the internal address
In our browser we entered the internal url for the organisation: https://organisation.domain.com.
Rightaway we were presented with the ADFS login page (single sign on) and we were able to login and connect to CRM.
So far so good!
Test 2. Use the external address
In our browser we entered the external url for the organisation: https://auth.domain.com.
Rightaway we were presented with the ADFS login page (single sign on) and we were able to login and then we were presented with a 404 error. *WUT!?*
We ran a couple of double checks, settings seemed to be fine.
We decided to check the eventlog on the already existing ADFS 2.2 server. In the eventlog we encountered a large number of errors with eventID 364. In the exception details it looked like there was a problem with wsfed.
What was going on??
Time for some analysis
When we use the internal CRM address to access Dynamics CRM, we get redirected by IFD to authenticate with the ADFS server. once authenticated by the ADFS server we get redirected to Dynamics CRM and we are shown the CRM dashboard. In this scenario both IFD and ADFS work like a charm.
When we use the external CRM address to access Dyanmics CRM, we get redirected by IFD to authenticate with the ADFS server. Once authenticated by the ADFS server we get redirected to a non existent page on the CRM server. In this scenario IFD works, ADFS redirects in a wrong way.
We double checked the ADFS server. Checked the federation metadata XML’s at both sides of the trust (CRM and ADFS), both returned the correct XML.
No matted what we tried, the ADFS server kept redirecting a the wrong location. From our perspective it looks like the ADFS server is not configured flawlessly.
As time kept ticking, we had to deliver a fully configured Dynamics CRM environment using IFD and ADFS, we came up with a simple but clever workaround.
The ADFS server redirected the external url to a non existing location on the IIS of the CRM server, resulting in a 404 error.
This meant that our CRM server was serving an error page. We opened the Internet Information Services Manager on the CRM web frontend and navigated to the Error Pages section at the Microsoft Dynamics CRM site.
When opening the error pages, you’ll find per HTML error status code an action the Internet Information Server has to perform.
We located the 404 status code, and decided to change it. Instead of showing an error, we decided that IIS has to do the last 302 redirection (in our case https://crm.domain.com).
In DNS we configured an additional A record for “crm” that pointed to the CRM server (the CRM website was bound to port 443 using a wildcard certificate).
We saved the setting, and our list of error pages looked like the list below:
After resetting IIS we did another attempt by calling the external CRM url https://auth.domain.com.
Via IFD we were redirected to ADFS, there we logged in. ADFS redirected us to the Internet Information Server. In IIS error 404 (page not found) was trapped, redirecting us to our new url https://crm.domain.com.
This resulted in a Dynamics CRM website running from the address: https://crm.domain.com/organisation
From this moment on, we were able to connect to both the internal and external addresses, regardless of application, location or device.