You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Copy file name to clipboardExpand all lines: articles/lighthouse/how-to/deploy-policy-remediation.md
+5-5Lines changed: 5 additions & 5 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -1,6 +1,6 @@
1
1
---
2
2
title: Deploy a policy that can be remediated within a delegated subscription
3
-
description: To deploy policies that use a remediation task via Azure Lighthouse, you'll need to create a managed identity in the customer tenant.
3
+
description: To deploy policies that use a remediation task via Azure Lighthouse, you need to create a managed identity in the customer tenant.
4
4
ms.date: 07/16/2024
5
5
ms.topic: how-to
6
6
---
@@ -16,14 +16,14 @@ ms.topic: how-to
16
16
17
17
When you [onboard a customer to Azure Lighthouse](onboard-customer.md), you define authorizations that grant access to delegated resources in the customer tenant. Each authorization specifies a **principalId** that corresponds to a Microsoft Entra user, group, or service principal in the managing tenant, and a **roleDefinitionId** that corresponds to the [Azure built-in role](../../role-based-access-control/built-in-roles.md) that will be granted.
18
18
19
-
To allow a **principalId** to assign roles to a managed identity in the customer tenant, you must set its **roleDefinitionId** to **User Access Administrator**. While this role is not generally supported for Azure Lighthouse, it can be used in this specific scenario. Granting this role to this **principalId** allows it to assign specific built-in roles to managed identities. These roles are defined in the **delegatedRoleDefinitionIds** property, and can include any [supported Azure built-in role](../concepts/tenants-users-roles.md#role-support-for-azure-lighthouse) except for User Access Administrator or Owner.
19
+
To allow a **principalId** to assign roles to a managed identity in the customer tenant, you must set its **roleDefinitionId** to **User Access Administrator**. While this role isn't generally supported for Azure Lighthouse, it can be used in this specific scenario. Granting this role to this **principalId** allows it to assign specific built-in roles to managed identities. These roles are defined in the **delegatedRoleDefinitionIds** property, and can include any [supported Azure built-in role](../concepts/tenants-users-roles.md#role-support-for-azure-lighthouse) except for User Access Administrator or Owner.
20
20
21
-
After the customer is onboarded, the **principalId** created in this authorization will be able to assign these built-in roles to managed identities in the customer tenant. It will not have any other permissions normally associated with the User Access Administrator role.
21
+
After the customer is onboarded, the **principalId** created in this authorization will be able to assign these built-in roles to managed identities in the customer tenant. It won't any other permissions normally associated with the User Access Administrator role.
22
22
23
23
> [!NOTE]
24
24
> [Role assignments](../../role-based-access-control/role-assignments-steps.md#step-5-assign-role) across tenants must currently be done through APIs, not in the Azure portal.
25
25
26
-
The example below shows a **principalId**who will have the User Access Administrator role. This user will be able to assign two built-in roles to managed identities in the customer tenant: Contributor and Log Analytics Contributor.
26
+
This example shows a **principalId**with the User Access Administrator role. This user will be able to assign two built-in roles to managed identities in the customer tenant: Contributor and Log Analytics Contributor.
27
27
28
28
```json
29
29
{
@@ -39,7 +39,7 @@ The example below shows a **principalId** who will have the User Access Administ
39
39
40
40
## Deploy policies that can be remediated
41
41
42
-
Once you have created the user with the necessary permissions as described above, that user can deploy policies that use remediation tasks within delegated customer subscriptions.
42
+
After you create the user with the necessary permissions, that user can deploy policies that use remediation tasks within delegated customer subscriptions.
43
43
44
44
For example, let's say you wanted to enable diagnostics on Azure Key Vault resources in the customer tenant, as illustrated in this [sample](https://github.com/Azure/Azure-Lighthouse-samples/tree/master/templates/policy-enforce-keyvault-monitoring). A user in the managing tenant with the appropriate permissions (as described above) would deploy an [Azure Resource Manager template](https://github.com/Azure/Azure-Lighthouse-samples/blob/master/templates/policy-enforce-keyvault-monitoring/enforceAzureMonitoredKeyVault.json) to enable this scenario.
Copy file name to clipboardExpand all lines: articles/lighthouse/how-to/migration-at-scale.md
+10-10Lines changed: 10 additions & 10 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -18,22 +18,22 @@ Azure Lighthouse integration with Azure Migrate lets service providers discover,
18
18
> [!TIP]
19
19
> Though we refer to service providers and customers in this topic, this guidance also applies to [enterprises using Azure Lighthouse to manage multiple tenants](../concepts/enterprise.md).
20
20
21
-
Depending on your scenario, you can to create the Azure Migrate project in the customer tenant or in your managing tenant. Review the considerations below and determine which model best fits your customers' migration needs.
21
+
Depending on your scenario, you can create the Azure Migrate project in the customer tenant or in your managing tenant. This article describes each model so you can determine which one best fits your customers' migration needs.
22
22
23
23
> [!NOTE]
24
24
> With Azure Lighthouse, partners can perform discovery, assessment and migration for on-premises VMware VMs, Hyper-V VMs, physical servers and AWS/GCP instances. For [VMware VM migration](../../migrate/server-migrate-overview.md), only the [agent-based migration method](../../migrate/tutorial-migrate-vmware-agent.md) can be used for a migration project in a delegated customer subscription. Migration using agentless replication is not currently supported through delegated access to the customer's scope.
25
25
26
26
## Create an Azure Migrate project in the customer tenant
27
27
28
-
One option when using Azure Lighthouse is to create the Azure Migrate project in the customer tenant. Users in the managing tenant can then select the customer subscription when creating a migration project. From the managing tenant, the service provider can perform the necessary migration operations. Examples of thes operations are deploying the Azure Migrate appliance to discover the workloads, assessing workloads by grouping VMs and calculating cloud-related costs, reviewing VM readiness, and performing the actual migration.
28
+
One option when using Azure Lighthouse is to create the Azure Migrate project in the customer tenant. Users in the managing tenant can then select the customer subscription when creating a migration project. From the managing tenant, the service provider can perform the necessary migration operations. Examples of these operations are deploying the Azure Migrate appliance to discover the workloads, assessing workloads by grouping VMs and calculating cloud-related costs, reviewing VM readiness, and performing the actual migration.
29
29
30
-
In this scenario, no resources will be created and stored in the managing tenant, even though the discovery and assessment steps are initiated and executed from that tenant. All of the resources, such as migration projects, assessment reports for on-premises workloads, and migrated resources at the target destination, will be deployed in the delegated customer subscription. The service provider can access all customer projects from their own tenant and portal experience.
30
+
In this scenario, no resources are created or stored in the managing tenant, even though the discovery and assessment steps are initiated and executed from that tenant. All of the resources, such as migration projects, assessment reports for on-premises workloads, and migrated resources at the target destination, are deployed in the delegated customer subscription. The service provider can access all customer projects from their own tenant and portal experience.
31
31
32
32
This approach minimizes context switching for service providers working across multiple customers, and lets customers keep all of their resources in their own tenants.
33
33
34
34
A high-level workflow for this model is:
35
35
36
-
1. The customer is [onboarded to Azure Lighthouse](onboard-customer.md). The Contributor built-in role is required for the identity that will be used with Azure Migrate. See the [delegated-resource-management-azmigrate](https://github.com/Azure/Azure-Lighthouse-samples/tree/master/templates/delegated-resource-management-azmigrate) sample template for an example using this role. Be sure to modify the parameter file to reflect your environment before deploying the template.
36
+
1. The customer is [onboarded to Azure Lighthouse](onboard-customer.md). The Contributor built-in role is required for the identity that will be used with Azure Migrate. See the [delegated-resource-management-azmigrate](https://github.com/Azure/Azure-Lighthouse-samples/tree/master/templates/delegated-resource-management-azmigrate) sample template for an example using this role. Before deploying the template, be sure to modify the parameter file to reflect your environment.
37
37
1. The designated user signs into the managing tenant in the Azure portal, then goes to Azure Migrate. This user [creates an Azure Migrate project](../../migrate/create-manage-projects.md), selecting the appropriate delegated customer subscription.
38
38
1. The user then [performs steps for discovery and assessment](../../migrate/tutorial-discover-vmware.md).
39
39
@@ -51,23 +51,23 @@ A high-level workflow for this model is:
51
51
52
52
## Create an Azure Migrate project in the managing tenant
53
53
54
-
In this scenario, the migration project and all of the relevant resources reside in the managing tenant. Customers won't have direct access to the migration project, although assessments can be shared with customers if desired. As with the previous scenario, migration-related operations such as discovery and assessment are performed by users in the managing tenant, and the migration destination for each customer is the target subscription in their tenant.
54
+
In this scenario, the migration project and all of the relevant resources reside in the managing tenant. Customers don't have direct access to the migration project, although assessments can be shared with customers if desired. As with the previous scenario, migration-related operations such as discovery and assessment are performed by users in the managing tenant, and the migration destination for each customer is the target subscription in their tenant.
55
55
56
56
This approach enables service providers to begin migration discovery and assessment projects quickly, abstracting those initial steps from customer subscriptions and tenants.
57
57
58
58
A high-level workflow for this model is:
59
59
60
-
1. The customer is [onboarded to Azure Lighthouse](onboard-customer.md). The Contributor built-in role is required for the identity that will be used with Azure Migrate. See the [delegated-resource-management-azmigrate](https://github.com/Azure/Azure-Lighthouse-samples/tree/master/templates/delegated-resource-management-azmigrate) sample template for an example using this role. Be sure to modify the parameter file to reflect your environment before deploying the template.
60
+
1. The customer is [onboarded to Azure Lighthouse](onboard-customer.md). The Contributor built-in role is required for the identity that will be used with Azure Migrate. See the [delegated-resource-management-azmigrate](https://github.com/Azure/Azure-Lighthouse-samples/tree/master/templates/delegated-resource-management-azmigrate) sample template for an example using this role. Before deploying the template, be sure to modify the parameter file to reflect your environment.
61
61
1. The designated user signs into the managing tenant in the Azure portal, then goes to Azure Migrate. This user [creates an Azure Migrate project](../../migrate/create-manage-projects.md) in a subscription belonging to the managing tenant.
62
-
1. The user then [performs steps for discovery and assessment](../../migrate/tutorial-discover-vmware.md). The on-premises VMs will be discovered and assessed within the migration project created in the managing tenant, then migrated from there.
62
+
1. The user then [performs steps for discovery and assessment](../../migrate/tutorial-discover-vmware.md). The on-premises VMs are discovered and assessed within the migration project created in the managing tenant, then migrated from there.
63
63
64
-
If you are managing multiple customers in the same Hyper-V host, you can discover all workloads at once. You can select customer-specific VMs in the same group, and then create an assessment. Migration is performed by selecting the appropriate customer's subscription as the target destination. There's no need to limit the discovery scope, and you can maintain a full overview of all customer workloads in one migration project.
64
+
If you manage multiple customers in the same Hyper-V host, you can discover all workloads at once. You can select customer-specific VMs in the same group, and then create an assessment. Migration is performed by selecting the appropriate customer's subscription as the target destination. There's no need to limit the discovery scope, and you can maintain a full overview of all customer workloads in one migration project.
65
65
66
-
1. When ready, proceed with the migration by selecting the delegated customer subscription as the target destination for replicating and migrating the workloads. The newly created resources will exist in the customer subscription, while the assessment data and resources pertaining to the migration project remain in the managing tenant.
66
+
1. When ready, proceed with the migration by selecting the delegated customer subscription as the target destination for replicating and migrating the workloads. The new resources are created in the customer subscription, while assessment data and resources pertaining to the migration project remain in the managing tenant.
67
67
68
68
## Partner recognition for customer migrations
69
69
70
-
As a member of the [Microsoft Cloud Partner Program](https://partner.microsoft.com), you can link your partner ID with the credentials used to manage delegated customer resources. This allows Microsoft to attribute influence and Azure consumed revenue to your organization based on the tasks you perform for customers, including migration projects.
70
+
As a member of the [Microsoft Cloud Partner Program](https://partner.microsoft.com), you can link your partner ID with the credentials used to manage delegated customer resources. This link allows Microsoft to attribute influence and Azure consumed revenue to your organization based on the tasks you perform for customers, including migration projects.
71
71
72
72
For more information, see [Link a partner ID](../../cost-management-billing/manage/link-partner-id.md).
Copy file name to clipboardExpand all lines: articles/lighthouse/how-to/policy-at-scale.md
+1-1Lines changed: 1 addition & 1 deletion
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -31,7 +31,7 @@ Search-AzGraph -Query "Resources | where type =~ 'Microsoft.Storage/storageAccou
31
31
32
32
## Deploy a policy across multiple customer tenants
33
33
34
-
The following example shows how to use an [Azure Resource Manager template](https://github.com/Azure/Azure-Lighthouse-samples/blob/master/templates/policy-enforce-https-storage/enforceHttpsStorage.json) to deploy a policy definition and policy assignment across delegated subscriptions in multiple customer tenants. This policy definition requires all storage accounts to use HTTPS traffic. It prevents the creation of any new storage accounts that don't comply. Any existing storage accounts without the setting are marked as non-compliant.
34
+
The following example shows how to use an [Azure Resource Manager template](https://github.com/Azure/Azure-Lighthouse-samples/blob/master/templates/policy-enforce-https-storage/enforceHttpsStorage.json) to deploy a policy definition and policy assignment across delegated subscriptions in multiple customer tenants. This policy definition requires all storage accounts to use HTTPS traffic. It prevents the creation of any new storage accounts that don't comply. Any existing storage accounts without the setting are marked as noncompliant.
35
35
36
36
```powershell
37
37
Write-Output "In total, there are $($ManagedSubscriptions.Count) delegated customer subscriptions to be managed"
0 commit comments