Is your feature request related to a problem? Please describe.

As requested from #951 and #951 (comment)

Context

As an MS(S)P, we want to serve our customers with a lot of policy content using built-in and custom policy definitions. So, we'd like to utilize EPAC and our Lighthouse delegated SPN access to manage the lifecycle of our policy content across all our customers' subscriptions (hundreds/thousands of subscriptions). This means exclusively to Lighthoused subscriptions, no internal Azure resources or subscriptions will be defined in our PacEnvironments.

At this moment we can assign audit policies without any problem using a PacSelector for audit purposes, however when we use policy's with an effect that can be remediated (addToNetworkGroup, append, deployIfNotExists, modify, mutate), all deployments fail.

Mechanism

Lighthouse allows for role assignments on the lighthoused subscription, only to managed identities (this is defined in Azure ABAC). Role assignments also only works using the ARM REST API, which Set-AzRoleAssignmentRestMethod uses. Since Lighthouse only supports delegations via the REST API, just to managed identities, delegatedManagedIdentityResourceId is a required field in the body of a role assignment, and the assignment and it's managed identity must exist before attempting the role assignment.

We tried several setups in our global-settings.jsonc, swapping the managingTenant it's managingTenantId value with the tenantId in the PacEnvironments (based on the comment (#740 (comment))), but also based on our interpretation of the EPAC Docs on Lighthouse(which could use some TLC).

Lighthouse quirks

The annoying thing about Azure Lighthouse is, is that you can't delegate a management group, so the highest level of resource container context you can delegate using a Lighthouse offer is a subscription. So there is no parent scope you can delegate to for that customer their subscriptions. Every subscription is the highest deployable context, viewed from your management tenant. Meaning, you can't state deploy all policies to the root scope of the customer, each subscription must receive all custom definitions and receive individual assignments (because no shared parent resource container scope).

Describe the solution you'd like

In an ideal scenario we'd be able to define every individual lighthouse customer in their own single PacEnvironment, where we could specify several subscriptions to a single PacSelector and EPAC would then deploy to each of those lighthoused subscriptions. The Azure PowerShell tenant login context would always be the same (our MSP Tenant, where all customer lighthoused subscriptions are accessible to the EPAC service principals). The deployment rootscope would have to be different for each subscription.

Describe alternatives you've considered

If an PacEnvironment per customer is not possible, then we'd have to create a PacEnvironment per subscription, which would be less ideal from an administrative standpoint. Some of our customers have hundreds of subscriptions we'd need to manage, thus meaning hundreds of PacEnvironments.

Additional context

We initiated some debugging/tinkering using the EPAC module code. When we flipped the tenantIds, added additionalRoleAssignments, and set crossTenant to true, EPAC initiated a role assignment on the defaultcontext (which failed) and an additional role assignment on the customer their lighthoused sub (which succeeded). The source code points out that Set-AzRoleAssignmentRestMethod adds delegatedManagedIdentityResourceId to the role assignment, which is required in a role assignment to a lighthoused subscription. This is a hacky and not what you'd want, but shows that it's possible to initiate role assignments, if the body contains the delegatedManagedIdentityResourceId.