1.0 Foundation: Mastering Workload Identity Security in Microsoft Entra ID - An Exploratory Guide
The Foundation - Understanding & Discovering Your Workload Identities (Free Tier)
Welcome to the first official blog in our series on mastering workload identity security in Microsoft Entra ID. Before securing these critical non-human identities, we must understand what they are, the types you'll encounter, and how to discover them within your tenant. This blog focuses on foundational knowledge and actions you can take using the free tier of Microsoft Entra ID.
What are Workload Identities?
In Microsoft Entra ID, a workload identity is used by a software workload (such as an application, script, service, or container) to authenticate and access other resources. Think of them as non-human equivalents to user identities. Just as users need to prove who they are to access data, your applications and services also need identities to securely interact with other services, like Microsoft Graph, Azure resources, or other APIs.
The primary types of workload identities in Microsoft Entra ID are:
Service Principals: A service principal is the local representation, or instance, of an application object in a specific tenant. When an application is registered in Microsoft Entra ID, an application object (the global template) is created. A service principal object is created when that application can access resources in your tenant (either upon registration in your tenant or by consenting to a multi-tenant application). This service principal defines what the app can do in your tenant, who can use it, and what resources it can access. Most of our discussion on securing workload identities will centre on service principals.
Managed Identities for Azure Resources: These are a special type of service principal in Microsoft Entra ID that provides Azure services with an automatically managed identity. The key benefit is that you don't need to manage credentials (like secrets or certificates) for these identities; Azure handles that for you. There are two types:
System-assigned managed identities: Enabled directly on an Azure resource (e.g., a Virtual Machine or Azure Function). Its lifecycle is tied to that resource.
User-assigned managed identities: Created as a standalone Azure resource and can then be assigned to one or more Azure resources. Its lifecycle is managed independently. Managed identities are generally more secure for Azure-to-Azure service authentication as they eliminate the need for developers to handle credentials.
Differentiating Service Principal Types
Not all service principals in your tenant are created equal. You'll typically encounter a mix:
Microsoft-Deployed (Default) Service Principals: These are service principals created by Microsoft for its services and applications that integrate with your tenant (e.g., Exchange Online, SharePoint Online, Azure portal components). They often have well-known Application IDs.
Administrator-Deployed Service Principals (Single-Tenant): These are created when you or other administrators register new applications directly within your tenant for internal use. Their AppOwnerOrganizationId will be your tenant's ID.
ISV or Third-Party Service Principals (Multi-Tenant Consented): These are created when a user or administrator in your tenant consents to a multi-tenant application developed by an Independent Software Vendor (ISV) or another organisation. The application object resides in the ISV's tenant, but a service principal is created in your tenant to represent it locally. Their AppOwnerOrganizationId will be the tenant ID of the external organisation that owns the application.
It's crucial to distinguish these because your management and security posture might differ. For example, while you have full control over your administrator-deployed applications, you rely on Microsoft to manage their default service principals and on ISVs to maintain the security of their applications.
Identifying Microsoft's Default Service Principals:
A reliable way to identify service principals for applications owned by Microsoft is to check their AppOwnerOrganizationId property. Microsoft's services typically use a specific tenant ID.
Microsoft Services Tenant ID:
f8cdef31-a31e-4b4a-93e4-5f571e91255a
You can also often identify them by well-known DisplayName or AppId values, but the AppOwnerOrganizationId is a more definitive indicator.
Inventorying Your Service Principals using PowerShell (Beta Cmdlets)
Let's get hands-on. To see the service principals in your tenant, we'll use the Microsoft Graph PowerShell SDK, specifically calling the beta cmdlets as established in our supporting blog on setting up your PowerShell environment.
Prerequisites:
Microsoft Graph PowerShell SDK installed (see Supporting Blog 0.4).
Connected to Microsoft Graph with appropriate permissions (e.g., Application.Read.All, Directory.Read.All, Organization.Read.All).
# Ensure you have connected with necessary scopes. Connect-MgGraph -Scopes "Application.Read.All","Directory.Read.All","Organization.Read.All"
1. Listing All Service Principals:
To get a list of all service principals in your tenant:
# Get all service principals using the beta cmdlet.
# Request specific properties to potentially improve performance if not all are needed by default.
$allServicePrincipals = Get-MgBetaServicePrincipal -All -Property "Id,AppId,DisplayName,ServicePrincipalType,AppOwnerOrganizationId,SignInAudience"
Write-Host "Found $($allServicePrincipals.Count) service principals."
# Display a few properties of the first few service principals
$allServicePrincipals | Select-Object -First 5 -Property ID, AppId, DisplayName, ServicePrincipalType, AppOwnerOrganizationId | Format-Table
2. Identifying Microsoft-Owned Service Principals:
Due to observed inconsistencies with server-side filtering on the appOwnerOrganizationId (an Edm.Guid property) via Get-MgBetaServicePrincipal, we will use client-side filtering for reliability.
$microsoftTenantIdGuid = [guid]"f8cdef31-a31e-4b4a-93e4-5f571e91255a"
# Fetch all service principals, ensuring appOwnerOrganizationId is retrieved
Write-Host "Retrieving all service principals to identify Microsoft-owned ones (this may take a moment)..."
$allSPsForMsCheck = Get-MgBetaServicePrincipal -All -Property "Id,AppId,DisplayName,AppOwnerOrganizationId"
# Filter client-side
$microsoftSPs = $allSPsForMsCheck | Where-Object { $_.AppOwnerOrganizationId -eq $microsoftTenantIdGuid }
Write-Host "Found $($microsoftSPs.Count) Microsoft-owned service principals."
$microsoftSPs | Select-Object -First 5 -Property ID, AppId, DisplayName, AppOwnerOrganizationId | Format-Table
3. Identifying Service Principals for Your Own Registered Applications (Single-Tenant):
Similarly, we'll use client-side filtering for service principals.
# Get your tenant ID
$myTenantIdObject = Get-MgBetaOrganization
$myTenantIdGuid = [guid]$myTenantIdObject.Id # Corrected: Direct property access
# Fetch all service principals, ensuring appOwnerOrganizationId and signInAudience are retrieved
Write-Host "Retrieving all service principals to identify your organization's SPs (this may take a moment)..."
$allSPsForMyOrgCheck = Get-MgBetaServicePrincipal -All -Property "Id,AppId,DisplayName,AppOwnerOrganizationId,SignInAudience"
# Filter client-side
$myOrgSPs = $allSPsForMyOrgCheck | Where-Object { $_.AppOwnerOrganizationId -eq $myTenantIdGuid }
Write-Host "Found $($myOrgSPs.Count) service principals for applications registered in your tenant."
$myOrgSPs | Select-Object -First 5 -Property ID, AppId, DisplayName, AppOwnerOrganizationId, SignInAudience | Format-Table
Note: For these, also check the SignInAudience property. AzureADMyOrg indicates single-tenant.
4. Identifying Consented Multi-Tenant (ISV/Third-Party) Service Principals:
Client-side filtering is also recommended here for service principals.
$microsoftTenantIdGuid = [guid]"f8cdef31-a31e-4b4a-93e4-5f571e91255a"
$myTenantIdObject = Get-MgBetaOrganization
$myTenantIdGuid = [guid]$myTenantIdObject.Id # Corrected: Direct property access
# Fetch all service principals with necessary properties
Write-Host "Retrieving all service principals to identify third-party SPs (this may take a moment)..."
$allSPsForThirdPartyCheck = Get-MgBetaServicePrincipal -All -Property "Id,AppId,DisplayName,AppOwnerOrganizationId,SignInAudience"
$thirdPartySPs = $allSPsForThirdPartyCheck | Where-Object {
$_.AppOwnerOrganizationId -ne $null -and
$_.AppOwnerOrganizationId -ne $myTenantIdGuid -and
$_.AppOwnerOrganizationId -ne $microsoftTenantIdGuid
}
Write-Host "Found $($thirdPartySPs.Count) service principals for third-party applications."
$thirdPartySPs | Select-Object -First 5 -Property ID, AppId, DisplayName, AppOwnerOrganizationId, SignInAudience | Format-Table
Note: For these, SignInAudience might be AzureADMultipleOrgs or AzureADandPersonalMicrosoftAccount.
5. Identifying Managed Identities:
Server-side filtering for servicePrincipalType is generally reliable.
$managedIdentities = Get-MgBetaServicePrincipal -All -Filter "servicePrincipalType eq 'ManagedIdentity'"
Write-Host "Found $($managedIdentities.Count) managed identities."
$managedIdentities | Select-Object -First 5 -Property ID, DisplayName, ServicePrincipalType, AppOwnerOrganizationId | Format-Table
Understanding the Scope of the Free Tier for Workload Identities
With Microsoft Entra ID Free, you have foundational capabilities for managing workload identities:
Creation and Management: You can create, read, update, and delete application registrations and their associated service principals.
Authentication and Authorisation: Service principals can authenticate and be authorised to access resources based on assigned permissions.
Basic Sign-in Logs: You can view service principal sign-in activity (ServicePrincipalSignInLogs), though retention is limited (typically 30 days). This is crucial for basic auditing.
Managed Identities: The core functionality of managed identities (credential-less authentication for Azure resources) is available.
Application Management Policies: Some basic policies for configuring applications can be enforced.
However, advanced security and governance features like Conditional Access for workload identities, Identity Protection risk detections, automated App Health Recommendations, and sophisticated Access Reviews specifically for workload identity roles require Microsoft Entra Workload Identities Premium.
Next Steps
In this blog, we've laid the groundwork by defining workload identities and showing how to inventory and categorise them using PowerShell. Understanding what you have is the first critical step.
In Blog 2.0, we will build upon this foundation, focusing on basic hygiene practices and native controls available in the free tier to start securing your workload identities, including managing their credentials and permissions. Stay tuned!