Cannot list Service Principals of an App

[Tbohunek]

Get-MgServicePrincipal doesn't take -applicationId, which makes it impossible to list Service Principals of an App.
On contrary, Get-MgApplication only takes -applicationId but does not take -objectId.
This limits possible usage.

Why do Get-MgServicePrincipal and Get-MgApplication require specific parameter names -serviceprincipalId and -applicationId rater than generic -objectId as was the case with Get-AzAdServicePrincipal and Get-AzAdApplication?

[ddyett]

this looks like a consequence of the Graph service design. Looking for team to provide feedback.

[dani3lh3pe]

Hi @Tbohunek,
just stumbled across the same problem. Solved it by using Filter option like this:

# For Service Principal
Get-MgServicePrincipal -Filter "AppId eq '64ebc126-26b2-4cda-9eb0-e6bcf50aa987'"

# For App Registration
Get-MgApplication -Filter "Id eq '86143777-9b2e-40d1-a045-0468ae918051'" # --> where 'id' is objectId

Does this solve your problem?
Greetings
Daniel

[Tbohunek]

Ohh, the -filters... I hope they'd die with onprem Active Directories. 😉

Thanks @dani3lheidemann , it works, but is that the solution we want as final?

[dani3lh3pe]

@Tbohunek yeah it's absolutely different from what we got with AzureAD PowerShell modules.
I hope they put some parameters in as well!

[wsmelton]

I have one app registration created and only way to have it returned is to use the filter on AppId. It has no Enterprise Application associated with it, which seems to be only thing the command returns with no parameters.

[peombwa]

Why do Get-MgServicePrincipal and Get-MgApplication require specific parameter names -serviceprincipalId and -applicationId rater than generic -objectId as was the case with Get-AzAdServicePrincipal and Get-AzAdApplication?

This is by design. The soon to be deprecated AzAd* commands called Azure AD Graph API. As per the Azure AD Graph to Microsoft Graph App migration checklist:

In many respects, Microsoft Graph is similar to the earlier Azure AD Graph. In many cases, simply change the endpoint service name and version in your code, and everything should continue to work.

Nonetheless, there are differences. Certain resources, properties, methods, and core capabilities have changed.

ObjectId is one of those properties that changed. In Microsoft Graph, directory objects use Id for the entity key instead of ObjectId. This is covered in the Azure Graph AD to Microsoft Graph API migration guide at https://learn.microsoft.com/en-us/graph/migrate-azure-ad-graph-property-differences?context=graph%2Fapi%2F1.0&view=graph-rest-1.0#directoryobject-property-differences.

For PowerShell, we use -{EntityTypeId} syntax for resource Id parameter names to ensure uniqueness for each path parameter. For example, GET /applications/{id}/federatedIdentityCredentials/{Id} will yield Get-MgAppliicationFederatedIdentityCredential -ApplicationId "" -FederatedIdentityCredentialId "". You cannot have duplicate parameter names on a command in PowerShell, so Id or ObjectId cannot be used here.

[Tbohunek]

Thanks for your explanations @peombwa, makes sense! However..

You cannot have duplicate parameter names on a command in PowerShell..

Can you not translate the display name of a parameter (requested from user) to the real parameter sent to API?
-objectID or even -id would map to {applicationId} and {serviceprincipalId} respectively in each PS command?

I believe this would bring consistence also with the upcoming mgc..

[peombwa]

Can you not translate the display name of a parameter (requested from user) to the real parameter sent to API?
-objectID or even -id would map to {applicationId} and {serviceprincipalId} respectively in each PS command?

We've already explored this pattern in #906. It doesn't scale well when you have paths with nested resource segments like GET /groups/{id}/memberOf/{id}. In this case, both groups/{id} (-Id) and memberOf/{id} (-Id) represent directoryObject type resource. Soley using -objectId or even -id will result in duplicate path parameters if you don't consider the entity type when constructing the parameter name.

To address #906, we are considering aliasing top-level path parameters to Id. This should help disambiguate the parameter names.