What? How? When? Why?... What?!
Service principals are great to give an identity to an application and set its permissions. Using a service principal, we can, as an example, restrict access for an application to other resources (such as a database) and control what it can do on that database in a more granular way.
Service principals are also great when setting a service endpoint connection in Azure DevOps for example, so you can deploy/configure your Azure resources from within your pipelines using ARM.
However, when you create a service principal, its credentials are by default valid for one year. This is for security reasons, so you don't forget about existing service principals that are hanging there forever and possibly creating a security breach in your infrastructure.
Why should I care?
You should! Because if you don't, your services that rely on service principals for authentication and authorization may just stop working.
In the above scenario of the service endpoint connection in Azure DevOps, your pipelines executions will fail due to the lack of the required permissions.
How do I check for the credentials expiration date of my service principal?
You can do that by using those two simple commands:
$sp = Get-AzADServicePrincipal -DisplayName $myServiceprincipalName
Get-AzADSpCredential -ObjectId $sp.Id
How to deal with that?
Depending on whether your service principal already exists or not, the procedure is slightly different.
Setting the expiration date at the creation of the service principal
If you haven't yet created your service principal, here's how to set a custom expiration date for it during its creation.
Here, we create a service principal named totoSP with the role Reader and we ensure the password will be valid for 150 years. Seems weird (and it is actually) but it's just for the sake of the demo ;) :
$start = get-date
$end = $start.AddYears(150)
New-AzADServicePrincipal -DisplayName 'totoSP' -Role Reader -StartDate $start -EndDate $end
Extend the expiration date for an existing service principal
If your service principal already exists (whether its credentials have expired or not yet), you can set a custom expiration date using the following commands.
Once again, we ensure the password will be valid for 150 years which seems weird (and it is actually) but it's just for the sake of the demo ;) :
# Get the Id of the service principal
$sp = Get-AzADServicePrincipal -DisplayName $myServiceprincipalName
# Set new password with extended expiration date
$start = get-date
$end = $start.AddYears(150)
$credentials = New-AzADSpCredential -ObjectId $sp.Id -StartDate $start -EndDate $end
In case you need that new password (e.g. in order to update your service endpoint connection in Azure DevOps), you can use these commands. Be careful however, you can only use them in the same PowerShell session in which you created that password:
$BSTR = [System.Runtime.InteropServices.Marshal]::SecureStringToBSTR($credentials.Secret)
$UnsecureSecret = [System.Runtime.InteropServices.Marshal]::PtrToStringAuto($BSTR)
Write-Host $UnsecureSecret
The previous script will generate a random password and use it for the new, updated credentials.
If you want to specify your own password, you can do that instead:
$SecureStringPassword = ConvertTo-SecureString -String "@zuR3_R0ck$!!!!" -AsPlainText -Force
New-AzADSpCredential -ObjectId $sp.Id -StartDate $start -EndDate $end -Password $SecureStringPassword
As a conclusion...
Today, we've learned that Azure service principal's credentials have an expiration date. We also learned how to deal with that.
I hope that you found it valuable.
Keep the discussion
You can reach me on Twitter or LinkedIn.
See you soon!
Top comments (5)
@tidjani So is it accurate to assume that the Service Principal's Expiration is agnostic of the person's Azure Account i.e. if the person whose id was used to create the Service Principal, leaves the company or leaves the Azure Tenant, the service principal will still live on until the defined expiry date?
Sorry for the late reply @bbarman4u . Thank you for your question.
It is right to assume that the two entities (the Service Principal and the user account who created it) have their own (and independent lifeycle).
However, it's worth mentioning that you can remove permissions of a Service Principal at any time and even delete that Service Principal.
Just a heads up... I believe Microsoft removed the ability to set your own passwords on service principals.
New-AzADSpCredential :** A parameter cannot be found that matches parameter name 'Password'.**
At line:1 char:68
hmm...looks so, indeed!
Since April 2021 the option to set long-lived passwords has been removed: devblogs.microsoft.com/microsoft36...