Tenants, roles, and users in Azure Lighthouse scenarios
Before onboarding customers for Azure Lighthouse, it's important to understand how Azure Active Directory (Azure AD) tenants, users, and roles work, as well as how they can be used in Azure Lighthouse scenarios.
A tenant is a dedicated and trusted instance of Azure AD. Typically, each tenant represents a single organization. Azure delegated resource management enables logical projection of resources from one tenant to another tenant. This allows users in the managing tenant (such as one belonging to a service provider) to access delegated resources in a customer's tenant, or lets enterprises with multiple tenants centralize their management operations.
In order to achieve this logical projection, a subscription (or one or more resource groups within a subscription) in the customer tenant must be onboarded to Azure Lighthouse. This onboarding process can be done either through Azure Resource Manager templates or by publishing a public or private offer to Azure Marketplace.
Whichever onboarding method you choose, you will need to define authorizations. Each authorization specifies a user account in the managing tenant which will have access to the delegated resources, and a built-in role that sets the permissions that each of these users will have for these resources.
Role support for Azure Lighthouse
When defining an authorization, each user account must be assigned one of the role-based access control (RBAC) built-in roles. Custom roles and classic subscription administrator roles are not supported.
All built-in roles are currently supported with Azure Lighthouse, with the following exceptions:
- The Owner role is not supported.
- Any built-in roles with DataActions permission are not supported.
- The User Access Administrator built-in role is supported, but only for the limited purpose of assigning roles to a managed identity in the customer tenant. No other permissions typically granted by this role will apply. If you define a user with this role, you must also specify the built-in role(s) that this user can assign to managed identities.
Once a new applicable built-in role is added to Azure, it can be assigned when onboarding a customer using Azure Resource Manager templates. There may be a delay before the newly-added role becomes available in Partner Center when publishing a managed service offer.
Best practices for defining users and roles
When creating your authorizations, we recommend the following best practices:
- In most cases, you'll want to assign permissions to an Azure AD user group or service principal, rather than to a series of individual user accounts. This lets you add or remove access for individual users without having to update and republish the plan when your access requirements change.
- 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 information, see Recommended security practices.
- Include a user with the Managed Services Registration Assignment Delete Role so that you can remove access to the delegation later if needed. If this role is not assigned, delegated resources can only be removed by a user in the customer's tenant.
- Be sure that any user who needs to view the My customers page in the Azure portal has the Reader role (or another built-in role which includes Reader access).
In order to add permissions for an Azure AD group, the Group type must be Security and not Office 365. This option is selected when the group is created. For more information, see Create a basic group and add members using Azure Active Directory.
- Learn about recommended security practices for Azure Lighthouse.
- Onboard your customers to Azure Lighthouse, either by using Azure Resource Manager templates or by publishing a private or public managed services offer to Azure Marketplace.