How I locked myself out of my VSTS tenant
One of our main concerns at Nexus Innovations is to deliver quality software for clients without taking them hostage. After being involved in the phase-out process of dozens of clients with my previous employer, I learned that transferring the output of a software project goes way beyond the source code. What about the precious information included in the product and sprint backlogs? The automated builds and deployments? The different test and pre-production environments? Documentation sprinkled across various tools, Sharepoint Wikis, OneNotes, etc?
To ensure that the client phase-out process is as fast and efficient as possible, efforts should be invested in the earliest stages of the project kickoff to package all the relevant artefacts in an easily transferable unit. In that spirit, we’re currently working on a proof of concept approach consisting of creating one VSTS tenant per client, linked to an Azure tenant for the same client. This means that our developers are invited as Guest users in the client’s Azure AD and the VSTS tenant. So far, the approach looks promising, but there is a real danger of locking yourself out of the VSTS tenant! Here’s how it happened to us, and how we could get ourselves out of this frustrating situation.
Fast-forward: filling the AD with Guest users
Here are the steps taken to prepare the client tenants and give access to our team:
- Create the client Azure tenant (domain client.onmicrosoft.com). The owner is admin@client.onmicrosoft.com
- Login to portal.azure.com with admin credentials. Add and configure a subscription.
- Invite myself (user@nexusinno.com) and assign myself as subscription Owner.
- Log to portal.azure.com as user@nexusinno.com. Add a team of Nexus developers to the Active Directory (as Guests).
- Login to https://app.vsaex.visualstudio.com with my Nexus user.
- Create a new VSTS tenant for the client (client.visualstudio.com). In the tenant configuration, click Change to select the client’s active directory:
- Go to the Users tab. Add the Nexus users that were previously added to the client’s Azure AD.
At the end of this procedure. You have a client Azure AD filled with Guest users, a client VSTS tenant with a Guest owner, and a team of Guest users. Sounds like trouble is up next!
This button is begging to be clicked… IT’S A TRAP!
In the Settings tab of the client’s VSTS tenant, there’s a confusingly designed UI that invites you to click if you want to Allow External guest access:
Actually, clicking it denies Guest access (facepalm). And there it is, you instantly get locked out of your VSTS tenant! Any attempts to log back on, with any user, will give you a nice 403 error page.
Why was I tempted to click this button in the first place? Actually, I was trying to connect VSTS connectors to our Microsoft Teams channel (Nexus domain) and could not achieve it with Guest users. I thought I would invite a real Member of the client’s Azure AD, such as admin@client.onmicrosoft.com, to VSTS, and use that User to login to the Teams connector. Unfortunately, for reasons that are still not clear to me, my user could not discover Member users in the VSTS user invite window, as shown below. This led me to think more control should be given to Guest users, and thus to click on the dared button.
Get out of jail free card: PowerShell
If you ever get stuck like I was, there is a way to get out. The idea is to force VSTS into believing you’re a full-fledged Member of client.onmicrosoft.com instead of a Guest. Then you’ll be able to login and reverse the Guest user denial. This simple PowerShell script will do the trick:
#prereq: Install-Module AzureAD Connect-AzureAD #A popup will prompt for your credentials. Use the tenant admin credentials if possible. $user = Get-AzureAdUser -SearchString "john.doe" Set-AzureADUser -ObjectId $user.ObjectId -UserType Member
$$
One you run the script, you can login to the Azure portal to confirm that the change in user type was successful. Then, you should be able to log back to client.visualstudio.com.