Azure Lighthouse - Control which managing tenants can be delegated to

The supporting features of Azure Lighthouse keep coming. Microsoft has recently released a new policy sample that allows you to control which tenants you can delegate access to. This sounds like a pretty simple thing but in reality it's a policy you probably want to implement for multiple reasons.

Use Cases

This policy has multiple use cases from both a customer and managed service provider (MSP) perspective.

From a customer perspective
Let's assume there are at least more than 1-2 employees with owner level permissions on your subscription. With that level of permission comes great responsibility. And.. the ability to configure delegations.

A delegation doesn't necessarily happen by accident. Configuring a delegation either requires an ARM Template which means you need to configure the template and deploy it. Or, you can onboard using a market place offering. This requires you to simply click on the offering and onboard your subscription. Still not likely that this happens by accident but mistakes can happen. Indeed.. It is far more likely that someone does this knowingly but still, you want to have the guard rails in place to prevent this from happening as this will prevent another party receiving access to your environment.

From a MSP perspective
If you're a MSP (and probably a CSP) managing your customers through Azure Lighthouse this policy is definitely one to configure. Again, for multiple reasons.

First of all, a customer has trusted you to take certain responsibilities. You onboard them onto your managed services practice, provide an SLA and you're good to go. What if an additional party is provided access to the very same resources you are managing? That might impact your ability to take responsibility of that environment and thus impact your SLA. Usually you would also have a clause in your SLA where you and the customer agree this wouldn't happen but maybe it's better to prevent this from happening in the first place. And if it still happens, someone knowingly disabled a policy and there's an audit trail and accountability.

Additionally, when another managing party is granted enough access to the environment you are managing this might impact your Partner Earned Credits which means that this will actually have a financial impact for you.

Long story short, very small piece of technology but it can make a worlds difference.

The Policy

Microsoft has shared a custom policy (link) that allows you to control which Tenant ids can be delegated to. This is done by checking the field "managedByTenantId" (Microsoft.ManagedServices/registrationDefinitions/managedByTenantId) and match it with the provided parameters which can be one or multiple tenant ids. In this example we're going to allow just a single tenant. This policy supports the "Deny" effect which means that once the deployment starts, any configurations that are not compliant (read: the tenant id isn't allowed) should be stopped upon hitting the Azure APIs.

After downloading the templates here, all you really need to do is change the parameter file and add the tenant(s) you wish to allow for delegation.

{
    "$schema": "https://schema.management.azure.com/schemas/2018-05-01/subscriptionDeploymentParameters.json#",
    "contentVersion": "1.0.0.0",
    "parameters": {
        "listOfAllowedTenants": {
            "value": ["TENANTID1","TENANTID2"]
        }             
    }
}

After doing so you can deploy template as you would normally deploy an ARM Template. If you're unfamiliar with deploying ARM templates please check the Microsoft Docs page on ARM Templates. In my example this would look like so:

New-AzDeployment `
 -location westeurope `
 -TemplateFile .\policyAllowCertainTenantIds.json `
 -TemplateParameterFile .\policyAllowCertainTenantIds.parameters.json `

After a couple of seconds the deployment succeeds and the policy is showing in the Azure Policy blade. Don't worry if your policy states "Not Started". As we're configuring a "Deny" effect here, it works instantly after deploying the policy.

Now let's try to configure a delegation (once again using ARM Templates) with a "managedByTenantId" that we didn't allow in the first place. If you're unfamiliar with the Azure Lighthouse ARM Templates please check this GitHub repository and enjoy the samples provided :)

Back to business. The parameter for our deployment:

The deployment:

New-AzDeployment `
 -location westeurope `
 -TemplateFile .\delegatedResourceManagement.json `
 -TemplateParameterFile .\delegatedResourceManagement.parameters.json `
 -verbose

It works! The deployment comes to a screeching halt.

Just to see if this really works. Let's run it again with a Tenant ID that we did allow.

Looks like it's a win!

To summarize: a very straight forward policy with a great use case. If you're using Azure Lighthouse it's probably a good idea to add this to your standard deployments!