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.
Related
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 want to develop and publish a bot for Teams, to interface with my SaaS (I already have a Slackbot that I'm porting). I'm creating a Bot Channel Registration as per this guide and came across the choice of whether to auto-generate a new App Id and password, or manually registering one (described here). I already have an Azure AD app for my SaaS that is published to the AppSource marketplace (the integration currently mainly allows logging in with your M365 account and syncing users from AD). Is it possible, and would it make sense to use the same App ID for the bot I'm developing for the same SaaS? Or is it somehow not advisable? And relatedly, can I expand my existing listing on AppSource to also contain the new bot, or should this be a separate listing?
I noticed in the documentation for manual registration of a bot, that it says that bots only work with "Accounts in any organizational directory and personal Microsoft accounts (e.g. Xbox, Outlook.com)" - my existing app only works with organization accounts, not personal accounts (since it's a B2B app) - does that change things?
Perhaps consider the question the other way - is there any good reason TO re-use the app ? It's very easy and basically free to create an additional app, and that way you don't run the risk of possibly ending up with settings needed for one scenario that conflict with another scenario's requirements, now or in the future. Here are some other possible considerations though:
new apps require Publisher verification, since 9 Nov 2020. This won't affect you for an internal app, which can be consented to by a global admin.
If you need the user (or admin) consent for some set of privileges (e.g. delegated Graph access), then using the same app might make sense. An example, in a Teams context, might be a bot and a tab that both need to access something from the Graph on the user's behalf. You could get consent in one context, and use it to access the resources from both contexts.
In a nutshell, and especially without a really really good idea of both of your current and planned use cases, it's hard to give a really solid 'yes' or 'no'. My gut says go with a separate app for a separate, unrelated scenario though.
Reusing the same appid against any other B2B won't create any problem. Being said that you can't use the above app if you're planning to implement/use BOT framework with it, as it's registered for organization only.
If you plan to create BOT related app registration then i would
suggest you to create new app registration with Organization +
personal for you scenario.
Please see the documentation and it's disclaimer:
In the above document it's pretty clear if you create any other app registration (other than Organization + personal), then the BOT will be unusable.
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.
We are building a web app that lets Office365 customers create a realistic plan for their week, by showing them how much time they actually have to work each day (it's called Weekly if you're interested).
The problem we are running into however is that some companies, primarily large ones, block apps entirely from making Microsoft Graph calls to their users. What's tricky is that we send them to Office365 to grant us permissions, their company blocks the access request, and we never see those users again, so currently don't have any way of knowing what happened.
We'd like to be able to display our own message that says something like "Your company has blocked access to our application, please contact your IT department for help".
Is there any way of knowing before sending the user over to grant access that their company (the domain) even allows apps? If not is there some way to send the user back to the requesting app with some details about why the grant failed (did the user not grant permissions, did the company block access, etc.)?
Thanks for your help!
If the administrator disables the ability for users in the organization to consent then the error message will be something like:
AADSTS90093: An administrator of {tenantDisplayName} has set a policy that prevents you from granting {name of app} the permissions
it is requesting. Contact an administrator of {tenantDisplayName}, who
can grant permissions to this app on your behalf.
https://apps.dev.microsoft.com/portal/tools/errors?errorName=graph_user_unauthorized
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.