Connect to CRM 2015 via SDK and IFD fails ADFS Authentication Unless Port 80 Inbound is Opened for ADFS

(0) Share

Report

Posted on by Community Member

We found in order to get the CRM SDK (2016 version of the SDK) to connect to our CRM 2015 organization (discovery service) through the IFD we needed to open inbound port 80 to ADFS. This puzzled us since we intended everything to work through port 443 and https. Oddly before we opened port 80 we could fully login to the CRM application from outside our network through the IFD and fully authenticated through ADFS. While logging into CRM through the IFD we noticed the ADFS authentication URL was https://adfs.....

In looking at the error log file for the SDK connector tool (tried from Visual Studio, Plugin Registration Tool or LoginControlTester.exe) we always found the connection attempt found the discovery service but while attempting to authenticate via ADFS was trying to use http://adfs...... We looked at the discovery service in detail and found the <ms-xrm:SecureTokenService> section of the xml to contain http://adfs... We further found in the wsx:MetadataReference section to contain https://adfs...../trust/mex.

From this we figured, fine, we need to revisit our IFD setup in CRM and also recheck settings in ADFS. We tried a lot of different things and had trouble getting the discovery service <ms-xrm:SecureTokenService> section of the xml to contain https://adfs.... I'm almost certain a few times we got the <ms-xrm:SecureTokenService> section to contain https://adfs... but the CRM SDK connector still reported the authentication failed because the endpoint http://adfs.... could not be resolved.

Finally we resorted to simply opening inbound port 80 to ADFS in our firewall. When inbound port 80 is open the CRM SDK connector works fine and connects to the environment. However we don't feel completely comfortable leaving it this way. I have read a few articles saying ADFS requires outbound port 80 open for certificate validation but I haven't read anything further to absolutely state inbound port 80 is OK and needed for ADFS. It just seems like the whole system should operate primarily over port 443 and https.

I thought I would post this to see if anyone else has run into this issue with the CRM SDK and an IFD. Remember before we opened inbound port 80 the CRM application itself was working fine and using https for ADFS.

You might say why are we concerned about connecting the SDK from outside the network and that would be a good question. Our actual need to make the SDK connection work from the outside and through IFD was to prepare for our installation of Click Dimensions and Click Dimensions works via connectivity from/to the Cloud.

Thanks for reading and any insight is much appreciated!

*This post is locked for comments

I have the same question (0)

All responses (9)

Answers (0)

Aric Levin - MVP 30,190 Moderator on at

Like (0)

Report
Copy link

Link copied!

Hi,

This should not be the case.

Port 80 should not be open, and should be able to access the CRM environment using the v8 SDK on port 443 only.

Can you provide more details about your error?

Also, on your CRM and IFD servers, in IIS, is the web site bindings configured to port 443 only or both port 443 and 80?

In your CRM Server, in deployment wizard, when you go to the properties of the server (Dynamics 365), on the web address tab, in the binding type configured as HTTPS?

I would also check if there are any other errors in the event viewer on the CRM Server or on the ADFS Server.

Please check and maybe this can shine some light.

Was this reply helpful? Yes No
Tony Amaral 190 on at

Like (1)

Report
Copy link

Link copied!

Hi Mark

You should only have to open port 443. That's all we have open and we can for example connect with the plugin registration tool from outside without any problems.

Sometimes if you install Windows updates on the crm and AD servers and you have to restart the servers or some sort of maintenance you might get the ADFS and the crm IFD out of sync.

Most of the time doing an iisreset in the crm server and then opening the Deployment Manager and just click Next on the Configure Claims-Based Authentication and Configure Internet-Facing Deployment.

Go to the ADFS server, select each of the crm's relying party and do an Update from Federation Metadata to see if that helps.

Was this reply helpful? Yes No
Community Member on at

Like (0)

Report
Copy link

Link copied!

Thanks Aric. Below is a clip from the error log of the LoginControlTester.exe SDK component in the Bin folder. We are going to check what you suggested. What puzzled us is where the SDK Login component was getting the URL for the ADFS authentication. Is it coming from the IFD configuration or the ADFS setup? I'm primarily working with our network administrator. I think this morning we did see where the CRM site in IIS was bound to both port 80 and 443. Thanks again for your reply. Appreciate any other info if you can provide. Will follow up if we find anything based on this input.

Microsoft.Xrm.Tooling.CrmConnectControl Information: 8 : Created CrmConnectionManager

Microsoft.Xrm.Tooling.CrmConnectControl Information: 8 : CheckBoxState = False

Microsoft.Xrm.Tooling.CrmConnectControl Error: 2 : Error Message: Exception logged by the CRM Connector control:

Source   : Not Provided

Method : Not Provided

Date       : 8/7/2017

Time       : 4:16:43 PM

Error      : A CRM server name is required.

Parameter name: CrmServerName

Stack Trace          : Not Provided

======================================================================================================================

Microsoft.Xrm.Tooling.CrmConnectControl Information: 8 : You must specify a CRM Server to connect too

Microsoft.Xrm.Tooling.CrmConnectControl Information: 8 : CheckBoxState = False

Microsoft.Xrm.Tooling.CrmConnectControl Information: 8 : SetConfigKeyInfo, Key Count = 14

Microsoft.Xrm.Tooling.CrmConnectControl Information: 8 : Login Status in Connect is = Connecting to the Microsoft Dynamics CRM server...

Microsoft.Xrm.Tooling.CrmConnectControl Information: 8 : Using CRM deployment type Prem

