{
	"id": "cfe38213-85ed-45a4-b552-f048ee664809",
	"created_at": "2026-04-06T00:21:20.805948Z",
	"updated_at": "2026-04-10T13:11:28.926127Z",
	"deleted_at": null,
	"sha1_hash": "d621e02fcd33c6bcef5f89fbb3ef86704ec5e559",
	"title": "Demystifying Azure AD Service Principals",
	"llm_title": "",
	"authors": "",
	"file_creation_date": "0001-01-01T00:00:00Z",
	"file_modification_date": "0001-01-01T00:00:00Z",
	"file_size": 81301,
	"plain_text": "Demystifying Azure AD Service Principals\r\nPublished: 2019-07-16 · Archived: 2026-04-05 13:28:55 UTC\r\nAnyone who’s worked with Azure for a bit has encountered the need to create a service principal. If you are an IT\r\nOps person, you probably equate an SP with a service account in local Active Directory. If you’re more of an\r\napplication developer, then you may have created an SP as part of your application in Azure, because you want to\r\ngive that application permissions to Azure resources. The purpose of this post is to tease apart what service\r\nprincipals are, how they interact with application objects, and all the myriad ways to create an SP on Azure.\r\nAzure Active Directory Applications\r\nThe first thing you need to understand when it comes to service principals is that they cannot exist without an\r\napplication object. If that sounds totally odd, you aren’t wrong. The service principal construct came from a need\r\nto grant an Azure based application permissions in Azure Active Directory. Since access to resources in Azure is\r\ngoverned by Azure Active Directory, creating an SP for an application in Azure also enabled the scenario where\r\nthe application was granted access to Azure resources at the management level. That is all very useful in the\r\ncontext of creating applications in Azure. If you wanted an account in Azure AD to use for automation or to power\r\na service, then you could use the same construct. Instead of creating a separate object type in Azure AD, Microsoft\r\ndecided to roll forward with an application object that has a service principal. For the purposes of using an SP like\r\na service account, the application it creates as part of the process sits unused and misunderstood.\r\nTo make things even more confusing, a single application object can have multiple service principals across\r\ndifferent Azure AD tenants. When an application object is registered with the home tenant, an SP is also created in\r\nthat Azure AD tenant. If the application being developed is a single-tenant application, that’s the only SP needed.\r\nBut if the application is meant to be multi-tenant - by which I mean multiple Azure AD tenants - then it will have\r\nan SP created in each tenant that uses it. The consent process of enabling an application for your Azure AD tenant\r\nincludes creating and granting permissions to that application object in the form of an SP in your tenant.\r\nOf course, if your whole goal was to use a service principal to do some automation, then you don’t care about any\r\nof this nonsense. You just want to create an SP and be done with it.\r\nService Principals\r\nAs an IT Ops person trying to get some work done, you don’t care about the application object. You probably\r\ndon’t want to deal with the application object. You just want to create an SP. There is NO way to do this without\r\nalso creating an application object. That’s the decision that Microsoft made, and it seems to be sticking with it.\r\nWhat that means is that depending on which tool you use to create a service principal, you may need to create an\r\napplication object first. For instance, the portal requires that you create the application object first and doesn’t\r\neven mention the service principal as a construct. If you are using a different tool, it may automatically create that\r\napplication object for you. For instance, the Azure CLI allows you to directly create an SP, and it will take care of\r\nhttps://nedinthecloud.com/2019/07/16/demystifying-azure-ad-service-principals/\r\nPage 1 of 6\n\ncreating that application object for you in the background. How helpful! The downside is that there are so many\r\ndifferent tools to use with Azure, and they ALL seem to have a different workflow. You can create an SP by using:\r\nThe Azure Portal\r\nThe AzureAD PowerShell Module\r\nThe Az PowerShell Module\r\nThe AzureRM PowerShell Module\r\nThe Azure CLI\r\nOther Azure SDKs\r\nThe Azure AD API\r\nThe Microsoft Graph API\r\nHoly cow! What’s a poor IT Ops person to do? Let’s break it down with what will likely be the most common\r\nways you will create a Service Principal.\r\nCreating Service Principals\r\nMicrosoft Graph API\r\nThe one thing that all of these tools have in common is that they are all referencing one of two APIs to perform\r\ntheir operations. Microsoft is in the process of deprecating the Azure AD API in favor of the Microsoft Graph API.\r\nAll the other methods are using some kind of SDK to interact with one of these two APIs. If you’re curious about\r\nthe Azure AD API, the relevant sections for the application and service principal objects can be found in the entity\r\nand complex types area of the docs. The Microsoft Graph API docs seem to be a little better organized, and you\r\ncan find information on applications and service principals. Funny thing that I noticed, there is no create function\r\nfor the service principal object. The resource appears to be implicitly created when an application is registered\r\nwith a tenant.\r\nThe Azure Portal\r\nThe experience for registering an application and creating a service principal has changed recently. I’d like to say\r\nit makes more sense now, but I would be lying. As far as I can tell it’s more confusing with check boxes that don’t\r\nfully explain what they want you to do. Regardless, if you want to create a service principal through the portal,\r\njust follow these directions.\r\nThe AzureAD PowerShell Module\r\nIf you don’t already have the AzureAD PowerShell module, you can install it by running Install-Module\r\nAzureAD -Force . Then run the following commands:\r\nConnect-AzureAD -TenantId \"YOUR_TENANT_ID\"\r\n$myApp = New-AzureADApplication -DisplayName \"AzureAD Module App\" -IdentifierUris \"https://azureadmoduleapp\"\r\n$mySP = New-AzureADServicePrincipal -AppId $myApp.AppId\r\nhttps://nedinthecloud.com/2019/07/16/demystifying-azure-ad-service-principals/\r\nPage 2 of 6\n\nObviusly, the AzureAD module does not take care of creating the application object for you. You have to do that\r\nfirst and then create the SP. The commands above will get you a service principal, but without any type of\r\ncredentials to login. If you want a password associated with the service principal, then you can run the following:\r\n$spCredParameters = @{\r\n StartDate = [DateTime]::UtcNow\r\n EndDate = [DateTime]::UtcNow.AddYears(1)\r\n Value = 'MySuperAwesomePasswordIs3373'\r\n ObjectId = $mySP.ObjectID\r\n}\r\nNew-AzureADServicePrincipalPasswordCredential @spCredParameters\r\nNow you have a service principal that you can assign roles and permissions to.\r\nThe Az PowerShell Module\r\nThere’s a new Azure PowerShell module on the block. The Az module is replacing the original AzureRM module.\r\nThe reason? Partly, Microsoft just wanted to shorten the commands by five letters. They also wanted to rewrite the\r\nmodule to take advantage of new functionality in PowerShell and in Azure and get rid of some of the old\r\ncommands that maybe weren’t following best practices. Regardless, this is the module you’ll be using to do things\r\nwith Azure going forward. If you’re currently running AzureRM, beware here there be dragons. You need to\r\ncompletely remove AzureRM first, or install PowerShell 6 and run the Az module in PowerShell 6 context instead.\r\nTo create a service principal with the Az module, run the following commands:\r\nConnect-AzAccount\r\n$mySP = New-AzADServicePrincipal\r\nThat’s it. The good news is that the command creates the application in the background for you. And that is pretty\r\nmuch where the good news ends. In this case, the command creates a service principal with a display name that\r\nstarts azure-powershell- and appends the current date and time. It also gives it a secret of the type\r\nSystem.Security.SecureString which is not particularly useful. It is possible to decrypt it, but I would recommend\r\nsetting a password credential manually like we did in the AzureAD module example. You might think that there is\r\na command like New-AzureADServicePrincipalPasswordCredential in the Az module, and you would be partly\r\ncorrect. There is the New-AzADSpCredential command, but that only allows you to add a certificate type and not\r\na password. No idea why that choice was made. Maybe because Microsoft hates passwords?\r\nBefore we get into the process for creating a password based credential, which I assure you is non-intuitive and\r\nannoying, I would first like to point out something that really annoys me. The service principal object from the\r\nAzureAD module isn’t the same type as the service principal object from the Az module. If you run Get-Member\r\non the SP object from the AzureAD module you get the TypeName\r\nMicrosoft.Open.AzureAD.Model.ServicePrincipal , whereas with the Az module you get the TypeName\r\nMicrosoft.Azure.Commands.Resources.Models.Authorization.PSADServicePrincipalWrapper . The properties\r\nhttps://nedinthecloud.com/2019/07/16/demystifying-azure-ad-service-principals/\r\nPage 3 of 6\n\nexposed in each object type also differ. The AzureAD module exposes 25 different properties, and the Az module\r\nexposes only 7. If I might present a table for comparison:\r\nAz AzureAD\r\nApplicationId AppId\r\nDisplayName DisplayName\r\nId ObjectId\r\nObjectType ObjectType\r\nSecret N/A\r\nServicePrincipalNames ServicePrincipalNames\r\nType N/A\r\nRight off the bat, the ApplicationId is named differently across the two objects. So is the ObjectId. And it’s not\r\neven consistent in its inconsistency. The Az modules uses the longer ApplicationId property and the shorter Id\r\nproperty. Then there is the Secret property, which is really just the value stored in one of the keys in the\r\nPasswordCredential property. A service principal can have multiple passwords - aka secrets - which are held in an\r\narray in the PasswordCredential property. The PasswordCredential property is an object type of\r\nMicrosoft.Open.AzureAD.Model.PasswordCredential . There is a separate KeyCredentials property and object\r\ntype that houses certificate based authentication. The New-AzADSpCredential command takes a cert value and\r\nadds it to the service principal in a property that is not even exposed by the Az implementation of the service\r\nprincipal type. That means you need to run the Get-AzADSpCredential command to get the value back. In order to\r\ncreate a password based credential, you have to create PasswordCredential object directly like this:\r\n$credProps = @{\r\n StartDate = Get-Date\r\n EndDate = (Get-Date -Year 2024)\r\n KeyId = (New-Guid).ToString()\r\n Value = 'MySuperAwesomePasswordIs3373'\r\n}\r\n$credentials = New-Object Microsoft.Azure.Graph.RBAC.Models.PasswordCredential -Property $credProps\r\nSet-AzADServicePrincipal -ObjectId $mysp.Id -PasswordCredential $credentials\r\nThat’s if you want to configure a password after creation of the SP. If you wanted to set the password while\r\ncreating the service principal, you have to create a completely different object type. When you run New-AzAdServicePrincipal with the PasswordCredential parameter, the command is expecting an object of type\r\nMicrosoft.Azure.Commands.ActiveDirectory.PSADPasswordCredential . When you run Set-AzAdServicePrincipal with the PasswordCredential parameter, the command is expecting an object of type\r\nhttps://nedinthecloud.com/2019/07/16/demystifying-azure-ad-service-principals/\r\nPage 4 of 6\n\nMicrosoft.Azure.Graph.RBAC.Models.PasswordCredential . And it will not do an implicit conversion for you!\r\nInstead you have to do the following:\r\n$credProps = @{\r\n StartDate = Get-Date\r\n EndDate = (Get-Date -Year 2024)\r\n Password = 'MySuperAwesomePasswordIs3373'\r\n}\r\n$credentials = New-Object Microsoft.Azure.Commands.ActiveDirectory.PSADPasswordCredential -Property $credProps\r\n$sp = New-AzAdServicePrincipal -DisplayName \"WhateverItDoesntMatter\" -PasswordCredential $credentials\r\nYou may have also noticed that the two different object types have different arguments. One expects a KeyId and\r\nValue and the other expects a Password argument only.\r\nMy advice is this. Don’t use the Az module for managing Azure AD resources. It’s a hot mess.\r\nThe Azure CLI\r\nUnlike the PowerShell modules, the Azure CLI is written in Python. The process for creating a service principal is\r\nsimple. Run the following command:\r\naz ad sp create-for-rbac -n \"MySpCLI\"\r\nThe command will create the application object in the background for you. And the output will include all the\r\ninformation you need to use the service principal, including the password in clear text.\r\n{\r\n \"appId\": \"d9bdde72-73eb-4bc2-8dbf-0855c0d19820\",\r\n \"displayName\": \"MySpCLI\",\r\n \"name\": \"http://MySpCLI\",\r\n \"password\": \"7778ef85-2c5a-4f8d-81d5-88389c9a4feb\",\r\n \"tenant\": \"f06624a8-558d-45ab-8a87-a88094a3995d\"\r\n}\r\nThat’s all there is to it. Super easy and simple.\r\nConclusion\r\nI started this post hoping to demystify the application and service principal relationship and shed some light on\r\nhow to use different tools to accomplish the same goal. At the end, I may have made things a little more\r\nconfusing. But that simply reflects the confusing nature of service principal kludge. My advice would be to use\r\nthe Azure CLI to create a service principal. The command is simple. You can run it from the Cloud Shell if you\r\ndon’t have the Azure CLI locally. It is faster than using the portal, and easier than using PowerShell. Additionally,\r\nhttps://nedinthecloud.com/2019/07/16/demystifying-azure-ad-service-principals/\r\nPage 5 of 6\n\nmany resources in Azure now have the ability to use Managed Service Idenities (MSIs) to access other Azure\r\nresources. You still need service principals for some use cases, but I would highly recommend checking to see if\r\nan MSI can meet your requirements.\r\nSource: https://nedinthecloud.com/2019/07/16/demystifying-azure-ad-service-principals/\r\nhttps://nedinthecloud.com/2019/07/16/demystifying-azure-ad-service-principals/\r\nPage 6 of 6",
	"extraction_quality": 1,
	"language": "EN",
	"sources": [
		"MITRE"
	],
	"origins": [
		"web"
	],
	"references": [
		"https://nedinthecloud.com/2019/07/16/demystifying-azure-ad-service-principals/"
	],
	"report_names": [
		"demystifying-azure-ad-service-principals"
	],
	"threat_actors": [],
	"ts_created_at": 1775434880,
	"ts_updated_at": 1775826688,
	"ts_creation_date": 0,
	"ts_modification_date": 0,
	"files": {
		"pdf": "https://archive.orkl.eu/d621e02fcd33c6bcef5f89fbb3ef86704ec5e559.pdf",
		"text": "https://archive.orkl.eu/d621e02fcd33c6bcef5f89fbb3ef86704ec5e559.txt",
		"img": "https://archive.orkl.eu/d621e02fcd33c6bcef5f89fbb3ef86704ec5e559.jpg"
	}
}