Customer experience | Sales, Customer Insights,...

WAP/ADFS IP address/DNS question

(1) Share

Report

Posted on by Michael Hlavinka

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.

I have the same question (0)

All responses (13)

Answers (0)

Suggested answer

saurabhtiwarii on at

Like (0)

Report
Hello,

Yes, your configuration very much appears to be accurate. One thing that doesn't seem right is the internal URL configuration, it is not supposed to be published externally as they are internal and should only remain resolvable on to your internal network. If you have mistakenly published this URL on WAP and applied DisableTranslateUrlInResponseHeaders on this, please roll these changes back.

The external DNS configuration should look like this ::

External DNS ::

...Please do not use CNAME type resource record for resolving internal/external names to IP addresses of the end server resources....

Our external DNS records for each of these URLs must point to the WAP server IP address.

External Org URL

Auth URL

Dev URL

ADFS URL

Additionally, I would recommend you to go through this WAP configuration documentation for CRM on-premises which includes step by step configurations with screenshots.

https://docs.microsoft.com/en-us/archive/blogs/dynamicspts/using-web-application-proxy-to-publish-dynamics-crm-2013-to-the-internet

Please mark my comment as answered if this helps.

Thanks,

Saurabh

Was this reply helpful? Yes No
David Jennaway 14,065 on at

Like (0)

Report

If you still have problems, can you give more details on how it fails. Is it name resolution (if so to which name, and in which configuration), or do you get errors from either the ADFS or CRM pages (and if so, what are they ?). It's also useful to see the full query string of any pages that display errors

Was this reply helpful? Yes No
Michael Hlavinka 545 on at

Like (0)

Report

Thanks for your responses! To make life simple, I put everything on the internal network so all firewalls and NAT are eliminated. When I attempt to open the federation external URL https;//auth.domain.com/FederationMetadata/2007-06/FederationMetadata.xml I get a 404 not found error. I suspect that is the major issue.   The internal https://internalcrm.domain.com/FederationMetadata/2007-06/FederationMetadata.xml is successful. I notice this event in the WAP server:

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: https://auth.domain.com:443/FederationMetadata/2007-06/FederationMetadata.xml.

ADFS Debug tracing shows this event:

Blocking the request for 'auth.domain.com:443/.../FederationMetadata.xml', Allowed Host Names: EnterpriseRegistration.domain.com,EnterpriseRegistration.int.domain.com,sts.domain.com

The name auth.domain.com:443 is published in WAP and appears to be registered on the proxy as indicated by the command: netsh http show ssl

Here is the DNS info and IP addresses:

1) WAP server address: 172.18.8.87/21

2) Internal CRM server IP Address: 172.18.8.90/21 DNS A record for internalcrm.domain.com set to 172.18.8.90.

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.

4) DNS A record for ADFS: sts.domain.com/172.18.8.87

5) DNS A record for CRM auth: auth.domain.com/172.18.8.87

6) DNS A record for CRM dev: dev.domain.com/172.18.8.87

7) DNS A record for CRM org: org.domain.com/172.18.8.87

8) I'm using a wildcard cert with the 2 SANs: *.domain.com, domain.com

Here is the application information in the proxy:

PS C:\windows\system32> Get-WebApplicationProxyApplication | fl name,*id*,*url*

name                                 : auth.domain.com
ADFSRelyingPartyID                   :
BackendServerCertificateValidation   : None
ID                                   : 9b265660-73b9-63b0-eb0b-bbe2ebdb1ed9
BackendServerUrl                     : https://auth.domain.com/
DisableTranslateUrlInRequestHeaders : False
DisableTranslateUrlInResponseHeaders : True
ExternalUrl                          : https://auth.domain.com/

name                                 : dev.domain.com
ADFSRelyingPartyID                   :
BackendServerCertificateValidation   : None
ID                                   : 4384c29d-e413-1203-43fa-f9ced6b1f299
BackendServerUrl                     : https://dev.domain.com/
DisableTranslateUrlInRequestHeaders : False
DisableTranslateUrlInResponseHeaders : True
ExternalUrl                          : https://dev.domain.com/

name                                 : org.domain.com
ADFSRelyingPartyID                   :
BackendServerCertificateValidation   : None
ID                                   : f1f5531a-41ba-b143-6041-4fec8370e699
BackendServerUrl                     : https://org.domain.com/
DisableTranslateUrlInRequestHeaders : False
DisableTranslateUrlInResponseHeaders : True
ExternalUrl                          : https://org.domain.com/

Was this reply helpful? Yes No
Suggested answer

saurabhtiwarii on at

Like (0)

Report

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 ::

https://jaredmeredith.com/2015/11/30/getting-event-id-144-on-your-web-application-proxy-when-trying-to-connect-to-adfs/

Thanks,

Saurabh

Was this reply helpful? Yes No
Michael Hlavinka 545 on at

Like (1)

Report

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.

Was this reply helpful? Yes No
Suggested answer

saurabhtiwarii on at

Like (0)

Report

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

Was this reply helpful? Yes No
Michael Hlavinka 545 on at

Like (1)

Report

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.

Was this reply helpful? Yes No
Suggested answer

saurabhtiwarii on at

Like (0)

Report

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

Was this reply helpful? Yes No
saurabhtiwarii on at

Like (0)

Report

Any updates on this till now? :-)

Was this reply helpful? Yes No
Michael Hlavinka 545 on at

Like (1)

Report

Not yet. I have a MS case open. I will definitely provide information once we figure it out.

Was this reply helpful? Yes No