How to Onboard Customers in Azure Lighthouse

This blog post will show you how to onboard your customers’ Azure resources in Azure Lighthouse.

Azure Lighthouse is a new collection of technologies that allows Managed Service Providers (MSPs) and software developers (ISVs) to centrally manage their tenants and monetize hosted services. These providers are able to use the Azure Marketplace as a web portal to post public offerings that are available worldwide, similar to an app store. MSPs can list IT services they can offer to deploy, manage, optimize, secure or make compliant their customers’ cloud infrastructures and ISVs will include their Azure software with additional services. The providers can use Azure Delegated Resource Manager (ADRM) and Azure Active Directory (AAD) to centrally manage all of their tenants from a single interface. For more information, check all from a single interface. Check out the Altaro blog series about the Azure Lighthouse solutions, its foundational technologies using ADRM and AAD, Azure integration, and the go-to-market strategy.

There are three ways that a tenant can subscribe to a service from the MSP, which changes that way that the customer grants the MSP access to their environment.

The most common way is for a provider to publish a service to the Azure Marketplace, and this can be configured to be public or private. A public service is accessible to everyone, but there is not any way to restrict the subscribers by location, size nor any other factor. These customers who purchase a public service will automatically grant access to the MSP automatically during the onboarding process. It is important to realize that there are multiple ways that a tenant can subscribe to a service from the MSP. The most common way is for them to publish a service to the Azure Marketplace, and this can be configured to be public or private. A public service is accessible to everyone, but there is not any way to restrict users by location or size and they are onboarded automatically as described in how to publish a managed service on the Azure Marketplace.

• To make a service private and only accessible to certain predefined users (“private”), a specific list of tenant subscription IDs must be defined when the offering is created in the Azure Marketplace provided. Once the private customer has purchased an Azure Lighthouse service, the service provider must onboard their tenant which requires delegating resources through Azure Active Directory (AAD).
• Alternatively, the entire Azure Marketplace process can skipped and a MSP can onboard a tenant through the same series of steps which are described in this blog using the following steps:
  • Collect Details for the Tenant and their Subscription
  • Either
    • Create Azure AD User Groups and Define Permissions
    • Create Service Principals and Define Permissions
  • Create an Azure Resource Manager (ARM) Template
  • Deploy an Azure Resource Manager (ARM) Template
  • Confirm Successful Onboarding for Both Parties

For either scenario, make sure that you’ve associated the tenant’s subscription ID with your Microsoft Partner Network (MPN) ID so that you get credited for consumption. While this guide is written from the perspective of an MSP, these same best practices are also applicable to ISVs who are offering managed services to deploy their software.

Step 1) Collect Details for the Tenant and their Subscription

When you are onboarding a customer you have to know some of their unique identifier information so that you add the correct user and their subscription information. Make sure that have the following information:

• Your Tenant ID (as an MSP or ISV). This can be found in the Azure Portal by hovering over your account name in the upper-right corner in the Azure Portal.
• The Tenant ID of the customer. This can be found in the Azure Portal by asking the tenant to hover over their account name in the upper-right corner in the Azure Portal.
• The Subscription ID of the customer for the subscription of every resource that you will be managing. If you are managing multiple resources that are in different subscriptions then you will need each of these subscription IDs. This can be found by searching for the subscription(s) in Azure Active Directory. This will also create a new resource provider (Microsoft Managed Services) to be registered for the selected subscription(s).

Next, you need to set up the security framework using either Azure AD user groups, service principals or individual Azure user accounts (not recommended). Whenever you manage tenants’ accounts, especially if you have multiple tenants, you should never assign access to any individual user. This is because your staff may change over time, so as you need to add or remove certain administrators you can do this at the group level, instead of on each individual resource group. Not only does this provide centralized and simplified management at scale, but it also makes you look better to your tenants as they are not seeing your company’s turnover.

Steps for the user groups and service principals are described below. First, you must connect to the Azure subscription which is done using the following PowerShell cmdlet:

PS C:\> Select-AZSubscription <SubscriptionID>

Step 2) Create Azure AD User Groups and Define Permissions

Configuration for AAD user groups is fairly easy. It requires creating a new group for each role or task, then adding the appropriate administrators. You will then assign the type of administrative role that that group has from the 70+ Azure user roles. You should also use a friendly name to help you and your tenants understand what that resource group is used for.

Next, you will get the object ID and role definitions for each Azure AD group which can be determined through the following PowerShell queries:

PS C:\> (Get-AzADGroup -DisplayName ‘<GroupName>’).id

PS C:\> (Get-AzRoleDefinition -Name ‘<roleName>’).id

Instead of using AD User Groups for user account access you can create an Azure service principal for application access.

