Permission requirements

[DennisLundtoft]

Hi,
I'm currently implementing IPAM within our organization, and I am wondering exactly why it requires the Directory.Read.All permission and whether it instead would be possible to change it to use User.ReadBasic.All, which does not require admin consent?

After trying it out, and not granting admin consent to anything other than user_impersonation for the backend app registration, everything seems to work fine. The only noticable change is users are prompted to grant some access upon login.

[DCMattyG]

Hi @DennisLundtoft, some key functionality of the UI is the ability to search AAD for users to be added as Admins. This feature requires (at least) Directory.Read.All, hence why this permission is applied to the UI App Registration when you use our deployment script. Our automation also assumes that this will be deployed as an Enterprise application, and as such granting Admin Consent affords a much smoother experience by not bothering users for permissions when they login.

If you would prefer not to go this route and have users prompted for permissions then there shouldn't be any issue (that I can think of). Our deployment script will cover the "ideal" scenarios, but we also realize there are lots of customers with different wants here. We're currently working on some more detailed architectural guidance in our docs for those customers who would like to deviate a bit from the fairly ridged way the script deploys things today.

I hope that answered your question, but if not I'm more than happy to go into a much detail as you'd like. Just let me know!

[DCMattyG]

Good morning @DennisLundtoft, please allow me apologize for my delayed response.

I did see you're PR, but before I respond to that I believe there may be some confusion around the permissions we use and how exactly they work....

First and foremost, the UI App Registration, which has the "Directory.Read.All", is assigned that as a Delegated Permission. This means the users can only do what they could already do, and nothing more.

Supporting documentation:

https://learn.microsoft.com/en-us/azure/active-directory/develop/permissions-consent-overview#types-of-permissions

Delegated permissions are used in the delegated access scenario. They're permissions that allow the application to act on a user's behalf. The application will never be able to access anything the signed in user themselves couldn't access.

Additionally, this App Registration doesn't have a Secret (Password or Cert), so it can only be used in an On-Behalf-Of type flow. This takes the users Access Token as-is, and utilizes that to make call to Microsoft Graph on the users' behalf. Again here we cannot exceed the permission the user already has from Azure.

By default, users of Azure Active Directory can already browse the Directory (including Users & Groups) and view App Registrations & Service Principals (Enterprise Applications).

Supporting documentation:

https://learn.microsoft.com/en-us/azure/active-directory/fundamentals/users-default-permissions#compare-member-and-guest-default-permissions

We use Microsoft Graph for the following uses within the IPAM UI:

-Read information about the logged-in user
-Fetch the users photo (if available)
-Read Azure AD to search for Admins (Users & Service Principals)

You mentioned yourself that the changes in your PR cripple the Admin function, and I'm not sure why you wouldn't want the ability to manage Admins in IPAM as that seems more risky. By default ALL users are Admins unless you assign specific Admins in the UI (or via API).

So, all of that being said, I'm not quite clear why you aren't comfortable with permissions as set. Is there perhaps something else I'm missing as to why this doesn't sit right with you and/or your company?

I'm here to listen & learn. Thank you!

[DennisLundtoft]

Hi @DCMattyG,
Thanks for the clarification.

I'll try to go into a dialog with our AAD administrator.

Understandably our AAD admins are strict at granting consent of specific permissions to third party apps without a good reason. Coupled that with a lack of need of the administrator functionality in IPAM, as only a small team of developers would be using IPAM, lead to searching for a less intrusive permission than Directory.Read.All.

[DennisLundtoft]

Hi again,
I closed the PR as we (finally) were given the delegated Directory.Read.All permission from our AAD administrators. Thanks for the assistance.

[aazherelyeu]

@DennisLundtoft What did you do to skip "Directory.Read.All" permission to be used by the IPAM? I changed in both js scripts:
/ui/src/msal/graph.jsx
/ui/src/msal/authConfig.jsx

Then redeployed IPAM but it still asks for "Directory.Read.All" permission.

[DCMattyG]

Hi @aazherelyeu, the request for that is embedded into some of the code, but you could try navigating to the Azure IPAM UI App Registration and deleting the Directory.Read.All permission from the API's list.

I would like to once again reiterate that this is a Delegated Permission, which means it will only allow permission that the user already has and cannot grant any permissions beyond that. Hence, if your organization blocks this already somehow, allowing this permission won't subvert that.

Please see here for additional details on Delegated Permission vs. Application Permission:

https://learn.microsoft.com/en-us/azure/active-directory/develop/permissions-consent-overview#types-of-permissions