WTH is Azure Lighthouse?

This week we continue our series looking at new services that have been announced recently, where the marketing material doesn’t do a great job of explaining what this new service is. This week we’re taking a look at Azure Lighthouse, which adds a reasonably cryptic name to the mix.

What is Azure Lighthouse?

Azure Lighthouse is new functionality that is primarily aimed at service providers. It provides the ability to project resources that sit under one Azure AD tenant into another tenant. What this means is that Azure customers can deploy resources in their subscription and tenant, but have them managed by users in another tenant, without the need to add these users as guests. There are several scenarios where this could be useful.

• Service Providers - where the client is paying the bill and wants control of the resources, but is paying a third party to manage and support them
• Application Providers - companies that are providing applications in Azure that come with a management part, can now package them on the marketplace and allow customers to deploy them in their subscription, but retain management of some or all resources
• Multi-Tenant - many Azure customers have multiple tenants across their organisation for various reasons. Azure Lighthouse would allow managing resources in all these tenants from one place without needing to switch tenants

If you don’t have multiple tenants, work with 3rd parties, or provide Azure-based applications, then Lighthouse might not be of interest to you. If you do any of these, this does have the potential to make your life easier.

How does Azure Lighthouse work?

To use Lighthouse to delegate resource management to users in another tenant, you need to onboard the subscription into Lighthouse. All of this work is done on the subscription you want to be managed. Onboarding can be done one of two ways:

1. Deploying an ARM template into this subscription to be managed
2. Implementing a Marketplace managed application which is configured to enabled delegated management

There is currently not a UI or CLI based way to do this; it is template only.

When you onboard a subscription you first need to know what the scope of the management is going to be. The delegated administration can be scoped to a whole subscription, a resource group or multiple resources groups in a single subscription. You cannot scope it to specific resources in a resource group. This choice is implemented by selecting the appropriate ARM template for the scope you require.

Once the scope is confirmed you then need to pass parameters to the ARM template that define the name of the service provider, the tenant ID that will be managing these resources, and most importantly the authorizations required by the service provider tenant. These authorizations consist of a list of Azure AD users or group ID’s from the service provider tenant, along with the ID of the built-in role required for these users/groups. The recommendation is to use Azure AD groups to avoid needing to update and re-deploy the template each time a new user needs access. An example parameters file can be seen below:

{
    "$schema": "https://schema.management.azure.com/schemas/2018-05-01/subscriptionDeploymentParameters.json#",

    "contentVersion": "1.0.0.0",

    "parameters": {
        "mspName": {
            "value": "Fabrikam Managed Services - Interstellar"
        },
       "mspOfferDescription": {
           "value": "Fabrikam Managed Services - Interstellar"
       },
       "managedByTenantId": {
           "value": "df4602a3-920c-435f-98c4-49ff031b9ef6"
       },
       "authorizations": {
           "value": [
               {
                   "principalId": "0019bcfb-6d35-48c1-a491-a701cf73b419",
                   "principalIdDisplayName": "Tier 1 Support",
                   "roleDefinitionId": "b24988ac-6180-42a0-ab88-20f7382dd24c"
               },
               {
                   "principalId": "0afd8497-7bff-4873-a7ff-b19a6b7b332c",
                   "principalIdDisplayName": "Tier 2 Support",
                   "roleDefinitionId": "acdd72a7-3385-48ef-bd42-f606fba81ae7"
               },
               {
                   "principalId": "9fe47fff-5655-4779-b726-2cf02b07c7c7",
                   "principalIdDisplayName": "Service Automation Account",
                   "roleDefinitionId": "b24988ac-6180-42a0-ab88-20f7382dd24c"
               },
               {
                   "principalId": "3kl47fff-5655-4779-b726-2cf02b05c7c4",
                   "principalIdDisplayName": "Policy Automation Account",
                   "roleDefinitionId": "18d7d88d-d35e-4fb5-a5c3-7773c20a72d9",
                   "delegatedRoleDefinitionIds": [
                       "b24988ac-6180-42a0-ab88-20f7382dd24c",
                       "92aaf0da-9dab-42b6-94a3-d43ce8d16293"
                   ]
               }
           ]
       }
   }
}

