If you are connecting to Dynamics 365 CRM from a micro service, service, azure function, web apps, web jobs etc you might be using Organization service connectivity. There is an important deprecation happening with this connectivity. OauthType of Office365 wouldn't be supproted in the future.
Office 365 Authentication Type and OrganizationServiceProxy would be deprecated soon. Key dates are below. But I would highly recommend to replace them as soon as possible and test. This post will provide some tips on how to replace them. Views are my own.
- Effective April 2021, the authentication protocol will be retired for all new environments within a tenant.
- Effective April 2022, the authentication protocol will be retired for all new and existing environments within a tenant.
As you all know there are two type of connectivities to Dynamics 365 CRM.
1. Organization Service ( SOAP)
2. CRM Web API (REST API)
This post is regarding organization service only. If you want to know more about CRM Web API have a look at this post - https://crmdm.blogspot.com/2020/12/dynamics-365-crm-web-api-with-azure.html
If you want to find out whether you would be affected, here are the recommendations from the microsoft documentations.
1) Check your connection string of the micro service / web app / web job etc. If it has AuthType as Office 365, you need to action on it. For instace, a sample is given below.(ref: Microsoft)
connectionString = "AuthType=Office365;Username=jsmith@contoso.onmicrosoft.com;Password=passcode;Url=https://contoso.crm.dynamics.com"
(2) In your source code search for OrganizationServiceProxy to see if it is in use. Please note that it is 'z' not s. So make sure you search it correctly.
"Remove all use of that property in your code. CrmServiceClient implements IOrganizationService and exposes everything that is settable for the organization service proxy." - This is the change for OrganizationServiceProxy. Just code changes required as per this instruction and make sure that no OrganizationServiceProxy is in use.
If these are applicable to you then below are some tips for the connection string part.
If you are already using AuthType=Office365, that needs to be replaced by AuthType=OAuth. Now if you are thinking, it is just a keyword change, nope, it is not. It is much more than that.
Here is the sample OAuth AuthType sample from Microsoft.
connectionString = "AuthType=OAuth;Username=jsmith@contoso.onmicrosoft.com; Password=passcode;Url=https://contosotest.crm.dynamics.com;AppId=51f81489-12ee-4a9e-aaae-a2591f45987d; RedirectUri=app://58145B91-0C36-4500-8554-080854F2AC97;LoginPrompt=Auto"
Some bits are easy here and some are can be a bit confusing. Here is diagram to understand the concept.
First part is the connection using Office 365. Very straightforward one, just need username, password and url - This connection type wouldn't be supported anymore.
Second one is the OAuth type. In addition to username, password and url we need application id, redirect url which is registered in App registrations of Azure Active Directory.
In other words, this new OAuth type authentication is happening in 2 stages.
1st stage - It authenticates the user
2nd stage - It authenticates the application using application user + app registration.
Let's see the azure set up first. Usually azure part is configured by an infrastructure engineer. I have explained the steps for your understanding. If you just want to see the code part, it is at the bottom of this post.
Navigate to https://portal.azure.com
Navigate to Azure Active Directory
Select the Users part from the Active Directory.
Click on New User button.
Create the user with the preferred name. It also provides the option to set the password. Take a note of username and pwd as this is needed in the connection string.
Once created, the user is listed in the users list. We use this user for the stage 1
Select the user and assign license. In this case, CE license is assigned.
So stage 1 is ready - We have a user, passord ready to go.
Stage 2 is setting up the app registration to get application id, redirect url.
So navigate to Azure Active Directory again and choose app registrations section.
Register a new application. Redirect URI can be a bit confusing.
Here is the documentation part - "We’ll return the authentication response to this URI after successfully authenticating the user. Providing this now is optional and it can be changed later, but a value is required for most authentication scenarios."
So what value to be provided, it is upto you and it depends on your scenario. It doesn't have to be a working url as per my understanding. So here I have provided localhost (https://localhost). Important bit is that a url to be provided, and that should be the same url in your connection string (both should match).
Click on the Register button.
Open the app registration and note the application id. This application needs to be provided in the connection string. Also see the highlighted sections. Click on API Permissions as the next step.
Click on Add Permission
Select Dynamics CRM from the API list.
Tick user_impersonation and click on Add Permissions button.
Also grant admin consent as well.
Next step is to set the Manifest. Navigate to app registration and choose Manifest section. Set allowPublicClient to true. And then click on the Save button.
Azure part is done!
Now navigate to Dynamics 365 CRM and users area. Add an application user by clicking the new button.
The only information you need to provide here is application id from Azure AD app registration. Rest is populated by Dynamics when the record is saved.
So here is the record after saving.
Now one final bit is missing - Assign the security role for this application user.
Ready to roll!
I have created a very simple .Net framework based console app to test it. Please note that organization service is not supported by .NET core. So it has to be a .NET framework app.
Sample code for a simple WhoAmI request is below. Connection string to be replaced with yours.
using Microsoft.Crm.Sdk.Messages;
using Microsoft.Xrm.Tooling.Connector;
using System;
namespace OrganizationServiceDemo
{
public class Program
{
public static void Main(string[] args)
{
string dynamicsCrmConnectionString =
"AuthType=OAuth;Url=https://yourorganization.crm11.dynamics.com;Username=youruser@yourorganization.onmicrosoft.com;Password=yourpassword;AppId=yourappguid;RedirectUri=https://localhost;LoginPrompt=Never;";
CrmServiceClient.MaxConnectionTimeout= new TimeSpan(0, 5, 0);
CrmServiceClient client = new CrmServiceClient(dynamicsCrmConnectionString);
if (client.IsReady)
{
var whoAmIResult = client.Execute(new WhoAmIRequest());
foreach (var item in whoAmIResult.Results)
{
Console.WriteLine($"\n Key - {item.Key}");
Console.WriteLine($" Value - {item.Value}");
}
Console.ReadLine();
}
}
}
}
Please note this line - CrmServiceClient.MaxConnectionTimeout= new TimeSpan(0, 5, 0);
Default connection timeout for organization service is 2 minutes. If you want to set a higher time out value ie: if your application need connection to organization service for more than 2 minutes at a time, this the setting to be used. In Oauth type connection, it has become a static property. In Office365 connection, it used to be tied up with service client it self and not static.
In this scenario it is setting the connection time out to 5 min.
Result from the console:
References to Microsoft documentation is below.
I hope it helps!
No comments:
Post a Comment