[Azure AD]: Delete User Group Unauthorized - azure

I was Integration Azure Ad in my application User and Group i was maintain in local that the same scenario i was made in azure using Graph API.
The Create user, create Group, Add the member into Group and remove the member in group also working fine for me. but, the Remove group is not working. it's throw 403 forbidden.
The Sample Post Request is screen is
I was Selected all Application permission.in Microsoft Graph and Active Directory. and Grant Permissions.but, i also Get the Insufficient privileges to complete the operation.
My Access token is
eyJ0eXAiOiJKV1QiLCJhbGciOiJSUzI1NiIsIng1dCI6IkhIQnlLVS0wRHFBcU1aaDZaRlBkMlZXYU90ZyIsImtpZCI6IkhIQnlLVS0wRHFBcU1aaDZaRlBkMlZXYU90ZyJ9.eyJhdWQiOiJodHRwczovL2dyYXBoLndpbmRvd3MubmV0LyIsImlzcyI6Imh0dHBzOi8vc3RzLndpbmRvd3MubmV0LzFlNDVmNzc1LTlhMTAtNDQ1MS04YmI2LTRjNTVkMDgxMDI1Ni8iLCJpYXQiOjE1MDczNzUyNzQsIm5iZiI6MTUwNzM3NTI3NCwiZXhwIjoxNTA3Mzc5MTc0LCJhaW8iOiJZMlZnWU5qNjBKcEZwWkxyNTZFTm9WK2NGejZRQWdBPSIsImFwcGlkIjoiMGJhZTJjMTktMzEwNC00YWM3LTkzNjQtMGQ2NjI1YmU5NDc0IiwiYXBwaWRhY3IiOiIxIiwiaWRwIjoiaHR0cHM6Ly9zdHMud2luZG93cy5uZXQvMWU0NWY3NzUtOWExMC00NDUxLThiYjYtNGM1NWQwODEwMjU2LyIsIm9pZCI6ImU5OGRjYTkzLTI2MzktNDU0ZC1hMDg3LWNkZjIzNjg2ODhlMCIsInJvbGVzIjpbIkRldmljZS5SZWFkV3JpdGUuQWxsIiwiRGlyZWN0b3J5LlJlYWQuQWxsIiwiTWVtYmVyLlJlYWQuSGlkZGVuIiwiRGlyZWN0b3J5LlJlYWRXcml0ZS5BbGwiLCJEb21haW4uUmVhZFdyaXRlLkFsbCIsIkFwcGxpY2F0aW9uLlJlYWRXcml0ZS5Pd25lZEJ5IiwiQXBwbGljYXRpb24uUmVhZFdyaXRlLkFsbCJdLCJzdWIiOiJlOThkY2E5My0yNjM5LTQ1NGQtYTA4Ny1jZGYyMzY4Njg4ZTAiLCJ0ZW5hbnRfcmVnaW9uX3Njb3BlIjoiQVMiLCJ0aWQiOiIxZTQ1Zjc3NS05YTEwLTQ0NTEtOGJiNi00YzU1ZDA4MTAyNTYiLCJ1dGkiOiJMVHBWY3VxUFBFMm1uQ1FaYTBrSUFBIiwidmVyIjoiMS4wIn0.liMUK4oOBtNuU-AFHr0VfwFxiIV57pMdha8oae2Xu7tKgQR8HeSTdKm7Ex4s7n7GSAF-2YATXMdFGF5vvfrlF3ALMH8zvENJwY8BOrVsB516z_BROVmagvAKuPWoByRrlDPrhsalJBwwcy_ex1bG-sWvGSBoMpKy53EGWzMt9IF9CSp5IiiVp5xHXHog8BV-P-Bb98smOrnrTK7WhO0ZMkDIUCbfF-4QySwAbFJaUSZPqdZXA8XE-rt7RLZGlpbSpAv5Lmzb2V4mAioO1eSKEjoYQApifCyNHg76FgcRx10PPt1HO2yN9z6s7RaH6H1C1BABJRPaO58SCJI-BsgjFg
Anyone Know Help me.
Thanks in Advance.

Deleting directory objects isn't support at this time using application credentials.
This applies to both the Azure AD Graph and the Microsoft Graph.
The only way to delete objects is using user delegated auth with a token from a user that has sufficient permissions to do so (generally an admin).
PS: I can tell you are using application credentials and application permission because the token you shared, when put in jwt.ms has an appId and roles.

Related

How do I add administrator accounts for granting static permissions to my Azure AD App?

