How to fix Office 365 WS-Trust Authentication Deprecation and Regional Discovery Deprecation for Dataverse and Dynamics 365 Client Applications

Today I had a problem to solve, so went back to the tried and trusted method of firing up a console application to connect to a Dynamics 365 instance, to quickly run some tests to make sure that something I thought was possible, was actually possible.

In true old school style, I’ve still got a trusty boilerplate console application with a set of Nuget packages and libraries in place so I can do a variety of things quickly and easily without a lot of setup. These include log4net for logging, spkl for generating early bound code and other third party libraries and helper utilities.

The first lines of the Main method looked like this :

CrmServiceClient crmConn = new CrmServiceClient(_CrmConnectionString); var svcContext = new XrmSvc(crmConn); IOrganizationService crmService = crmConn.OrganizationServiceProxy; OrganizationServiceContext orgContext = new OrganizationServiceContext(crmService); WhoAmIRequest request = new WhoAmIRequest(); WhoAmIResponse response = (WhoAmIResponse) crmConn.Execute(request); _log.Info("Your UserId is {0}" + response.UserId);

When I ran the code, which pointed to an existing Dynamics 365 instance, it worked. So I made a few tweaks, regenerated my early bound classes and pointed them to another, Vanilla Dataverse instance with a different data model I was working with. This time, when I ran the code, I got a different result. When I debugged, I got a ‘Object reference not set to an instance of an object’ – it looked like the OrganizationServiceProxy was returning a null.

But when I repointed my app to point to my previous Dynamics 365 organization, things worked fine again. So what changed? The sort of things that went through my head were:

• Did I enter the wrong credentials in the app.config file and _CrmConnectionString was wrong?
• Did the regeneration of the early bound classes cause the problem?
• Was it a problem because I was now accessing a vanilla Dataverse app instead of a Dynamics 365 app?
• Was it because I was pointing to a Community Developer instance instead of a sandbox or production organization?
• Was it because I put the connection string in the orgname.api.crm.dynamics.com format instead of orgname.crm.dynamics.com format?
• Did I mess up the connection string format when I repointed the app?

When I then tried to connect to the Organization with XrmToolbox using the connection wizard, I also got the following error :

• Unable to connect to CRM: An error occurred when processing the security tokens in the message:You are using Ws-Tust authentication which has been deprecated and no longer supported in your environment. Please use oAuth2.0 authentication

After a bit of investigation, I tracked down the issue. It was partly related to the connection string and partly related to external factors related to the Dataverse organization itself.

The issue is directly related to the deprecation of Office365 / WS-Trust authentication for connections to Dataverse instances. WS-Trust and Office365 authentication are one and the same thing in this respect. This method of authentication is being removed for new tenants from 1st April 2021. It will be removed from ALL tenants – Dataverse or Dynamics 365 from April 2022.

Moving to OAuth will also fix any issue you have having related to the regional discovery service being deprecated too.

For more information, see this announcement, but here’s a summary of how to fix it for my scenario.

Step 1 – Update your connection string

The connection string in my app.config file which is read into _CrmConnectionString looked like this.

<add key="CrmConnectionString" value="AuthType=Office365;Url=https://myenvironment. crm11.dynamics.com/;Username=myuseraccount@test.onmicrosoft.com;Password=Pa55word"/>

As Office365 and WS-Trust authentication will no longer work on Organizations where Office365 has been deprecated, this had to be changed to use OAuth authentication as per below.

<add key="CrmConnectionString" value="AuthType=OAuth;Username= myuseraccount@test.onmicrosoft.com; Password=Pa55word;Url= https://myenvironment.crm11.dynamics.com;AppId=51f81489-12ee-4a9e-aaae-a2591f45987d; RedirectUri=app://58145B91-0C36-4500-8554-080854F2AC97;LoginPrompt=Never"/>

The additional parts of the connection string I’ve added above – for AppId and RedirectUri – are required. You can set up your own app registration for your own values for these, or you can just use the values above if it’s a throwaway app like mine. These are catch all values from Microsoft which will work everywhere. ‘Loginprompt=Never’ simulates the way Office365 authentication worked, but you could also set it to Always or Auto, which allows the user to specify the behaviour.

Step 2 – Get rid of OrganizationServiceProxy references

When I made the change I ran the console app again, but still got the same error. This is because my code was still referencing the CrmServiceClient.OrganizationServiceProxy property. There’s no need to reference this any more because CrmServiceClient implements IOrganizationService and exposes everything that is settable for the organization service proxy.

So, as well as updating the connection string, there was another minor tweak required. Here’s a comparison of my old and new code.

CrmServiceClient crmConn = new CrmServiceClient(_CrmConnectionString); IOrganizationService crmService = crmConn.OrganizationServiceProxy; OrganizationServiceContext orgContext = new OrganizationServiceContext(crmService);   WhoAmIRequest request = new WhoAmIRequest(); WhoAmIResponse response = (WhoAmIResponse) crmService.Execute(request); _log.Info(“Your UserId is {0}” + response.UserId); _log.Info(“Press any key to exit.”); Console.ReadLine();

Old

CrmServiceClient crmConn = new CrmServiceClient(_CrmConnectionString); var svcContext = new XrmSvc(crmConn);   WhoAmIRequest request = new WhoAmIRequest(); WhoAmIResponse response = (WhoAmIResponse) crmConn.Execute(request); _log.Info(“Your UserId is {0}” + response.UserId); _log.Info(“Press any key to continue.”); Console.ReadLine();

New XrmSrv is IOrganizationService in early bound class Xrm.cs

I’m guessing this is going to affect people more and more in the months ahead – probably a lot from 2022 onwards, so get ahead of the game and do an audit of any client application that use Office365 connection strings or OrganizationServiceProxy. Thankfully, this does not affect plugins or workflow activities. If by the time you read this you are using a 9.2 version of Microsoft.CrmSdk.XrmTooling.CoreAssembly, you may not need to change your connection string at all as this capability will be added to this release. I’m unfortunately still using 9.1 right now.

Update 23rd June : Some people have been asking me if this fix will also fix an issue people are having where the regional discovery service has been deprecated. The answer is yes, if you switch your Auth to OAuth, you will find that things work properly as the client will prefer global discovery – not regional discovery.

Further Reading

For further reading on this, here’s some helpful links. Please post any further details in the comments.

Link	Description
https://docs.microsoft.com/en-us/power-platform/important-changes-coming#deprecation-of-office365-authentication-type-and-organizationserviceproxy-class-for-connecting-to-dataverse	Original announcement of timetable of deprecation
https://docs.microsoft.com/en-us/powerapps/developer/data-platform/authenticate-office365-deprecation	Further official guidance on changing client applications.
https://docs.microsoft.com/en-us/powerapps/developer/data-platform/xrm-tooling/use-connection-strings-xrm-tooling-connect	Sample connection strings to use.
https://docs.microsoft.com/en-us/powerapps/developer/data-platform/walkthrough-register-app-azure-active-directory	If you want to register your own app ids and not use the default ones
https://nishantrana.me/2020/11/06/an-error-occurred-when-processing-the-security-tokens-in-the-messageyou-are-using-ws-tust-authentication-which-has-been-deprecated-and-no-longer-supported-in-your-environment-please-use-oauth2-0-aut/	The same underlying issue manifesting in XrmToolbox and Kingswaysoft