Or: Step 2b) Create Service Principals and Define Permissions

An Azure service principal is an alternatives type of identity which is used for tools, services, and applications to provide role-based access control (RBAC), rather than user accounts. It only supports a subset of the Azure roles to restrict a single application from having too much control. Also, you should pick the role which provides the minimum access that your staff needs. You want to ensure that you do not request more than is necessary, as potential clients could view this negatively and you may get the perception of not being trustworthy.

You will also need to know the object ID and role definitions for each Azure service principle which can be determined through the following PowerShell queries:

PS C:\> (Get-AzADApplication -DisplayName '<DisplayName>').objectId

PS C:\> (Get-AzRoleDefinition -Name '<RoleName>').id

Whenever you manage tenants’ accounts, especially if you have multiple tenants, Microsoft recommends:

“using Azure AD user groups for each role, allowing you to add or remove individual users to the group rather than assigning permissions directly to that user. You may also want to assign roles to a service principal. Be sure to follow the principle of least privilege so that users only have the permissions needed to complete their job, helping to reduce the chance of inadvertent errors.”

For more info, see Recommended security practices.

3) Create an Azure Resource Manager (ARM) Template

An ARM template lets administrators deploy an Azure-managed resource or resources group the exact same way every time. The template provides the framework to ensure consistency, which is critical so that you can automate and scale the management of this resource across multiple tenants. Your ARM template should include the following fields:

• MSPName: This is your service provider name
• MSPOfferDescription: This is a short description of your offer
• ManagedByTenantID: This is the ID of your tenant
• Authorizations: This describes the access needed, which can include:
  • RoleDefinitionID: This is the level of access needed for the resource template
  • PrincipalID: This the ID for either your Azure group or Azure service principal
  • PrincipalDisplayName: This is the display name which your tenants see for your Azure group or Azure service principal

Since ARM templates can be tricky to create for inexperienced service providers, Microsoft provides code samples for different scenarios. These include both the template file along with a parameter file which are found here: https://github.com/Azure/Azure-Lighthouse-samples/. Here are the links to onboard:

• Subscription (through the Azure Marketplace)
  • Template: MarketplaceDelegatedResourceManagement.json
  • Parameter file: MarketplaceDelegatedResourceManagement.parameters.json
• Subscription (without the Azure Marketplace)
  • Template: DelegatedResourceManagement.json
  • Parameter file: DelegatedResourceManagement.parameters.json
• Resource Group
  • Template: RGDelegatedResourceManagement.json
  • Parameter file:RGDelegatedResourceManagement.parameters.json
• Multiple Resource Groups in a Subscription
  • Template: MultipleRgDelegatedResourceManagement.json
  • Parameter file:MultipleRgDelegatedResourceManagement.parameters.json

4) Deploy an Azure Resource Manager (ARM) Template

The hardest step is usually the deployment of the ARM template within the customer’s environment because either the MSP needs to do it on the tenant’s behalf, or the tenant must grant the MSP the correct permissions. And since a Guest account cannot be used, it makes it tougher for a novice customer. Every subscription needs a separate deployment, however, if you have multiple resource groups within a single subscription you can do this in a single deployment.

Once the correct permissions are configured, the following PowerShell cmdlets can be used for a remote deployment:

PS C:\> New-AzDeployment -Name <DeploymentName> `

-TemplateUri <TemplateURI> `

-TemplateParameterUri <ParameterURI> `

-Location <AzureRegion> `

-Verbose

5) Confirm Successful Onboarding for Both Parties

Now that the ARM template has been deployed, it is important to test that it can be effectively managed by the MSP within the tenant’s environment. Both the MSP and the tenant should be able to see the connected subscription and ARM resources. After the template has been initially deployed, it could take a few minutes for this to appear while the portal refreshes.

The tenant can see the connected service(s) by navigating to the Service Providers Page, selecting Service Providers Offers and seeing the subscription(s) with the correct offer name.

As the MSP, you can see this by going to the My Customers page, clicking on Customers, and verifying that you can see the tenant’s subscription(s).

Using these steps, you will have successfully onboarded a tenant by knowing the security identifiers, creating the appropriate security groups, creating an ARM template, deploying the template and verifying that both parties can see it. Remember that when doing this at scale, that consistency is critical so that the same ongoing management processes and scripts can be replicated on identical templates. Keep in mind that with Azure Lighthouse, one of your greatest assets is the operational efficiency that you can achieve through consistent global management. So if you make a change to your template after deploying it for several tenants, be sure to update their versions so that every template in production is identical to avoid any challenges with version control. With the steps you have learned, you will be able to streamline deployment and management for all of your Azure Lighthouse tenants. If you experience any issues with these steps, let me know in the comments below and I’ll get back to you!