Introducing the Microsoft Entra PowerShell module

Should the Beta module not be called Microsoft.Graph.Beta.Entra to align with the other Microsoft Graph PowerShell SDK Beta modules?

Well, something had to change given how well the transition to the Graph SDK was going. So I am glad to see some real improvements, though this is... unexpected, and confusing.

I would guess that one thing most administrators will be looking to see resolved is SDK-API finger pointing scenarios to come to an end. As in, the SDK not properly supporting a feature from the API, the SDK team pointing the finger at the API team, while the API team points the finger back at the SDK team, in an infinite loop while the SDK feature remains broken for months (or longer!) This doesn't seem to have the potential to address that, as it relies on the same imperfect API translation layer?

Will Microsoft Entra PowerShell use a pre-consented app like AzureAD or MSOnline modules?

No. Microsoft Entra PowerShell permissions aren't preauthorized, and users must request the specific app permissions needed. This granularity ensures that the application has only the necessary permissions, providing granular control over resource management.

I don't really buy this argument, not when you had the opportunity to do something better in this module. You developed a module with the understanding that the developer-focused modules were not meeting needs, and I would argue this was not tackled simply due to time or resources, and you fail to own up to that (further emphasized by the fact that you still require the API's parameter of TenantId.) Many administrators will simply connect with scope Organization.ReadWrite.All, and we all know it, so the granular permissions argument, in my mind, holds little water given the intention and target audience of this specific module. This is just lazy.

Also, cmdlets such as Get-EntraUser still use parameters with names like ObjectId, versus something more "human-readable" as you said would be the case like UserPrincipalName.

My final thought is why continue pushing this API translation layer so hard, when other Microsoft 365 teams continue not to go down this road? If it has proven to be this problematic, why write a new module that still incorporates most of what has failed? For example, the Teams and Exchange Online teams have PowerShell modules that do not rely on such a translation layer, and those modules work well, and are well received.

I mean, I get that you can't please everybody, but this is your solution? You should have just invested this time into improving the existing Graph SDK modules and their documentation, instead of just confusing everybody even more.

ians-uleth 

I would guess that one thing most administrators will be looking to see resolved is SDK-API finger pointing scenarios to come to an end.

We understand the frustration here and have worked with the Entra service owners to resolve issues when alerted. Please raise any issues you come across on Entra PowerShell in GitHub and we will work with service owners to have the issues fixed.

Will Microsoft Entra PowerShell use a pre-consented app like AzureAD or MSOnline modules? No

I don't really buy this argument....This is just lazy.

This is intentional. Pre-consented Graph permissions for Azure AD and MSOL have allowed threat actors and offensive tool builders to leverage this powerful service principle to gain API access to tenants. While we do understand admins can consent to privileged permissions, our goal is to provide a solution that is secure-by-design and secure-by-default. This will ensure the millions of tenants that don't use PowerShell, to be protected and gives the flexibility for admins to restrict the permission of the Graph client to specific users and permission scopes. In our updated docs we provide guidance on following a least privilege model.

On a side note, the Organization.ReadWrite.All is not a very privileged scope, maybe you were referring to Directory.ReadWrite.All? Even in this case it is limited to core directory permission and does not by default grant access to privileged operations such as updating conditional access policies.

...why continue pushing this API translation layer...

While the initial release of Entra PowerShell does rely on a translation layer, we don't plan on extending its use to new cmdlets.

...invested this time into improving the existing Graph SDK modules and their documentation...

Graph PowerShell SDK has a much wider use case and covers all of Microsoft 365, as such it aims to stay as close as possible to the Graph REST API. It also follows a very rapid release cycle based on auto generated content. 

The Entra and Graph PowerShell teams work together and have been working on improving the quality of Graph PowerShell docs. This can be seen in the improvements that have been made to the docs in the last few months including least privilege permission scopes, rich examples and cloud specific support. A good example is https://learn.microsoft.com/en-us/graph/api/user-get?view=graph-rest-1.0&tabs=http

My view:

Practical Graph: Microsoft Launches Entra PowerShell Module

On June 27, 2024, Microsoft launched the preview of the Entra PowerShell module. Built on top of the Microsoft Graph PowerShell SDK, the new module helps organizations that still have PowerShell scripts based on the now-deprecated AzureAD and AzureADPreview modules. If you're in that situation, the Entra module might help. But overall, I recommend using the Microsoft Graph PowerShell SDK instead.

https://practical365.com/entra-powershell-module/

EricOhlin : Connect-Entra is an 'alias' for Connect-MgGraph command. You can use either one based on your preference. 

What’s the benefit of using this module instead of the current in Microsoft Graph Users/Groups/Applications 2.x.x modules, and does this support anything new those do not?

Really nice to see a new module to "replace" AzureAD ones 🙂

Thanks for sharing 🙂

Happy Azure Stacking!!!

This is interesting and a more 'admin friendly' module for tasks would be welcome considering the existing Graph module is barely a wrapper over the API

However disappointing that even in V1.0 some obvious things aren't possible

e.g. Get-EntraUser -UserPrincipalName [email]

or being able to easily query readable properties

e.g. Get-EntraUserMembership -UserPrincipalName [email] | Where-Object { $_.DisplayName -eq "My Group"}

It would be nice to see this as a layer to making admin tasks a little more friendly. Its definitely not there at the moment

Thank you merillms, I appreciate the clarification you provided, especially regarding not necessarily relying upon the API translation layer (that alone will be huge.) I am excited to see how this module shapes up and where it takes us.

I suppose you can answer my follow-up question and JamesC95's together - existing cmdlets that are currently implemented using the API translation layer, such as Get-EntraUser and Get-EntraUserMembership seem to be highly reflective of the API at the moment, obviously. Does the Entra module's current implementation allow for more user-friendly things such as what JamesC95 is saying in the short-term with just some quick over-the-top customization by the development team, or would these things be a longer-term goal for the development team in uncoupling these cmdlets from the API translation layer?

ians-uleth : merillms has captured this really well. Here are some additional thoughts.

Thank you for taking the time to share your perspective and feedback – we sincerely appreciate it. This is a preview release of a new module, and our focus has been on providing a broad range of resource/cmdlet coverage so that customers can test the module in real-world scenarios. We recognize that there are areas where we can continue to improve the experience and implementation.

While there are many benefits that the Microsoft Graph PowerShell SDK has brought about, we understand that there were usability gaps for Entra customers. Our goal with Entra PowerShell is to deliver excellent usability while retaining the breadth, rapid update cadence, and best-practice Microsoft Graph and authentication client patterns of the Microsoft Graph PowerShell SDK.

I'd like to address some of the points you raised to continue the discussion.

a) Application permissions

We believe strongly that customers should have control over which applications are consented to use privilege in their tenant. Like the underlying Microsoft Graph PowerShell SDK, Entra PowerShell is very flexible in this regard.

Customers can choose to grant application permissions to the default application ID for simplicity or register their own applications with granular permissions. While we believe this is the right approach for administrative control of application access, we are interested in opportunities to streamline this experience and would love to hear any further suggestions you have on how this could be optimized.

b) Parameter naming improvements

We would greatly appreciate it if you could file an issue on the GitHub repo: Microsoft Entra PowerShell issues.

In summary, our goal is to deliver a PowerShell module that provides excellent functionality and usability for Microsoft Entra, and seamlessly integrates with the broader Microsoft Graph ecosystem. We believe that this new module in the Microsoft Graph PowerShell SDK is the best way to solve for this, and appreciate your feedback towards helping us improve the experience.

Note: The Entra PowerShell module and its documentation are public and open for contributions. We encourage you to participate and help us improve!