Problem connecting to Dynamics 365 with Microsoft.Xrm.Tooling.Connector

(0) Share

Report

Posted on by Tim Dutcher

2,100

I'm attempting to connect to a Dynamics 365 (CRM) Online org using an AD account that's integrated with Office 365. E.g., service_account@contoso.com

Using the plugin registration tool, I can login with the account fine. I can also login to the CRM Web UI with the account.

However, the login fails using the Microsoft.Xrm.Tooling.Connector class (with a connection string, where AuthType=Office365) and it also fails with the sample tooling WPF application that's included with the CRM SDK.

I ran Fiddler and it shows that the plugin registration tool follows a different path as the tooling WPF applications.

Has anyone else experienced the inability to use the tooling class/apps to connect to online with AD-connected Office 365 accounts?

Thanks,

-Tim

*This post is locked for comments

I have the same question (0)

All responses (16)

Answers (0)

a33ik 84,331 Most Valuable Professional on at

Like (0)

Report

RE: Problem connecting to Dynamics 365 with Microsoft.Xrm.Tooling.Connector

Hello Tim,

Can you please provide connection string you use to connect to Dynamics365?

Was this reply helpful? Yes No
Suggested answer

Community Member on at

Like (0)

Report

RE: Problem connecting to Dynamics 365 with Microsoft.Xrm.Tooling.Connector

I have used this:

CrmServiceClient crmSvc = new CrmServiceClient("Url=orgname.crm8.dynamics.com;AuthType=Office365;UserName=username; Password=Password;");

if (crmSvc.IsReady)

{

IOrganizationService service = crmSvc.OrganizationServiceProxy;

}

Was this reply helpful? Yes No
Tim Dutcher 2,100 on at

Like (0)

Report

RE: Problem connecting to Dynamics 365 with Microsoft.Xrm.Tooling.Connector

Here are two examples of what I've tried.

This AD/Office365 connected account does not connect using "tooling":

Url=customer.crm.dynamics.com; AuthType=Office365; Username=CRMInt@customer.com; Password=password

The IsReady property of the CrmServiceClient is false and the message simply says that it cannot login.

This one connects fine:

Url=customer.crm.dynamics.com; AuthType=Office365; Username=Tim.Dutcher@customer.onmicrosoft.com; Password=password

The plug-in registration tool can connect using both accounts but the tooling assembly and tooling-based WPF apps that Microsoft provides can't connect with the AD/Office365 account.

Was this reply helpful? Yes No
Gopalan Bhuvanesh 11,401 on at

Like (0)

Report

RE: Problem connecting to Dynamics 365 with Microsoft.Xrm.Tooling.Connector

--

Was this reply helpful? Yes No
Suggested answer

Tim Dutcher 2,100 on at

Like (0)

Report

RE: Problem connecting to Dynamics 365 with Microsoft.Xrm.Tooling.Connector

We ended up contacting Microsoft Support. They said there's a bug ("limitation") in the tooling libraries for some ADFS configurations. Our client did not want to change ADFS for purposes of using Dynamics 365 online so we ended up creating a new Office 365 (cloud only) account to use for the integration.

Was this reply helpful? Yes No
MattB-MSFT on at

Like (0)

Report

RE: Problem connecting to Dynamics 365 with Microsoft.Xrm.Tooling.Connector

Can you PM me the Ticket number you were working under please.

also so I'm clear,

You used the CRMInt@customer.com in PRT using the online login type and it let you pass, but when you passed that to the connection string it did not let you pass?

if so can you Open the LoginControlTester.exe in the SDK and try it.. if it works can you share the LoginControlTester.log file, that will tell us what path its using.

Was this reply helpful? Yes No
Tim Dutcher 2,100 on at

Like (0)

Report

RE: Problem connecting to Dynamics 365 with Microsoft.Xrm.Tooling.Connector

Here are two sets of log entries. The first is from the PRT and the second set is typical of what we're getting when trying to use the Xrm.Tooling assemblies (the latest from Nuget) in a console app with a connection string. From the log output, it's pretty clear that the Xrm.Tooling assemblies that the PRT and other Windows apps use in the SDK are not the same assemblies that Microsoft provides via the Nuget package. The interactive tooling login connector works and the connection string approach does not.

Plug-in Registration Tool Log (successful connection):

DiscoverOrganizations - Initializing Discovery Server Object with disco.crm.dynamics.com/.../Discovery.svc

AuthenticateService - find authority with name login.windows.net/.../authorize

DiscoverOrganizations - Discovery Server Get Orgs Call Complete - Elapsed:00:00:04.9924629

User Specified Org details are used.

Found 1 Org(s)

Microsoft.Xrm.Tooling.Connector.CrmServiceClient Verbose: 16 : DiscoveryServer indicated organization service location = contoso.api.crm.dynamics.com/.../Organization.svc

Organization Service URI is = contoso.api.crm.dynamics.com/.../Organization.svc

ConnectAndInitCrmOrgService - Initializing Organization Service Object

