Azure DevOps - Are orphaned orgs deleted automatically by the service?

DevOps Azure DevOps
#1

We restrict AzDO org creation for a lot of reasons. When a user leaves the company their org becomes orphaned, that is simple enough to understand and I can claim ownership, I’m the only person in the company with the Azure DevOps Administrator role in AAD.

Are orphaned orgs deleted automatically by the service? An employee left and I did not claim their throw away org, and pulling a list today its gone from the list and the URL throws a 401. I haven’t located a doc that states says orphaned orgs get deleted after x# of days.

I don’t care that its gone, I didn’t expect it to be. Maybe I’ll create a burner user ID in Azure and create and org using it and delete the ID tomorrow.

#2

I do remember hearing that after some amount of inactivity they can be cleaned up but I don’t remember where I got it from so it might as well have been a rumor

#3

If they get automatically deleted I’d think that would be documented some place. I created an org with a burner ID today and want to see what happens to it and have another orphan from another recent separation to watch too. I know a deleted org has 28 days to be recovered, maybe orphaned orgs have similar rules, IDK.

#4

I doubt it would be such a short time if it exists

#5

And I know my users, even if I said delete your orgs on your last day they wouldn’t know how.

#6

Im not sure i would call it orphan org, unless you remove the user from AAD. The azure devops admin can take ownership of accounts at any given time, even when user is still working in the company.

We used to allow users to open their own orgs using company mail. We trusted them to not use any internal material from work into their own org. I mean they go a git pull to thier machines, so not allowing orgs is counter productive and actually reduces capability of users to learn and experiment.

You just inform them that the org can be taken under the ownership of the company at any given time.

In either way, use the report exporter to see how many orgs are open by users and every few months send them a mail reminding them about policy and ask them to close it if they done need it anymore.

#7

These are orgs were created by accounts that have been revently deleted from AAD. Until the user accounts are at least in the recycle bin accessing them goes to the request access page. Some limited testing today once the are deleted it changes to the claim button. Claiming them is easy enough, the surprise was to see orgs from users that quit drop off the report your talking about when I’m the only person that has the ability to claim them and I didn’t. That’s what peeked my interest.

We have some open world test environments that users can do what they like in. Some of the big differences vs a personal org is access/license controls, conditional access, auditing, that sort of stuff. Here the is really no functional reason to have a private org and creating them was disabled long ago. We have tons of integrations and pipeline tasks, non of that exists in a personal org.

Data leakage is a concern, company intellectual property can only exist in specific places. It’s a big challenge to get thousands of users to read a do this not that doc.

#8

I used to work in a very controlled environment where ad users never got deleted even after they left as you needed to have traceability vs security logs kept for years . All users of employees that left were moved to an OU, like xUsers with strict policy. Users were disabled and group membership recorded externally and then cleaned off. All this to not create ghosts records in other systems.

#9

Just remember, users do git pull to local machine, you cant stop them opening an account say at gitlab and pushing the code to their private repo, thus blocking orgs for the sake of IP doesnt really hold ground. Its one of the wrong reasons i hear people try to use when discussing moving from internal onprem repo systems to cloud ones.

Yes i expected the report to ‘miss’ data when users are deleted from aad, thanks for validating this.
Since MS removed the free node for new orgs, i would say opening orgs has become stale.

#10

I don’t disagree. On the network here reaching an external destinations means there are rules that allow traffic to reach them, the doors are closed by default. Your right though a user with enough motivation will always find a way round the layers of firewalls and proxies, its not possible to block every possible destination.

Storing confidential data improperly is a job endangering violation of company policy, they might not read our doc but they sign off on HR’s as a condition of employment :slight_smile:

#11

Personally I won’t check my own 401k or email on my work computer with the ssl injections. I get it, I just don’t care to have my creds decrypted and logged anywhere.

#12

I would be more worried about your bank/pension and email not using certificate pinning in that case

#13

No financial org with their salt should be vulnerable to that kinda mitm in this day and age

#14

Mhm I just looked it up to be sure and apparently certificate pinning is not a thing anymore??? :thinking_face::thinking_face::thinking_face:

#15

I don’t know a ton about certs myself.