6

I have a hard time understanding the lifetime of the service principal created in Azure AD when creating the service connection between Azure DevOps and Azure. I do it like this:

I pick the Azure Resource Manager Choosing the ARM connection manager

And then i choose the recommended Recommended approach

Hereafter I fill in the blanks Service connection create

I now have a valid service connection and I can deploy from DevOps to Azure. The only thing i need is a user with enough rights to do this. I can even see the service principal in Azure where it tells me that the client secret will expire in two years: Expire of client secret

What i dont understand:

  1. does the service connection then stop working when the secret expires? Or will DevOps somehow extend the expire date?
  2. i cant read this anywhere, so it is up for my own interpretation on how i understand the "service principal" concept, but if the user used to create the principal gets disabled or deleted, then the service principal will persist, correct?
  3. if 2) is correct, then when will the principal get deleted? When the scope of the principal gets deleted? Or when the service principal itself gets deleted?
Improve this question

2 Answers 2

Reset to default
4

I will try to elaborate a lite about those topics.

  1. When secret expires and you got error, you have to refresh connection. Go to Edit dialog for connection and save without any changes. Described here: Azure devops service connection expired and cannot edit/renew

    But I have already tested scenario when I delete all secrets assigned to service principal used for the Azure DevOps connection. And it is still working. So I can assume, that it depends on how you create connection (automatic or manual service principal). When created with automatic path, it doesn't depend on secrets.

    On the other hand, when I add connection with manually providing service principal, then delete all secrets, the connection stops working.

  2. Yes, the service principal will exist. But best practice is to set up more then one Owner of the service principal. If the only one service principal owner is deleted, you need to have higher permission to manage all service principals.

  3. Service principal will not expire itself, only secrets generated for it. To delete service principal object, you have to do it manually.
Improve this answer
1
  • So properly "mute" a connection (if a databreach happended) that has been created with the recommnended approach, you have to delete the service principal? It is not enough to just update, or delete secret.
    – mslot
    May 9, 2020 at 6:50
1

  1. The service principal you created actually exists in your AAD. When it expires, then AAD will stop authorizing any token requests that AAD gets for that SP. So yes, then Azure Devops will start failing auth when it tries to do work.

  2. The SP exists 100% independently of the user that created it so it will persist if the user that created it is deleted.

  3. I believe when it expires, it will sit in AAD in expired state, you can then manually delete it.

SP's exist in AAD under the "application registrations" blade. Another thing to keep note of is that the default creation behavior of a SP is for it to have full RW access to the entire subscription it was created for. You can disable this at creation with an -- option flag.

Improve this answer

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.