<ol>
<li><p>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.</p></li>
<li><p>The SP exists 100% independently of the user that created it so it will persist if the user that created it is deleted.</p></li>
<li><p>I believe when it expires, it will sit in AAD in expired state, you can then manually delete it.</p></li>
</ol>

<p>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.</p>

CC BY-SA 4.0
2020-03-21T05:30:12.227Z
2020-03-21T05:30:12.227Z
Optical Carrier
<p>I will try to elaborate a lite about those topics.</p>

<ol>
<li><p>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: <a href="https://developercommunity.visualstudio.com/content/problem/929344/azure-devops-service-connection-expired-and-cannot.html" rel="nofollow noreferrer">Azure devops service connection expired and cannot edit/renew</a></p>

<p>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.</p>

<p>On the other hand, when I add connection with manually providing service principal, then delete all secrets, the connection stops working. </p></li>
<li><p>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.</p></li>
<li>Service principal will not expire itself, only secrets generated for it. To delete service principal object, you have to do it manually.</li>
</ol>

CC BY-SA 4.0
2020-05-09T06:50:07.527Z
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
CC BY-SA 4.0
2020-04-10T22:14:03.280Z
2020-04-10T22:14:03.280Z
Paweł Tajs
<p>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:</p>

<p>I pick the Azure Resource Manager
<a href="https://i.sstatic.net/xfDbi.png" rel="noreferrer"><img src="https://i.sstatic.net/xfDbi.png" alt="Choosing the ARM connection manager"></a></p>

<p>And then i choose the recommended
<a href="https://i.sstatic.net/WMoC3.png" rel="noreferrer"><img src="https://i.sstatic.net/WMoC3.png" alt="Recommended approach"></a></p>

<p>Hereafter I fill in the blanks
<a href="https://i.sstatic.net/9Reeg.png" rel="noreferrer"><img src="https://i.sstatic.net/9Reeg.png" alt="Service connection create"></a></p>

<p>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:
<a href="https://i.sstatic.net/RtSr3.png" rel="noreferrer"><img src="https://i.sstatic.net/RtSr3.png" alt="Expire of client secret"></a></p>

<p>What i dont understand:</p>

<ol>
<li>does the service connection then stop working when the secret expires? Or will DevOps somehow extend the expire date?</li>
<li>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 <em>will</em> persist, correct?</li>
<li>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?</li>
</ol>

<azure-devops><azure><active-directory>
Azure DevOps service connection: lifetime of service principal
mslot
# Azure DevOps service connection: lifetime of service principal

(Asked by: username_0 on 2020-02-27)

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](https://i.sstatic.net/xfDbi.png)](https://i.sstatic.net/xfDbi.png)

And then i choose the recommended
[![Recommended approach](https://i.sstatic.net/WMoC3.png)](https://i.sstatic.net/WMoC3.png)

Hereafter I fill in the blanks
[![Service connection create](https://i.sstatic.net/9Reeg.png)](https://i.sstatic.net/9Reeg.png)

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](https://i.sstatic.net/RtSr3.png)](https://i.sstatic.net/RtSr3.png)

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?

**Tags:** azure-devops, azure, active-directory


---

## 2 answers

### Answer by username_2 on 2020-04-10. Score: 4 | Accepted answer

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](https://developercommunity.visualstudio.com/content/problem/929344/azure-devops-service-connection-expired-and-cannot.html)

   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.

> **Comments:**
> **username_0**: 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.  

---

### Answer by username_1 on 2020-03-21. Score: 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.


---

