Azure Lighthouse: Cross Tenant Management
Azure Lighthouse is a newly announced service by Microsoft Azure. It makes MSP/service provider’s life easier in terms of customer/tenant management and onboarding.
Azure Lighthouse has changed things in many ways and here we are discussing one of them. As a service provider, earlier, to access the customer’s resources in the order to give support, the engineers identify must be in customer’s tenants as guest users. Even if the engineer’s identity is in each customer tenant, they need to switch the directory/tenants in order to work with a different customer. Now, we don’t need to be a guest user in each customer tenant and we don’t need to switch directory/tenants in order to work with multiple customers. Once we login into the portal, we can see all the customers under ‘My Customer‘ and we can access their resources from there. As shown in the below image ‘janakpur’ is the customer and once we click on the customer, we can navigate to the subscription and will get access to the resources as per the permission assigned.
On top of this, it is highly automated and has many ARM templates to make the onboarding process easier.
In this post, we are going to demonstrate how to define the roles and permission of support engineers for all the customer’s tenants.
Preresequites
You must have at least two tenants to perform this task, one will be treated as an MSP and another as a customer. The customer’s tenant must have an active Azure subscription.
Scenario
Azure user Group Nepal (AUGN) is a service provider and has multi-levels of support teams named ‘ Tier 1 Engineer’, ‘Tier 2 Engineer’, and ‘Tier 3 Engineer’. As a service provider, we want Tier 1 engineers should have Read permission, and Tier 2 and Tier 3 engineers should have Contributor permission in all customer’s tenants. To achieve this, we are going to create three groups to assign permission instead of assigning it to each individual user. We create the groups as below in the service provider tenants.
Group Name | Member of the Group |
Tier 1 | All the tier 1 engineers |
Tier 2 | All the tier 2 engineers |
Tier 3 | All the tier 3 engineers |
Prepare MSP Tenants
There is an ARM template available on GitHub by Microsoft. We need to modify the parameters file as per our tenants. Download below both files and modify the parameters file.
File Name | Description |
delegatedResourceManagement.json | Template JSON |
delegatedResourceManagement.parameters.json | Parameters JSON |
Before modifying the file we need to gather certain information from the service provider tenants.
- mspName: Name of the MSP/service provider. In this case, Azure User Group Nepal.
- mspOfferDecription: The service we offer to the customer. Here, AUGN Fully Managed Service.
- managedByTenantid: Tenant ID of the MSP (Azure Active Directory->Properties->Directory ID)
- principalId: Object Id of the group/user (Get-AzADGroup -DisplayName ‘<yourGroupName>’).id . Here, is the object ID of Tier1, Tier2, and Tier3.
- principleIdDisplayName: the display name of the group/user in the customer’s tenant.
- roleDefinitionID: predefined GUID of the role, like Reader, Contributor, and Owner. We can find it here. PowerShell command to get it (Get-AzRoleDefinition -Name ‘<roleName>’).id
{
"$schema": "https://schema.management.azure.com/schemas/2018-05-01/subscriptionDeploymentParameters.json#",
"contentVersion": "1.0.0.0",
"parameters": {
"mspName": {
"value": "Azure User Group Nepal"
},
"mspOfferDescription": {
"value": "AUGN Fully Managed Service"
},
"managedByTenantId": {
"value": "09fsdsdb677-425a-4d83-aa73-7455477bc7"
},
"authorizations": {
"value": [
{
"principalId": "5ae35555-7c67-4adb-876e-67657hf9ad4c6",
"principalIdDisplayName": "Tier 1 Support",
"roleDefinitionId": "acdd72a7-3385-48ef-bd42-f606fba81ae7"
},
{
"principalId": "f29f1555-af6d-4555-b32c-6803a943d7d3",
"principalIdDisplayName": "Tier 2 Support",
"roleDefinitionId": "b24988ac-6180-42a0-ab88-20f7382dd24c"
},
{
"principalId": "fe514555-cf72-4agd42-8e55-dbf93d775cdf",
"principalIdDisplayName": "Tier 3 Support",
"roleDefinitionId": "b24988ac-6180-42a0-ab88-20f7382dd24c"
}
]
}
}
}
We are ready with the service provider’s tenant, now we need to work on the customer’s tenant.
Deploying the Template in the Customer’s Tenant
The customer’s tenant must have registered with Microsoft.ManagedServices before onboarding. To register, log in to the Azure portal, Click on the subscription->Navigate to the Resource providers->Search for Microsoft.ManagedServices->Click on Register.
It will take a moment to get registered. After the registration, it should look as below.
The ARM template we created earlier needs to deploy at the subscription level in each customer tenant. Login into the customer’s tenant using PowerShell. The user must be a non-guest in the customer’s tenants. We have to repeat this step for each customer.
Login-AzAccount
Get-AzSubscription
$context = Get-AzSubscription -SubscriptionId xxxxxxx-axxx-xxx4-xxx-xxxxx
Set-AzContext $context
New-azdeployment -Name "AUGN" -Location westeurope -TemplateFile .\delegatedResourceManagement.json -TemplateParameterFile .\delegatedResourceManagement.parameters.json
On MSP Portal
Click All Services and search for My Customers, and click on it. In the new window click on My Customers.
We can see above the Customer (janakpur) is under the customer section and see below under the Delegations, we see the appropriate right has been assigned.
We can more dig down and see IAM, resource group, resources, etc. We can access the resources of janakpur (customer) without switching the directory.
On Customer Portal
Click All Services and search for Service Provider, and click on it. In the new window click on Service Provider.
Here, we can see, that Azure User Group Nepal is a service provider for janakpur. As a customer, we can see what the permission service provider has for the tenants as below.
If any new engineer joins the service provider team and once he/she will be in the right group, he/she will automatically get access to the customer’s tenants. We don’t need to invite them manually. And once he/she will leave the service provider and is removed from the group, automatically permission will withdraw and we don’t need to delete guest users from the customer’s tenant.