0

I'm trying to install Microsoft Dynamics CRM 2016 with IFD (Internet-Facing Deployment) and ADFS on the same server (Windows Server 2012 R2)

ADFS is running and seems to be working fine. I can fetch the metadata on https://sts.mydomain.com/FederationMetadata/2007-06/FederationMetadata.xml

I've configured Dynamics CRM IFD to use the following settings:
Web Application Server Domain: mydomain.com
Organization Web Service Domain: mydomain.com
Discovery Web Service Domain: discovery.mydomain.com
External domain where Internet-Facing servers are located: auth.mydomain.com

The problem starts when trying to setup the Relying Party Trust on ADFS.
When using the address https://auth.mydomain.com/FederationMetadata/2007-06/FederationMetadata.xml as the federation metadata address, it is fetching the wrong metadata.
It's fetching the ADFS metadata instead of the CRM metadata.

The only way to get this working is if I set a different port for the CRM endpoints, for example by appending :444 to the CRM IFD settings.

The problem with this configuration is that it would use non-standard HTTPS port 444 for the Dynamics CRM website and also during the Authentication phase using auth.mydomain.com:444

Is there any way to have both ADFS and Dynamics CRM running on HTTPS on port 443?

Arun Vinoth - MVP
  • 314
  • 1
  • 3
  • 15
taborda
  • 11
  • 4
  • You can configure your ADFS service to use a custom port such as 444 in your case, then update your CRM properties to point to the new ADFS federation metadata URL: ( https://sts.mydomain.com：444/FederationMetadata/2007-06/FederationMetadata.xml ). More details configurations about this can be found here:http://www.inogic.com/blog/2014/07/how-to-change-the-port-of-adfs-3-0-windows-server-2012-r2-to-444/ – Jimmy Sun Feb 27 '17 at 09:54
  • The problem as I said, is that I don't want to have any of these endpoints running on a non-standard HTTPS port. If I configure ADFS to use port 444, clients will need to login on a 444 port endpoint. – taborda Feb 27 '17 at 10:27
  • I'm afraid you cannot have both ADFS and Dynamics CRM on the same server running with HTTPS 443 port. Why not separate them to two servers instead of on the same server? – Jimmy Sun Feb 28 '17 at 04:50
  • Why not separate them? Windows Server licensing, most likely. But the problem is that ADFS and CRM publish their metadata to the same url, so one will overwrite the other. There may be some host header trickery you can do in IIS to get them to cooexist if you configure them both with unique subdomains, but I haven't tried this. – Thomas Mar 01 '17 at 11:15

1 Answers1

0

Tried to mess around with the URL reservation but with no success.
Tried to add another IP to the network interface again with no success.
It seems that ADFS always tries to bind to 0.0.0.0 instead of a specific IP. If the reservation is not there, then ADFS won't bind at all.

I've also tried what Thomas suggested, but ADFS always catch the request first. (because of the URL reservation)

I've got it working by getting Dynamics CRM to provide its metadata on another URL path.

Basically I thought I could do this with URL rewrite rules.
I was about to create a new rule when I found this on the Dynamics CRM web.config 

<rule name="FederationMetadataRule" stopProcessing="true">
  <match url="FederationMetadata/2007-06/FederationMetadata.xml" />
  <action type="Rewrite" url="/Handlers/FederationMetadata.ashx" />
</rule>

Default path: C:\Program Files\Microsoft Dynamics CRM\CRMWeb\web.config

You just need to change the url to something other than FederationMetadata ex:

<rule name="FederationMetadataRule" stopProcessing="true">
  <match url="FederationMetadataCrm/2007-06/FederationMetadata.xml" />
  <action type="Rewrite" url="/Handlers/FederationMetadata.ashx" />
</rule>

After this change you can add the Relying Party Trust using the url https://auth.mydomain.com/FederationMetadataCrm/2007-06/FederationMetadata.xml

Another option would be to add it using the url https://auth.mydomain.com/Handlers/FederationMetadata.ashx

With the former, you need to be sure that the change persists when you update Dynamics CRM.

The later seems to be better because you don't need to modify the web.config and only if Microsoft doesn't remember to change the handler name and its location.

Either way, it's best if you check it after updating Dynamics CRM.

Everything is running now on port 443.

taborda
  • 11
  • 4