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

All responses (16)

Answers (0)

MattB-MSFT on at

Like (0)

Report

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

This can happen if your tenant is configured for MFA only auth ( which requires the oAuth flows )

all of our shipping tools use oAuth now and have for quite a while.

if your tenant is requiring MFA for user auth ( or Legacy auth is disabled or conditional auth is enabled ), You will need to create an AppID and use that as part of your constructor or connection string flows.
Manuesev 115 on at

Like (0)

Report

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

[quote user="Tim Dutcher"]
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
[/quote]
In large organizations, it is not uncommon that network configuration adds some difficulties at our activities.

Try with this in your App.config:

<system.net>
<defaultProxy useDefaultCredentials="true">
</defaultProxy>
</system.net>
ALTOSHAAM 180 on at

Like (0)

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

ServicePointManager.SecurityProtocol = SecurityProtocolType.Tls12;

This helped me a lot, thanks Bashar Sadig!

One thing to notice - this issue appears for me only when I'm launching my code on old versions of Windows (Win Server 2008 R2, Win 7).
New versions of Windows (Win 10 for example) - seem to have TLS enabled by default and don't require this line. But there is no harm to keep it for them also.
Suggested answer

Community Member Microsoft Employee on at

Like (3)

Report

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

Took Over a Month to Figure It Out: Unable to Connect to CRM After Upgrade. The Reason is that SecurityProtocolType.Tls12 Must Be Provided Before Calling XRM Underlying Code. This is due to Changes to the .NET Framework and the Fact that XRM Tooling somehow uses telemetry.

Using XRM Tooling to Connect to Dynamics CRM 365 - Online, Once You Upgrade From Earlier (Pre 8.x), You Will Get This Error

Error Title:
Unable to Login to Dynamics CRMOrganizationServiceProxy is nullOrganizationServiceProxy is null OrganizationServiceProxy is null

Root Cause:
(TLS 1.2 is NOT negotiated in .NET 4.7 without explicit ServicePointManager.SecurityProtocol call)

I Found the Fix to Be As Follows (Thanks to Microsoft Brightest Mrs. - Swarnavalli Microsoft 365 Development Team):

LastCrmError = "Unable to Login to Dynamics CRMOrganizationServiceProxy is nullOrganizationServiceProxy is null OrganizationServiceProxy is null"

1. Fix Step 1 - Get Nuget Packages for Verion 9.0 of the Dynamics CRM From This Location

www.nuget.org/.../Microsoft.CrmSdk.XrmTooling.CoreAss
embly/

Install the Nuget Package(PM > Install-Package Microsoft.CrmSdk.XrmTooling.CoreAssembly -Version 9.0.0.7)

2. Fix Step 2 - Clean Up All Your Visual Studio Development Not to Use Older Versions of CRM SDK (Use .NET Framework 4.6x or 4.7). Add required XRM Dlls Back for Newest Version - V9 for Me Now)

3. Fix Step 3 - Specify Protocol Right Before You Make Calls TO XRM Tooling DLL. Add a Line to Your C# or Dot Net Code.

ServicePointManager.SecurityProtocol = SecurityProtocolType.Tls12;

Add (ServicePointManager.SecurityProtocol = SecurityProtocolType.Tls12;) Somewhere in your Project. As Proof of Concept, Add It Before You Call the Connect to CRM Constructor

m_CrmServiceClient = new CrmServiceClient(LoginUserName, CrmServiceClient.MakeSecureString(LoginPassword), OrganizationRegionName, OrganizationName, useUniqueInstance, useSsl, orgDetail, isOffice365);

This Has Taken Near 1 Month to Figure It Out. With Many Many Calls to Microsoft (Thanks Largely to Microsoft Brightest Mrs. - Swarnavalli Microsoft 365 Development Team)

Bashar Sadig
MattB-MSFT on at

Like (0)

Report

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

[quote user="Tim Dutcher"]

That's all helpful information. But note that while the customer had CRM 2016 Online, the use of a connection string with the 2016 SDK tooling assemblies worked fine. They upgraded to Dynamics 365 without telling us and called when their integrations stopped working. The error was related to inability to connect/authenticate to Dynamics 365.

It's a large corporation and their IT dept said they did not make any changes to the AD/O365 sync'd service account nor did they change anything in ADFS.

So, I recompiled their apps using the D365 SDK (new tooling classes) and added the new AuthType=O365 to the connection string and the account still could not connect.

[/quote]

And That's why Im asking for the SR#,, if you were using the XRMTooling.Connector before and the customer updated it should have continued to work w/out issue. if you were using the Xrm.Client API before the connection string pattern is different between the too, but it still should have worked just fine.

if you could Private message me the name of the customer I might be able to look up the SR number.

I want to discuss this with the support engineer in question to determine what was really going on as it didn't get raised back to dev.
Tim Dutcher 2,100 on at

Like (0)

Report

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

That's all helpful information. But note that while the customer had CRM 2016 Online, the use of a connection string with the 2016 SDK tooling assemblies worked fine. They upgraded to Dynamics 365 without telling us and called when their integrations stopped working. The error was related to inability to connect/authenticate to Dynamics 365.

It's a large corporation and their IT dept said they did not make any changes to the AD/O365 sync'd service account nor did they change anything in ADFS.

So, I recompiled their apps using the D365 SDK (new tooling classes) and added the new AuthType=O365 to the connection string and the account still could not connect.

I don't have the insight that you do as to why the 2016 tooling library could no longer connect after the upgrade nor why the D365 libraries also do not work. What would be helpful is to provide the source code to the tooling libraries so that we can see precisely how the components are attempting to connect. In this case, I could step through and determine why the PRT can connect and the use of a connection string (one that used to work) can no longer connect. The log files aren't very helpful to troubleshoot this particular problem. And the exception back from CrmServiceClient is basically "could not connect", with no details about the problem.

99% of our clients use an O365 cloud-only service account for integrations, etc. so this hasn't been a big problem. Like I said before, the company created a new O365 account and they were then good to go using a connection string.
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.
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.
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.
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)