I have set up a Azure Active Directory App so that I can access the Microsoft Graph API with MSAL. However, I want to perform API calls without a user (https://learn.microsoft.com/en-us/graph/auth-v2-service) and as such I have added a few permissions that require "Admin consent" to my app. However, I cannot find a way to grant my app these permissions.
I've tried looking around the Azure portal for a way to grant these permissions but without success. I have also tried using the https://login.microsoftonline.com/{tenant}/adminconsent&... link to grant permissions, but unsucessfully so.
The response I received was
AADSTS500201: We are unable to issue tokens from this API version for
a Microsoft account. Please contact the application vendor as they
need to use version 2.0 of the protocol to support this.
I do not have an Azure subscription (not even the free one), but seeing as I was able to add apps to Azure AD as well as get access tokens and then make API calls on behalf of the authorized users I assumed I might not need a subscription.
I just made another app and now I have the grant consent button when I open the API Permissions view.

Identical Azure apps do not work in different tenants

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.

Azure Ad Application Permission

In azure ad application, We are giving permission to application and run our app. It give proper data, after doing this we remove all permission, then also we does not get unauthorized error. What is issue with Azure Ad permission? Is there cache issue, which we have to clear?
I don't know how you revoked the permission for your application but I assume you used the Azure Portal. The most likely reason is that you forgot to hit the Grant permissions button:
To revoke a permission isn’t currently available through the Portal. When you apply a permission a link is created between the application and service principal.
There are two types of permission grants between Applications and Service Principals.
Application grants are represented by AppRoleAssignments. These can be seen by using the graph api to get them for a particular Service Principal. Once you know the principal id for the permission you want to delete you can remove it using by sending a delete request to the delete endpoint. .
Delegated permission are represented by OAuth2PermissionGrants. Similar to AppRoleAsssignments there is a get method and a delete method.
Let me know if I need to make anything clearer or can help.

Authorization_RequestDenied when trying to get groups from Azure Active Directory using Graph API

I'm trying to get information about Azure Active Directory groups using the Graph API, but I keep getting an "Authorization_RequestDenied" response.
This question is similar to Insufficient privileges error when trying to fetch signed in user's group membership using Azure AD Graph API, but that question's answer didn't work for me.
Here's what I've done:
Logged onto the Azure portal using my Microsoft account (e.g. example#hotmail.com)
Set up an Azure Active Directory instance for testing. The domain of the instance is something like examplehotmail247.onmicrosoft.com
Created a user (TestMember#examplehotmail247.onmicrosoft.com)
Created some groups, and made the user part of those groups
Created an ASP.NET application configured to authenticate to AAD using OpenID Connect.
Registered the application in AAD, created client secret, reply URL, etc.
Modified the manifest of the application in AAD so that group membership claims are returned.
The authentication part works fine. After the user logs on, I can see all the information I expect (name, ID, etc.), along with claims containing the IDs of all the groups the user belongs to.
So far, so good.
Now, I want to translate those group IDs to human-readable group names. For this, I'm using the Microsoft.Azure.ActiveDirectory.GraphClient NuGet package, which provides a GetObjectsByObjectIdsAsync method. This method seems to be a wrapper for the getObjectsByObjectIds REST method.
To try and get this working, I've done the following:
In the Azure portal, I've granted the "Sign in and read user profile" and "Read directory data" permissions to my application.
Logged in to my ASP.NET application at least once using my Microsoft account
What I see: When I log in to my ASP.NET application using my Microsoft account, everything works. However, when I log in using the AAD account I created (TestMember#examplehotmail247.onmicrosoft.com), it fails with the following error:
[DataServiceClientException: {"odata.error":{"code":"Authorization_RequestDenied","message":{"lang":"en","value":"Insufficient privileges to complete the operation."},"requestId":"1234e0bb-3144-4494-a5fb-12a937147bcf","date":"2016-12-06T18:39:13"}}]
System.Data.Services.Client.BaseAsyncResult.EndExecute(Object source, String method, IAsyncResult asyncResult) +919
System.Data.Services.Client.QueryResult.EndExecuteQuery(Object source, String method, IAsyncResult asyncResult) +116
Trying the equivalent query using the REST api directly (i.e. taking ASP.NET out of the picture) gives the same result.
So what am I missing here?
Update: I also granted the application the following delegated permissions (to Windows Azure Active Directory): Sign in and read user profile, Read directory data, Access the directory as the signed-in user. However, it didn't make any difference.
Update #2: I even made the TestMember#examplehotmail247.onmicrosoft.com a Global Administrator for the AAD instance, and it still didn't help.
Update #3: Ok, so first, some clarification. After a user logs on, my ASP.NET app gets an authorization code from the OpenID Connect flow. Once I get the code, I'm exchanging it for an access token using AcquireTokenByAuthorizationCodeAsync. The access token is tied to the user, and so I want to rely on delegated permissions, not application permissions.
The problem was that although the proper delegated permissions were granted to my ASP.NET app in the Azure portal, the user never had an opportunity to consent to them.
I started over by creating a completely new app registration in azure for my ASP.NET app, and here's what I found: When a user logs on for the first time, they are asked for consent to whatever delegated permissions are required. However, if I change which delegated permissions are required after they've logged on for the first time, the user is not asked for consent (for the newly-required permissions) the next time he logs on.
This is definitely not what I expected, so I'm going to open a new question about this.

How do I add users to tenant via the Graph API?

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).

Resources