We are using webhook to get AD user changes within our system through subscription. For this we have a App registered within Azure AD which has read access to user changes through Graph API .
As webhook subscription expires in 2.5 days we require to renew the subscription through our application. Can anyone help to let me know what will be the minimum privilege App requires on Graph to renew the webhook as we cannot give lot of access to this app .
App having the consent to ‘User.Read.All’ should be sufficient for creating & updating subscriptions on ‘users’ resource type.
https://developer.microsoft.com/en-us/graph/docs/api-reference/beta/api/subscription_update
Is that not working ?
According to the Microsoft Graph Doc here (Permissions Section): Creating a subscription requires read permission to the resource for which the app will receive notifications - so, if creating requires it, you can bet that renewing it will too. For instance, if the subscription you want to renew monitors a mailbox, the service needs to have Mail.Read permission IN ADDITION TO the Users.Read.All permission which is required to read the user accounts (for which subscription is an attribute).
Also, some other helpful hints from hours of banging my head against the wall:
1) You also need to be aware that there are two types of permission: Delegated and Application. When I first started using the MS Graph, I always got tripped up on this - so you can read up here to make sure you understand it and have applied the appropriate permissions.
2) In addition, make sure that your admin has consented AND if you change any permissions at anytime, your admin has to re-consent in order to have the new permissions take effect - i.e. when you update them to have the Mail.Read or whatever else. Also remember that when you do this, you are going to want to make sure to flush your previous auth token caches to force a refresh so your new token will have the appropriate permissions there as well.
Related
Recently the Teams API has been extended so that applications can set the availability / presence for a user logged into Teams: https://learn.microsoft.com/en-us/graph/api/presence-setpresence
However, the permissions for this API do not allow access with delegated permissions, only with permission type application:
https://learn.microsoft.com/en-us/graph/api/presence-setpresence?view=graph-rest-1.0&tabs=http#permissions
Am I right in assuming, that this means I will need an administrators consent from every tenant if I intend to build an application using this API?
Is it therefore impossible / impractical to implement this into my app that allows a user to set their presence based on the activity in my app? Because, and please correct me if I am mistaken, a user by themself cannot actually give my app the permission to do this. Right?
(Doesn't this make this api point sort of nearly useless?)
This API supports only Application permission, so on behalf of user token, you can not change the status where as using application token, you can update the status: https://learn.microsoft.com/en-us/graph/api/presence-setpresence?view=graph-rest-1.0&tabs=http#permissions
We have an app registered on Azure AD (we got app ID, secret, redirect URL). This app is a daemon/background application which is performing actions on behalf of a user, there is no signed-in user that can grant permissions. In particular, the app will periodically retrieve all emails from a particular outlook mailbox called my.test#org.com
We are following the permission scoping documentation and the permission documentation when there is no signed in user.
In my understanding we need
to give application-permissions on the API permissions page in Azure AD
create a security group which is somehow assigned to the mailbox we want to read from via
New-ApplicationAccessPolicy
-AppId e7e4dbfc-046f-4074-9b3b-2ae8f144f59b
-PolicyScopeGroupId EvenUsers#contoso.com <-- would I put here my.test#org.com or the ID of the security group?
-AccessRight RestrictAccess
-Description "Restrict this app to members of distribution group EvenUsers."
Is my understanding correct that both of the above steps are needed. It seems strange that in the first step we can only give tenant wide permissions to the application when we really only need to limit it to one particular mailbox.
Thanks for the help
The above steps looks good to me and i would do the same as well. Just provide necessary Graph permissions while you grant permissions to access your/others mailboxes - as described in the documentation/steps.
I am trying to read a person's Out of Office text with MSGraph. I understand the only way to do this is by getting the person's mailbox settings as indicated here.
Is there another way to read a person's Out of Office Message?
Assuming there is no other way I then have read for example in this link that to call GET /users/{id|userPrincipalName}/mailboxSettings you need to have Application Permissions for MailboxSettings.Read, MailboxSettings.ReadWrite. Is this still the case? It does not make sense to me that you need Application level permissions. Is there not a delegated (admin consent required) MailboxSettings.Read.All??? The problem is that most IT departments will be hesitant (or pigs are going to fly before some IT departments) give an application this permission to run without a signed in user.
Alternatively, I see that there is a User property of mailboxsettings, thus using the $select query parameter you can call this https://graph.microsoft.com/v1.0/users/{id}?$select=mailboxSettings does or should this work with the User.Read.All.
UPDATE in accordance with the suggestion below I have added 2 suggestions to the MSGraph user voice.
A person's out of office information should be included with their calendar / freebusy (getschedule) information.
There should be a Mailboxsettings.Read.All permission.
Please click on the link and vote them up if you agree.
No, there is no MailboxSettings.Read.All or MailboxSettings.Read.Shared. You can see the list at https://learn.microsoft.com/graph/permissions-reference#mail-permissions. I encourage you to request this as a feature at https://microsoftgraph.uservoice.com.
One possible approach given the currently available permissions around this API is to use app permissions and configure an app access policy to limit the mailboxes it can access - if that's the concern you're mentioning. I'm not clear on why it would be preferable to give a user account access to this info for all mailboxes in an org but not an app service principal.
It isn't included as part of User.Read.All by design. It's not really a property on the user, it's config stored in the mailbox. It's abstracted as a property in Graph, but it requires additional permissions to access.
I'm setting up permissions for a new app I registered and saw this blurb:
These are the permissions that this application requests statically. You may also request user consent-able permissions dynamically through code.
Can an app dynamically request more permissions than what is given statically?
The concern is that this app is developed by a third-party service provider and we don't wish the app to request more permissions that what is listed. Yes, we understand the user has to consent. We know a good portion of users will just accept without reading and/or understanding what is being requested. We wish to restrict the permissions the app can request.
With Azure AD V2, you are not able to restrict the permissions.But users will be asked to consent if new permissions were required, and if the permission is admin consent required, then only the admin can consent. So, basically that will not be a big problem.
At the same time, you can always check the granted permissions in Azure Portal. Click: Azure Active Directory -> Enterprise applications -> Search with app name, and you will find the application. You will be able to check the granted permission and the operators.
In my application I want to be able to programmatically create and delete user accounts in Azure Active Directory. This program needs to run unattended.
I am able to create Azure AD users but keep getting failures when deleting a user account. Specifically, I am getting the following error message:
Microsoft.Graph.ServiceException:
Code: Authorization_RequestDenied
Message: Insufficient privileges to complete the operation.
I think this is by design because the documentation states that only delegated permissions are supported. Can someone from MS Graph team confirm that it is not possible to delete AD users in unattended fashion (e.g. without prompting for admin user account and password)? Is this functionality going to be supported in the future?
Are there different ways to solve this problem? Would the Azure AD Graph API work for this (even though it is not recommended to use now)?
That is correct, DELETE /users/{id} requires Directory.AccessAsUser.All which is only available for delegated scenarios.
This is unlikely to change given the security exposure this would introduce. A rogue application creating users would certainly be extremely annoying, but a rogue application deleting users would be outright catastrophic.
My suggestion would be to have your application maintain a "deletion queue". Whenever you need to delete a user, simply add that id to the queue. Then provide an interactive experience for Admins that allows them to login and delete the queued users after reviewing the list.