Service Principals and Azure AD

There are a few scenarios with Azure AD that folks commonly run in to.

I have not blogged about the relationships of an Azure Tenant and Azure AD.  So let me briefly mention the relationship between these two.
(I will be repeating this all in future posts, as this relationship is important to grok)

An Azure Tenant is the Account that you or your company has in Azure.  It is divided into Subscriptions. 
Each Subscription is where you 'consume' in Azure; and it also serves as an isolation boundary (as in, resources in different services can only talk to each other through public entry points - they cannot directly touch each other).
Below that you have Resource Groups, which are management containers (not isolation).
And then you have the actual resources that you get billed for consuming.

All of this together is an Azure Tenant - or phrased another way, you are a Tenant of Azure and this is your playground and thus billing entity.
I will keep using the phrase Azure Tenant in this way.
(I run across MSFT folks that use the word Subscription when referring to the Tenant, and it is just plain incorrect and thus confusing as to the ramifications)

Azure AD is an entirely separate thing.  It is this huge multi-tenant cloud based identity provider, with a number of cool features and touch points.
An Azure Tenant must have an associated Azure AD, but an Azure AD has no dependency on an Azure Tenant (or an Office365 tenant - which is yet another entity).

A single company can have multiple Azure AD's (which is highly likely), they could also have multiple Azure Tenants (which is not very likely, but possible).

A single Azure Tenant can only be associated with one Azure AD.  Nuance here; the tenant has one Azure AD, but people from other Azure ADs can be granted access.  But the invited accounts are foreign accounts.

I bring all of this up since it is this multi-pronged association that usually gets folks into a pickle.

The "Service Principal" is a term that has been within the IT world for a long time.  It describes the user account that a particular application or service runs under.  If that application needs to access resources on the network, the Service Principal user account for that particular service is used.

This has worked well for decades in the enterprise with Active Directory.  And now we need to take this to the cloud.  And it works a bit differently with Azure Active Directory.

Within Azure Active Directory the service principal is called an "App Registration".  And just like with the enterprise, you would have a unique app registration for each application.

This is different than a user account that you simply grant access to Azure resources.  While it really appears to be the same thing, it actually isn't.

Now, as we put things together a number of questions arise.  Which Azure AD should my app registration reside in?  Is there any limitation on the user account?  What resources does the app registration need to access?

Most likely you are using the app registration to interact with your Azure tenant resources.  For example, the app registration is used to provision new machines, or to power machines on and off.  Essentially to perform lifecycle events on your Azure resources.

This means that the app registration must be "native" to the Azure Tenant Azure AD - regardless of what Azure AD your user accounts reside in.  You cannot simply use a random user account.

If you manually create your app registration, you need to be a user administrator in your Azure AD.  And then you can grant the permissions to the Subscription or Resource Groups and you are golden.

https://itproctology.blogspot.com/2017/04/manually-creating-service-principal-for.html

If you are using some other app to create the app registration programmatically things immediately get unique.  All of a sudden your user account matters.

And to programmatically create an app registration, your user account needs to be native to the 

Azure AD.

This is a special kind of native.  The Azure AD account that you use must be an "onMicrosoft" account within that Azure AD.  You cannot use a user account that is synchronized with your on-premises Active Directory.  It does not even matter if your user is a domain admin.

Each Azure AD begins life as an "onMicrosoft" entity.  If you look at the properties of the Azure AD, you will see the information about its original creation, such as brianeh.onmicrosoft.com.  And this remains even if you add a vanity domain, such as ITProctology.com to the Azure AD.

I mention all of this because you might be in a position where you need to create a special Azure AD account, so that your app can create its own app registration (Citrix Cloud does this, RDMI does this).

In your Azure AD, create a new cloud user, using name@domain.onmicrosoft.com  This will create a cloud user that is native only to the Azure AD, and this user will have the full permissions to the API that it needs to create an app registration.

In your app you need to then use the credentials of this new user account so that it can access the API and self create its app registration.

A lot of explanation just to get you to the answer, but the why is often as important as the what.