The case
You want to manage resources in other tenants without additional workload around that like accounts creation for you and your teammates in the destination Azure tenant or disabling those accounts if someone leaves the team. Is there any solution for that?
The answer is: yes! And it is called Azure Lighthouse.
From docs:
Azure Lighthouse enables cross- and multi-tenant management, allowing for higher automation, scalability, and enhanced governance across resources and tenants. ~What is Azure Lighthouse?
How does it work?
Azure Lighthouse enables managing resources in another tenant directly from your ‘home’ tenant. You can define with that which users and/or Active Directory Security groups should have access to which resources and with which roles.
Requirements
To set up the Azure Lighthouse solution, you have to fulfill some requirements and gather a bunch of information. The full list you can find here:
- Your tenant ID
- Customer’s tenant ID
- List of subscription IDs and/or resource group IDs to which you have to have access
- List of users and/or Active Directory groups which you want to assign to manage customer environments - IMPORTANT: AD groups have to be Security groups!
- List of roles and permissions (with their IDs) which you want to assign
- Someone with non-guest account in customer’s tenant and
Microsoft.Authorization/roleAssignments/write permission - it is required to create assignment (Deploy the Azure Resource Manager templates) - Something called
mspOfferName and mspOfferDescription - the first one defines the connection between both tenants and their resources. IMPORTANT: You can’t have multiple assignments at the same scope with the same mspOfferName.
How to onboard the customer?
If you gathered all of the above requirements, on Github you can find example ARM templates that allow you to onboard. You have to deploy prepared and fulfilled templates to each subscription separately.
Example
For preparing example I will use the template from the official docs:
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
| {
"$schema": "https://schema.management.azure.com/schemas/2018-05-01/subscriptionDeploymentTemplate.json#",
"contentVersion": "1.0.0.0",
"parameters": {
"mspOfferName": {
"type": "string",
"metadata": {
"description": "Specify a unique name for your offer"
},
"defaultValue": "<to be filled out by MSP> Specify a title for your offer"
},
"mspOfferDescription": {
"type": "string",
"metadata": {
"description": "Name of the Managed Service Provider offering"
},
"defaultValue": "<to be filled out by MSP> Provide a brief description of your offer"
},
"managedByTenantId": {
"type": "string",
"metadata": {
"description": "Specify the tenant id of the Managed Service Provider"
},
"defaultValue": "<to be filled out by MSP> Provide your tenant id"
},
"authorizations": {
"type": "array",
"metadata": {
"description": "Specify an array of objects, containing tuples of Azure Active Directory principalId, a Azure roleDefinitionId, and an optional principalIdDisplayName. The roleDefinition specified is granted to the principalId in the provider's Active Directory and the principalIdDisplayName is visible to customers."
}
}
},
"variables": {
"mspRegistrationName": "[guid(parameters('mspOfferName'))]",
"mspAssignmentName": "[guid(parameters('mspOfferName'))]"
},
"resources": [
{
"type": "Microsoft.ManagedServices/registrationDefinitions",
"apiVersion": "2019-09-01",
"name": "[variables('mspRegistrationName')]",
"properties": {
"registrationDefinitionName": "[parameters('mspOfferName')]",
"description": "[parameters('mspOfferDescription')]",
"managedByTenantId": "[parameters('managedByTenantId')]",
"authorizations": "[parameters('authorizations')]"
}
},
{
"type": "Microsoft.ManagedServices/registrationAssignments",
"apiVersion": "2019-09-01",
"name": "[variables('mspAssignmentName')]",
"dependsOn": [
"[resourceId('Microsoft.ManagedServices/registrationDefinitions/', variables('mspRegistrationName'))]"
],
"properties": {
"registrationDefinitionId": "[resourceId('Microsoft.ManagedServices/registrationDefinitions/', variables('mspRegistrationName'))]"
}
}
]
}
|
with parameters file:
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
| {
"$schema": "https://schema.management.azure.com/schemas/2018-05-01/subscriptionDeploymentParameters.json#",
"contentVersion": "1.0.0.0",
"parameters": {
"mspOfferName": {
"value": "Test PW Lighthouse"
},
"mspOfferDescription": {
"value": "Test PW Lighthouse"
},
"managedByTenantId": {
"value": "11111111-1111-1111-1111-111111111111"
},
"authorizations": {
"value": [
{
"principalId": "22222222-2222-2222-2222-222222222222",
"roleDefinitionId": "b24988ac-6180-42a0-ab88-20f7382dd24c",
"principalIdDisplayName": "PW MC"
}
]
}
}
}
|
I translated the above template to Bicep - it’s much easier to read and edit for me:
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
| @description('Specify a unique name for your offer')
param mspOfferName string
@description('Name of the Managed Service Provider offering')
param mspOfferDescription string
@description('Specify the tenant id of the Managed Service Provider')
param managedByTenantId string
@description('Specify an array of objects, containing tuples of Azure Active Directory principalId, a Azure roleDefinitionId, and an optional principalIdDisplayName. The roleDefinition specified is granted to the principalId in the provider`s Active Directory and the principalIdDisplayName is visible to customers.')
param authorizations array
var mspRegistrationName = guid(mspOfferName)
var mspAssignmentName = guid(mspOfferName)
targetScope = 'subscription'
resource regDefinintion 'Microsoft.ManagedServices/registrationDefinitions@2019-09-01' = {
name: mspRegistrationName
properties: {
registrationDefinitionName: mspOfferName
description: mspOfferDescription
managedByTenantId: managedByTenantId
authorizations: authorizations
}
}
resource regAssignment 'Microsoft.ManagedServices/registrationAssignments@2019-09-01' = {
name: mspAssignmentName
properties: {
registrationDefinitionId: regDefinintion.id
}
}
|
The Bicep file can be used with the same parameters file as the classic ARM template.
For test purposes, I used two different Azure tenants. I ‘home’ tenant I created AD Security group called ‘PW MC’. I wanted to give to chosen subscription the Contributor rights for ‘PW MC’ AD group, so I deployed the above template with the Azure CLI:
1
| az deployment sub create --location WestEurope --template-file ./lighthouse.bicep --parameters lighthouse.parameters.json
|
Previously I logged into the tenant with az login --tenant command.
Effect
The effect should be visible in two places, in both tenants. In the customer tenant when we will go to the Service providers page, we will able to see something like on the screenshot below:
and in the ‘home’ tenant when we will visit the My customers page:
If we click on ‘Default directory’:
Then you can click on the subscription name and do whatever you want with the resources.
Summary
You can see that implementing Azure Lighthouse is quite easy and reduce management concerns. And what is the most important - it is free!
Newsletter
Thank you for visiting my website. I hope you enjoyed the content that I prepared and learned something valuable from it. If you want to be informed about my next entries or occasionally get a message with a collection of some interesting links, please subscribe to my newsletter. I will be extremely pleased if you do this and join my community!