Microsoft.Xrm.Tooling.CrmConnectControl Information: 8 : SSL Connection = True

Microsoft.Xrm.Tooling.CrmConnectControl Information: 8 : Discovery URI is = crmdev.racoindustries.com/.../Discovery.svc

Microsoft.Xrm.Tooling.CrmConnectControl Information: 8 : Login Status in Connect is = Initializing UII core connections to Microsoft Dynamics CRM...

Microsoft.Xrm.Tooling.CrmConnectControl Information: 8 : Login Status in Connect is = Connecting to the Microsoft Dynamics CRM server...

Microsoft.Xrm.Tooling.CrmConnectControl Information: 8 : Login Status in Connect is = Retrieving organizations from CRM...

Microsoft.Xrm.Tooling.Connector.CrmServiceClient Information: 8 : DiscoverOrganizations - Initializing Discovery Server Object with crmdev.racoindustries.com/.../Discovery.svc

Microsoft.Xrm.Tooling.Connector.CrmServiceClient Verbose: 16 : DiscoverOrganizations - attempting to connect to CRM server @ crmdev.racoindustries.com/.../Discovery.svc

Microsoft.Xrm.Tooling.Connector.CrmServiceClient Verbose: 16 : DiscoverOrganizations - created CRM server proxy configuration for crmdev.racoindustries.com/.../Discovery.svc - duration: 00:00:01.1426325

Microsoft.Xrm.Tooling.Connector.CrmServiceClient Verbose: 16 : DiscoverOrganizations - proxy requiring authentication type : Federation

Microsoft.Xrm.Tooling.CrmConnectControl Error: 2 : Error Message: Exception logged by the CRM Connector control:

Source   : mscorlib

Method : HandleReturnMessage

Date       : 8/7/2017

Time       : 4:17:36 PM

Error      : There was no endpoint listening at adfsdev.racoindustries.com/.../username that could accept the message. This is often caused by an incorrect address or SOAP action. See InnerException, if present, for more details.

Stack Trace          : Server stack trace:

   at System.ServiceModel.Channels.HttpOutput.WebRequestHttpOutput.GetOutputStream()

   at System.ServiceModel.Channels.HttpOutput.Send(TimeSpan timeout)

   at System.ServiceModel.Channels.HttpChannelFactory`1.HttpRequestChannel.HttpChannelRequest.SendRequest(Message message, TimeSpan timeout)

   at System.ServiceModel.Channels.RequestChannel.Request(Message message, TimeSpan timeout)

   at System.ServiceModel.Channels.SecurityChannelFactory`1.SecurityRequestChannel.Request(Message message, TimeSpan timeout)

   at System.ServiceModel.Dispatcher.RequestChannelBinder.Request(Message message, TimeSpan timeout)

   at System.ServiceModel.Channels.ServiceChannel.Call(String action, Boolean oneway, ProxyOperationRuntime operation, Object[] ins, Object[] outs, TimeSpan timeout)

   at System.ServiceModel.Channels.ServiceChannelProxy.InvokeService(IMethodCallMessage methodCall, ProxyOperationRuntime operation)

   at System.ServiceModel.Channels.ServiceChannelProxy.Invoke(IMessage message)

Was this reply helpful? Yes No
Community Member on at

Like (0)

Report
Copy link

Link copied!

Thanks Tony we will try

Was this reply helpful? Yes No
Tony Amaral 190 on at

Like (0)

Report
Copy link

Link copied!

Mark,

This part of the message if I'm not wrong pretty much confirms that you just need to update the IFD and the relying parts:

"There was no endpoint listening at adfsdev.racoindustries.com/.../username that could accept the message"

Was this reply helpful? Yes No
Aric Levin - MVP 30,190 Moderator on at

Like (0)

Report
Copy link

Link copied!

Hi Mark,

It seems like the issue is the the endpoint listening at adfsdev.../username

Can you please check your ADFS settings and make sure that everything is connected.

Also, is the username format that you are entering in your sdk application that same as the one that you are entering when you log into the application?

Are you using the domain field as well, or just username and password?

If you are using domain field to log in, don't. Enter the domain in the username field as domain\user or user@domain.com

Let me know if this helps.

Was this reply helpful? Yes No
Community Member on at

Like (0)

Report
Copy link

Link copied!

We're going to revisit this. We have found we still need port 80 open to support our click dimensions operation. We've secured it somewhat by white listing inbound IPs for port 80 for this server.

Was this reply helpful? Yes No
Community Member on at

Like (0)

Report
Copy link

Link copied!

We were able to resolve this by disabling the service endpoint /adfs/services/trust/13/username

We found our adfs implementation wasn't using this endpoint and this endpoint was trying to use port 80.

Was this reply helpful? Yes No
Community Member on at

Like (0)

Report
Copy link

Link copied!

We had a similar problem when trying to connect with the Plugin Registration Tool using IFD authentication. We found the following error in the log file:

There was no endpoint listening at http://ADFS Server FQDN/adfs/services/trust/13/username that could accept the message.

Also the CRM Outlook client and a custom developed web service were unable to authenticate over the internet if HTTP / tcp port 80 access to the ADFS server was disabled.

As also explained here and by Mark we had to disable the '/adfs/services/trust/13/username' endpoint on the ADFS server to resolve the issue:
http://blog.lerun.info/2016/12/04/crm-adfs-woes/

This endpoint is published over HTTP and conflicts with the usernamemixed and kerberosmixed endpoints, which are published over HTTPS and are the endpoints that we should be using for the CRM client applications.

Was this reply helpful? Yes No