Understanding Azure service accounts

• Author
• Recent Posts

Timothy Warner

Timothy Warner is a Microsoft Cloud and Datacenter Management Most Valuable Professional (MVP) who is based in Nashville, TN. Check out his Azure and Windows Server video training at Pluralsight, and feel free to reach out to Tim via Twitter.

Latest posts by Timothy Warner (see all)

• Install Ansible on Windows - Thu, Jul 20 2023
• Use Azure Bastion as a jump host for RDP and SSH - Tue, Apr 18 2023
• Azure Virtual Desktop: Getting started - Fri, Apr 14 2023

A service account in Windows Server is a noninteractive user account that runs a specific service or service component. Service accounts provide a way to isolate the identity and permissions of a service from the identity of the user who is logged on to the computer.

Service accounts enable a Windows service to run with the privileges and permissions it needs to perform its functions without requiring the user to have elevated permissions or access to sensitive information; this is the information security principle of least privilege. Critical to service accounts is the fact that they are noninteractive identities that are used by processes and not by human beings.

A group managed service account in Windows Server Active Directory

You can draw a direct analogy between the service account in Windows Server AD and the service principal in Azure AD. A service principal in Azure is a type of security identity used by applications, services, and automation tools to access resources and perform operations in Azure.

In addition to service principals, Azure knows two other types of service accounts: managed identities and user accounts employed as service accounts. Let's have a closer look at these three types of Azure service accounts.

Azure service principals

In my experience, the confusion for many Azure professionals here lies in determining:

• Of the various types of service principal available in Azure, which should I choose for my use case?
• What's the difference between the App registrations and Enterprise applications blades in the Azure portal?
• Which Azure resources can be granted role-based access control (RBAC) role assignments directly?

Let's dive right in to iron out these common and understandable points of confusion. To do so, we'll differentiate the service principal types:

• Application service principals
• Managed identities
• User accounts designated as service principals

Application service principals

Application registration in Microsoft Azure is the process of listing your Azure AD-backed application in your Azure AD tenant. By registering an application in Azure AD, a service principal is automatically created. It therefore becomes a recognizable entity in the directory and can be assigned roles, granted permissions, and managed just like a user account.

The application registration process generates an application ID (also called a client ID), which serves as the unique identifier for the application, and can be used to obtain an OAuth2 access token that authenticates both itself and other Azure AD users to access Azure resources.

Therefore, an app registration endpoint can sign users into your app using Azure AD authentication. The app can also obtain a token on its own behalf if you granted the service principal direct permissions.

Here's how a developer can create an application registration by using Azure PowerShell:

$app = New-AzADApplication -DisplayName '4sysopsCloudApp1 -IdentifierUris 'https://4sysopscloudapp1.azurewebsites.net'
$secret = New-AzADAppPasswordCredential -ObjectId $app.ObjectId
New-AzADAppRoleAssignment -ObjectId $app.ObjectId -RoleDefinitionName 'Contributor' -PrincipalId $app.ObjectId

Note that the preceding PowerShell code creates a client secret (essentially, a time-limited password) in addition to app registration. Thus, the app registration service principal presents its application ID as "username" and either a secret or public key certificate as its "password" to Azure AD to obtain an access token.

An app registration service principal in the Azure portal

Now let's address the eternally confusing "What's the difference between the App registrations and Enterprise applications blades in the Azure portal?" question. Here's the deal:

• App registrations: These are the canonical definitions and endpoints for your own organization's Azure AD-backed applications.
• Enterprise applications: These are applications that you created yourself (and that also appear on the App registrations blade), as well as third-party applications for which you've configured a single sign-on (SSO) authentication flow.

Enterprise applications blade in the Azure portal

Let's consider another type of Azure service principal that's optimized for our work as systems administrators: the managed identity.

Managed identities

Two types of managed identities exist: user-assigned identities and system-assigned identities.

User-assigned managed identities

What's been historically confusing for us systems administrators is that we had to create app registrations whenever we needed a noninteractive service principal identity for use in our automation scripts. That's not the case anymore (although you're welcome to continue using app registrations for this purpose, if that's your thing).

A user-assigned managed identity in Microsoft Azure is created and managed by an Azure user rather than by the Azure platform. It provides Azure resources with an identity that can be used to authenticate with other Azure resources, without the need for the user to manage or store the identity's credentials.

A user-assigned managed identity can be created and managed through the Azure portal, Azure CLI, or Azure PowerShell, a software development kit (SDK), or by making direct calls to the Azure Resource Manager REST API.

The managed identity can be associated with one or more Azure resources. This type of managed identity can be used in situations where a resource needs to run a long-running process or communicate with other resources without the need for the user to manage the identity's credentials, particularly the password.

Granting an RBAC role to a user assigned managed identity in Azure

Here's how you can authenticate a PowerShell script with a user-assigned managed identity:

$resourceGroupName = '4sysops-rg'
$managedIdentityName = 'msi-4sysops'
$managedIdentity = Get-AzUserAssignedIdentity -ResourceGroupName $resourceGroupName -Name $managedIdentityName
Connect-AzAccount -Identity -AccountId $managedIdentity.ClientId -TenantId $managedIdentity.TenantId -SubscriptionId $managedIdentity.$SubscriptionId

System-assigned managed identities

A system-assigned managed identity in Microsoft Azure is automatically created and managed by the Azure platform for an Azure resource. It provides the resource with a unique identity that can be used to authenticate with other Azure resources, without the need for the user to manage or store the identity's credentials.

A system-assigned managed identity is automatically created when you enable the feature for an Azure resource, such as a virtual machine or an Azure function. It is tied to the lifecycle of the resource, meaning that when the resource is deleted, the system-assigned managed identity is also deleted.

System-assigned managed identities provide a secure and convenient way to access other Azure resources and perform operations with specific permissions. They can be used in situations where a resource needs to run a long-running process or communicate with other resources, without the need for the user to manage the identity's credentials.

Once created, a system-assigned managed identity can be used just like any other managed identity in Azure, providing a secure and convenient way to access other Azure resources and perform operations with specific permissions. See the Azure docs to learn which Azure services support system-assigned managed identities.

Assigning a role to a system assigned managed identity

User accounts employed as service accounts

Although technically, you can use any interactive Azure AD user account as a service account, doing so is not recommended. In my experience, the biggest disadvantage here is the human factor. Remember, we use service accounts to foster noninteractive authentication for our automation scripts and services.

Human beings are…human beings. They mess up their password, and they get confused with their role-based access control (RBAC) assignments. It's much more reliable and efficient to separate your human Azure AD users from your noninteractive service account identities.

Wrap-up

We covered quite a bit of ground in this article, that's for sure. Let me sum up what you've learned as concisely as possible:

• For your automation scripts, think of user-assigned managed identities first due to their intuitive nature and flexibility.
• For cloud apps, you need to create a registration for them anyway. Leverage their service principals along with least privilege authorization to protect your users, Azure resources, and cloud-hosted data.
• For maximum Azure service traceability, consider enabling a system-assigned managed identity for supported Azure resources to gain visibility into exactly which service requests access which resources.

So whenever someone talks about "service principal" identities in Azure, you know we're essentially talking about a service account, either for a cloud app, a native Azure resource, or a standalone noninteractive identity.