Unlike the subscription level, you cannot just uses Az DevOps command with a management group parameter. This does not appear to be available, the answer is to pass in a json template.
On the above picture, you can see next to the words Tenant Root Group a link (details). You probably do not have the details link clickable at this time. This is because although you have been able to create the initial Tenant Root Group – Management Group, you need to promote your account access to it.
Note: You can only do this as a Global Administrator.
In the left hand navigation under Manage, click Properties
Under Access management for Azure resources switch the button to Yes.
Now if you go back to the Tenant Root Group – Management Group, you will be able to click the details link and have access to the Management group, see deployments made at that level, modify access for others etc.
Switching the button to No will then remove your access.
Programatically
Using Az Cli, log in with you account first az login. The below snippet, on line 2 shows how to give yourself access. Where line 5 & 6 would remove the account.
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Running of this code, will create a DevOps project if it doesn’t exist, and then create a Management Group level Service Connection to the Tenant Root Management Group. To apply to a different level management group would require modification to the code to grab the name and ID of the management group you wish to use and pass into the JSON template.
Your account is now set up to run, you will need to first be logged into AZ Cli.
Note: This can be a Service Principal, as long as the account being used is able to list App Registrations, and has ‘User Access Administrator’ RBAC on the Tenant Root Group – Management Group.
You will need to create a ‘management-group.json’ file which is used as a template, and key tokens will be replaced within the script.
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
(Line 32) – How the authentication works with DevOps. The Personal Access Token is added to the $Env: variable “AZURE_DEVOPS_EXT_PAT”
(Line 61 – 74) – Updating the json template, saving the file as a temp file, and then creating the Service Connection passing in the json template. The json template is the same template used by Azure DevOps when you set up the Management Group Service connection manually, you can see this by watching the network traffic.
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
To run the above code, you will need to put in your parameters. Replace with your values then run the below script, this will call the script above.
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
A previous post of mine Connecting to Azure Devops with a Service Principal has been popular since I have written it. Therefore, I’ve decided to extend on the topic and show how you can do it programatically with AZ DevOps.
Sign in and click on User settings -> Personal access tokens
Click New Token
Give it a meaningful name so you know what the PAT token is for in the future. (E.g, Devops Service Connection)
Select your Organization
Select the Expiration date for as long as you need. Maximum 1 Year
Select Scopes at Full access (You might want to tighten your permission in a production environment, for this demo Full access is fine).
Click Create
Once you have clicked Create this is the only chance to grab a copy of the token. Please take a copy of this token as you will require it later.
The Code
You will need to first be logged into Az Cli. You can sign in using a service principal as you might with a pipeline, as long as the account being used is able to list App Registrations, and ‘User Access Administrator’ RBAC role to be able to apply contribute access to the DevOps service principal on the subscription (Line 43) .
The important part to note in the code is how the authentication works with Devops. The Personal Access Token is added to the $Env: variable “AZURE_DEVOPS_EXT_PAT”. (Line 32)
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
To run the above code, you will need to put in your parameters. Replace with your values then run the script, this will call the script above.
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
I see a lot of blogs and examples on the internet that shows you how to connect to environments using a username and password. This is all well and good for testing, but I believe it is bad for real world scenarios.
I’m a contractor, and my time at the job is defined, after I leave the contract and move onto the next one, the company should disable my account. What happens next? Everything I have built using a username/password, stops working. Yes, I could argue, it ensures I get a call back, but most contracts I’ve been involved in have a clause that any bugs found will be fixed for free up to 3-6 months after the job is done. Also, I like to leave a place with them thinking “That guy is awesome, lets get him back for the next project!”.
This post is going to show you how to set up a Service Principal for your Azure Devops CI/CD. At the end, I will give a very basic deployment that creates a Resource Group in Azure. Please note, this example is to show how to set up when your Azure Devops is not part of the same Directory as your Azure Resource Tenant. When it is part of the same tenant.
First, we need to start in Azure and create a Service Principal. The Service Principal will need to be a contributor on the Subscription or the Resource group that your Devops project is going to manage.
Supported account types: Accounts in this organizational directory only (Single Tenant)
Redirect URI: (Leave blank)
Click Register
Make a note of Application (client) ID and your Directory (tenant) ID.
Create a Secret for the Service Principal
In the App Registration for the above app, click Certificates & secrets.
Under Client secrets, click New client secret
Description: DEVOPS
Expires: Never
Click Add
Make note of the secret
Assign Service Principal permission to Subscription
Open Azure Portal
Navigate to Subscriptions and select your subscription
Click Access control (IAM)
Click Add -> Add role assignment
Role: Contributor
Assign access to: Azure AD user, group, or service principal
Select: <Name of service Principal>
Click Save
From the Overview blade, grab the Subscription ID and Subscription Name.
You can also add API permissions, such as Graph, and then make direct calls to Graph API using PowerShell using this service principal within the pipeline. Now this side has all been set up, we can head over to our Devops.
Create Service Connection in Devops
Go into your project.
At the bottom left of your screen click Project Settings
Within Project settings, underneath Pipelines click Service connections*. If you have a star next to the Service connections word, it means that you are viewing the preview version. I’m going to show the following screens using a preview version.
Click Create service connection
Select Azure Resource Manager, click Next
Select Service principal (manual), click Next
On the New Azure service connection blade, (replace values with your values you grabbed earlier)
Environment: Azure Cloud
Scope Level: Subscription
Subscription Id: <SubscriptionID>
Subscription Name: <Subscription Name>
Service Principal Id: <Application (client) ID>
Credential: Service principal key
Service Principal Key: <Secret>
Tenant ID: <Directory (tenant) ID>
Details (This section is your choice)
Service connection name: <Name of Tenant>-<SubscriptionName>
Description:
Security: Tick – Grant access permission to all pipelines.
Click Verify, a Verification Succeeded should show if all the details are correct, and the service account has permission.
Click Verify and save
The Service Principle is now connected
Proving the Service Principal connections works
Within your Dev Ops project, click on Pipelines and select releases. We are going to create a Resource Group within our subscription.
Close the stage window. We don’t need any artifacts for this as I’m going to write AZ CLI code inline. Click on 1 Job, 0 task.
Add an Azure CLI task.
Task verison: 2*
Azure Resource Manager connection: Pick the subscription you have created in the previous section.
Script Type: PowerShell
Inline script: Inline Script
Inline script: az group create –name “Demo-rg” –location uksouth
Click Save and create a release. After the release has run, and you have received success, an empty resource group should have been created within the subscription.
SharePoint and other geeky stuff 
