Bug Report - 403 when using key for storage accounts

[ocag305]

Describe the bug

When deploying, if organizational policies prevent access to storage accounts using keys, the deployment fails. The error message indicates that key-based authentication is not permitted on the storage account. In such cases, the deployment scripts should utilize managed identity for authentication instead of relying on storage account keys.

Steps to reproduce

1. Deploy the solution in an environment where policies disallow key-based access to storage accounts.
2. Observe deployment failure due to forbidden key-based authentication.

Error sample (sensitive information removed):

"code": "DeploymentFailed",
"message": "At least one resource deployment operation failed.",
"details": [{
  "code": "ResourceDeploymentFailure",
  "message": "Key based authentication is not permitted on this storage account. Status: 403 (Key based authentication is not permitted on this storage account.) ErrorCode: KeyBasedAuthenticationNotPermitted"
}]

Suggestion: Update deployment scripts to use managed identity when access with keys is not allowed by policy.

[jtracey93]

I believe this is for the alz-prerequistes deployment, correct @ocag305 ?

If so, @Springstone can we investigate this and look to altering the deployment script? Also it may be worth waiting for the retryOn feature coming to Bicep, which also means ARM, that will allow us to retry deployments based on errors we get back, meaning we can remove this artificial wait

...
"resources": {
    "retryOnExample": {
      "@options": {
        "retryOn": [
          [
            "DeploymentFailed",
            "InternalServerError",
            "InvalidResourceReference",
            "NotFound",
            "ResourceNotFound"
          ],
          5
        ]
      },
      "type": "Microsoft.Authorization/policyDefinitions",
      "apiVersion": "2025-01-01",
      "name": "test-policy-assignment"
    }
  }
...

[ocag305]

I believe this is for the alz-prerequistes deployment, correct @ocag305 ?

If so, @Springstone can we investigate this and look to altering the deployment script? Also it may be worth waiting for the retryOn feature coming to Bicep, which also means ARM, that will allow us to retry deployments based on errors we get back, meaning we can remove this artificial wait

...
"resources": {
"retryOnExample": {
"@options": {
"retryOn": [
[
"DeploymentFailed",
"InternalServerError",
"InvalidResourceReference",
"NotFound",
"ResourceNotFound"
],
5
]
},
"type": "Microsoft.Authorization/policyDefinitions",
"apiVersion": "2025-01-01",
"name": "test-policy-assignment"
}
}
...

Hey @jtracey93 that is correct

Please take a look of the repro

{
"code": "DeploymentFailed",
"target": "/providers/Microsoft.Management/managementGroups/ALZ-DEMO/providers/Microsoft.Resources/deployments/alz-prerequisites",
"message": "At least one resource deployment operation failed. Please list deployment operations for details. Please see https://aka.ms/arm-deployment-operations for usage details.",
"details": [
{
"code": "ResourceDeploymentFailure",
"target": "/subscriptions//providers/Microsoft.Resources/deployments/alz-prerequisites-002",
"message": "The resource write operation failed to complete successfully, because it reached terminal provisioning state 'Failed'.",
"details": [
{
"code": "DeploymentFailed",
"target": "/subscriptions//providers/Microsoft.Resources/deployments/alz-prerequisites-002",
"message": "At least one resource deployment operation failed. Please list deployment operations for details. Please see https://aka.ms/arm-deployment-operations for usage details.",
"details": [
{
"code": "ResourceDeploymentFailure",
"target": "/subscriptions//resourceGroups/rg-alz-prereqs/providers/Microsoft.Resources/deployments/alz-prereq-ds",
"message": "The resource write operation failed to complete successfully, because it reached terminal provisioning state 'Failed'.",
"details": [
{
"code": "DeploymentFailed",
"target": "/subscriptions//resourceGroups/rg-alz-prereqs/providers/Microsoft.Resources/deployments/alz-prereq-ds",
"message": "At least one resource deployment operation failed. Please list deployment operations for details. Please see https://aka.ms/arm-deployment-operations for usage details.",
"details": [
{
"code": "ResourceDeploymentFailure",
"target": "/subscriptions//resourceGroups/rg-alz-prereqs/providers/Microsoft.Resources/deploymentScripts/alz-prereq-deploymentscript",
"message": "The resource write operation failed to complete successfully, because it reached terminal provisioning state 'failed'.",
"details": [
{
"code": "DeploymentScriptOperationFailed",
"message": "Key based authentication is not permitted on this storage account.\nRequestId:\nTime:2025-11-30T04:49:44.3659014Z\r\nStatus: 403 (Key based authentication is not permitted on this storage account.)\r\nErrorCode: KeyBasedAuthenticationNotPermitted\r\n\r\nContent:\r\nKeyBasedAuthenticationNotPermittedKey based authentication is not permitted on this storage account.\nRequestId:\nTime:2025-11-30T04:49:44.3659014Z\r\n\r\nHeaders:\r\nx-ms-request-id: \r\nx-ms-error-code: KeyBasedAuthenticationNotPermitted\r\nDate: Sun, 30 Nov 2025 04:49:43 GMT\r\nServer: Microsoft-HTTPAPI/2.0\r\nContent-Length: 269\r\nContent-Type: application/xml\r\n"
}
]
}
]
}
]
}
]
}
]
}
]

[Springstone]

@ocag305 @jtracey93 unfortunately this is an issue with Deployment Scripts in ARM. We don't actually create any resources other than the deployment script itself - the DS feature creates a temporary storage account, etc to create and deploy the script. We have no control over this, and this has been raised by MS employees testing with their dedicated subscriptions as well - we have an internal policy blocking this as well.

WORKAROUND: exempt that policy on the management subscription for the duration of the deployment (2 hours is sufficient).

[matt-FFFFFF]

This is a niche issue typically occurring with internal MSFT tenants