Insufficient privileges New-MgOauth2PermissionGrant_CreateExpanded error

[jeevanions]

I have started the deploy script for a POC, and I am stuck with this error.

We use SP with the necessary permission to log in from the command line, and we are not sure what permission to be given for the SP we use here. Any clue/suggestion?

The SP we use has restricted permission, so we definitely need to add more, but we are not sure which one.

INFO: Granting admin consent for Azure Service Management API permissions assigned to IPAM Engine application
New-MgOauth2PermissionGrant_CreateExpanded1: deploy.ps1:564:7
Line |
 564 |        New-MgOauth2PermissionGrant `
     |        ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
     | Insufficient privileges to complete the operation.

[DCMattyG]

Hi @jeevanions, I'll refer you to the prerequisites section of our documentation, which can be found here:

https://azure.github.io/ipam/#/deployment/README?id=prerequisites

The script is attempting to assign "Reader" at the Root Management Group, so whatever principal you're using to execute the script will need Microsoft.Authorization/roleAssignments/write at the Root Management Group level.

Hope that helps, if not we're always here for additional assistance, or even 1:1 support if required.

[jeevanions]

Thank you for your quick reply. We have changed the scope to one of the subscriptions and the SP we use is the owner of the subscription. Is this solution only work with Management group scope?

[jeevanions]

@DCMattyG Also we have two sub-management groups under the root management group. Could we set the scope to one of the child mgmt groups?

[DCMattyG]

At the moment, the "out of the box" deployment script targets the Root Management Group. That said, there are others whom have modified the script to target a child Management Group, so it can be done (See Discussion #90). Alternatively, you can manually assign the Engine App Registration as a Reader on those Management groups, and that should be sufficient.

As always, happy to work closely with you to ensure success. I'm also open to feedback perhaps to add an additional deployment field to override the currently hard-coded scope of the script execution.

[jeevanions]

Ok, there is a couple of feedback that I can think off.

1. The SP we have does not have permission to perform admin consent. So it would be nice to disable this part by using a flag and display a message to users contacting their admin for performing these admin tasks.

2. Every time we run the deploy script, a new App reg is created, and it would be good to make this idempotent. Maybe reuse the ones which are created in the earlier run.

[DCMattyG]

Thanks for the feedback @jeevanions, my thoughts below:

1. The application needs Admin Consent to work. Users cannot consent to the backend App Registration, and without Admin Consent, I'm not sure the application will function properly. We have a 2-part deployment where in step 1, a team responsible for Azure AD could pre-stage the App Registrations, then pass a generated Parameters file to an infrastructure team to create the assets in Azure.
   a. Part 1: https://azure.github.io/ipam/#/deployment/README?id=app-registration-only-deployment
   b. Part 2: https://azure.github.io/ipam/#/deployment/README?id=infrastructure-stack-only-deployment
2. I'm actually working with another user on a PR to address this. It's a valid concern and I 100% agree that we should be addressing this in a better way.

[jeevanions]

@DCMattyG I managed to deploy the solution for one of the child management groups and used the two part deployment approach. The AppOnly option does throw error during Microsoft graph oAuth permission grant in 3 places. So I have commented out just these three places and requested our admin to perform a permission grant. Then used, the parameters file to deploy the infrastructure.

Now the web UI is available to the whole directory. Is there a chance to allow users from a particular AD group to log in rather than users from the whole tenant?

[DCMattyG]

Hey there @jeevanions, at this moment there's no way within the Azure IPAM tool to strictly control user access.

There is the construct of Admins/Non-Admins, and for non-admins, when they login to the Azure IPAM tool, the only things they are presented are what they can already see today within the Azure Portal itself because we're using their same AuthN/AuthZ to query Azure Resource Graph.

There are two options here:

1. You can leverage pre-existing mechanisms in Azure to control access to the App Registration for the Azure IPAM UI, which you can read about here.
2. I can built in a user-management mechanism, but that seems like it might be an extra layer not needed given that all the IPAM tool is exposing is what users can already see (outside of the IPAM specific constructs).

I'm more than open to your thoughts on this matter. Please let me know what you'd like to see as next steps. Thanks!