Comment je me suis barré l’accès à mon propre tenant VSTS
Une de nos principales préoccupations chez Nexus Innovations est de livrer du logiciel de qualité pour nos clients sans les prendre en otage. Après avoir été impliqué dans la fermeture d’un département de service impliquant des dizaines de dossiers clients, j’ai appris que le transfert d’un projet logiciel va bien au-delà du code source. Que faire de l’information précieuse contenu dans le backlog de produit et les backlogs de sprints? Que faire des builds et des déploiements automatisés, des environnements de test et pré-production? Que faire de la documentation saupoudrée à travers plusieurs outils (OneNote, Wikis SharePoint, Confluence, etc)?
Pour assurer un processus de transfert rapide et efficace, des efforts devraient être investis en début de projet pour regrouper tous les extrants en un seul endroit, facilement transférable. Pour y arriver, nous travaillons présentement sur une stratégie qui consiste à créer un tenant Visual Studio Team Services (VSTS) pour chaque client lié à un tenant Azure propre au même client. Le client devient donc propriétaire du code, des backlogs, des builds automatisés, et de tous les environnements de test. Par contre, nos développeurs se trouvent à être de simples Guest Users lorsqu’ils s’enregistrent au tenant VSTS et à l’Azure AD. Jusqu’à maintenant, l’approche semble prometteuse, mais il y a un réel danger de se barrer l’accès au tenant VSTS! Voici comment ça nous est arrivé, et comment nous avons réussi à nous sortir de cette fâcheuse situation.
L’histoire courte: comment on se retrouve avec un AD rempli de Guest users
Voici, en quelques étapes, comment nous avons préparé les environnements clients et donné accès à notre équipe de développement:
- Créer un tenant Azure (domaine client.onmicrosoft.com). Le propriétaire du tenant est admin@client.onmicrosoft.com.
- Se connecter à portal.azure.com avec l’usager admin. Ajouter et configurer une souscription.
- Inviter mon propre usager (user@nexusinno.com) et m’assigner en tant que co-propriétaire de la souscription, ainsi que global admin de l’Azure AD.
- Se connecter à portal.azure.com en tant que user@nexusinno.com. Ajouter l’équipe de développement Nexus à l’Azure AD (Guest users).
- Se connecter à https://app.vsaex.visualstudio.com avec mon identifiant Nexus.
- Créer un tenant VSTS pour le client (client.visualstudio.com). Dans la configuration du tenant, cliquer Change pour sélectionner l’AD du client:
- Cliquer sur l’onglet Users. Ajouter l’équipe Nexus qui a déjà été invitée à l’Azure AD du client.
À la fin de cette procédure, vous avez maintenant un Azure AD rempli de Guest users et un tenant VSTS avec un Guest owner et une équipe de Guest users. Ça n’inspire rien de bon pour la suite des choses!
Le bouton qui vous supplie de le cliquer est un traitre!
Dans l’onglet Settings du tenant VSTS, le design visuel est extrêmement ambigu et vous invite à cliquer pour permettre l’accès aux Guest users:
Par contre, le texte du bouton réflète l’état actuel de la configuration, et aura donc l’effet contraire : barrer l’accès aux Guest users (facepalm). Voilà, vous êtes instantannément barrés de votre tenant VSTS! Toute tentative d’y accéder, peu importe l’usager, affichera une belle erreur 403.
Certains pourraient se demander pourquoi j’ai été tenté de cliquer ce fameux bouton… En fait, j’essayais d’utiliser un connecteur VSTS pour Microsoft Teams (domaine Nexus) et je n’y arrivais pas avec les accès invités. J’ai donc essayé d’ajouter un vrai membre de l’Azure AD du client (admin@client.onmicrosoft.com) au tenant VSTS pour ensuite m’en servir au niveau du connecteur Teams. Malheureusement, pour des raisons que j’ignore toujours (délais d’activation, permissions restreintes pour les membres?) mon user@nexusinno.com, propriétaire du tenant VSTS, n’arrivait pas à découvrir les usagers membres de l’Azure AD (tel qu’illustré ci-dessous). J’ai donc cherché une façon de donner plus de droits aux Guest users, dans l’espoir que ça me permettrait d’inviter des membres, et j’ai accidentellement cliqué sur le bouton maudit!
Votre sortie de prison sans frais: PowerShell
Si vous vous retrouvez dans le même pétrin, il y a une façon de s’en sortir sans faire appel au support Microsoft. L’idée est de forcer VSTS à croire que vous êtes un membre en règle du domaine client.onmicrosoft.com plutôt qu’un simple Guest user. Vous serez ensuite en mesure de vous connecter sur client.visualstudio.com et de renverser la mauvaise configuration pour l’accès aux Guest users. Ce script PowerShell tout simple vous permettra de forcer votre statut d’usager auprès de l’Azure AD:
#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
$$
Une fois le script roulé avec succès, vous pourrez vous connecter au portal Azure pour confirmer que le type d’usager a bien été change, puis vous aurez accès au tenant client.visualstudio.com.