Entra Provider: support AdministrativeUnit membership via Entitlements

[ntt-matthias-fleschuetz]

Problem Statement

For Entra ID users, assigning and revoking Administrative Unit (AU) memberships is not supported by the Entra Provider. Administrative Units are essential for fine-grained delegated administration — they control which scoped admins can manage which users. Without AU support, JML workflows cannot manage this dimension of the identity lifecycle.

Proposed Solution

Administrative Units are modelled as a new Kind = 'AdministrativeUnit' within the existing entitlement contract. This is architecturally consistent: AUs are relationships between a user and an AU object, not user attributes - identical in structure to group memberships, but using different Microsoft Graph endpoints.

No Step or Core changes are required.
All changes are isolated to IdLE.Provider.EntraID.

The following provider ScriptMethods are extended to handle Kind = 'AdministrativeUnit':
ListEntitlements - reads current AU memberships via Graph (GET /users/{id}/memberOf/microsoft.graph.administrativeUnit). Returns entitlements with Kind = 'AdministrativeUnit' and Id = <AU objectId>.
GrantEntitlement - adds the user to the specified AU via Graph (POST /administrativeUnits/{id}/members/$ref).
RevokeEntitlement - removes the user from the specified AU via Graph (DELETE /administrativeUnits/{id}/members/{userId}/$ref).
PruneEntitlements - the existing IdLE.Entitlement.Prune capability advertisement is extended to also cover Kind = 'AdministrativeUnit', enabling bulk-remove scenarios (e.g. Leaver offboarding).

AUs are referenced by their Entra Object ID (GUID), consistent with how groups are referenced today.

Validation: If a referenced AU ID does not exist in Entra, the provider must throw a clear, actionable error - not a raw Graph API error.

Workflow usage example:

@{
    Name = 'Assign to HR Administrative Unit'
    Type = 'IdLE.Step.EnsureEntitlement'
    With = @{
        IdentityKey     = '{{Request.IdentityKeys.Id}}'
        Provider        = 'Entra'
        AuthSessionName = 'MicrosoftGraph'
        Entitlement     = @{ Kind = 'AdministrativeUnit'; Id = '<AU-ObjectId-GUID>' }
        State           = 'Present'
    }
}

Alternatives Considered

Modelling AUs as attributes (EnsureAttributes with an AdministrativeUnits key): rejected because AUs are relationships, not attributes. Hiding relationship management inside the attribute bag would introduce invisible side effects and violate the attribute/entitlement separation.

Dedicated Step type (IdLE.Step.EnsureAdministrativeUnitMembership): rejected because it would be provider-specific and violate the headless, provider-agnostic Step design.

Impact

• Does this affect existing workflows? No.
• Any backward compatibility concerns? No.

Additional Context

• Administrative Units must be pre-created in Entra before being referenced in a workflow. The provider validates AU existence and fails with a clear error if the AU ID is not found.
• Required Microsoft Graph permissions (in addition to existing group permissions): AdministrativeUnit.Read.All (for List), AdministrativeUnit.ReadWrite.All (for Grant/Revoke). Exact permissions depend on delegated vs. application auth model.
• The provider documentation (docs/reference/providers/provider-entraID.md) must be updated to document Kind = 'AdministrativeUnit', the new Graph endpoints used, and the additional required permissions.