Advertisements

Archive

Posts Tagged ‘Application user’

Dynamics 365 – Different types of User Accounts and License consumption

Other day I was asked a question “What are the options to create/migrate users in Dynamics 365 application with no license consumption”

The options are

  • Create a User of type ‘Stub User’ which does not consume license
  • Sync a User from O365 to Dynamics 365 and remove the license later. This approach deactivates the User in D365 and free up the license.
  • Create an Application User
  • Create an Administrative User account
  • Create a Non-Interactive User account

To know different options is crucial, especially, when you are migrating the Users from legacy systems and the Users are not expected to access the D365 application which should not cost any licenses.

In this article, I am going explain the different type of Users and how they consume the licenses.

Administrative User Account:

  • An Administrative user is a user, who has access to the Settings and Administration features but has no access to any of the customer engagement functionality.
  • Since the administrative user does not have access to customer data and any of the customer engagement functionalities, it does not require a Dynamics 365 (online) license.
  • To create an ‘Administrative User’
    • Create a User in Office 365; (Admin Center -> Users -> Active users -> Add a user)
  • User2
    • Assign a Dynamics 365 license under ‘Product licenses’ tab.
  • User3
    • Go to D365 application and open the User record
    • On the User form, under ‘Administration’ tab, ‘Client Access License (CAL) Information’ section and select “Administrative” for Access Mode.
  • User1
    • Final step is, remove the Dynamics 365 license of the User from Office 365, so that you can free the license and still the User can login to the application as ‘Administrative’

Non-interactive User Account:

  • Non-interactive user is not a physical User and It is used for programmatic access to and from Dynamics 365 between applications.
  • Non-interactive user let applications (i.e., Consoles, SSIS packages or ERP connector etc.) authenticate and access Dynamics 365 (online), without requiring a Dynamics 365 (online) license.
  • Creation of Non-interactive user account is same as Administrative User Account, except setting the Access Mode to ‘Non-interactive’
  • There is a limit of five non-interactive user accounts

Application User Account:

  • ‘Application User’ is used while establishing server-to-server (S2S) authentication
  • ‘Application User’ with conjunction of Azure Active Directory (Azure AD) will establish S2S authentication.
  • ‘Application User’ does not consume license.
  • Application users are created with a non-interactive user account, however they are not counted towards the 5 non-interactive user accounts limit.

Stub User:

  • Stub user cannot log in, cannot be enabled, and cannot be synchronized to Office 365 and will not consume license.
  • Stub Users are designed for records that have been imported that refer to this user but the user does not exist in Dynamics 365 (online).
  • Stub users are user records that are created in Dynamics 365 using Data Import or using the Create or Create Requests methods of the SDK.

Licensed User:

  • Licensed user is an User whom gets created in O365 with license and synced to D365.
  • Licensed users must be assigned at least one Dynamics 365 security role to access Dynamics 365 (online).
  • The service does not allow access to users who do not have at least one security role.
  • Removing all security roles from the user prevents the user from signing into and accessing Dynamics 365 (online). However, it doesn’t remove the license from the user.

Refer article for more details.

🙂

 

Advertisements

[Step By Step] Configure Server-to-Server (S2S) authentication using Azure AD and Application User – Dynamics 365

March 24, 2018 2 comments

In this article I am going to explain, what is ‘Application User’ and how it helps to establish using Server-to-Server (S2S) authentication and Azure Active Directory

To explain the S2S authentication simpler, let’s take an integration requirement

  • You have an ASP.Net Web Application
  • You need pull the Contacts from a CRM organization and display in the ASP.Net Web Page

The conventional design approach for the above requirement would be

  • Establish the CRM connection in your ASP.Net page by passing CRM User credentials
  • Make a Retrieve call to CRM
  • Read and bind the Contacts to a grid.

To implement the above design you need to have a paid CRM User credentials to interact with your Dynamics CRM organization.

So what is S2S authentication and how is it different from the legacy integration model we discussed above.

Server-to-Server (S2S) authentication:

  • S2S authentication means you don’t need to use a paid Dynamics 365 user license when you connect to Dynamics 365 tenants.
  • We will use a special user (i.e., Application User)
  • Best part is, you can connect to D365 and make server calls from your application (i.e.,Web/Console) with no Dynamics SDK dlls and no ‘UserID/Password’.

What is this ‘Application User’:

  • ‘Application User’ is a ‘systemuser’ record of type ‘Application User’
  • There is no license fee for the ‘Application User’ account

