Connect-Entra seems to give more Scopes than requested.

[KentNordstrom]

Describe the bug
If I start a brand new PS console and connect using for example the Scope Group.Read.All...
Connect-Entra -TenantId xxxx -Scopes Group.Read.All

And then look at my Context using
(Get-EntraContext).Scopes
it will show all available scopes assigned to the Enterprise Application
Example...
![image](https://github.com/user-attachments/assets/1edfa930-1009-46cf-ae77-1b2177142255

I would expect the Context to only show the "Active" Context.Scopes I currently have available in the session.

[alexandair]

What you expect is not how the scopes in an interactive session work. Scopes are accumulative.

[KentNordstrom]

What you expect is not how the scopes in an interactive session work. Scopes are accumulative.

So, what we need to do when migrating from AzureAD module is to tell our IT-staff to not bother about -Scopes but just do Connect-Entra and then it will be up to the Entra Admins to make sure we have all needed delegated permissions assigned to the Microsoft Graph Enterprise application with Admin Consent on them...

... and then somehow have a process for assigning "odd permissions" when users see the need for them.

I typically work with the Scope / Permission Directory.AccessAsUser.All and as far as I can understand... to work with the Entra Module, that would be the only permission we need to assign the Enterprise App as far as interactive sessions needs.

@alexandair Have I got this right now?

[alexandair]

First, Connect-Entra and Connect-MgGraph are practically the same commands (just a branding thing) and I would recommend reading a help for any of them.

Connecting to the AzureAD API and Microsoft Graph is very different and your users of the Entra PowerShell should bother with the -Scopes parameter.

I would also recommend reading this blog post.

You should avoid using the Directory.AccessAsUser.All permission. It's overprivileged permission and goes against the least privilege model suggested for Microsoft Graph (and Entra).

[KentNordstrom]

So your suggestion would be to create different App Registrations for different IT teams needing different -Scopes of accesses.

For example one for the Device Team with Permissions related to their needs and another for Help Desk team with Permissions related to theirs.

But what do we do in smaller companies where all in IT need to be able to perform almost all tasks in Entra/Intune.
In my mind using delegated Admin Consented, Directory.AccessAsUser.All still makes sence and then focus on Roles and accesses in Entra / Intune to control what users can actually do. This is how we controlled the access when AzureAD module was used.

Because what I see happen there is a very long list of User Consent Permissions when the IT-users and Power Users read some blog and use some odd scope and just approves it.

But maybe I'm wrong when trying to avoid User Consent Permissions and it's considered "better" to have "odd" Permissions/Scopes being User Consented than Admin Consented.

@alexandair What would you say is best practice around Admin vs User consent around the Application used for Graph Access?