Dynamics Community Forum Thread Details

IFD Configuration Question

Hello,

We have the standard Internal and External IFD access setup for our CRM. We have internalcrm.domain.com URL for internal and the orgname.domain.com for the IFD external access.

We have a requirement to add a SAN for the external access in addition to the standard orgname.domain.com.

We added the SAN to our certificate on the IIS server. e.g. mobilecrm.domain.com

When we navigate to this SAN mobilecrm.domain.com on our internal network, it resolves to the internalcrm.domain.com URL and authenticates without prompting the ADFS login page.

This isn't what we want. We want the SAN URL to work like the standard orgname.domain.com IFD URL and bring up the ADFS login page. We can't figure out how to do this.

Is it possible to add a SAN in addition to the standard "orgname"? Relevant section from guide: "With the example settings above, if your organization name was "orgname", clients would access your Microsoft Dynamics CRM website with the following URL: https://orgname.contoso.com."

Any ideas on what we are doing wrong? Thank you.

Hey Chibby,

Thanks for reaching Dynamics community. It very much appears that you are talking about using CNAME/Alias DNS type records usage in order to access Dynamics 365 CE orgs. I will talk about the internal and the external (IFD) name resolution configurations separately which may help you to understand why exactly we do not recommend the usage of CNAMES/Alias.

Internal (Claims based access) ::

The internal CRM URL looks like internalcrm.contoso.com/CRM/main.aspx#376420107 and you can see that the org unique name gets appended in the front of the whatever name/URL we chose (internalcrm.contoso.com) to configure dynamics 365 for internal access.

So the unique name of the org doesn't affect the URL, internalcrm.contoso.com

If we use CNAMEs/Alias records which maps them to internalcrm.contoso.com, this works fine as expected within the standard browsers like IE, Chrome etc however, the CRM SDK tools would fail to connect to CRM using these CNAMES and in such case you will have to use the original internal CRM URL.

External Access (IFD) ::

Well this changes the game completely as now the unique name of the org becomes a part of the URL and it would uniquely call one of the many CRM orgs hosted under the CRM deployment deployment.

https://crmorg1.contso.com, https://crmorg2.contoso.com

If we chose to access CRM externally using CNAME/Alias or even A type DNS records in order to access these orgs with a different name ADFS would serve us with this exception ::

Example case ::

https://crmorg2.contoso.com is being accessed through https://cname.contoso.com where

1. crmorg2.contoso.com points to cname.contoso.com using a CNAME/Alias type DNS record.

2. We are pointing the IP address of CRM server directly to cname.contoso.com using A type DNS record.

In any of the above two cases, we will get an error on to the ADFS log page with an exception MSIS7007: The requested relying party trust 'https://cname.contoso.com/' is unspecified or unsupported.

We might be able to workaround this issue by manually adding the new URL as identifier within CRM ADFS relying party as ::

Post escaping the error on to the ADFS log on page, we will now be served with this exception from CRM ::

Error Details: ID1038: The AudienceRestrictionCondition was not valid because the specified Audience is not present in AudienceUris.
Audience: 'https://cname.contoso.com/'

There might be ways to escape this as well using set of URIs that are acceptable identifiers of the relying party (RP) however, this is nowhere tested/documented and hence I wont recommend moving forward with such implementation.

https://docs.microsoft.com/en-us/dotnet/framework/configure-apps/file-schema/windows-identity-foundation/audienceuris

Please mark my comment as answered if this helps. :-)

Thanks,

Saurabh

Quick Links

Subscribe to this forum!