I'm really hoping someone can explain why admin consent is required in our situation and, if possible, how we can avoid it. The following is a simplified version of our normal application in which I was able to reproduce the issue.
I control two tenants: T1, used for development and where all app registrations/resources live. And tenant T2, where I have control over all user settings and which we use for testing multi-tenancy.
In T1 I've registered two app registration named 'app-frontend' and 'app-api'.
Both have a required permission on User.Read on Graph. In addition app-api exposes an (admin and users) scope that is set as a required permission for app-frontend. App-frontend is also registered as known client application on app-api.
Now the behavior we would expect is that when a first time user requests a token for app-frontend, they are requested for consent and given a token after accepting. For any non-admin account this results in a 'Need admin approval' error though when testing with users from T2. When the required permission from app-frontend to app-api is removed, consent works fine for non-admin users.
I've gone through a number of answers on here to try and figure out why admin consent seems to be required here, but none of the suggested answers/reasons seem to apply in our case. To summarize:
The setting 'Users can register applications' is on in T2.
The setting 'Users can consent to apps accessing company data on their behalf' is on in T2.
User assignment is not required (for either app registration).
No other permissions are required by either app registration (so no application permissions are involved).
The problem appears for requests to both the v1 and v2 endpoints.
Most of these I would expect to also cause admin consent to be required when the only permission on app-frontend is User.Read, but the problem only appears when the required permission to the scope from app-api is present.
If any other info is required I would be happy to provide it, I've been stuck on figuring this out for quite a bit now.
Update:
Screenshots of the app permissions set on both registrations.
Front end app registration: Front end app registration
Api app registration: Api app registration
I didn't reproduce your issue on my side, see my steps as below.
1.create tonyFronEnd application and tonyBackend application in tenant A, both of them are multi-tenant application. Also, tonyFronEnd application has access to tonyBackend application. And File.Read doesn't need admin consent.
2.use user from tennatB to login in tonyFronEnd application
https://login.microsoftonline.com/common/oauth2/v2.0/authorize?
client_id=90ffbdb4-5b89-4bbc-9f90-d42b2419294c
&response_type=code
&redirect_uri=https://localhost:8080
&response_mode=query
&scope=openid api://08b3e812-2141-47af-a00a-75de13d3916d/Files.Read
&state=12345
Admin consent is not required.
update:(user consenet)
I've found a solution for the problem in our case:
The cause of the admin consent in our situation turned out to be the fact that the publisher of the app registration was showing as unverified. It was linked to the domain of our Azure tenant (*.onmicrosoft.com), which is not valid as publisher domain.
Surprisingly this appears to have influenced whether admin consent is required or not in scenario. After changing and validating the app registration to another domain, the requirement for admin consent instantly disappeared.
Also of note: This does not seem to apply to older app registrations. We have several app registrations from the end of 2018, which used the same domain (*.onmicrosoft.com). These app registrations do not appear as unverified in the consent screen however and also do not require admin consent. I suspect app registrations from before a certain change have been grandfathered in to not require consent.
this is delegated consent, not admin consent. Please understand the various types of permissions at Delegated permissions, Application permissions, and effective permissions
Related
My multi-tenant Azure application requires only the app-level EWS legacy permission full_access_as_app to run. This app-level permission can only be consented to by an administrator---it's extremely powerful because it gives the app read and write permissions over every EWS mailbox in a tenancy.
If I, as an admin for my Azure tenancy, grant my application only this single permission behind the scenes in AAD configuration, everything works fine when I run the application for my tenancy.
However when you create a new app in Azure, Azure always assumes you will want the user-level Graph API User.Read permission automatically. When you try to remove the permission you get this ominous warning:
And in the case when I leave it out, interactive OAuth consent forms don't work. The error message looks like this.
The client has not listed any permissions for 'AAD Graph' in the requested permissions in the client's application registration. Or, The admin has not consented in the tenant. Or, Check the application identifier in the request to ensure it matches the configured client application identifier. Please contact your admin to fix the configuration or consent on behalf of the tenant.
In other words, it appears that the application won't be able to run for anyone else's tenancy because their admins can't consent to it.
My hypothesis is that this is because Azure is using the User.Read permission to check whether the person signing in through the OAuth form is an administrator. In other words this permission is needed just this one time, before the application is ever run for the admin's tenancy.
Looking at the actual OAuth consent form, this does appear to be the case.The app wants to sign in and read my profile, to check if I am admin... or so it seems to me.
Am I right about this? Documentation I have been able to find is rather scanty.
I'm hoping someone has some insight into an issue I'm having with a newly registered app within Microsoft's Azure Portal (portal.azure.com).
My issue on login when I get the following dialog
The error code and message appears in the lower right corner;
AADSTS90094: This operation can only be performed by an administrator. Sign out and sign in as an administrator or contact one of your organization's administrators.
Configuration-wise, I believe I have this setup to not require admin consent, however there maybe something I'm missing.
My app is configured with;
Id Token, single tenant (web) application
Delegated, user consent permissions with no admin permissions
With the enterprise application, the configuration is set to;
Enabled for users to sign-in: Yes
User assignment required: Yes
Visible to users: Yes
4 users have been added with the Default Access role
Allow users to request access to this application: No (as they are assigned)
Last of all, within the azure directory itself under the Enterprise applications - User settings configuration I have set the company data user consent to Yes
When I navigate to either my application URL, or from the app within myapps.microsoft.com, both give me the above dialog requesting an admin consent.
I don't want to grant admin consent if not required, as it seems a bit like using a sledgehammer to solve the problem.
I feel like I'm either missing something big, or doing something silly - please help, and let me know if I can provide further information.
Edit 1.1:
My authentication request URL is: https://login.microsoftonline.com/<tenantid>/oauth2/v2.0/authorize?client_id=<clientid>&redirect_uri=<redirecturi>&response_mode=form_post&response_type=code id_token&scope=openid email profile offline_access User.Read User.ReadBasic.All Mail.ReadWrite&state=OpenIdConnect.AuthenticationProperties=<gibberish>&nonce=<gibberish>&x-client-SKU=ID_NET461&x-client-ver=5.4.0.0
(I'm using ASP.NET MVC combined with Microsoft's OpenId Connect authentication library)
When a user consents to an application which does not require assignment (in a tenant where user consent is allowed, and for an application requesting only permissions which do not require admin consent), two things happen:
Consent grants are recorded for the app, the user and the delegated permissions being requested.
The user is assigned to the app at a "default" app role.
The second step may seem surprising, but it serves a simple role: it ensures the user sees apps they've consented to in the Azure AD Access Panel (https://myapps.microsoft.com). (The Azure AD Access Panel will show a user all apps they are assigned to.)
It would defeat the purpose of the "user assignment is required" control if users could cause themselves to be assigned by triggering user consent. So, currently, when an application is set to require user assignment, users are simply not allowed to consent to the application.
Today, you have two options:
Ask an admin to grant tenant-wide consent for the application (e.g. Enterprise apps > Permissions > Grant admin consent, or App Registrations > API Permissions > Grant admin consent).
Configure the app to not require user assignment, and update the app's code to require the user be assigned to an app role by checking the "roles" claim.
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.
We've created a Multi Tenant Azure Application Which is registered by several other tenants, with a set of permissions to which an admin already gave consent.
Now we want to add some more permissions which require "Admin consent"
My question is what will happen?
I would expect, the application will keep running as before. But the new features (which require the new permissions) are not available until an admin from a different tenant renews the consent.
Worst case scenario is the application will not be available to other tenant's users, until an admin renews his/hers consent.
Add consent to these items
I actually wrote a blog article related to this: AADSTS90094: The grant requires admin permission, how to fix it and why it happens.
So the answer, as usual, is that it depends.
If:
A user is logging in
And some consent has already been given
And explicit consent is not requested (e.g. with prompt=consent or prompt=admin_consent)
Then the user will sign in successfully and the scopes in the tokens will be based on the previously consented scopes.
So it should continue to work as it did before.
Since an admin has already done consent for the whole org some consent is already granted for every user.
Though if you require consent, then they will be unable to log in...
But testing this scenario should not be overly difficult for you, and I do recommend it.
You can do the following:
If you don't have a testing version of your app in AAD, create it
Create a new AAD tenant/use another existing one
Go through onboarding with the test app
Change the permissions
Test login with a regular user
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.