You’re offline. This is a read only version of the page.
545
Trying to configure WAP/ADFS (on Server 2016) with Dynamics 365 9. I cannot get WAP to work correctly. The internal URL https://intenalcrm.domain.com is DNS resolved to the internal CRM server on an internal IP address.
If I open the ADFS server to the internet through port 443 and NAT (for ADFS use), and the CRM server to the internet through port 443 (for org/dev/auth), both the internal and external URLs work correctly.
When I add the WAP server they fail. I've performed all the WAP steps (publish org/auth/dev URLs, set DisableTranslateUrlInResponseHeaders to true) that I aware of. From my reading the external IP address and DNS entries for BOTH the ADFS and CRM services should point to the WAP server in this configuration (after NAT). Is this correct as it fails for me.
If I set the external ADFS IP address to the WAP server and leave the external CRM addresses pointing at the CRM server, the external URLs work, but not the internal. I suspect this is not the correct configuration though.
Any feedback is appreciated.
It is working. I believe what I had to do was add external names to the hosts file on the WAP server that mapped to internal IP addresses such as below. These are internal IP addresses, not external, with external names. The hosts file is searched before DNS in name resolution. I no longer do this because I changed to a split brain DNS so the external names could be retuned as internal addresses internally but as Internet addresses externally. You may want to see if this helps.
172.18.8.82 adfs.domain.com
172.18.8.83 auth.domain.com
172.18.8.83 dev.domain.com
172.18.8.83 org.domain.com
After going back and forth for almost a month on this issue, Microsoft has told me that using ADFS 2016 with Dynamics 365 9.0.12 is unsupported although the article below seems clearly to state otherwise. They said ADFS 2016/WAP is only supported for strictly IFD deployments, not both IFD and internal deployments. This is hard to believe.
docs.microsoft.com/.../software-requirements-for-microsoft-dynamics-365-server
Not yet. I have a MS case open. I will definitely provide information once we figure it out.
Any updates on this till now? :-)
Hello Simdoc,
Thanks again for reaching back. I meant to use the original federation service name of your ADFS farm while re-configuring the WAP if that would be required as I am assuming that you used some other names while configuring the WAP with ADFS initially. (Please correct me if I am wrong here )
The details of which can be checked on to the ADFS box using Get-AdfsProperties
Additionally, since we are getting 404 not found while accessing the CRM Auth endpoint externally, I can think of these possible actions.
Is the CRM IIS website has any additional bindings other than standard 443 or the custom port we chose to go with (It is not supported to have more than one binding or use Host Header configurations with CRM IIS website). If there are, please remove them and perform IIS reset, reconfigure claims and IFD, update the ADFS relying parties.
If we go to the ADFS CRM IFD relying party and check the list of the identifiers within the "Identifiers" tab, does that show CRM Auth endpoint URL?
Is the CRM front-end server have any other IIS website or any other web services hosted on to it and it has any conflicts with the standard 443 port or non-standard port we are using, if it is, let's ensure that they do not pose any such conflicts.
I am hopeful that CRM and ADFS/ADFS proxy services are not hosted on to the CRM server, if it is we may consider to change the ADFS port using :: (Not a recommended practice)
Set-ADFSProperties -nettcpport 80x (Requires ADFS service restart).
In case, everything mentioned above looks okay, chances are that the CRM IIS rewrite module could have been gone into a problematic state. CRM creates rules within the rewrite module; one of these rules is to load the handlers/FederationMetadata.ashx when Federation Metadata/2007-06/FederationMetadata.xml is requested.
We may run a repair of this Rewrite module from the CRM server through "Programs and features". And apply a server reboot.
Thanks,
Saurabh
What do you mean by "And before doing all the above most importantly, let's configure WAP to use the original external Federation Service name used to configure the primary ADFS endpoint on your farm"? Do you not mean sts.domain.com the name I am using? The sts.int.domain.com is not used in any URL's or in the hosts file of the WAP server. It's only the internal name of the system.
I already have a case filed with Microsoft. Unfortunately that is not a fast process for something like this even though I am a premier customer.
I will definitely post back any results.
Hey Simdoc,
Thanks for reaching back. Let's do one thing if you are okay with it.. We will go with the simplest implementation through WAP where the External URL and the Back-end sever URL remains same, we will only publish CRM relevant endpoint URLs like org, auth., reconfigure DNS a records to point them to the WAP and then apply Disable URL Translation for them to see if at least this works for us. And before doing all the above most importantly, let's configure WAP to use the original external Federation Service name used to configure the primary ADFS endpoint on your farm initially, I believe this is one thing that is breaking the auth with CRM web app.
In any of the scenarios, as you had pointed out earlier on this thread, the CRM Auth metadata endpoint URL should be accessible. Once the above configuration which is kind of a general documented approach to put the WAP in place in order to publish CRM web application works we may gradually try to push towards the current set of configurations to see what exactly breaks this.
We know that CRM auth URL issues a domain cookie and redirects to the org URL and this domain cookie gets scoped to *.contoso.com. and I guess we just need to keep this thing in mind that we are not switching back to any other domains or going beyond one level of subdomains during the course of this entire request/response paradigm for the authentication process.
In case, the above general implementation of WAP doesn't work for you, please open a support request with Microsoft so that this can be thoroughly looked into from ADFS/WAP and CRM standpoint.
Thanks,
Saurabh
Saurabh thanks for the feedback. Isn't the internal FQDN always going to be different than the external? I thought that was the reason for the hosts file so that you could direct an external ADFS name needed to configure WAP to the internal IP address because DNS would provide the external IP. Since hosts is used before DNS, WAP should find the internal IP address for the external name. All URLs use the external FQDN.
I understand the wildcard does not cover *.int.domain.com, but it does cover the name of the farm.
Hey Simdoc,
Thanks for reaching us back. You see this error ::
The Federation Service Proxy blocked an illegitimate request made by a client, as there was no matching endpoint registered at the proxy. This could point to a DNS misconfiguration, a partially configured application published through the proxy, or a malicious request.
Url Path: auth.domain.com:443/.../FederationMetadata.xml.
And moreover, your ADFS farm name is different than the internal name being used to access the federation service as pointed by you over here ::
3) ADFS server internal address: 172.18.8.88/21. The internal DNS name is sts.int.domain.com. Mapped to sts.domain.com/172.18.8.88 in the WAP server hosts file. The name of the ADFS farm is sts.domain.com.
One more thing that I noticed in your comment is the domain names covered by your wild card cert and the name being used to access the internal ADFS service has some serious conflicts unless you missed to add any other details.
The wildcard certificate only covers one level of subdomains and hence certs for *.domain.com & domain.com will not cover sts.int.domain.com.
I would recommend checking the certificate and URL name spaces being used once again and we should also use the same URL on the internal network which is being used for the ADFS farm sts.domain.com as this has been known to cause the above exception like it has been talked over here ::
Thanks,
Saurabh
#1
Daivat Vartak (v-9d...
225
Super User 2025 Season 1
#2
Eugen Podkorytov
106
#2
Muhammad Shahzad Sh...
106
Most Valuable Professional
Share
Report
All responses (
Answers (
