loading...
Cover image for Manage Azure Service principal's credentials expiry

Manage Azure Service principal's credentials expiry

tidjani profile image Tidjani Belmansour, Ph.D. ・3 min read

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!

Discussion

pic
Editor guide