As you can see from the image, it's not letting regular users login to the application. How do I bring down this access to members? This is an azure active directory application. I can login just fine with an admin user but my regular accounts gets blocked. Note, I created the application with the regular account. I don't suppose this has something to do with it?
I've granted the app all delegated permissions. No application permissions though. I'm thinking there's something in the manifest I need to alter but I'm not sure and I've never messed with this before. So any help is appreciated.
You likely need to perform admin consent for the application. There are two ways to do this in Azure AD:
In the Azure portal, you can go into the App Registrations blade, then click on the App, click on Permissions, and hit Grant Permissions.
Construct a request to Azure AD with the extra parameter &prompt=admin_consent.
For example:
https://login.microsoftonline.com/common/oauth2/authorize?client_id=<AppID>&resource=<Resource App ID URI>&response_type=code&redirect_uri=<Redirect URI>&prompt=admin_consent
Related
I'm trying to manage multiple outlook calendars using a single account as a proxy, so all other accounts share their personal calendar with this "master" account and within this one i can add, edit or delete events "for everyone".
The problem is that i can't get the account grant the Calendar.ReadWrite.Shared to the app, even though that in my app this permissions are configured as recommended.
Azure portal - app permissions:
permissions of the app in azure portal
msalconfig:
msal configuration used
The "funny" thing is, with the account used to create the app in the first place everything works, but with any other account not.
I even created another app with the intended final account and nothing. This is the, incompplete permissions, resul:
actual result
This is the desired result:
desired result
If you just want to make a proxy to modify calendars for all users, have you tried application-only Auth and grant Calendars.ReadWrite permission with application type to it? Based on this permission official comment: Read and write calendars in all mailboxes which seems to meet your requirement.
TL;DR
How can I delegate my user permissions to a service principal in Azure Ad when the usual interactive way (e.g. web app with consent screen popup) is not feasible? This is because I cannot configure the MSI in the Azure Portal properly to work that way.
More detail
I want to grant an application permission to access the Graph API on behalf of a user. Usually, this is a well-documented scenario in which you create an app registration, acquire delegated user permissions by asking permission for the needed scopes, and then use these permissions in the app.
The app that needs Graph access is a background service that is to work on its own without user intervention/activity. For this use case, the common approach is to use application permissions. In my case this is not feasible, because application permissions require admin-consent and are all-or-nothing kind of permissions. There is no way this will be granted for me. Rightfully so, because its overkill.
But on the other hand that's really a pity. A pity, because I've found an example on how to assign Graph API application permissions directly to a Managed Service Identity rather than to a self-registered app. And my service (as an Azure Functions app) already has a MSI assigned to it. So this would be the perfect fit, b then again, there is no way I'll get those application permissions.
So what is the workaround? We have this one user principal which has all the required permissions we need for our background service. What I want to do is to delegate this user's permissions to the Function App/MSI. In order to do this, I used this SPA-template by the MSAL team to have something that will prompt me the permissions popup.
This however failed because the implicit oauth flow was not enabled. To remedy this, you usually need to update the app manifest in the portal. However, since this is a MANAGED service identity, and not a self-registered one, the MSI is not listed in the portal under app registrations. So I cannot set this property to true.
Doing the same via Azure CLI also failed because apparently the MSI is not identified as an app.
az ad app update --oauth2-allow-implicit-flow true --id <appId_of_MSI>
This yields the following error:
ResourceNotFoundError: Resource '<appId_of_MSI>' does not exist or one of its queried reference-property objects are not present.
It shows fine when doing this
az ad sp show --id <appId_of_MSI>
So in summary: I cannot complete the process of delegating that user's permissions interactively. Is there any other way? Maybe via CLI?
The fallback the solution is to create a separate unmanaged/self-registered app identity. But I want to really avoid this because then I would need to manage and rotate client (app) credentials again, which the MSI took care of for me.
Why o why can't I just assign fine-scoped application permissions 😒
Any help on this is greatly appreciated. Cheers.
In my experience Managed Identities don't support the scenario you are suggesting.
They do not have an app registration and in that way cannot authenticate users interactively.
I would go with your fallback solution; a normal app registration and use that to access Graph API on behalf of the user.
This is what we do in our projects at least.
App permissions -> Managed Identity if possible. Delegated permissions -> normal app registration + secret/certificate in Key Vault, retrieved with Managed Identity.
My AD tenant has user consent disabled, i.e., all permissions added to AD app registration need an admin consent.
For an application using static permissions/scopes (v1.0 OAuth/OpenId endpoint), is it possible to add new permissions such that until the admin consent is granted, users can continue using features which require only the existing consented scopes?
Microsoft docs say: "The app needs to know all of the resources it would ever access ahead of time. It was difficult to create apps that could access an arbitrary number of resources." Does it mean that for my scenario, all users need to wait for admin consent before they can access the app?
I receive the below error when a user tries logging in to the app using the Open ID Connect flow. For reference, my login URL is similar to https://login.microsoftonline.com/{tenant}/oauth2/authorize?response_type=id_token&client_id=b8ad6a99-cd23-40a6-a1b4-1184af990aa2&redirect_uri=https%3A%2F%2Flocalhost%2F&state=13ccfb84-cfd1-4cb0-bfe3-bb2c227e19f7&client-request-id=4d76947a-0000-48af-aeff-7bc2d5e40000&x-client-SKU=Js&x-client-Ver=1.0.17&nonce=ef1caa16-d3fe-4523-a9c9-000000000000
is it possible to add new permissions such that until the admin consent is granted, users can continue using features which require only the existing consented scopes?
Yes, you can.
When the admin consent the API permission of an AD App(App registration), the permissions essentially will be given to the service principal(Enterprise application) in your AAD tenant. Actually if you use the AD App in your tenant, the permissions are essentially from the service principal.
You could refer to the screenshot below, there are four permissions, the two permission has been granted.
Navigate to the Overview, click the option Manage application in local directory.
Then in the Permissions, you will find the two permissions which have been consent.
When you add the new scopes, the app will keep working, but it will only be able to access the old scopes until the admin consents to the new scopes.
Thanks!
Alex Simons
When registering a native application on the Azure AD 1.0 endpoint, and assigning Graph API permissions, it seems like consented permissions are 'cached' somewhere and can't be managed properly.
Example scenario:
Application registered and permission scopes (incl. ones requiring admin consent) assigned.
Administrator consents to the permission scopes
Simple user can use the app with consented permissions.
Permission scopes change (adding a new one for example)
Same admin doesn't get the consent form anymore
Simple user is stuck with "consent required, have an admin account?"
Another global admin must use the app for the first time to trigger the consent page.
Note that #7 doesn't always work; even if the other admin provides consent, simple users can't get through sometimes.
This is a multi-tenant application, yet when start using it in another tenant, I can not see its consented permissions in the AAD portal under enterprise applications.
Shouldn't permissions that have been consented to be listed in other tenants so that the admin can at least see what has been consented to?
Also, when I register an app on the V1.0 endpoint in my own tenant, I have an option to 'grant permissions' centrally, from the Azure AD portal for my tenant.
This option isn't available if I'm looking at an application that was registered in another tenant.
Am I overlooking something? Any help much appreciated.
When you change permissions, it does not automatically re-consent (for user or admin). You can find a detailed overview of this at Understanding user and admin consent.
You'll first need kick off the Admin Consent workflow. For a multi-tenant app this is done by adding prompt=admin_consent to your OAUTH URL and having an Admin authenticate.
Once that is done you can also force existing users to re-consent as well by adding prompt=consent to your Auth URL.
I have 2 tenants:
One for my organization, where I manage users (A)
One that I manage the applications and permissions (B)
My webapp is on tenant A and I configured authentication on the portal using Azure AD on tenant B.
On tenant B I registered the application with only one permission which does not require admin consent: Windows Azure Active Directory > Sign in and read user profile.
When the user logs in he gets the following error:
AADSTS90093: 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.
I believe that this error should not be raised, since the only permission required by the application doesn't required admin.
EDIT
This is the URL that I am redirected to when I try to access the application when I'm not logged in
https://login.microsoftonline.com/d6ac45af-3289-4f79-a826-27824e1c467d/oauth2/authorize?response_type=code+id_token&redirect_uri=https%3A%2F%2Ftechnipfmc-tools-app-test.azurewebsites.net%2F.auth%2Flogin%2Faad%2Fcallback&client_id=d340f0ed-5eb3-43e8-9a50-c449649f3ee1&scope=openid+profile+email&response_mode=form_post&nonce=1895ec0ffef64447bbb712bdae61c7fb_20170521070654&state=redir%3D%252F
EDIT 2
I found out 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.
I don't know why had to do that since I'm only using permissions that don't require admin consent.
There are several potential problems with your setup:
Your authorization request is set to a specific tenant, the one with tenantId d6ac45af-3289-4f79-a826-27824e1c467d. Only users from that tenant will be able to log in. If this tenantId corresponds to the one for your organization, where you manage users (A), then disregard this point. Otherwise you should either replace this with the tenantId of that tenant or with common which will allow users from any tenant to sign in.
Your application is not multi-tenant. For testing purposes, I replaced the tenantId with common and wasn't able to use this with my test tenant due to the following error: AADSTS70001: Application with identifier 'd340f0ed-5eb3-43e8-9a50-c449649f3ee1' was not found in the directory <MY_TEST_TENANT>. This indicates that the application isn't configured as a multi-tenant application. This is something you must explicitly turn on.
Your organization's tenant (A) might have disabled the ability for regular users to consent to applications. If this capability is disabled, admin consent is always required for the application to be set up in the tenant. To test to see if this is the case, address points #1 (use /common/) and #2 above and try with any other tenant. If you are able to consent with that other tenant but not your organization's tenant, then you'll know that admin consent is required for your organization.
You should check out the How to sign in any Azure Active Directory (AD) user using the multi-tenant application pattern article as it explains all of the points above in more detail.
I think that error appears when you are passing "&prompt=admin_consent" in the Login URL.
Even though you are not requesting Admin permissions, if you pass that query string, it will try to show you a consent dialogue so that you can consent on behalf of the whole tenant, which is an operation that only an admin can do.