I am developing a multi-tenant application to use Microsoft's Business Central API. At first I want to check if I can simply log in myself.
However, every time I try to grant admin consent inside the app's API permissions, I get this error:
This app requires access to a service (\"https://*.api.cds.appsplatform.us/\") that your organization is not subscribed to or has not enabled.
I cannot find anything online about "api.cds.appsplatform.us". I have a subscription (trial) set up, I also have a trial subscription with Business Central (although removing all the API permissions to just the default Microsoft Graph permission, still gives me the same error).
The error message is sort of unhelpful, so what do I need to enable to access my own app?
I believe that the CDS here is Common Data Service. Common Data Service for Apps is a service built on the Common Data model that you can use to store, build, and manage apps and app data. It's used most by PowerApps and Microsoft Flow.
https://learn.microsoft.com/en-us/powerapps/maker/common-data-service/data-platform-intro
https://powerapps.microsoft.com/en-us/common-data-service/
https://learn.microsoft.com/en-us/business-applications-release-notes/april19/dynamics365-business-central/
The only API permissions I needed for a Microsoft Dynamics 365 Business Central app was "Dynamics 365 Business Central" and its subpermissions.
I had included "Dynamics CRM" as an API permission, which requires CDS (Common Data Service), hence the error above.
However, when I wrote above that I had attempted to remove the above permissions and tried the 'grant admin consent' button again, and I got the error again, the problem was that I had forgotten to refresh the page after I had removed the "Dynamics CRM" permission.
Indeed, the takeaway from the error is that one has added a permission too many. But every time one removes a permission, it is paramount that one refreshes the page before attempting the 'grant admin consent' button again.
Related
I have delegated access to Azure resources in a third-party tenant using Lighthouse, and this works fine via the portal; users receive the roles expected (typically Contributor).
However, they are unable to access Kudu (at webappname.scm.azurewebsites.net), receiving an error;
Selected user account does not exist in tenant 'Tenant Name' and
cannot access the application 'abfa0a7c-a6b6-4736-8310-5855508787cd'
in that tenant. The account needs to be added as an external user in
the tenant first. Please use a different account.
If the same user account is added as a guest to the third-party tenant and given the same role, they can access Kudu as expected.
It's clear that Kudu is expecting/demanding an account in the same tenant as the application, but Azure Lighthouse delegated permissions is all about not having to do that.
Is there something I'm missing, or another role that needs granting?
#PhilD, Thanks for the detailed description of the scenario. I have also posted this on your Q&A thread.
Currently, Kudu is not compatible with Lighthouse-delegated permissions.
Our product engineering team is working on it; however, we do not have an exact ETA to share.
We’re expecting it to be available in a few months. Please note that this timeline is just an estimate and is subject to change, depending on a myriad of factors.
I have relayed the feedback internally to our product engineering team and it’s being tracked.
-On a side note, as mentioned in this Kudu wiki :
“Only those with Contributor / Owner access (to be exact, with microsoft.web/sites/publish/action or, for slot, microsoft.web/sites/slots/publish/action) can access to Kudu (SCM).”
Much appreciate your valuable feedback on this. Thanks for your patience!
I have a web app in Azure. The access to that web app is controlled by Azure Active Directory. The app is up and running since September of last year. I didn't make any changes to the app for a while and have 33 users in that app.
So, a week ago I tried to add a user, using the same methods and paths I used before.
The new user can log in to microsoft (portal.office.com). After the initial log in and changing of the password the user goes to the web app in Azure and get the following error: You do not have permission to view this directory or page.
Error tracing gives me this:
HTTP Error 401.73 - Unauthorized You do not have permission to view
this directory or page.
Most likely causes: The authenticated user does not have access to a
resource needed to process the request.
Things you can try: Create a tracing rule to track failed requests for
this HTTP status code. For more information about creating a tracing
rule for failed requests, click here.
Detailed Error Information: Module EasyAuthModule_32bit
Notification BeginRequest Handler
ExtensionlessUrlHandler-Integrated-4.0 Error Code 0x80004005
Requested URL https://*******:80/.auth/login/aad/callback Physical
Path D:\home\site\wwwroot.auth\login\aad\callback Logon Method
Not yet determined Logon User Not yet determined
More Information: This is the generic Access Denied error returned by
IIS. Typically, there is a substatus code associated with this error
that describes why the server denied the request. Check the IIS Log
file to determine whether a substatus code is associated with this
failure. View more information »
Microsoft Knowledge Base Articles:
Another observed behavior: usually when new users are logging in the web app asks for permissions for the AD to access their account information. Ever since this problem came up this is not the case any more.
Other users do not have any problems logging in. This problem only happens with new users who never logged in before.
EDIT: When I go to Active Directory and look at sign ins, I see failures to log into the web app with sign-in error code 90092. Failure Reason: Other.
Microsoft help desk could not give me details on that error code.
Checkout the related question and answer here. All new users have to first consent the application (agree and give your application permissions to access their profile / or you indicated as required permissions).
In short, you have to design "sign-up" button for your application, which uses the "login_url" and appends "&prompt=consent" to the query string.
Read all related resources here to better understand the consent framework.
And please read the documentation about Azure App Service Authentication/Authorization here, as well as the Azure AD specific documentation here.
OMG, I just found an answer. I created a test app and set it up to mirror the settings of my live app.
In Required Permissions the new app had nothing for Microsoft Graph, the live app had 5 permissions. I deleted Microsoft Graph and it works now!
I wish Microsoft communicated better about discontinued API's. I did get an alert, but it was mostly talking about MS Office 365.
Our company has a Microsoft Azure account (Pay-As-You-Go).
We had a programmer that developed our web app. We gave him full access to our Azure account. So, he had access to everything.
We intend to hire another developer to make modifications to the web app, so he'll need access to the App Services and SQL Databases. Our intention is to just allow him access to those features.
We did our research and came across the documentation, Resources, roles, and access control in Application Insights. We followed it step by step, but there's an issue. Doc LINK
We tested the procedure by adding one of our IT staff's Microsoft account (personal Outlook.com account) and assigning him the Contributor role, and sent him an invite. He's not seeing the invite. We did the same for another staff, but it's the same problem.
Can we get some assistance please?
It was not working earlier .I tried with one gmail id. Now it is working perfectly fine and I am able to receive the invitation email.
To send invitation, you need to go to active directory. Add user's email as a guest under add user option (Add guest user).
(Related to this question)
I have an application that should be automatically usable for all customer tenants, and therefore tried this tutorial to enable preconsent.
After doing the Powershell commands and getting again the application, I can see that it is enabled:
PS C:\Windows\system32> $graphResponse.value.recordConsentConditions
SilentConsentForPartnerManagedApp
However, when creating a new tenant(or using an existing one) and trying to access Microsoft Graph's /users call, I get a 500 error until I navigate to https://login.windows.net/common/oauth2/authorize?response_type=code&client_id={0}&prompt=admin_consent (with {0} being the cliendId of the app), sign in as an admin and accept the delegation.
Am I missing a step here?
After a contact with Microsoft support, this is a bug on their side. They told me yesterday that the engineer team acknowledged it. It will be fixed.
In order to query the MS Graph, your app will need to be granted the appropriate permissions by an end user or by an administrator of the tenant. Usually the best way to acquire consent from an administrator is by using the prompt=admin_consent parameter, as you've done above.
If for some reason you must do so via powershell, you can create an oAuth2PermissionGrant object using a consentType of AllPrincipals.
Personally I wouldn't recommend using the recordConsentConditions property. It's only there for legacy reasons - I don't even know what it does.
I'm getting the following error when non-global admin users are trying to access graph explorer 2 within our tenant:
Additional technical information:
Correlation ID: 2346b0f5-bb5f-4138-8f9d-07fa96dcf02f
Timestamp: 2015-05-29 17:18:48Z
AADSTS90093: Calling principal cannot consent due to lack of permissions.
From within Azure we have "users may give applications permission to access their data" set to use. We also have "users may add integrated applications" to yes.
Just wanted to check which URL you are going to. We have 2 "graph explorers" - one is for exploring Azure AD Graph API, while the other (called API explorer) is for exploring the Office 365 unified API.
If you are going to https://graphexplorer2.cloudapp.net - this is (AAD) graph explorer, and should not require admin permissions. Please let us know if this is what you are using and if this is causing issues.
If on the other hand you are going to https://graphexplorer2.azurewebsites.net - this is the API explorer, and due to the number of APIs it requires access to, it currently requires admin consent. We'll look into a way to reduce the number of scopes that this requires access to, to get to a place where users can consent (but that's not the case currently).
Hope this helps,
I ran into this issue today and here what I did:
Login to your AD application in classic portal
(https://manage.windowsazure.com/)
Under "Configure" section, there
is "permissions to other applications", look at the "delegated
permissions" for "Window Azure Active Directory".
Make sure you pick
the correct permissions for your app. Normally, "Sign in and read
user profile" is enough for user to login.
For more information you
can take a look at this link
https://graph.microsoft.io/en-us/docs/authorization/permission_scopes
I worked for Skype for business online use case (WEB API). I faced this issue for users not global admins. The users who added by global admin.
I managed to resolve the issue by passing extra parameter prompt=admin_consent.
var href = 'https://login.microsoftonline.com/common/oauth2/authorize?response_type=token&client_id=';
href += client_id + '&resource=https://webdir.online.lync.com&redirect_uri=' + window.location.href+'&prompt=admin_consent';
For more details visit link https://blogs.msdn.microsoft.com/exchangedev/2014/03/25/using-oauth2-to-access-calendar-contact-and-mail-api-in-office-365-exchange-online/