Insufficient privileges New-MgOauth2PermissionGrant_CreateExpanded error about ipam HOT 8 CLOSED

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.

from ipam.

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.

from ipam.

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?

from ipam.

@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?

from ipam.

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.

from ipam.

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.

from ipam.

@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?

from ipam.

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!

from ipam.