Managing multiple Azure customers – but how?

As a service provider that works with a variety of customers, you need a way to manage multiple environments in an easy and efficient way. Azure offers different approaches for this that I want to cover in this blog post.

The following diagram shows the methods partners can use to manage their customers.

 

Management Methods

 

Dedicated Account

This is the easiest method for customers to give partners access. They create dedicated accounts in their own Azure AD and assign the needed permissions in Azure AD and on the appropriate Azure resources.

Pros:

  • Simple to setup
  • Customer is in control of everything

Cons:

  • Partner employee might have multiple accounts in different customer environments
  • Customer is responsible of the account and maybe does not know that an employee left the partner company – the account stays active
  • Partners that want to automate processes or configurations in multiple customer environments need multiple accounts
  • Depending on the enabled features, the dedicated account might need an Azure AD license that the customer needs to assign

 

B2B Guest Account

In this scenario, customers invite partner accounts into their environment. This can easily be done in Azure AD by using the “New guest user” task. The only thing you need to invite someone is his/her user principal name (UPN). The invited user will get an email with the invitation details and can now connect to the customer environment. Guest accounts can easily be identified by the user type “Guest”.

Invite Guest User

After successfully logging in th the Azure portal with a user account that has been invited to other environments, you can now jump back and forth between the different environments a.k.a. directories. Just use the directory selector in the Azure portal, then select the directory you want to work in.

Switch Directory

 

4

IMPORTANT: If you are using Azure Powershell or the Azure CLI (or any other automation features that use your account), then keep in mind to always select the correct tenant/directory – otherwise you might start firing scripts or do interactive configuration against the wrong directory!

  • Azure Powershell:  login-azaccount -tenant marcelzehner.ch (tenant name)
  • Azure CLI: az login –tenant marcelzehner.ch (tenant name)

Pros:

  • Less accounts for partner employees as they can re-use the same admin account to access multiple customer environments
  • Access to customer environment is automatically terminated if account is disabled in partner environment (e.g. when an employee leaves the company)

Cons:

  • The same account has access to multiple environments and needs additional protection (technical and organizational)
  • Depending on the enabled features, the guest account might need an Azure AD license that the customer needs to assign. For guest users, the license conversion rate is 1:5. Means, the customer needs to purchase 1 full license and can then use it for 5 guest accounts.

 

Azure Lighthouse

Azure Lighthouse was introduced in Q3 2019 as a new management method for partners to work with multiple customers. Using Azure Lighthouse, customers can delegate specific roles on subscriptions or resource groups so that the partner can easily access and manage these resources. Depending on the delegated permissions, the partner can also deploy new services directly to the customer environment, either from the Azure marketplace or by using imperative or declarative automation procedures.

The delegation is done using an Azure ARM template or an equivalent marketplace offering that needs to be prepared by the partner and must be executed in the customer environment (by the customer). Beside some generic information, the ARM template contains one or multiple security principals that needs to be prepared in the partner environment. Normally these are security groups in Azure AD. These security principals are then assigned resource-specific roles which live in the customer environment, e.g. contributor or reader roles.

The following ARM template example will delegate contributor and reader permissions to two pre-created groups in the partner AAD. The GUIDs of these groups as well as the GUID for the partner tenant are available from the partner AAD. The role definition GUIDs are from the customer’s environment. The GUIDs in this example are from built-in roles.

