Default Admin Consent Directory.Read.All permissions due this taking over from MSOnline and Azure AD modules

[RobinDadswell]

Based on this blog post https://techcommunity.microsoft.com/t5/azure-active-directory-identity/automate-and-manage-azure-ad-tasks-at-scale-with-the-microsoft/ba-p/1942489 this module is set to be used in place of both the old MSOnline module and the Azure AD module
With the above in mind I would like to suggest that the Enterprise App is by default configured with Directory.Read.All permissions (as a minimum) pre admin consented in order to ensure that users that are not GA are able to use this from the beginning to read relevant properties. This will make the module more usable today and will not involve change control processes in regulated environments for a basic PowerShell module.

AB#9792

[peombwa]

@RobinDadswell This is indeed a valid ask and is a feedback that we have gotten from many customers. We will discuss this internally to explore what our options are when it comes to supporting pre-approved permissions and matching them to those found in Azure AD module.

cc/ @adamedx, @darrelmiller, @ddyett , @mairissi

[darrelmiller]

Regardless of whether or not pre-consenting that permission in today's security environment is a good idea, it currently is not possible to pre-consent the Microsoft Graph PowerShell SDK. Due to the broad horizontal nature of the tool, it is essential to have incremental consent. It is currently not possible to have incremental consent and pre-consent with the same app registration.

[RobinDadswell]

Regardless of whether or not pre-consenting that permission in today's security environment is a good idea.

I'd normally completely agree that it's maybe not the best idea to pre consent, however as this is a replacement to some heavily utilised tool sets that are used across many M365 tenants I think that it would be counter intuitive to not have some form of basic read permissions as a minimum, if not replicate at least the current permission set. I personally have no issue with consenting to it if I have the right permissions but across various customer environments I would need to fill customer change requests for this application in particular to be able to do some very basic reporting of certain settings which are not currently available through the Azure AD Admin Centre (amongst other locations) let alone the configuration steps in the future.

[darrelmiller]

@RobinDadswell Sorry, I missed your response. I wish it were possible to do this, but currently it is not possible to have an application registration that can be pre-consented to some scopes and allow user consent for others. This is an issue we have discussed with the Identity team, but it is not something that I expect to be possible any time soon.

[J0F3]

@darrelmiller Wich App Registration is actually used? I expected to find a Enterprise Application "Microsoft Graph PowerShell" im my Tenant. But I cloud not found anything. So I am a little confused how the authentication actually happens and where I could see which permissions are consented already for the app.

Thx!

[darrelmiller]

@J0F3 This script here https://github.com/microsoftgraph/msgraph-sdk-powershell/blob/dev/samples/Scripts/Remove-ServicePrincipal.ps1 that we use for deleting the service principal AKA Enterprise App has the appId in it.

[J0F3]

@darrelmiller
Ah very cool! Thanks a lot! 👍

[maisarissi]

Hello everyone.

As mentioned before by Darrel, having pre-consented scopes, and allowing users to consent is currently not supported. In addition to that, having pre-consented permissions for a built-in publicly available 3P appId is something that we cannot add from a security standpoint.

However, an alternative option to consider is to use an app registration of your own, on which you can set all permissions you want, and use it with the Microsoft Graph PowerShell SDK:

Connect-MgGraph -ClientId"{from-your-own-app}" -TenantId "{from-your-own-app}"