in Azure, Flow

How to grant permissions to users to use the Azure AD connector in Flow

You probably noticed that you can't use the Azure AD connector in Flow without a Global Administrator account. You will get the error below if you try to connect:

You will get an error that looks like this:

Need admin approval
Azure AD Connector – PowerApps and Flow
Azure AD Connector – 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.


Message: AADSTS900941: An administrator of SuperTeam has set a policy that prevents you from granting Azure AD Connector – PowerApps and Flow the permissions it is requesting. Contact an administrator of SuperTeam who can grant permissions to this application on your behalf.

If you plan on getting support for an issue, turn this on and try to reproduce the error. This will collect additional information that will help troubleshoot the issue.

This error occurs because the user doesn't have permissions to use this connector. This is expected if a Global Administrator did not consent on behalf of the organization to use the Azure AD connector.

Word of advice: don't consent on behalf of your organization for this connector. Read further and you will understand why.

Some Global Administrators would like to grant consent to other users to use this connector without granting the Global Administrator role to these users. Usually this is needed when a user is appointed to develop an integration with Azure AD.

To grant permission to a single user, a Global Administrator has to follow the steps below. Note that this method will give the user the following permissions over AAD: Directory.ReadWrite.All, Group.ReadWrite.All, User.ReadWrite.All.

Make sure you know what you are doing before going through these steps:

  • Go to Azure Portal and login
  • Click on the Azure Active Directory Blade and go to Enterprise applications

 

  • Search for this application ID in Enterprise applications: 2bed6734-1911-40e6-ac44-00d79d70d2bc and copy the object ID. If you can't find it by searching for the GUID, search for the app name: MSFT Power Platform – Azure AD

If you can't find the application, then it means it hasn't been provisioned yet. To provision the app simply go to Flow and login with a Global Administrator account and create a connection to Azure AD.

  • Once you copied the Object ID go to Azure AD Graph Explorer, login with your Global Administrator account and run a GET request on this resource: https://graph.windows.net/myorganization/oauth2PermissionGrants
  • This request will return the OAuth 2 permission grants in your organization.
  • Search (CTRL+F in the response window) for the Object ID you copied in the previous step and copy the permission grant. If you can't find it then it means that the response from AAD Graph was paginated and the permission grant is probably on the next page. You will find a continuation token at the bottom of the response in the @odata:nextLink property which you can use to run the request again (e.g.
    https://graph.windows.net/myorganization/oauth2PermissionGrants?$continuationtoken=X'4453707402…..0000′)
  • Next step is to go to AAD and get the Object ID of your user:
  • Change the request method to POST, paste the permission grant in the request window, replace the principalID property with the Object ID you copied in the previous step, and hit Go. If you did everything right, the response should look like below – it will return the permission grant as a response (step 4):
  • The user should be able to create a connection to Azure AD now:

If you have issues with this procedure, please leave a comment.

Write a Comment

Comment

  1. Good to see it able to be assigned per person vs per tenant.
    It's about three months but I think you can now assign users separately (I was unable to find my Object Id in the Microsoft Graph) –
    Enterprise applications – All applications- Azure AD Connector – PowerApps and Flow – Overview – Users and groups

    Is this the same as what is done above?

  2. Thanks for this guide.
    It works, with a minor variation.
    The connector is now called "MSFT Power Platform – Azure AD" and it has the App ID "e7712fcb-ff8b-46a3-9dc7-869fa577ef50".

    Everything else works like a charm.

    Thanks again!

  3. Hi Alex,

    I did all the steps plus an additional one because the principalId was null:
    I changed the consentType from "AllPrincipals" to "Principal".

    I ended up with two blocks of authorizations now 🙁

    {
    "clientId": "47b2dc74-9545-4112-addd-95daf41e2c0a",
    "consentType": "AllPrincipals",
    "expiryTime": "2020-09-23T12:23:18.9951749",
    "objectId": "dNyyR0WVEkGt3ZXa9B4sCt8481RAzlNGr6mK2rV2k7w",
    "principalId": null,
    "resourceId": "54f338df-ce40-4653-afa9-8adab57693bc",
    "scope": " Directory.ReadWrite.All Group.ReadWrite.All User.ReadWrite.All offline_access",
    "startTime": "0001-01-01T00:00:00"
    },
    {
    "clientId": "47b2dc74-9545-4112-addd-95daf41e2c0a",
    "consentType": "Principal",
    "expiryTime": "2020-09-23T12:23:18.9951749",
    "objectId": "dNyyR0WVEkGt3ZXa9B4sCt8481RAzlNGr6mK2rV2k7w3E8rCaOctToK0ZUWIW8jt",
    "principalId": "c2ca1337-e768-4e2d-82b4-6545885bc8ed",
    "resourceId": "54f338df-ce40-4653-afa9-8adab57693bc",
    "scope": " Directory.ReadWrite.All Group.ReadWrite.All User.ReadWrite.All offline_access",
    "startTime": "0001-01-01T00:00:00"
    }

    Should one of the two blocks be removed? And how?

  4. I've assigned the users based on these instructions, but they still get the "requires admin consent" dialog after logging in to use the connector. What did I miss? The users show in the User Consent list under permissions.

  5. Hey Alex – after reading the walkthrough, i'm still not clear on why granting admin consent for the connector is a bad thing. It doesn't appear to give non-privileged users any additional permissions in AAD that they don't already have. So for example, "regular" users are still limited to reading membership on all groups (which can be very handy – and something they could already do anyway). Group owners can read/write/modify their groups, and read all others. Global Admins can read/write/modify all groups.

    As long as your organization is ok with all users reading membership from all groups (which i understand might be a problem for some), what's the drawback?

    • Hi Jon, the only reason admins may not want to consent is to not allow users, other than admins and designated devs with enough privileges, automate actions in AAD. Since I wrote the article, the connector and the service principal have been updated, so I will update the article as well to reflect this and make it clearer.