Azure Active Directory application and service principals Azure Active Directory application and service principals powershell powershell

Azure Active Directory application and service principals


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.


1 and 2 - probably it is using existing office 365 application in the tenant (I believe it is hidden)?

3 - Since you created a service principal, you need to look at enterprise applications in the Azure portal to see the service principals objects in your tenant (rather than the applications tab).

4 - this link

Application object
An Azure AD application is defined by its one and only application object, which resides in the Azure AD tenant where the application was registered, known as the application's "home" tenant. The application object provides identity-related information for an application, and is the template from which its corresponding service principal object(s) are derived for use at run-time.

Consider the application object as the global representation of your application (for use across all tenants), and the service principal as the local representation (for use in a specific tenant). The Azure AD Graph Application entity defines the schema for an application object. An application object therefore has a 1:1 relationship with the software application, and a 1:n relationship with its corresponding n service principal object(s).

Service principal object
The service principal object defines the policy and permissions for an application, providing the basis for a security principal to represent the application when accessing resources at run-time. The Azure AD Graph ServicePrincipal entity defines the schema for a service principal object.

Before an Azure AD tenant will allow an application to access the resources it is securing, a service principal must be created in the given tenant. The service principal provides the basis for Azure AD to secure the application's access to resources owned by users from that tenant. A single-tenant application will have only one service principal (in its home tenant). A multi-tenant Web application will also have a service principal in each tenant where an administrator or user(s) from that tenant have given consent, allowing it to access their resources. Following consent, the service principal object will be consulted for future authorization requests.