Are you still using WS-Trust Auth and OrganizationServiceProxy…then it is time to change …

Hi Folks,

Microsoft had recently announced on docs.microsoft.com that using WS-Trust authentication security protocol to connect to your Common Data Service had been deprecated.

So what does this mean??

Firstly you need to note that this only applies to client applications that connect to CDS.

It does not impact your custom plug-ins, workflow activities, or on-premises/IFD service connections.

Below are the places where you need to replace them…

If your code uses Username & Password for authenticating with Common Data Service or an application, you are likely using the WS-Trust security protocol.

  • If you are using the OrganizationServiceProxy  class at all in your code, you are using WS-Trust.
  • If you are using CrmServiceClient.OrganizationServiceProxy  in your code, you are using WS-Trust.

Check the following:

  1. If your client applications using Microsoft.Xrm.Sdk.Client.OrganizationServiceProxy:

         Action Required:

        Replace all occurrences of the type OrganizationServiceProxy with  the IOrganizationService interface

      2.                            using CrmServiceClient with the “Office365” authentication type:

          Action Required:

          Switch over to using an OAuth based connection string, Note that LoginPrompt can be set to “never” to simulate the way that the Office 365 behavior worked. Please note that the App ID and Redirect URI should be created in AAD in your tenant.

Few points to note before we conclude:

  • An update to Microsoft.CrmSdk.XrmTooling.CoreAssembly is available for download through NuGet package that includes auto redirect support. This library will redirect an authentication type of Office365 to OAuth.
  • If you were not able to login even using OAuth, check if MultiFactor Authentication/conditional access is enabled, if so consider registering application user (Service Principal) in Azure Active Directory.

 

References:

CDS/CRM SDK – WS-Trust auth and OrganizationServiceProxy Deprecated

Use of Office365 authentication with the WS-Trust security protocol

 

If you still have issue, don’t hesitate to comment here…or reach to community using this link…

Cheers,

PMDY

 

 

 

Issue configuring Data export service – Unable to connect to the Destination mentioned in the Keyvault URL

After knowing the wide advantages of reporting with the help of Data export service, I would like to share some tips and valuable resources for the same.

This Data export service in D365 by MVP Scott Durow is the first step to jump start your learning, people preferred to view instead video can better go through this Data export service blog content from MVP Nishant Rana.

Edit: 20 April, 2018: Suprizing what was Azure Key vault? Azure Key Vault helps safeguard cryptographic keys and secrets used by cloud applications and services.

Followed the steps mentioned, however I still used to receive error Unable to connect to the Destination mentioned in the Keyvault URL while configuring the data export service taken from the Secret Identifier in Azure obtained after running the Powershell script with all the details filled in.

I followed the fix provided in this Unable to connect with KeyVaultURL, but it didn’t help in my case.

Point to note for creation of this feature:

1.Don’t forget to create the login & username for the new Azure SQL Database, this is needed for the secret vault to communicate with the destination organization to load data.

2. After copying the Database connection string as mentioned, don’t forget to change the Username & Password in this string with details you had created in above step and don’t try with D365 login permissions.

Then I was able to validate the Keyvault URL successfully. Currently my Azure subscription is in South India, but still this data export feature works successfully.

 

Hope this helps someone trying to configure the Data export feature of Dynamics 365.

Happy CRM’ing.

Cheers,

PMDY