Tag: Azure Service Principal

Azure Default Service Principals vs Customer Created

· Leave a comment ·

The other day, a customer asked me to provide the number of Service Principals (SP) in their Azure tenant. Well, that is pretty easy right? Head over to the Azure AD service within the Azure Portal and browse the App registrations (Service Principals) here… But wait, I now want to extract the list of SPs to a file. Great, I can use the following CLI or PowerShell query “az ad sp list” or “Get-AzADServicePrincipal” to retrieve that information. Wait a second… now why do I see nearly 700 SPs in PowerShell, yet when I take a look at the Portal, I can see there are maybe 100 Service Principals at best. This cannot be right! Why is PowerShell/CLI generating a list of nearly 700 Service Principals, whereas the portal only shows me ~100 SPs? Something is up… Let’s take a deeper dive here.

Well, after some research, I ran into the following blog post from fellow Microsoft MVP, Rick Van Rousselt you can find that post HERE. Learning Microsoft creates a handful, ~600 Service Principals that are needed for various Azure services, ie. Azure AD, Office 365, Azure Policy, etc. This ia default behaviour for any Azure tenant, and is common for any tenant.

After you execute the following query (“az ad sp list” or “Get-AzADServicePrincipal“) you can see that for some of these ~600 SPs the Tenant ID does not match my customers… The appOwnerTenantId belongs to a Microsoft/Azure tenant. Interesting….

So how do you figure out which Service Principals are customer created/owned, and how do we differentiate between the customer and Microsoft?

Below is what I did, and this should help you identify which Service Principals belong to you (as the customer) and which belong to Microsoft/Azure.

  $result = az ad sp list --query "[].{ServicePrincipalName:appDisplayName,AppID:appId,TenantID:appOwnerTenantId}" --output table --all -o json | ConvertFrom-Json 
  $result | export-csv -Path "C:\temp\ServicePrincipals.csv"  -NoTypeInformation

Now I can filter the Service Principals based on the appOwnerTenantId to differentiate between customer created versus Microsoft/Azure created.

I hope this helped, and now you know Microsoft/Azure creates hundreds of Service Principals in every Azure tenant that are needed for various services, and roles.

What’s an Azure Service Principal and Managed Service Identity?

· 1 Comment ·

One of the general recommendations I always suggest to customers and their environments it leverage Azure Managed Service Identities (or MSI) over the traditional Service Principal (SP). Of course, the question then becomes, well what is the difference? When should I use a Service Principal and when should I use a Managed Service Identity?

In short, the difference is pretty clear. However, let’s make sure we understand what a Service Principal is, and what are they intended for…

What is a Service Principal (SP)?

In Azure, and many cloud environments, Service Principals carry the most weight with regards to access to the environment. Service Principals are an identity created for the use of applications, hosted services and automated tools to access Azure resources. This access is and can be restricted by assigning roles to the service principal(s).

What is a Managed Service Identity (MSI)?

With Managed Identities, there are two types of identities, system-assigned managed identity and user-assigned managed identity.

  1. System-assigned Managed Identity: is created and enabled directly on an Azure service. When enabled, Azure will automatically create the identity for the instance within Azure AD and will ensure it is trusted by the subscription where the instance resides. After the Azure resource/instance is created, the system-assigned managed identity credentials are provisioned onto the instance. The lifecycle is also directly attached to the Azure instance/resource and cannot be shared with other resources. In other words, the managed identity is created within Azure AD when the resource is created, and similarly the managed identity is deleted from Azure AD when the associated resource is deleted.
  1. User-assigned Managed Identity: is created as a standalone Azure resource, where the managed identity is created by the Azure AD administrator. The managed identity is trusted within the subscription and can also be assigned and shared with multiple Azure resources. The lifecycle is not dependent on the Azure resource, in other words, when the Azure resource is deleted, the managed identity is not deleted until the Azure AD administrator manually deletes the identity.

With MSI’s Azure automatically rotates/rolls the credentials every 46 days, Microsoft provides a workflow diagram on how MSIs work with Azure VM’s and other various Azure resources. See the diagram below to understand the credential rotation workflow.

Source: https://docs.microsoft.com/en-us/azure/active-directory/managed-identities-azure-resources/overview

What is the difference?

In short, when considering to use an MSI (Managed Service Identity) or a SP (Service Principal), also consider using a MSI for the reasons below.

MSI’s, managed the creation and automatically roll over the service principal for you. This is done by Azure in the background and requires no human/customer intervention. These credentials are rotated/rolled over every 46 days, this is a default behaviour/policy.

Use an MSI when and where available. Azure continues to grow their list of MSI’s and which resources can work with MSI’s, you can find the list HERE.

 

 

For a complete overview on MSI’s please visit Microsoft’s documentation HERE.