When you’re looking at any sort of IT integration project, that involves getting two separate systems “talking” to each other, a common challenge to address is how to achieve this as securely as possible. The traditional approach often involves the implementation of a dedicated service account, with a distinct user name and password. You would then grant this the correct level of privileges to perform its core functions - such as full Create, Read, Update and Delete (CRUD) permissions within a specific area of the system. In the world of Dynamics 365 / the Common Data Service (CDS), we have a unique user account type that has, traditionally, been well suited to these purposes - non-interactive user accounts.

The Problem with Non-Interactive User Accounts

Accounts of this type, in some respects, meet the needs outlined at the start of this post well. However, they do have a few issues:

• You are limited to a maximum of seven non-interactive user accounts for each online instance of Dynamics 365 / CDS. It’s not inconceivable that, for specific organisations, this limit could be breached, due to the number of potential integrations involved.
• The setup process for these accounts is ridiculously convoluted, involving many stages within both Office 365 and the system itself. In some cases, it may even be impossible for a Dynamics 365 / CDS administrator to complete all of them in a single sitting. The setup process is also contingent on you having the necessary licenses available, to ensure the new account lands in your system in the first place.
• These days, I would argue that any integration that involves the retaining of a user account and password is one that could be open to abuse; even if you have appropriately scoped the privileges of the new non-interactive user account.

Fortunately, thanks to some of the more recent developments across the platform, there is a new, potentially better, way of doing things. This solution will enable you to not only authenticate into Dynamics 365 / CDS, but also ensure that the setup steps involved remain condensed and, most importantly, familiar enough for any administrator of the system to work with quickly.

Introducing Application User Accounts

Application user accounts work on a similar basis to non-interactive user accounts but rely instead on Server to Server (S2S) authentication for applications that leverage Microsoft Azure Active Directory (AAD) behind the scenes. Administrators create a dedicated account, that your application impersonates as part of any requests made into Dynamics 365 / CDS. From a setup perspective, you need only then specify a unique Application ID and secret value; your application will then execute all operations targeting Dynamics 365 / CDS in the context of this dedicated account. Application user accounts address some of the concerns highlighted earlier with non-interactive user accounts:

• There is no limit to the number of application users you can have within a Dynamics 365 / CDS instance.
• Management and creation of these account types do not involve the whole license assignment/removal process in Office 365 à la non-interactive user accounts. However, their setup does require some configuration in Microsoft Azure (more on this shortly).
• While application user accounts involve the storing of a sensitive key/value pair, in much the same manner as a user name/password, they’re ultimately a more preferential option. This is because you can configure them to expire after a set period. Also, you can view detailed information for all authentication requests made within Microsoft Azure (provided you have a paid license). Therefore, I would argue, this makes them the lesser of two evils compared with non-interactive user accounts.

To get started with using application user accounts, it will be necessary first to jump into Microsoft Azure to carry out some pre-requisite setup.

Setting up the App Registration

After navigating to the Azure portal, go to Azure Active Directory -> App Registrations and click New Registration. Provide a descriptive name for the new registration (ideally indicating its business function area) and ensure that the Accounts in this organizational directory only ( only - Single Tenant) option is selected. The redirect URI will depend on your specific scenario but, in most costs, populating a value of http://localhost should be sufficient. You can refer to the following Microsoft Docs article for further assistance/guidance on how to set this all up.

Once provisioned, you then need to grant the App Registration the appropriate privileges to connect to Dynamics 365 / CDS. Steps 6 onwards of the following walkthrough will show you how to do this. If configured correctly and, most importantly, granted admin consent, the permissions should resemble the below screenshot:

Next, you will need to generate a client secret value for the App Registration. Again, the Microsoft Docs site provides excellent instructions on how to do this. I’d recommend setting an expiry for any secret value. Finally, before closing down the Azure portal, make a note of the Application (client) ID, which should be a globally unique identifier (GUID) value.

Account Configuration in Dynamics 365

Now we need to navigate to the Users area of Dynamics 365 and, with the Application Users view selected, press the New button. Instead of navigating you across to the Office 365 portal, you should instead see a form that resembles the below:

Populate the form with these details and press Save & Close to create the new application user:

• User Name: This should be a unique account name, that ties across to a domain on your Office 365 tenant. For example, you could use [email protected] or [email protected].
• Application ID: Enter the Application (client) ID value recorded from Azure earlier.
• Full Name: Provide a descriptive First / Last name value for the account, to make it clear what its purpose is.
• Primary Value: The value in this field should match the User Name field.

Using your new Application User Account

The next steps from here will depend on your particular application or integration requirement but, as a minimum, you will need both the Application (client) ID and secret values generated from the Azure portal earlier. For example, within Azure Data Factory, you would authenticate using the AAD Service Principal type, and supply these values as indicated below:

Closing Thoughts

Application user accounts are, I would argue, the preferred way of authenticating into Dynamics 365 / the CDS when you have already tightly integrated your application alongside Microsoft Azure. The setup steps involved are trivial in comparison to non-interactive user accounts and, ultimately, provide a more exceptional range of options to manage and curtail access, should the need arise. Hopefully, this post has provided enough detail for you to go away and start working with them yourself. 🙂