{
    “contentVersion”: “1.0.0.0”,
    “parameters”: {
        “mspName”: {
            “type”: “string”,
            “defaultValue”: “make it noble”
        },
        “mspOfferDescription”: {
            “type”: “string”,
            “defaultValue”: “Remote Access”
        },
        “managedByTenantId”: {
            “type”: “string”,
            “defaultValue”: “00000000-0000-0000-0000-000000000000
        },
        “authorizations”: {
            “type”: “array”,
            “defaultValue”: [
                {
                    “principalId”: “11111111-1111-1111-1111-111111111111“,
                    “principalIdDisplayName”: “sec-min-contributors”,
                    “roleDefinitionId”: “b24988ac-6180-42a0-ab88-20f7382dd24c
                },
                {
                    “principalId”: “22222222-2222-2222-2222-222222222222“,
                    “principalIdDisplayName”: “sec-min-readers”,
                    “roleDefinitionId”: “acdd72a7-3385-48ef-bd42-f606fba81ae7
                }
            ]
        }
    },
    “variables”: {
        “mspRegistrationName”: “[guid(parameters(‘mspName’))]”,
        “mspAssignmentName”: “[guid(parameters(‘mspName’))]”
    },
    “resources”: [
        {
            “type”: “Microsoft.ManagedServices/registrationDefinitions”,
            “apiVersion”: “2019-06-01”,
            “name”: “[variables(‘mspRegistrationName’)]”,
            “properties”: {
                “registrationDefinitionName”: “[parameters(‘mspName’)]”,
                “description”: “[parameters(‘mspOfferDescription’)]”,
                “managedByTenantId”: “[parameters(‘managedByTenantId’)]”,
                “authorizations”: “[parameters(‘authorizations’)]”
            }
        },
        {
            “type”: “Microsoft.ManagedServices/registrationAssignments”,
            “apiVersion”: “2019-06-01”,
            “name”: “[variables(‘mspAssignmentName’)]”,
            “dependsOn”: [
                “[resourceId(‘Microsoft.ManagedServices/registrationDefinitions/’, variables(‘mspRegistrationName’))]”
            ],
            “properties”: {
                “registrationDefinitionId”: “[resourceId(‘Microsoft.ManagedServices/registrationDefinitions/’, variables(‘mspRegistrationName’))]”
            }
        }
    ],
    “outputs”: {
        “mspName”: {
            “type”: “string”,
            “value”: “[concat(‘Managed by’, ‘ ‘, parameters(‘mspName’))]”
        },
        “authorizations”: {
            “type”: “array”,
            “value”: “[parameters(‘authorizations’)]”
        }
    }
}

This ARM template is deployed using a subscription level deploylemt to one or multiple subscriptions in the customer environment. The following example shows the deployment using the Azure CLI, but you can use any deployment procedure you like.

az deployment create –location “West Europe” –template-file .\lighthouse.json

Once executed, both involved parties – partner and customer – will see the delegation on their side. The customer can see (and terminate) his active delegations in the “Service Providers” area.

Lighthouse 1

Lighthouse 2

The partner can see all delegations he can use in the “My Customers” area.

Lighthouse 3

Once the Azure Lighthouse-based delegation is configured, partners can easily access the appropriate customer environments. After you login as a partner employee with delegated permissions through Azure Lighthouse, you can see and manage customer resources combined with your own resources (resource projection). Using the global subscription filter you can select what customers and what subscriptions you want to see/hide. After this is configured, you will see an consolidated view of all appropriate resources and can start managing them.

Select Subscriptions

Pros:

  • Less accounts for partner employees as they can re-use the same admin account to access multiple customer environments
  • Simple resource administration in multiple customer environments
  • Access to customer environment is automatically terminated if account is disabled in partner environment (e.g. when an employee leaves the company)
  • Partner is on control of group membership changes (can also be a con) and can add/remove permissions to manage a customer environment any time
  • Depending on the enabled features, the partner accounts need an Azure AD license in the partner environment. For the customer environment, no licenses are needed.

Cons:

  • The same account has access to multiple environments and needs additional protection (technical and organizational)
  • Partner is on control of group membership changes (can also be a pro) and can give additional users access to the customer environment
  • Delegation only works for specific services, not for everything (e.g. Azure AD)

 

Combination and recap

If needed, you can easily combine the mentioned methods. As a partner you need to find out what your prefered method is for the way you work with customers. As a customer you need to decide, how much control you are willing to handover to a partner and what exactly you want to keep in your own hands.

 

Have fun!
Marcel

 

Updates

  • Update 1, 01.10.2019: Thanks to Stefan Beckmann for the inputs about the Azure AD licenses

 

About Marcel Zehner

Microsoft Azure MVP
This entry was posted in Azure and tagged , , , , , , , , , , , , , . Bookmark the permalink.