Setting up and managing authentication can sometimes be a bit of a nightmare, even more so when it comes to creating a solution that integrates with an existing system. In these circumstances, the desire will often be to avoid the use of named accounts belonging to individuals or to ensure the configuration of any service accounts involves the granting of the minimum amount of privileges needed to satisfy their function. Additional complications can also arise if you introduce components such as multi-factor authentication into the equation. Services, such as Office 365, allow you to get around this by using a feature known as App Passwords, but the simple presence of this “backdoor” login mechanism could raise serious information security concerns. Attempting to find the best way forward in this scenario and, ultimately, how to go about setting up a satisfactory (and secure) authentication solution can be a significant challenge.
Such concerns recently became apparent to me when I was doing some work involving the SQL Server Integration Services (SSIS) connector for the Common Data Service (CDS) / Dynamics 365 from KingswaySoft. I was encountering issues when testing my connection to the application. Specifically, having followed the instructions on how to configure an OAuth connection and setting up the appropriate Azure Active Directory (AAD) App Registration, the following error message appeared when performing a test connection:
The full text of this error is reproduced below:
KingswaySoft.IntegrationToolkit.DynamicsCrm.WebAPI.WebApiServiceException: The remote server returned an error: (400) Bad Request. (Error Type / Reason: BadRequest, Detailed Message: {“error”:“invalid_grant”,“error_description”:“AADSTS65001: The user or administrator has not consented to use the application with ID ‘’ named ‘’. Send an interactive authorization request for this user and resource.\r\nTrace ID: \r\nCorrelation ID: \r\nTimestamp: ”,“error_codes”:[65001],“timestamp”:"",“trace_id”:"",“correlation_id”:"",“suberror”:“consent_required”}) (SSIS Integration Toolkit for Microsoft Dynamics 365, v11.1.0.7311 - devenv, v16.4.29613.14)System.Net.WebException
My initial reading of the error suggested that admin consent had not been granted for the app registration, even though I’d already done this. After some further research and, with a full grasping of how OAuth authentication works for CDS / Dynamics 365, the solution begins to become apparent. Although this type of authentication does require the full username and password for a licensed CDS / Dynamics 365 user, Microsoft handles the actual authentication into these services via the App Registration setup on the AAD tenant. This setup explains the need to include an Application ID and Client Secret when authenticating in this manner; after this initial hurdle, connections using the details supplied earlier will then be impersonate__d using the App Registration. All this is well and good but causes a potential security risk, as a single App Registration could inadvertently have full read/write access to your CDS / Dynamics 365 database. Microsoft deal with this by having the user_impersonation permission set that you must grant to your App Registration following its creation, to then allow for this action to take place. The API permission for this resembles the following within the Azure Portal:
Taking this into account, therefore, we can deal with error AADSTS65001 by assigning the above permission to your app registration. Once complete, make sure to also grant Admin Consent using a global administrator account on the tenant, via the button circled below:
With these two actions complete, any test authentication should now complete successfully:
With this vital barrier overcome, you can then plough ahead with building out your solution. 🙂
As this post hopefully demonstrates, OAuth authentication involving the CDS / Dynamics 365 introduces an additional complexity layer into the deployment of your solution. You need not only some experience working within Microsoft Azure, but also elevated privileges to ensure you can assign any required permissions in the first place. No doubt the technical implementation outlined in this post ticks a few boxes from an information security standpoint. It is nevertheless the potential cause of frustrating blockers when trying to get a new solution put in place and you are used to more simple authentication experience, involving just a user name and password. Keeping in mind the necessary setup steps involved here will allow you to implement and communicate the precise requirements more effectively, whenever you have to deal with this requirement now or in the future.