AADSTS90093: Calling principal cannot consent due to lack of permissions - azure

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/

Related

Azure Kudu access for users with Lighthouse delegated permissions

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!

How to query another Azure Active Directory tenant from Graph Explorer

I am using Azure Graph API Explorer. I want to query the apps list in a tenant. I am user in tenant_x (where user was originally created) as well as admin in tenant_y (created later with my user). I understand that when I log in I go directly in the origin tenant (so tenant_x) therefore Graph Explorer does not allow me to query tenant_y. So as admin of tenant_y I have added a new user in tenant_y. I log in now with that user but still I am not able to query the applications that are in tenant_y. So how can I query apps in tenant_y? Is there a way? thanks.
The API I am calling (with new user log-in) to first retrieve all applications:
https://graph.microsoft.com/beta/applications
Response is:
{
"#odata.context": "https://graph.microsoft.com/beta/$metadata#applications",
"value": []
}
Of course I have apps in that tenant.
Based on our communication, you have used a personal account as guest of tenant_y to query the apps list in tenant_y.
Unfortunately, Microsoft Graph Explorer will not recognize your personal account as a guest user. It will still treat it as a personal account.
So it will query the apps list for the personal account rather than tenant_y.
So now you have two choices:
Create a new user in tenant_y by following add a new user and
then use this new user to log into Microsoft Graph Explorer to query
the apps list.
Implement Get access on behalf of a user and make sure that you
call {your tenant} endpoint rather than common endpoint while
requesting the access token. And you should use another tool (for
example Postman) instead of Microsoft Graph Explorer.
Update:
You can modify the permissions in Microsoft Graph Explorer like this:
Click on the "modify permissions" under your username in Microsoft Graph Explorer and check the Directory.Read.All permission.
Today that's possible if you pass the tenant query string parameter like this:
https://developer.microsoft.com/en-us/graph/graph-explorer?tenant=mydomainname.onmicrosoft.com
Note that you need to logout before going to this URL with the tenant query string. It'll ask you to login again. After login you can issue queries against the other tenant you have access to (not your home tenant where your account was originally created on).
If you get a 401 while running the specific query, make sure you grant the required permissions on "Modify permissions" tab and click the Consent button in each required permission. After that your query should return a 200 success result.
Graph Explorer today does not support signing in to the tenanted endpoint. A tenanted endpoint is used in the following format
https://login.microsoftonline.com/{tenantId}/V2.0
Once your user account from tenant_x is made a guest user in tenant_y, to effectively query tenant_y using your guest user account, an app (like Graph explorer) has to sign you in the other tenant. Instead Graph Explorer uses the /Common endpoint, which will always sign you in your home tenant (tenant_x).
The only available workaround is to develop a application quickly and sign-in to a tenant of your choice and run Apis in it.
Graph explorer is a tool to help developer's discover and learn about the Graph Api and thus might shy away from introducing too much complexity. But it does not hurt to ask for this feature at their Github repo.

What is the Azure "api.cds.appsplatform.us" service?

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.

"Access Denied: You do not have access" error in Azure Portal

I am trying to do some experimentation with MSAL JS and ADAL JS libraries. I was able to get MSAL JS working fine by doing configuration at Azure Active Directory => "App Registrations (preview)". However when I switched to ADAL JS I get an error about needing version 2.0, so I think I need to use the regular "App Registrations" screen.
However, when I click on the regular "App Registrations" button I get:
Access Denied
You do not have access
Looks like you don't have access
to this content. To get access, please contact the owner.
I think it's odd that I can access the "preview" app registrations screen but not the regular one.
I saw somewhere online somebody suggested making changes at "User Settings", but that screen gives me the same error message. Going to "Users" I see 0 users, and it won't let me add any (the plus is greyed out).
The account I am using is just a personal account, it is not tied to any organization so there is no admin. I assume I should have full permission or be able to give it to myself, but can't figure out how.
Getting a Trial Azure account fixed this problem, so it appears one is needed to use the "App Registrations" section.
It is still a little unclear why an account is not needed for the preview mode, however.
Also, it would be nice if Azure would show a proper message saying an account is needed instead of a error message, but that is a minor point.

Azure AD application preconsent not working

(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.

Resources