I'm trying to fetch users from azure active directory using graph api. I've tried many ways, none of them worked, but let's stick to simplest one - using this instruction and some app to make http requests (I'm using postman) I'm able to obtain autherization token with no problem. After that I want to get users list using https://graph.microsoft.com/v1.0/users, passing token in header. Instead of the users list I get "Insufficient privileges to complete the operation." This error message is very confusing to me because app registration has now all possible permissions and service account that owns this app is in role of Global Administrator, so I believe there aren't any more privileges that this app could get.
Task of the application I'm developing is to merge users data from few companies and display users list on web page hosted on azure account of one of them. What's even weirder for me in all of this, is that for one these domains accesing users data using graph api actually works, so logically configuration isn't set correctly everywhere, but I don't really know what can be difference that makes one them work and others fail on "Insufficent privileges error".
As you are integrating AAD in app only applications, as the description at https://graph.microsoft.io/en-us/docs/authorization/app_only:
After you register the application, configure the application permissions that your service or daemon app requires.
So, firstly, you may check out whether you have configured the correct permission on Azure portal:
According to your error message:
Insufficient privileges to complete the operation
And the application permissions require that your application has admin privileges. You can try to upgrade the role of the AD application you use to a administrator permission. Run the following commands in PowerShell:
Connect-MsolService
$ClientIdWebApp = '{your_AD_application_client_id}'
$webApp = Get-MsolServicePrincipal –AppPrincipalId $ClientIdWebApp
#use Add-MsolRoleMember to add it to "Company Administrator" role).
Add-MsolRoleMember -RoleName "Company Administrator" -RoleMemberType ServicePrincipal -RoleMemberObjectId $webApp.ObjectId
Related
I'm working with an app registration that has a secret defined. Via PowerShell I am able to get the credential, but not the secret value. Function used is Get-AzADAppCredential This is expected behavior, no issue here.
To renew the secret I run two functions Remove-AzADAppCredential and New-AzADAppCredential.
I run these PowerShell cmdlets via a DevOps pipeline and use a service connection with permissions in Azure portal.
I noticed that, when we create a service connection from DevOps to Azure, the service principal gets the role Cloud application administrator automatically assigned.
This role includes the permission "microsoft.directory/applications/credentials/update".
So the above (remove + new) should work, but it does not...
DevOps returns an error:
Az.MSGraph.internal\Remove-AzADApplicationPassword : Insufficient privileges to complete the operation.
Az.MSGraph.internal\Add-AzADApplicationPassword : Insufficient privileges to complete the operation.
PS. Using Az.Resources version 5.4.0 when working with the PowerShell functions.
Anyone got any idea what I'm missing?
Thanks.
Insufficient privileges to complete the operation.
The error comes when the user doesn't have sufficient privileges in AAD and doesn't have Write permission for the selected Azure Subscription.
Note: If you have Cloud application administrator privileges of the user, this role grants the ability to manage application credentials. Users assigned this role can add credentials to an application and use those credentials to impersonate the application’s identity. If the application’s identity has been granted access to a resource, such as the ability to create or update User or other objects, then a user assigned to this role could perform those actions while impersonating the application.
Make sure to check once if you have Global Administrator Access. If you have the access you can able to Modify the secret.
Users who are assigned to the Global administrator role can read and modify every administrative setting in your Azure AD organization.
The permission issue may happen due to
The user has only guest permission in the directory
The user is not authorized to the add applications in the directory
Refer here for detailed information
To be able to update a secret on an app registration, through DevOps, using a service principal, with minimal permissions, first make the service connection owner on that random app registration.
Next, add the Application.ReadWrite.OwnedBy application API permission on the app registration that's linked to the enterprise application. Not on the app registration where the service principal was made owner.
Than renewing the secret works fine.
It remains a question though why the role Cloud application administrator isn't sufficient because microsoft.directory/applications/credentials/update is included in that role, and that should also be enough.
I need to register an application in Azure AD using PowerShell. I plan to use the New-AzADApplication cmdlet. The cmdlet documentation states the following:
Below are the permissions needed to create an application:
Azure Active Directory Graph
Application.ReadWrite.OwnedBy
Microsoft Graph
Directory.AccessAsUser.All
Directory.ReadWrite.All
I've learned that these permissions are scopes, which is a new concept to me and something I don't know how to deal with in Azure. I found this short demo, which shows these scopes can be managed as API permissions from the Azure App registration context. However, that demo shows the scopes being managed after the application has already been created. How can I establish the proper scopes before the application is created?
Or, more generally, how can I ensure that I have the appropriate permissions to execute the New-AzADApplication cmdlet?
The application that needs those permissions is Azure AD PowerShell in this case. If it didn't have a service principal in your AAD tenant yet, you would be asked for consent to those scopes on first login when using the Connect-AzureAD cmdlet.
In my experience, the service principal that it uses already exists in your tenant. So it already has the needed permissions. But what will also matter is your user permissions. Since it uses delegated permissions, it is acting on behalf of your user. In order for it to be able to create the app, it needs to have the necessary scope/delegated permission and your user must be able to create applications.
The cmdlets do also support acting as a service principal/app, in which case application permissions given to the app used to authenticate would apply, not delegated permissions. But that's another case that I don't think you are asking about.
Applications are able to note which permissions they require (both delegated and application) in the app registration portal. This allows use of the /.default scope and the Azure portal's "Grant admin consent" option.
You can follow this process:
1.Go to your application in the Azure portal – App registrations experience, or create an app if you haven't already.
2.Locate the API Permissions section, and within the API permissions
click Add a permission.
3.Select Microsoft Graph from the list of available APIs and then add
the permissions that your app requires.
4.Save the app registration.
I am working on documenting integration with Azure for later use by colleagues. This is for obtaining an AAD bearer token (done) and using it to get a Logic Apps callback URL. There is the problem, which is to correctly permit the client application. I am not finding documentation on the correct scope to set in the Portal. Also, I don't have the admin permissions myself to try and, so trial-and-error is not an option.
Right now, I have registered in Azure an app with only default permissions. So, when I try the desired action, I get back the error response:
{
"error": {
"code": "AuthorizationFailed",
"message": "The client '{Client Id}' with object id '{object id}' does not have authorization to perform action 'Microsoft.Logic/workflows/triggers/listCallbackUrl/action' over scope '/subscriptions/{subscription id}/resourceGroups/{resourceGroup Name}/providers/Microsoft.Logic/workflows/{workflow name}/triggers/manual'."
}
}
In trying to get the app the right permissions, I am encountering the error in Azure portal:
You are adding permission(s) that require an admin to consent, users will not be able to use the application until an admin grants permissions to the application.
Which I expect, so I am seeking to tell my admins the exact permission(s) that need to be granted or delegated.
Possibly this can be done in PowerShell and easier than in Portal, or even CLI. I am not wedded to a particular method, just looking for direction or documentation on how to correctly configure the client app. I figure I need to give our app at least Contributor access to the resource group via the Access Control (IAM) tab. However, in this subscription, I do not have the "Add" option there, suggesting I do not have permission to do it.
Right now, I am using the documentation at register your client application with azure ad but am not finding the steps toward correctly permitting the registered client when I am unable to try it out before explaining it to someone else. Maybe there is more detailed documentation, or a blog post someone knows of that I have not found?
Thank you
Getting the callback url at runtime requires permission to invoke the API action Microsoft.Logic/integrationAccounts/assemblies/listContentCallbackUrl/action. You can do this a couple of ways:
create a custom role with the required API access. This is nice from a least-privilege perspective, but you're limited to 200 custom roles and you'd need to document what the role is for and track that going forward
You could leverage the built in role of logic app contributor which has carte blanche on logic app apis.
Which ever you choose, the next step is to assign the service principal associated to your application (or the user or group account defined in AD) to the role. Here is a great walkthrough for the role assignment process using the portal or using the CLI, if you prefer
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.
Now I have one App in Azure active directory1, and a web api in Azure active directory2. My aim is to allow users in AAD1 and AAD2 can both login the App.
So far I've enabled App and Api as multi-tenant, added each other in the manifest as known client application.
The things I've not finished yet: add one as a custom domain into the other, add permissions btw api and app, and I met some problems on these two.
Right now my error msg is:
An error has occurred while authorizing access via Authorization Server: unauthorized_client AADSTS65005: Invalid > resource. The client has requested access to a resource which is not listed in the requested permissions in the client's application registration.
When I tried to give the access in the api, in the required permission list, I didn't see the web app (which is in the other directory). How should I do with it?
If I move both App and Api under the same directory, is there anyway that allows users from the other directory to login?
In order for you to see the Web API in Tenant 1 as an option for "Required Permission List", you need to provision the service principal for the Web API into Tenant 1.
You can do this a number of ways, but the easiest way may be to simply sign into the Web API by generating a Login URL. Once you login, using a user from Tenant 1, the service principal will be provisioned in the tenant, and then be an option available to select.
https://login.microsoftonline.com/common/oauth2/authorize?client_id=<appid>&response_type=code&redirect_uri=<replyurl>&resource=<resource>&prompt=consent
The other option might be to use AAD PowerShell to create a service principal based off your Web API App Id:
New-AzureADServicePrincipal
New-AzureADServicePrincipal -AccountEnabled $true -AppId $MyApp.AppId -DisplayName $App -Tags {WindowsAzureActiveDirectoryIntegratedApp}
Once you have successfully put the service principal on your required permissions, the error message you described above should go away.
In addition to Shawn Tabrizi's answer, you can also specify your API as a known client application of the App.
So in your App's manifest:
"knownClientApplications": [
"your-api-client-id"
]
Then if you try to authenticate to the App, it can do consent for the API as well at the same time.