I have an Excel plugin, which uses Azure AD (ADAL) for authentication. I have made a second copy of the app and the needed changes in Azure AD. All user can use the first app. The second app I am the only one who can log in. They have the same rights like in the first app. What Azure give as error on login is:
Error Code: 90094
Error reason: Other
I cannot find information for this error. What is returned to the user is "Admin have to give privileges to this app". But the privileges are given. The same like in the first app.
Do you have any information for this error code?
P.S. What I found is, that this is connected with required permissions from the app. If I add a user, who is a Global Administrator in Azure AD, after logon comes a window "The app needs permission to: ... (Accept, Cancel)" and after that, he can use the app, even if he is changed to normal user. If the user is normal Azure AD user, this windows does not appear and he is rejected with the error 90094. The same happens with a user, who is Limited Administrator and it does not matter what for admin role he has.
P.S. 2
On my support request, Microsoft support did not tell me what this error means ("This is a custom application and there is no info about this error. There would be info if this was an enterprise application").
After deleting the app registration and make it again, there is no more such a problem. And I cannot reproduce it (I have tried hard :) ). And if you give me an answer, I cannot prove it. So you can look on this question as closed.
I had a similar problem where the error occurred if anybody other than a Global Administrator was the one that created the AAD app registration. It came down to a subtle difference in the way Azure AD sets permissions for the application based on who sets the application permissions in the old Management Portal. I don't know if they have this problem in the new Resource Manager portal, or if it's even the same case as what you're encountering without more information.
Found a solution here:
As an administrator, you can also consent to an application's delegated permissions on behalf of all the users in your tenant. This will prevent the consent dialog from appearing for every user in the tenant. You can do this from the Azure portal from your application page. From the Settings blade for your application, click Required Permissions and click on the Grant Permissions button.
This worked for me.
Related
I use Azure apps to sign users in to a web app and a desktop app. I also query for user information via Microsoft Graphs /user/ endpoint.
So we have to apps registered in Azure; one is a web app / api with permissions to sign users in and read all user profiles from graph. The other is a native app with permissions to the first app, and permissions to sign users in.
In one tenant, this works fine. However in the other tenant the web api har permissions to sign users in, but Graph declines access to the /users/ endpoint due to insufficient privileges. The error is: Authorization_RequestDenied, Insufficient privileges to complete the operation.
However the exact same privileges work fine in another tenant. In the faulty tenant we get a token from graph but when we use the token on the user endpoint it throws the insufficient priv. error.
Signing in users via the desktop app (we use owin) works in one tenant but in the faulty one it sais that app tenant.onmicrosoft.com/guid does not exist in tenant.onmicrosoft.com
The app uri is correct in the settings and the app has the same privileges in both tenants.
We tried recreating the apps since this has solved similiar issues when developing things like this before. This time it doesnt seem to work however. Now I'm at my wits end here. Could there be some other issue blocking here?
The faulty tenant is part of a multi-tenant. However we only poll for users in one tenant as of now.
The apps have also been given consent by an admin via the azure portal. What am I missing here? How should i proceed with trying to fix this error?
Edit: I added a new directory in my tenant and it does not work in this new directory. Same error as with our clients tenant.
Working token for directory A:
eyJ0eXAiOiJKV1QiLCJub25jZSI6IkFRQUJBQUFBQUFDNXVuYTBFVUZnVElGOEVsYXh0V2pUQkVOV21GUUgtZjRGS0VjYlIwU3Y1NndrdzhvSjhjbDIwX3JtZEJBc2h6eDhKT2VNZjFEbVFjNm1GUUdxZ2VSRFJZMTEzNXE3ZXJkTjlHTFZ6T3NycnlBQSIsImFsZyI6IlJTMjU2IiwieDV0IjoiaTZsR2szRlp6eFJjVWIyQzNuRVE3c3lISmxZIiwia2lkIjoiaTZsR2szRlp6eFJjVWIyQzNuRVE3c3lISmxZIn0.eyJhdWQiOiJodHRwczovL2dyYXBoLm1pY3Jvc29mdC5jb20iLCJpc3MiOiJodHRwczovL3N0cy53aW5kb3dzLm5ldC83NTYzNTY2OC03OGNlLTQzNDMtODMzYy0xOWM5ODkzNTRkZWYvIiwiaWF0IjoxNTM5NjExMjk2LCJuYmYiOjE1Mzk2MTEyOTYsImV4cCI6MTUzOTYxNTE5NiwiYWlvIjoiNDJSZ1lNaWExaldMdTJqUmkvWjlQenU4bHZkUEJRQT0iLCJhcHBfZGlzcGxheW5hbWUiOiJLRVlPMzY1IiwiYXBwaWQiOiI1MmQwMTdmZi1lY2ZjLTQ2NjgtYjZkZi0zZDNlZGYwZDFjNjIiLCJhcHBpZGFjciI6IjEiLCJpZHAiOiJodHRwczovL3N0cy53aW5kb3dzLm5ldC83NTYzNTY2OC03OGNlLTQzNDMtODMzYy0xOWM5ODkzNTRkZWYvIiwib2lkIjoiMjM0ZDhmZTctNmYwZC00NmEwLWI1YmYtNzg1MWY0ZmFmNmMyIiwic3ViIjoiMjM0ZDhmZTctNmYwZC00NmEwLWI1YmYtNzg1MWY0ZmFmNmMyIiwidGlkIjoiNzU2MzU2NjgtNzhjZS00MzQzLTgzM2MtMTljOTg5MzU0ZGVmIiwidXRpIjoiUDNvc0hHdHQyMFdRTXhkLVFxcWNBQSIsInZlciI6IjEuMCIsInhtc190Y2R0IjoxNDQ3MDYyNTMyfQ.prmIaq8PzXfeovQPeIYS20xvZqpjPH-DvZNwQ3v08KOhTnfFaiCkxtw2wh1B37QQDbOveYqCWRi2CE6Uwpb6zg3-tFh1ma852HDqnJHYCKPajxeW9oIewAnCagB5FzOLQRT_EbX-lEREQVcPUHSZpRNmAWEM2MOZjDnkWun_aqohf_1op7Cy40Ol_PkRzoEgmA7pbXeI28IMPW3S4a5M_hBo_MZzRbVdxuG8YQKkVMWX0wAhpLHAYbdF1Rv5sITEpBP-KHdgJkTswLs3xvIRLyXxrXobG1aVQihr7LHFoCIU0NAcCUQLS2xkePuYGRB09k7hFQsbSNxoJSywBZWk7w
non working token for directory B:
eyJ0eXAiOiJKV1QiLCJub25jZSI6IkFRQUJBQUFBQUFDNXVuYTBFVUZnVElGOEVsYXh0V2pUUS1NMnBUdmVjYTgzUXFuVmlBWWpJX0dLNHZrMTBMYVF2dGF5SGQ0WmZDVlRySm0wSmtOVDU2UlJSU0NuUlFPU0k0aVNHdXZZZ1cxelpaTE9KTkJTVHlBQSIsImFsZyI6IlJTMjU2IiwieDV0IjoiaTZsR2szRlp6eFJjVWIyQzNuRVE3c3lISmxZIiwia2lkIjoiaTZsR2szRlp6eFJjVWIyQzNuRVE3c3lISmxZIn0.eyJhdWQiOiJodHRwczovL2dyYXBoLm1pY3Jvc29mdC5jb20iLCJpc3MiOiJodHRwczovL3N0cy53aW5kb3dzLm5ldC84MTFjNjA2OS1kZDE4LTRmN2UtOTlhMy1lNjA2YzMyYjhhMjAvIiwiaWF0IjoxNTM5NjExMjI1LCJuYmYiOjE1Mzk2MTEyMjUsImV4cCI6MTUzOTYxNTEyNSwiYWlvIjoiNDJSZ1lPZzlraUZYR3BxNCtVMko1NHAvL2N2M0FRQT0iLCJhcHBfZGlzcGxheW5hbWUiOiJGZXRjaGluZ1VzZXJzQXBwIiwiYXBwaWQiOiJiNDAyZjI5Ni05OTAxLTRjNmMtYjA2MC1hNGI1M2VjNmMzMDQiLCJhcHBpZGFjciI6IjEiLCJpZHAiOiJodHRwczovL3N0cy53aW5kb3dzLm5ldC84MTFjNjA2OS1kZDE4LTRmN2UtOTlhMy1lNjA2YzMyYjhhMjAvIiwib2lkIjoiYzIyZWJmNmEtZDNkYS00ZGRjLWIzZTYtOWFhY2VmZWY3MmE4Iiwic3ViIjoiYzIyZWJmNmEtZDNkYS00ZGRjLWIzZTYtOWFhY2VmZWY3MmE4IiwidGlkIjoiODExYzYwNjktZGQxOC00ZjdlLTk5YTMtZTYwNmMzMmI4YTIwIiwidXRpIjoiNk4xRnBkRVZEMGFvRnM0UndVRGZBQSIsInZlciI6IjEuMCIsInhtc190Y2R0IjoxNTM5MTU0MTkxfQ.l_7qgXkco5FWR7pbX5rQzAtvnrb1e6xOr5byrvkYDcyNa85KmCu5b6ArfjxTmeDR82XTmYw51n2YAbWl2q8R58dqELOguddwnKkBBCiMwKsD_UvG2oX_M9ZMy-Lc8lERduolyST7D0BZSoYCNe9f0j85AXIOgXr_yMA5MrVz7qSVFKZ1if2BR9YvvMCphW2uQCrebEJAnchyxHiCb5refnhm2sfsDBRJqd5NWwK0-a956a6dC2zg59JbW55-3wezQOfXKYzC5ybzO7l1hV41EnJ4atBW6EvR2er7WyCAFb1Y1hSB_wgZSo7pC4LnQRRm9KXq-x2aSRKiUSg265K0RQ
You need to receive Admin Consent for an administrator of the tenant. I'm assuming that because this happens when hitting /users, you've requested either User.Read.All or User.ReadWrite.All. Both of these require Admin Consent before a normal user can authenticate and provide User Consent.
I wrote an article a while back that you might find this helpful here: User vs Admin Consent. The examples target the v2 Endpoint while it sounds like you're using v1. That said, the same consent models and workflow apply to both v1 and v2.
This is my scenario:
As an administrator on Azure I want to add an application for my colleagues. This application will access the Microsoft Graph API to access e.g. their calendar or OneDrive files. I'm using a PHP-application for my Proof-of-Concept.
The user must be able to do three things: review what this application needs as permissions, give consent, and later be able te revoke the consent.
I have tested this by using Microsoft's Graph Explorer website. It correctly asks for consent (when logging in as a different user!). And when this users logs in to portal.office.com can revoke the access to the Graph Explorer.
However, I cannot seem to get it working for an application I built myself. In Azure I go to "App registrations" and setup the keys etc. In the permissions I make sure that no option is selected that requires admin-consent. I have selected a few in the category 'Delegated permissions".
THe PHP app wil not run on Azure IaaS/PaaS but hosted somewhere else.
What suprised my is two things:
- in my PHP-application I have to ask for a consent screen to appear. If I'm not asking for it, the app will skip it. Strange.
- in "My Account" it still says that the administrator granted access.
I've looked at the answer below, but that doesn't help either.
How to revoke access to Microsoft APP for a user in php
So, basically I'm looking for the same scenario as when I'm building an app to access e.g. Google Contacts. I've built that integration and works as expected and outlined above.
Any thoughts anyone?
Oke, after conferring with Microsoft this is what I came up with.
The problem is that some permissions/scopes require admin consent. In that case a number of things happen:
a user is not forced to give personal consent
a user cannot revoke consent through the portal.office.com portal (My Account--> Applications)
if the permission requiring admin consent is removed, none of the two situations above change!
So, If you setup an application and you accidentally select a scope requiring admin consent, you're in trouble.
Furthermore, there is a global setting you should enable so end users will see a consent screen at all.....
PS C:\Users\xxxx> Connect-MsolService -credential $msolcred
PS C:\Users\xxxx> Get-MsolCompanyInformation | fl DisplayName,UsersPermissionToUserConsentToAppEnabled
DisplayName : <your domain>
UsersPermissionToUserConsentToAppEnabled : False
Have a look at this link.
The new Azure portal gives a better list when choosing the permissions/scopes. In the second column there is an indicator for 'admin consent' that is missing in the v1-portal. So switch to the new portal and refrain from using those permissions requiring admin consent.
I have created a video to show you exactly what's happening: http://sendvid.com/urqpzeg2
I'm simply trying to give my application privileges to read directory data, and it fails with the following error:
Failed to add application Windows Azure Active Directory's
permissions. Error detail: Unable to complete the request due to data
validation error.
I created the app via the Portal, and then added it to the Company Administrator role via Powershell. I couldn't assign permissions before or after giving the app the Company Administrator role.
I'm logged in as the Directory owner.
Anyone any ideas?
I also could reproduce this issue. Based on the video, it seems you want to grant the app-permission to the b2c application. As a workaround, we can register a new normal application for the b2c tenant on the old Azure portal like figure below:
Then we can use this app to call the Azure AD graph REST and you can also see the required mission already be set in the new portal like figure below:
And for the original issue, I am also trying to report it internally.
I think this should be an easy fix but I've been looking at it for hours. I downloaded this sample on using ADAL with Xamarin and I'm just trying to get it to work as expected in the UWP project.
I am pretty sure my issue is in my Azure Portal configuration as I've changed the values in the sample correctly. Here is what I have done in Azure Portal though
Made an Active Directory
Made an application in that directory for a native app
Configured these permissions and granted all permissions on each for now - Windows Azure Active Directory, Microsoft Graph, Windows Azure Service Management, Office 365 Management APIs
In the app, after signing in, the app posts a AADSTSTS65001 the user or administrator has not consented to the use the application with id {id}
-but I never actually get a consent prompt, and I am already a user in the active directory.
Any ideas?
After build Msal is the supported library that handles ad authentication. So for xamarin you could check the samples for the newest library
Consent only gets triggered once per user (unless admin consent is performed in which case it doesn't show up at all for users).
Once consent granted, any changes to what permissions the app needs are not automatically added to existing consents nor does the system automatically prompt the user again for consent.
I suspect this might be your case, basically you started out setting up your app to required basic priviledges, ran the app and consented. Then you added more priviledges, some of which required admin consent, and ran the app. Because you had already consented, you weren't prompted again, but that initial consent didn't include those new permissions so you get an error.
You should be able to remove existing consent via Access Panel:
Go to https://myapps.microsoft.com
Find your app and click on ...
Select Remove.
NOTE: You can also do this via Graph but it requires a lengthy explanation.
There is a way to manually trigger the consent through the browser too if this is a once-only issue.
https://login.microsoftonline.com/<tenant>/oauth2/authorize?client_id=<client ID>&response_type=code&redirect_uri=<redirectionURI>&response_mode=query&resource=<resource ID for the AAD resource to access>&state=12345&prompt=consent
I have currently set up a AAD instance and I am authenticating my users against it via my web app, and it’s working great.
When I added and configured the application on AAD, I added the required Application and Delegated Permissions to access the Office365 Calendar API. However, the only thing that is missing is that during the login flow users aren’t being prompted to grant consent for the permissions, as it should happen from what I’ve read in your docs: https://msdn.microsoft.com/en-us/library/azure/dn132599.aspx#BKMK_Consent
I’m not sure what I’m missing. Apparently, from the docs,
After the user has signed in, Azure AD will determine if the user
needs to be shown a consent page. This determination is based on
whether the user (or their organization’s administrator) has already
granted the application consent. If consent has not already been
granted, Azure AD will prompt the user for consent and will display
the required permissions it needs to function. The set of permissions
that is displayed in the consent dialog are the same as what was
selected in the Permissions to other applications control in the Azure
Management Portal.
So maybe somehow I have already probably implicitly granted admin consent for those permissions, but I don’t know how that happened.
I've attached the permissions I configured on the AAD App.
Any help would be appreciated.
If an admin creates an application in their tenant using the AUX portal (manage.windowsazure.com), and requests permissions to other applications, then users in that same tenant are pre-consented for that application. Note this behavior is NOT true for our other App Registration Portals (portal.azure.com or identity.microsoft.com)
I believe this is why you are not seeing the consent dialogue when user's in your tenant are signing into your application. If you would like to push the consent dialogue experience, there are a few different things you can do:
You can use query strings to prompt "consent" or "admin_consent" during login. Check here: https://msdn.microsoft.com/en-us/library/azure/dn645542.aspx
You can delete the service principal for your application from your tenant using AAD PowerShell. You can learn how to do that here: https://msdn.microsoft.com/en-us/library/azure/dn194113.aspx
You can have a user from another tenant try to login to your multi-tenant application.
You can create your application under a non-admin account.
I hope this helps!
Shawn Tabrizi
Try this:
What is the Resource parameter in Windows Azure AD tenant application oAuth 2.0 specification
Changing the resource parameter to https://graph.windows.net did the trick for me.
Furthermore, Microsoft support suggests disabling all permissions except "Enable sign-on and read users' profiles", apparently to avoid permission related problems. I understand that this is not a solution in your case, but at least it gives you a test case.