[BUG] Access Denied using cmdlet that uses MG with ClientID permissions assigned using Roles

[AndersRask]

Reporting an Issue or Missing Feature

Getting 401 Unauthorized when using a client id / certificate that has assigned "Directory Readers" using Az Role assignment instead of granted API permissions (Directory.Read.All)

Works fine with Az (Get-AzADUser) but cmdlets like Get-PnPAzureADUser fails with 401 unauthorized

Expected behavior

Granting permission through AAD > Roles > Assignment > "Directory Readers", which works with both Az and AzureAD, should work just as well as Directory.Read.All API Permission grant.

Actual behavior

Getting 401 Unauthorized when trying to get AAD Users using Get-PnPAzureADUser

Steps to reproduce behavior

Connect-PnPOnline -Url $adminSiteUrl -ClientId $appId -Tenant tenant.onmicrosoft.com -Thumbprint $thumbPrint -ValidateConnection -WarningAction Ignore
$users = Get-PnPAzureADUser -Delta

What is the version of the Cmdlet module you are running?

2.2.23 nightly

Which operating system/environment are you running PnP PowerShell on?

• [x ] Windows
• [ ] Linux
• [ ] MacOS
• [ ] Azure Cloud Shell
• [ ] Azure Functions
• [ ] Other : please specify

[KoenZomers]

Can you explain what the advantage would be to try to add support for doing in this way over just assigning permissions to the application registration itself?

[AndersRask]

Can you explain what the advantage would be to try to add support for doing in this way over just assigning permissions to the application registration itself?

Thanx for looking at this :) Well one reason is consistency across the modules, so you don't have to change permissions, because you decide to use PnP along with Az and AzureAD (that has depricated their API permissions and now only works with RBAC). RBAC in general are also more flexible, and support stuff like PIM if permissions need to be either revoked or only enabled when needed. I also find RBAC a more well known concept when we have to get IT departments to assign roles. I guess it also offers more fine grained permission patterns than API permissions.

That said, it is difintely a nice-to-have, I was just surprised that it worked on one and not the other, and thought it was an oversight.

[KoenZomers]

I don't mind having a look why and where it fails and if we could easily fix it. Could you explain my step by step what you do to set up these permissions like you do?

[AndersRask]

Sorry, did not see your reply here.

The process is straight forward: Go to EntraID > [Manage] > Roles and administrators > search for Directory Readers > click role > click +Add Assignments > click "no member selected" to search for your service principal > click Select > (optionally if you have PIM enabled you will have to decide on assigment type etc) > click Assign