In this example we’re granting the Tier 1 Support group contributor rights, the Tier 2 support group reader rights, and a service principal with the contributor role. The last item is a service principal which is granted the “User Access Administrator” role. The “delegatedRoleDefinitionIds” list provides a list of roles that can be assigned by this service principal.

This ARM template needs to be deployed in the client’s subscription by a user who has the owner role in the subscription where rights are being delegated. The deployment needs to be a subscription level deployment, so using the new-azdeployment or az deploy commands.

Once the deployment completes, you can confirm it is set up by navigating to the “service providers” service in the client subscription.

Under the “Service Provider Offers” section, you will see the service providers that have been granted delegated access.

Selecting a provider will then allow you to see what rights have been delegated.

In the service providers portal, you can go to the “My Customers” service.

In the customers section, you will see a list of all customers that have delegated access to you.

Now this is all set up, as the service provider you can go to the “Directory and Subscription” selector, and you will now see an option to select the customer’s directory in the subscription filter. Once you do this, you will see the clients subscriptions as if they were you’re own.

You can select this subscription and then undertake administrative tasks as usual. You can also use the standard commands in the CLI to work with this subscription.

Why would I want to use Azure Lighthouse?

As we’ve already discussed, this service is primarily aimed at service providers who need to work with the Azure resources of their customers.

As a service provider, if you need to work with customers resources, then this removes the pain of having to get your account added as a guest user in their AAD (which many clients are adverse to). It also allows you to manage all your customers from a single portal view, without needing to switch between tenants.

As a customer, it provides a single point for me to view what access service providers have to my subscription and to amend or revoke this if needed. I no longer need to work with guest users from other tenants.

While the service is aimed at service providers, I see this also being useful to Azure customers who have multiple Azure AD tenants. This scenario is not uncommon, especially in large companies that create different tenants and subscriptions for various lines of business or departments. Using Lighthouse the central IT function can still manage all the Azure resources from a single view, but still provide the business teams with visibility of who has access and what they can do.

Finally, we haven’t touched much on it here, but if you are providing applications via the marketplace and need to retain some management and support responsibility, then this is a great way to do this transparently.

What issues does Azure Lighthouse have?

As with all services, Lighthouse is not perfect and has some issues to be aware of.

The first one, and my biggest concern is the amount of control the client has over how the provider accesses their subscriptions. As we saw, the client is in control of granting access and to what rights and roles this access is given. However, there are some things that they do not have control over.

• Group membership - The recommended approach is to grant delegated access to Azure AD groups, which makes sense. However, the client has no visibility of these groups and no control or oversight of which users are being added to these roles. If there is a concern over the service provider adding inappropriate users, or more users than there should be, then there is not a way to address this
• Access control - the client may be using services like Multifactor Authentication, Conditional Access, Privileged Identity Management, to control and secure access to their subscription. None of these settings on the client tenant applies to the service provider. These things are all set at the service providers tenant. There is no visibility for clients as to whether these are enabled or not. This is an easy way to compromise the security of your subscription.

Another limitation that may affect you is the fact that users/groups can only be assigned to the built-in roles; you cannot use custom roles. If a built-in role does not fit your needs, you may find yourself having to grant more rights than you wanted to.

Finally, not all service support delegated access, this includes some of the most common ones such as storage, web apps and Azure SQL. As time goes on, I would imagine that more services will be added. The full list of supported services can be found https://docs.microsoft.com/en-gb/azure/lighthouse/concepts/cross-tenant-management-experience#supported-services-and-scenarios

Further Reading

If you interested in testing our Azure Lighthouse you can find tutorials here:

• Onboard a customer to Azure delegated resource management
• Publish a managed services offer to Azure Marketplace

Image Credits

Lighthouse flickr photo by jchapiewsky shared under a Creative Commons (BY-SA) license