Azure Recovery Services Vault: Failure to attach identities when using SystemAssigned and UserAssigned.

[fblix]

Bicep version
0.13.1

Describe the bug
When trying to create a recovery services vault via bicep and setting both a systemassigned and a userassigned identity both identities get created (serviceprincipal for the systemassigned, managedidentity resource for the userassigned) but none of the get attached to the Azure Recovery Services Vault. However, when calling the REST API directly with the following code:

$body = @{
    'properties' = @{
        'publicNetworkAccess' = 'Disabled'
    }
    'sku'        = @{
        'name' = 'Standard'
    }
    'location'   = 'West US'
    'identity'   = @{
        'type'                   = 'systemassigned,userassigned'
        'userAssignedIdentities' = @{
            '/subscriptions/subscriptionid/resourcegroups/testRSV/providers/Microsoft.ManagedIdentity/userAssignedIdentities/testRSV' = @{}
        }
    }
}
$restUri = 'https://management.azure.com/subscriptions/' + $SubscriptionId + '/resourcegroups/' + $ResourceGroup + '/providers/Microsoft.RecoveryServices/vaults/' + $VaultName + '?api-version=2022-10-01' #&operation=DeleteVaultUsingPS
Invoke-RestMethod -Uri $restUri -Headers $authHeader -Method PUT -Body ($body | ConvertTo-Json -Depth 99)

the creation and the assignment succeed.

Upon running the same code but with

'type' = 'SystemAssigned, UserAssigned'

the creation succeeds but the assignment fails.
When running the equivalent code in bicep the assignment never happens, no matter the configuration.
The chosen API-Version does not seem to impact this behavior.

A clear and concise description of what the bug is vs what you expected to happen

To Reproduce

1. Create a user assigned identity in the azure portal.
2. Create a bicep file which creates a recovery services vault and make sure to enable both system assigned and user assigned identities at the same time.
3. Run the bicep file.

Additional context
This is especially troublesome since you are no longer able to delete the rogue system-assigned identity (which is a service principal) without a support ticket.

cc: @JPEasier

[alex-frankel]

Can you share the bicep code you are using to reproduce?

[alex-frankel]

Seems similar to #7496. I'm assuming this part of they payload is handled by the RP and we don't touch it, but the fact that you can do this directly with the API is surprising.

[fblix]

@alex-frankel We discovered this during our test runs with CARML.
Here are the two snippets used to deploy it on our side:
deploy.bicep
deploy.test.bicep

We are also quite certain this might be an RP issue, but we didn't have any point of contact to open a ticket/raise the issue with them directly. We were not sure if this is 100% on the RP side, thus this issue in this repo just to be sure.

[alex-frankel]

@fblix -- sorry about the delay on this. I played around with the repro steps and was able to successfully deploy with both variants ('SystemAssigned, UserAssigned' and 'systemassigned,userassigned'), but in neither case did the assignment actually happened. If you haven't already, can you open up a support ticket or ICM against this resource type?

[fblix]

hi @alex-frankel will open a support ticket on this case, thanks!