Azure Active Directory application and service principals

Question

Azure Active Directory has the nice concept of applications and service principals to authenticate as an application e. g. for a CI platform or SaaS application.

Now there are multiple ways to create those like using MSOL with the cmdlet:

New-MsolServicePrincipal -DisplayName "My new API app" -Type password -Value $myClientSecret

This works perfectly fine (after I assign some roles to the service principal using Add-MsolRoleMember, I can access the Graph API). But I still have some questions:

1. Why does this cmdlet doesn't require to create the application first?
2. Does this cmdlet create both - an application and a service principal?
3. Why I don't see the application neither in the classic nor the new azure portal?

And maybe someone can answer me a fourth question: What is the difference between the above MSOL cmdlets and New-AzureRmADApplication + New-AzureRmADServicePrincipal cmdlet? When should I use which of them?

Answer 1

The ARM cmdlets and the new Azure AD v2 cmdlets both use the Azure AD Graph API.

However, New-MsolServicePrincipal does not. It calls out to https://provisioningapi.microsoftonline.com/provisioningwebservice.svc using SOAP. It is a legacy API and you should not be using it.

A service principal must always have an appId, that is the client id of the Application from which it was created.

The field appOwnerTenantId identifies from what tenant the app came from. It can be null. This is the case for MS internal applications like the Graph API, Azure Portals etc. But also service principals created with New-MsolServicePrincipal, and leaving out the appId.

So the answer to question 1 and 2 is: an Application is automatically created if none is specified. But I am not sure where it is created, as it is not available through the Graph API. It is a pure service identity. And the appId is different each time, so it is not just using some placeholder app.

As for question 3: the reason you don't see the Application in the portal is because it is not available through the Graph API, it is hidden somewhere. As for the Service Principal, a very specific magic tag is required for the principal to show up in the Enterprise Applications list. And AFAIK, you can't specify it with New-MsolServicePrincipal or New-AzureRmADServicePrincipal.

The answer to your fourth question is that the MSOL cmdlets use a legacy API, whereas the two newer options use the Azure AD Graph API. And the ARM cmdlets create an application that you can see in the Portal. They still create one you can't see in the Enterprise Applications list.

The behaviour of the different cmdlets differs when it comes to creating service principals without an app though:

1. New-MsolServicePrincipal: Creates the principal with some kind of hidden app, similar to MS internal apps (also sets servicePrincipalType=Legacy)
2. New-AzureRmADServicePrincipal: Creates an application for you and then creates the service principal (the app is visible in Portal, but the principal is only visible through the app's blade, because of missing tag)
3. New-AzureADServicePrincipal: Does not allow you to create it without providing an appId

If you want the principal to show up in the Enterprise Applications list as if you created it through the portal, you can provide the tag necessary with the v2 cmdlet:

New-AzureADServicePrincipal -Tags @("WindowsAzureActiveDirectoryIntegratedApp") -AppId ed5fa582-3991-4114-87da-30081c4105fb

The new v2 cmdlets are the best in my opinion, at least they allow you to create a service principal in a manner similar to what the Portal does. The ARM cmdlets are fine if your purpose is to create a service identity for using RBAC in the ARM API, as the principal is visible for that.