You’re offline. This is a read only version of the page.
20
Greetings Experts,
Scenario: Connecting BC OnPrem (v18) to CRM OnPrem via Dataverse. A dataverse Sandbox has been created without Administrator mode. The user with which I access dataverse has Sys Admin, Sys Customizer Rights.
Whenever I try connecting my Business Central with Dataverse through Azure AD, it throws me this error. However this error has been discussed in the 2 blogs by Marco Mels but I haven't been able to follow the guidelines and still make it work
https://community.dynamics.com/business/f/dynamics-365-business-central-forum/p/1199359/reply?tsid=c391ba00-6adf-47e3-9eb3-9dd3e4345727&ReplyToContentTypeID=1
However, I had specific questions if anyone could help me answer that:
1. The second blog above mentions about Self APP API permissions. Can anyone please highlight the steps on how can we perform this function > "Next if your API permission do not contain the name of your own Azure AD app with user_impersonation, then you need to set that as well." ,
I do understand its just a matter of giving the permissions on the azure portal but I think I have misunderstood it.
2. Also my Reply URL is something like "">WebBaseURL:8080/.../". Does it necessarily have to be HTTPS and not HTTP?
Any responses to this post will be highly appreciated
Hello,
The first orange suggestion is about this:
Due to temporary differences in supported functionality, we don't recommend enabling personal Microsoft accounts for an existing registration. If you need to enable personal accounts, you can do so using the manifest editor. Learn more about these restrictions.?
This is related to the yellow part:
More information here:
https://go.microsoft.com/fwlink/?linkid=2107401
In general we do recommend to use MFA as this will bring security to next level.
The next suggestion is the following:
Starting November 9th, 2020 end users will no longer be able to grant consent to newly registered multitenant apps without verified publishers.
There is more information related to this suggestion:
Hope it is more clear. This is about end users in combination with risk-based step-up consent and a specific date time line of registration of new apps. Note that with Dataverse, we require OAUTH2.0 as authentication type. This will become mandatory for all integration to Dataverse after April 2022. More information here:
Important changes (deprecations) coming in Power Apps and Power Automate - Power Platform | Microsoft Docs
(see section: Deprecation of Office365 authentication type and OrganizationServiceProxy class for connecting to Dataverse).
Related to your issue, a successful connection can be created by following all steps in blog:
Connect to Microsoft Dataverse (contains video) - Business Central | Microsoft Docs
Yes, of course. Raise a support ticket as we are here to assist. You can do this via your partner or CSP.
Hope it helps.
Thankyou Very Much Marco Mels. Your explanation is flawless, it's me who has a bit of a learning curve on Azure portal. I followed exactly what you've mentioned. In a nutshell, let me just paste my steps:
1. Followed the steps in community.dynamics.com/.../1221763
2. Added the Redirect URL, etc. to the Azure App Authentication, generated the key, client ID, assigned delegated permissions to Business Central and D365 Sales.
3. Made sure the redirect URL on BC Dataverse and Azure is matching and is HTTPS (SSL Secured)
4. Followed the steps here and added the dll and the xml file from net45 folder to the service folder. Restarted BC service
5. Added the "user_impersonation" for My own APP in azure as wonderfully described by you. Made sure the app authentication is maked as "Multitenant"
6. Made sure to add the necessary Client ID App URI in the customsettings.config file both near AppIdUri and WSFederation of the Service folder and restarted BC Service once.
7. Tried connecting with dataverse and again I receive the same error. Access tokens cannot be downloaded.
However, whenever I select "multitenant" on the Azure App Registration it gives me a message like below stating i need to provide a MPN ID. Is it mandatory we do that? I am signing/authorizing everything from a user which is belonging to the same customer's tenant. And when i add MPN ID, it asks me to turn on MFA, the confusion is, should I turn on MFA for the user I am logged in with on Azure Portal or is it something else?
Do you think anything additional has to be done here in these steps apart from Multitenant which i might've missed, or should I raise it with Microsoft Support?
Hello,
Hope you are doing well and not so good that my responses are not that clear. The second blog already answered your second question.
E.g. your question:
2. Also my Reply URL is something like "">WebBaseURL:8080/.../". Does it necessarily have to be HTTPS and not HTTP?
My answer:
It must have the following format: https ://PublicWeBaseUrl/OAuthLanding.htm. The PublicWebBaseUrl is the url to the WebClientInstance.
So yes, it must be set to https. You can use a trusted cert for this (recommended in productive environments) or a self signed cert (not recommended in productive environment, but OK for a Sandbox).
Related to the user_impersonation part.
In App Registration in Azure, go to Expose an API. Click on Add a scope. Typically it will have a format like api://guid. Under Scopes, click on the the created api. This opens the Add a scope screen. Under scope name type in user_impersonation. Who can consent is a business decision, only Admins (users will have to ask an Admin account or Admins and Users). Type in display name, etc. When done, click on Add scope.
Now go API permissions. By default you do not see the new scope you created. You will have to add it by clicking on Add a permissions. Then select My API's. If you just created the scope, it may not be visible immediately. Usually it can take a minute or two. Here you will see the name of the Azure AD app with the application client ID that is written after api://application (client) ID.
Note that the apiL//application (client) ID needs to be set in AppID Uri in customsettings.config file:
<add key="AppIdUri" value="api://application (client) ID" />
And it is similar to wtrealm value:
<add key="WSFederationLoginEndpoint" value="https ://login.microsoftonline.com/domainname/wsfed?wa=wsignin1.0%26wtrealm=api://application (client) ID" /> " />
Note that that wreply value has become obsolete, this is no longer required. The wreply value is however similar to the PublicWebBaseUrl plus /SignIn.
If you end up with Microsoft support to receive direct assistance, I usually ask the partner if they are good in doing a puzzle. The values must be similar and be exactly the same and used in the correct values of specific keys. If not, this error may happen.
Hope it is now more clear.
#1
Sohail Ahmed
2,655
#2
Mansi Soni
1,574
#3
YUN ZHU
1,453
Super User 2025 Season 1
Share
Report
All responses (
Answers (