ConnectAndInitCrmOrgService - Requesting connection to Org with CRM Version: 8.2.1.176

AuthenticateService - find authority with name login.windows.net/.../authorize

ConnectAndInitCrmOrgService - Proxy created, total elapsed time: 00:00:00.9081282

User Org (crmNAorg05099) found in Discovery Server - ONLY ORG FOUND

Beginning Validation of CRM Connection

Validation of CRM Connection Complete, total duration: 00:00:01.0035615

Example of failed connection using Xrm.Tooling assemblies with various connection strings:

Microsoft.Xrm.Tooling.Connector.CrmServiceClient Information: 8 : Using User Specified Server

Microsoft.Xrm.Tooling.Connector.CrmServiceClient Information: 8 : Trying Live Discovery Server, (North America) URI is = disco.crm.dynamics.com/.../Discovery.svc

Microsoft.Xrm.Tooling.Connector.CrmServiceClient Information: 8 : DiscoverOrganizations - Initializing Discovery Server Object with disco.crm.dynamics.com/.../Discovery.svc

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

Microsoft.Xrm.Tooling.Connector.CrmServiceClient Verbose: 16 : DiscoverOrganizations - created CRM server proxy configuration for disco.crm.dynamics.com/.../Discovery.svc - duration: 00:00:00.3812132

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

Microsoft.Xrm.Tooling.Connector.CrmServiceClient Error: 2 : Source : mscorlib

Method : HandleReturnMessage

Date : 5/5/2017

Time : 9:44:40 AM

Error : There was no endpoint listening at fs.contoso.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)

Was this reply helpful? Yes No
MattB-MSFT on at

Like (0)

Report

RE: Problem connecting to Dynamics 365 with Microsoft.Xrm.Tooling.Connector

They are the same libs.

PRT defaults to use oAuth for authentication, so the flow is appears to be different.

By chance is the AAD instance setup to require MFA for the DirSynced Accounts?

Did you use the CRMInt@customer.com in PRT using the online login type and it let you pass, but when you passed that to the connection string it did not let you pass?

If so can you Open the LoginControlTester.exe in the SDK and try it.. if it works can you share the LoginControlTester.log file, that will tell us what path its using.

Was this reply helpful? Yes No
Tim Dutcher 2,100 on at

Like (0)

Report

RE: Problem connecting to Dynamics 365 with Microsoft.Xrm.Tooling.Connector

I'll need to check with our client about MFA and to get the support ticket. They created the new O365 account to use for CRM and have moved on to other issues.

The bottom line is that PRT and LCT connects with the sync'd account but no connection string that we could come up worked to connect.

Can you explain why PRT can connect but using a connection string (using the same library, as you mentioned) doesn't work? I would expect that the library would go down the same logic path to make the connection, regardless of whether it's running in conjunction with Microsoft.Xrm.Tooling.CrmConnectControl or by using it directly in code.

Thanks for your interest in helping to resolve this.

Was this reply helpful? Yes No
MattB-MSFT on at

Like (1)

Report
RE: Problem connecting to Dynamics 365 with Microsoft.Xrm.Tooling.Connector

Sure,

The CrmServiceClient is what is used by all the current devtools and utilities we provide, each tool has the ability to work with it in a number of different ways, based on the situational and connection needs.

In the case of PRT, CMT, DevTools, and optionally, the cmdline utilities and powershell, the Login Control is invoked to provide a easier way for login to happen. the Login control itself has a lot of code in it to sort out what you 'meant' to do vs what you actually selected. Also all the tools we provide are preconfigured to use oAuth as the primary auth process, with a fall back mechanic to WS-TRUST if required.

The documentation here: https://msdn.microsoft.com/en-us/library/microsoft.xrm.tooling.connector.crmserviceclient.aspx outlines all the possible ( current ) constructors that are available for the CrmServiceClient.

In the case of the PRT, the login control ultimately calls this method :

onLine: https://msdn.microsoft.com/en-us/library/mt608171.aspx

Were you do the same invocation via a connect string, you would use this form of the connection string:

connectionString="AuthType=OAuth;Username=jsmith@contoso.onmicrosoft.com; Password=passcode;Url=contosotest.crm.dynamics.com;AppId=<GUID>;RedirectUri =app://<GUID>;TokenCacheStorePath =c:\MyTokenCache;LoginPrompt=Auto"

This would cause the system to attempt a oAuth login using the provided client ID and pop a MFA Login UX if required.

If you needed to do a silent login, you would set LoginPrompt=never

This process also deals with SSO cleanly via AAD. which is how I think your customer is setup based on your behavior description.

Were you to want to replicate this, You would need to set up a native client application in the AAD instance for the Tenant, then pass the client ID and redirect URI of that application into the connection string + the user account and PW.

However it "should" work with Office365 as well, unless the customer has either not properly configured the relaying parties on their AAD tenant or they have explicitly blocked WS-TRUST

Hope that helps explain whats going on here.

Was this reply helpful? Yes No