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.
Related
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
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.
As you probably know, I am creating a multi-tenant azure application, which is using the B2B functionallity.
I am testing the B2B functionality and after some research I got a working sample.
Small summary: User authenticates against common authority, first token is acquired via common authority with the authorization code and from then, everytime I need a service client, I try to obtain those tokens from the 'current tenants' authority.
When I request 'Me', it only works against the home tenant. When I request me with a trusted tenant, I got an error that my user identifier does not exist in the directory. Probably because user does not actually exist in the trusted tenant.
When I request Users, it works fine. I can get both, home tenant users and trusted tenant users.
Is this normal behaviour?
Is this something I need to handle programmatically or would this been solved by using the AD graph?
(So when I know I need user info, just query the home tenant?)
Or is this a bug?
Any thoughts on this would be greatly appreciated!
Guests added to a directory via the B2B Collaboration feature will not work correctly on multi-tenant apps or the Microsoft Graph if you're using the common endpoint.
The common endpoint will always authenticate the user against his/her home tenant, not against any tenant where (s)he is a guest.
In order to successfully query /me for a guest, you'll need to have them sign-in through the tenant specific endpoint for the tenant where they're a guest.
See my answer to this other post for a more in-depth explanation / context:
Can users from an unmanaged Azure AD directory, sign into an Azure AD multi-tenant application which resides in a different directory?
I have noticed that when you want to switch between tenants, you need to re-authorize against the current tenant.
I got it working this way:
1. First sign-in needs to be done against the common endpoint.
2. Every time I need a token for certain resource, I try to get the token silently.
=> This can throw 2 different AdalSilentTokenAcquisitionException
Nothing found in cache, also no refresh token found
=> In this case, I redirect the user to the login page again.
When you switch between tenants, and it is the first time you want to login using a tenant where you've been trusted, you can get a error like: User or admin should be given consent for this application. Although the admin from his home tenant has added the application in the directory for the home tenant. Anyone who knows why this consent is needed? So tenant A and tenant B admins have both been given consent. Why does a trusted user from B in A still needs to consent someway?
I was able to trigger the consent flow by redirecting the user to the authorization request URL.
So when I got an AdalSilentTokenAcquisitionException, and the error code is "failed_to_acquire_token_silently" then I had to redirect the user to the URL generated by the authContext (authenticationContext.GetAuthorizationRequestUrlAsync) when the cache had been cleared, no refresh token will be found, then redirect the user to resign.
I've utilized the Partner Center REST API to provision tenants with orders/subscriptions. Now I want to start configuring the domains and users for the tenant I just created. My first step was to get a list of users using the Graph API https://msdn.microsoft.com/en-us/library/azure/ad/graph/api/users-operations as a test expecting to see the admin account. If I pass in the domain of the reseller account in the request URL, it shows me the reseller users. But when I put in the domain of the account I just provisioned, I get Invalid domain name in the request url. I'm using the resellers AD token to do this. I'm confused as it gives me the option to specify a domain, but I can only access my own.
What credentials am I supposed to be using here? I tried to use the user/pass that was generated for the admin account from the provision, but I get unauthorized_client when trying to get an AD token from the Graph API.
It is hard to directly address your issues here since they are a little broad, and I would need more specific details about the various tenants you are working with, how your app is provisioned, permissions your app has etc...
However I think there a few principals you can follow which may help you debug your issues.
All AAD Authentication happens within the context of a specific tenant. This means whenever you get an access token for a resource, the scope of that token is limited to the boundaries of the tenant.
To authenticate with a client application in the context of a tenant, you must have the app registered in the tenant you are trying to access (line of business application / single tenant) or you have to make the app multi-tenant, in which case your app should be able to function in the context of any tenant... if the right provisioning has occurred.
Every tenant where your app is trying to function must have a service principal for the application provisioned in the tenant. This service principal represents your application's identity in the context of that tenant, and acts as a place to store the permission your application has in the context of that tenant. Most normally, this service principal gets provisioned into a tenant after a user from that tenant has consented to use the app as a part of the login experience.
If you are trying to use user context (authorization code grant flow) to retrieve details about a tenant, you must ensure that that user is present in the directory you are trying to query. For example a user U can exist in their home tenant T1. If you try to query another tenant T2 using that user account, you will get any number of errors describing that the user account does not exist etc. You can remedy this by creating a guest account for U in T2, in which case there will be a brand new user object created in T2 which links to the original user object in T1. None the less, the user object should always be present in the tenant you are trying to query.
If you are trying to sign into an application with a user account that is in T1 and T2, you need to be sure to specify the tenant you want to actually get the token for. By default, if you use the common endpoint, you will get a token for the users home tenant. However, it is perfectly valid to get a token for the secondary tenant, as long as you specify that to our Token Service when making the request.
Finally the client application you use to make these requests needs to have the right permissions to the Graph API if you want to make specific calls to the Graph API. Every tenant needs to individually consent to the application in their tenant context in order to provision the correct permissions to their application.
With those principals in mind:
The error you are getting with "unauthorized_client" seems to be an issue with application provisioning in the secondary tenant. Please make sure to first login to the application with a user from the secondary tenant, and make sure that user has the correct permissions to consent to your app (a tenant admin is best here).
For the second issue with "Invalid domain name in the request url" please try using some hints here.
Specifically this:
By using the myOrganization alias. This alias is only available when using OAuth Authorization Code Grant type (3-legged) authentication; that is, when using a delegated permission scope. The alias is not case sensitive. It replaces the object ID or tenant domain in the URL. When the alias is used, Graph API derives the tenant from the claims presented in the token attached to the request. The following URL shows how to address the users resource collection of a tenant using this alias:
https://graph.windows.net/myorganization/users?api-version=1.6.
I hope this puts you on the correct path to resolve most of your issues.
There are issues with sandbox accounts and Azure. Access to the Azure Management Portal for the sandbox isn't straightforward and at this time does not work properly. I had to create a free Azure account with my hotmail account, then link AD from the new account to my sandbox AD to bypass the bug. When adding a new directory to the new Azure account, select "Use existing directory", sign out, then sign into the sandbox account you want to link it to. Then create your app from the new account.
After getting my app setup properly and new credentials, I had to enable pre-consent with the instructions listed at the end of: https://github.com/Microsoft/Partner-Center-Explorer
Lastly, I had to login to the Graph API with the customers ID, but with the resellers credentials.
The scenarios on the Partner Center SDK website include a section "Manage user accounts and assign licenses" under the "Manage customer accounts" section.
These samples include creating users and assigning licenses and a link to a console test app.
As an aside, a new version of the Partner Center SDK has just become available here. It was released on July 5th. While there is no official change history that I can find, I can see that it includes some new classes such as CustomerUser. You may find it easier to use that library rather than hitting the REST API (depending on how much work you've already done).
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.