App User - 14

How an ‘Application User’ account achieve the S2S authentication:

  •  ‘Application User’ with conjunction of Azure Active Directory (Azure AD) will establish S2S authentication.
  • We first generates an ‘Application ID’ in Azure AD which we set in ‘Application User’ in Dynamics.

Lets see the step by step approach to achieve S2S authentication.

  • Pre-requisites:
    • Dynamics 365 instance
    • Azure Subscription with same Office 365 account used for your D365 instance.
  • High Level Steps
    • Generate ‘Application ID’ and ‘Keys’ in ‘Azure’
    • Add a new User in ‘Azure Active Directory’ (Azure AD)
    • Create a new ‘Application User’ in Dynamics 365

Step 1 – Generate ‘Application ID’ and ‘Keys’ in ‘Azure’:

  • Connect to your Azure
  • Go to ‘App registrations’ service

App User - 1

  • Create a ‘New application registration’
    • Note: ‘Sign-on URL’ can be any valid URL.

App User - 2

  • Copy the generated ‘Application ID’ (This is needed while creating ‘Application User’ in CRM)

App User - 3

  • Generate ‘Keys’ (You need the ‘Key’ to establish connection in your Web Application/Console Application)

App User - 4

  • Save the ‘Key’ (Note: You cannot read the key if you move away from the screen)

App User - 5

Step 2 – Add a new User in ‘Azure Active Directory’ (Azure AD):

  • Connect to your Azure
  • Go to ‘Users’ service

App User - 6

  • Create a ‘New User’
    • Note: ‘Password’ auto generates once you save. You don’t need to copy as this is not required further.

App User - 7

  • Once the User saved, copy the ‘User Name’ (This is needed while creating ‘Application User’ in CRM)

App User - 8

Step 3 – Create a new ‘Application User’ in Dynamics 365:

This step we are going to create an ‘Application User’ in D365 by copying the details generated in Azure

  • Connect to Dynamics 365
  • Go to ‘Settings -> Security -> Users
  • Switch the view to ‘Application Users’ and click ‘New’

App User - 9

  • In the ‘New User’ screen
    • Set ‘User Name’ with the ‘User Name’ copied from ‘Azure’
    • Set ‘Application ID’ with the ‘Application ID’ copied from ‘Azure’
    • Save the User and once saved, you notice the auto populated ‘Application ID URI’ and ‘Azure AD Object ID’

App User - 10

  • Assign a ‘Security Role’
    • ‘Security Role’ must be a Custom Security Role and you cannot assign OOB role.
    • For this exercise, you might want to copy any existing OOB Security Role.

All right! We are all set and now its time to test S2S authentication from your console.

S2S Authentication Code Snippet:

Prerequisites:

  • Install ‘ADAL’ and ‘NewtonSoft’ NuGet packages

 Code:

using Microsoft.IdentityModel.Clients.ActiveDirectory;
using Newtonsoft.Json;
using Newtonsoft.Json.Linq;
using System;
private static async Task GetContactsAsync()
{
// Your Dynamics Web API URL
string api = “https://docmigrate.api.crm.dynamics.com/api/data/v9.0/”;

AuthenticationParameters ap = AuthenticationParameters.CreateFromResourceUrlAsync(new Uri(api)).Result;

// Set ‘Application ID’ and ‘Key’ generated from Azure
var creds = new ClientCredential(“e4ac3a78-xxxx-403a-a94c-xxxxxxx”, “hEo/xxxxxxxS+LEiYHpxxxxxxxRe8xg0=”);

AuthenticationContext authContext = new AuthenticationContext(ap.Authority);
var token = authContext.AcquireTokenAsync(ap.Resource, creds).Result.AccessToken;

using (HttpClient httpClient = new HttpClient())
{
httpClient.Timeout = new TimeSpan(0, 2, 0);
httpClient.DefaultRequestHeaders.Authorization = new AuthenticationHeaderValue(“Bearer”, token);

// Retrieve Top 1 Contact
HttpResponseMessage response = await httpClient.GetAsync(api + “/contacts?$top=1”);

// Parse the response
if (response.IsSuccessStatusCode)
{
JObject contact = JsonConvert.DeserializeObject<JObject>(await response.Content.ReadAsStringAsync());

var contactName = contact.GetValue(“fullname”);

}
}
}

App User - 13

🙂