I use delegation permission to obtain access token authorization. The user is a global administrator
The scope of authority is offline_ access User.ReadWrite.All Files.ReadWrite.All
I request the API to get the Same tenant subuser drive file
https://graph.microsoft.com/v1.0/users/xxx/drive/root/children
Return to access denied
https://graph.microsoft.com/v1.0/me/drive/root/children Return is normal
Please help me
It is expected.
Please see the delegated permission Files.ReadWrite.All.
It allows the app to access all files the signed-user CAN access. This means that unless that user shares the file with you, you will not have permission to access it.
Let's focus on the application permission Files.ReadWrite.All.
This permission allows the app to access all files.
This difference is what makes you confusing.
So with delegated permission (user token), in addition to Files.ReadWrite.All, you still need to let others share the file with you before you can access it.
Related
Our GAE app has been running fine for years. I'm trying to switch to IAM roles to manage buckets from the default (fine-grained access). It doesn't work.
After switching to uniform access, I give StorageAdmin permissions to the GAE service account. At that point our code fails in getServingUrl():
String filename = "/gs/" + bucketName + "/" + fileName;
String url = service.getServingUrl( ServingUrlOptions.Builder.withGoogleStorageFileName(filename ));
An IllegalArgumentException is thrown with no detailed error message.
So, I play around with the permissions a bit more. I add allUsers with StorageAdmin permissions to the bucket. Two interesting things to note: 1) I can access the image directly from a browser using: https://storage.googleapis.com/bucket/filename.png. 2) Nothing changes on our app. Still get the same behavior as described above!
To me, this makes no sense. Doesn't allUsers mean anyone or any service can access the files? And why doesn't adding the GAE service account work?
There are two types of permissions allowed by the cloud storage to access any bucket or objects, these are IAM and ACLs , so if you are using IAM to access buckets then make sure that you are following the norm mentioned in the documentation as:
In most cases, IAM is the recommended method for controlling access to your resources. IAM controls permissioning throughout Google Cloud and
allows you to grant permissions at the bucket and project levels. You should use IAM for any permissions that apply to multiple objects in a bucket to reduce
the risks of unintended exposure. To use IAM exclusively, enable uniform bucket-level access to disallow ACLs for all Cloud Storage resources.
If you use IAM and ACLs on the same resource, Cloud Storage grants the broader permission set on the resource. For example, if your IAM permissions only
allow a few users to access my-object, but your ACLs make my-object public, then my-object is exposed to the public. In general, IAM cannot detect
permissions granted by ACLs, and ACLs cannot detect permissions granted by IAM.
You can also refer to the stackoverflow question where a similar issue has been faced by the OP and got resolved by changing the permission in access control list of the object as READ or FULL_CONTROL.
I am trying to remove the assigement for a particular object id.Below is the error I am getting.
I am attaching my service principal access level in AD.
When I am trying to exectute the same command using devops pipline I am getting different errror.
To remove the access what is the permission is required to my service prinicpal in API permission
section only read can work ? and why I am geeting the clould.execption errror. Any advice.
I can reproduce your issue, the command Remove-AzRoleAssignment will call the Azure AD Graph to validate the $objectid you passed, so you need give the Application permission Directory.Read.All of Azure AD Graph(not Microsoft Graph,not Delegated permission).
After adding the permission, there is some delay(30m - 1h), then test the command, it works. (I test in local, the same in cloud shell)
Note: Except the permission in Azure AD, your service principal also need to have the permission in the subscription/specific resource scope, e.g. the servcie principal is the Owner/User Access Admin role in the Access control (IAM) of the subscription/specific resource scope(in your case, the storage account). If the service principal does not have the role, please add it as below.
In Azure Devops, you don't need to login with Connect-AzAccount(Actually in cloud shell, you also don’t need to login, but if you want to do so, it's also ok), it will login automatically with the service principal related to the service connection(Task version >= 4.*).
So please make sure the secret of your service principal is correct and the connection was verified. To run Remove-AzRoleAssignment, also add the permission above for the App Registration related to the service connection.
Then test it, it works.
Joy Wang is correct, but I would like to add that, you shouldn't give a service principal owner to the entire subscription if its not absolutely needed. its a security consideration.
The better way would be to create a custom role in the subscription with only the permissions you need. in this case, some of the permissions you'll need to get it to work in the custom role are:
"Microsoft.Management/managementGroups/read"
"Microsoft.Authorization/roleAssignments/*"
"Microsoft.Authorization/roleDefinitions/*"
Also, I tried to run get-azroleassignment without directory.read.all with a service principal, and it works as long as you have the role permissions assigned in the subscription. that leads me to believe the powershell get-add-remove-azroleassignment does not use the graph api permissions at all.
Update
As joy stated, its possible that the custom role may be useless as it could technically give itself ownership, however, here is proof that you dont need api graph permissions for the service principal to do this:
Update2:
proof that removing the subscription rule, and only having api permissions does not work, it can only get the role assignments for itself, (the service principal itself) nothing else.
This situation made me create a real monstrous work-around, but sometimes, you don't have an option right?
The problem is basically bumping into 503: 'serviceUnavailable' messages when several (specific?) Azure AD Application permissions are set in your Azure AD Application, which should not happen.
Context and technical queries
The context is specifically for Application permissions (app-only auth) and NOT delegated permissions. Token is retrieved by:
HTTP POST https://login.microsoftonline.com/e6fcb01a-f706-4b1b-872b-1e7645d78491/oauth2/v2.0/token
headers:
Content-Type=application/x-www-form-urlencoded
-------------
client_id=<App GUID>
client_secret=<App SECRET>
scope=https://graph.microsoft.com/.default
grant_type=client_credentials
/sites/root query retrieved by:
HTTP GET https://graph.microsoft.com/v1.0/sites/root
headers: Authorization=Bearer <AccessToken>
-------------
Reproduce this situation:
Create an Azure AD Application
Add Application Permission > Sites.ReadWrite.All
Grant Admin Consent for
Create Secret
Generate Access Token (using)
Run Query with token (works)
Forcing it to break (either add all at once or 1-by-1)
Add Application Permission > Group.Create
Grant Admin Consent for
Generate Access Token
Run Query with token (fails?)
Does it work?
Add Application Permission > Group.ReadWrite.All
Grant Admin Consent for
Generate Access Token
Run Query with token (fails?)
Repeat for another permission. until it breaks.
Does it break?
Fails forever
Workaround:
Split up App Permission across multiple AD applications.
I tested this and the issue is there but a workaround is you don't need Group.Create permission if you have Group.ReadWrite.All.
So in summary a single AD app can have Group.ReadWrite.All and Sites.ReadWrite.All permission and it will work but a single AD app will fail if it has all three permissions of Group.Create, Group.ReadWrite.All and Sites.ReadWrite.All
Based on my test (Did not test all permissions), the issue does exist.
There are two main permissions that affect the calling of this API endpoint.
They are Group.Create and Group.Selected.
I'm not sure why they cause the failure of the calling of /sites/root. But it's strongly recommended to remove these two permissions (maybe there are some more other permissions) from the Azure AD app which is used to access /sites/root.
At the same time, opening a support ticket on Azure portal for your Graph request is a good choice.
Unfortunately this was a previously known issue in SharePoint. A fix is on its way but I don't have an ETA for rollout to share.
I'm trying to get a list of all users in my organization (~300), but the /users endpoint only returns two admin accounts.
Our administrator has given the application consent.
Scope: https://graph.microsoft.com/.default
Does it have something to do with the "(Admin only)" marking on the screenshot below?
/v1.0/users returns:
Some permissions do require an Admin Consent and thus have the marking "(Admin only)".
"Admin only" means that only an administrator can consent this permission.
Most delegated permissions (access on behalf a user) do not need an Admin consent, but some like e.g. Agreement.Read.All are only available for administrators.
Since you are using Application Permissions (and getting access without a user) all permissions will have the "(Admin only)" mark. But this does not mean that the returned results are limted to admins.
Seeing you have given the app the permission User.Read.All your app should be able to request a list of all Users with /v1.0/users/ (it will definitely return all users).
The most likely explanation for your results is that you only have two users in your Office365 AD.
Maybe there was an error setting up the users?
I would suggest to login into the Graph-Explorer and check if you get the same results.
And to check in your Azure Admin Portal if all users registered in your AD.
I'm creating an application in with angular and nodejs and I need to be able to read another user's list of events. Right now I am attempting to use "https://graph.microsoft.com/v1.0/users/otherusername#companyurl.com/events" this gives me the 403 "Access is denied. Check credentials and try again.". However, if I use "https://graph.microsoft.com/v1.0/users/myusername#companyurl.com/events" it works(as most would expect). My question is, why is it when I use outlook I can use scheduling assistant to see the events for "otherusername#companyurl.com" without being an admin but in my application I cannot see their events due to credentials?
The library I'm using to connect to microsoft graph api is https://github.com/AzureAD/azure-activedirectory-library-for-js
The delegated permissions I have set in azure are
View users' email address
Sign users in
Read user contacts
Have full access to user calendars
Read user calendars
Send mail as a user
Read directory data
Read all users' basic profiles
Sign in and read user profile
Application permissions (I understand these require admin)
Read calendars in all mailboxes
Graph api permission scopes
Any help is appreciated, thankyou.
Fugal - This is by design. You can use FindMeetingTimes API to schedule meetings with other users. This can be accomplished with just Calendar.Read permission. See http://graph.microsoft.io/en-us/docs/api-reference/beta/api/user_findmeetingtimes for more info.
For you to view another user's calendar using /events endpoint, you need a special permission (something like Calendar.Read.Shared) that we are still in the process of adding. Once we add that, you will be able to use /Events to access any calendar that another user has explicitly shared with you. But if you want to just schedule meetings, FindMeetingTimes should be sufficient.