in Azure, Flow

How to grant permissions to one or more users to use the Outlook Tasks connector in Microsoft Flow

If you are reading this article you probably noticed that if you try to use the Outlook Tasks connector with a non-global admin account, the connection attempt fails with the following error:

OutlookTasksConnector-PowerApps and Flow needs permission to access resources in your organization that only an admin can grant. Please ask an admin to grant permission to this app before you can use it.

If you read further, you can see that the error comes from AAD:

OutlookTasksConnector-PowerApps and Flow needs permission to access Message: AADSTS90094: An administrator of SuperTeam has set a policy that prevents you from granting OutlookTasksConnector-PowerApps and Flow the permissions it is requesting. Contact an administrator of SuperTeam who can grant permissions to this application on your behalf.

As the message indicates, this connector hasn't received consent from a global admin to be used in the organization.

To clarify the origin of this error, note that OutlookTasksConnector-PowerApps and Flow is a Microsoft 3rd party multi tenant service principal (aka application) in AAD which is provisioned automatically when you successfully establish a connection to Outlook Tasks for the first time. This service principal is scoped to create, read, update and delete tasks and plans (and tasks in them), that are assigned to or shared with the signed-in user.

To resolve this issue you can choose one of the 3 options below:

Option #1 – let users grant consent to all 3rd party apps:

Turn on the "Users can consent to apps accessing company data on their behalf" option under Enterprise Applications >> User Settings.

If this option is set to yes, then users may consent to allow third-party multi-tenant applications to access their user profile data in your directory. This also means that the users will see these apps on their access panels.

Some admins don't want to do this, and I can understand why. So let's take a look at option #2.

Option #2 – consent to Outlook Tasks on behalf of all users:

Go to Flow >> sign in with a global admin account >> go to Data >> Connections >> New Connection >> search for Outlook Tasks connector >> create connection.

This experience will ask you to grant consent for the
OutlookTasksConnector-PowerApps and Flow service principal to read/write tasks on your behalf. Additionally, you have the option to Consent on behalf of your organization. Consenting on behalf of your organization will create an OAuth 2 permission grant for this service principal in AAD for all users.

Once you click Accept, a connection will be created in Flow, as you can see below.

If you go to AAD Enterprise Applications and search for app ID 99da6bf4-4525-4bfa-b39f-b6a35789c240 you will find the OutlookTasksConnector-PowerApps and Flow service principal

If you want to dig further, click on it and look at Permissions. You will notice that this service principal has the following claims: offline_access and Tasks.ReadWrite

Now if you go to AAD Graph Explorer, login with you Global Admin account, and run a GET request on https://graph.windows.net/myorganization/oauth2PermissionGrants you will get back a list of OAuth 2 Permission Grants. Among these permission grants you can find the Outlook Tasks permission grant and you do that by searching (CTRL+F) for the service principal Object ID in the response window, as you can see in the second screenshot below:

Option #3 – consent to Outlook Tasks on behalf of a limited number of users:

In Option 2 we saw that we can grant consent to all users. If you want some granularity and control over who can use this connector, you can grant consent to a limited number of users. You do this by removing the grant you gave on behalf of all users, or, if you haven't done that, then you can go to Flow >> sign in with a global admin account >> go to Data >> Connections >> New Connection >> search for Outlook Tasks connector >> create connection without consenting on behalf of your organization. If it's the first time you use this connector, then the service principal will be provisioned and a permission grant will be created on behalf of the global admin you used to connect.

In case you already gave consent on behalf of your organization, you can delete the permission by going to to AAD Graph Explorer, login with your Global Admin account, and run a GET request on https://graph.windows.net/myorganization/oauth2PermissionGrants to locate the permission grant by searching again for the service principal object ID. Once you find it, copy the entire permission grant object (highlighted in yellow below):

Next step is to paste the grant in a text file, because we will need it later, and copy the grant's objectID, highlighted below:

{
	"clientId": "4b7aac61-c554-4c49-9403-0003fdd21256",
	"consentType": "AllPrincipals",
	"expiryTime": "2019-08-14T14:46:33.2639284",
	"objectId": "Yax6S1TFSUyUAwAD_dISViRq_5xSrCdKn9zhhI8QpLY",
	"principalId": null,
	"resourceId": "9cff6a24-ac52-4a27-9fdc-e1848f10a4b6",
	"scope": " offline_access Tasks.ReadWrite",
	"startTime": "0001-01-01T00:00:00"
}

Append the objectID to the https://graph.windows.net/myorganization/oauth2PermissionGrants/ resource and run a DELETE request on the newly formed resource, which should look like this: https://graph.windows.net/myorganization/oauth2PermissionGrants/Yax6S1TFSUyUAwAD_dISViRq_5xSrCdKn9zhhI8QpLY. Obviously, you will have a different grant objectID than me. You delete the grant by changing the request method to DELETE, as illustrated below:

Make sure the object was deleted by running a GET request on the same resource – you only need to change the request method, nothing else. You will get a Resource not found for the segment 'oauth2PermissionGrants'. error.

Next go to Azure Active Directory >> Users >> search for a user who needs to use this connector >> copy the user's Object ID

Make the following modifications to the permission grant you copied eariler:

  • change the consentType to "Principal"
  • remove the objectID
  • replace the principalID with the user's Object ID you copied in the previous step
{
	"clientId": "4b7aac61-c554-4c49-9403-0003fdd21256",
	"consentType": "Principal",
	"expiryTime": "2019-08-14T14:46:33.2639284",
	"principalId": "155bfdc4-2bd6-4e3e-bbd0-263eb68c7060",
	"resourceId": "9cff6a24-ac52-4a27-9fdc-e1848f10a4b6",
	"scope": " offline_access Tasks.ReadWrite",
	"startTime": "0001-01-01T00:00:00"
}

Copy the modified grant, modify the request method to POST, paste it in the request window, change the resource back to https://graph.windows.net/myorganization/oauth2PermissionGrants, and click GO. If you did everything right, you will get the grant back as response, as below:

Next ask the user to create a connection to Outlook Tasks:

Write a Comment

Comment