An Azure service that provides an enterprise-wide hyper-scale repository for big data analytic workloads and is integrated with Azure Blob Storage.
Yes. The error is expected when the storage account has Shared Key access disabled and the automation is still attempting key-based authorization.
KeyBasedAuthenticationNotPermitted means the storage account is configured to disallow Shared Key authentication. In that state, requests that use account keys or key-based SAS fail with 403.
Workarounds supported by the documented behavior:
- Use Microsoft Entra ID authentication for the automation
- Authenticate the script as the service principal with OAuth/Microsoft Entra ID, not with an account key or key-based SAS.
- Grant the service principal the required Azure RBAC data role at the correct scope.
- For blob/data access, documented roles include:
- Storage Blob Data Reader for read operations
- Storage Blob Data Contributor for write operations
- Storage Blob Data Owner for management operations
- Verify the service principal is actually being used for data-plane auth
- If the script works with an Entra user account but fails with the service principal, the automation path is likely falling back to account keys or SAS.
- Check whether the SDK, script, or connection string includes an account key,
List Keys, or a key-generated SAS. - If Shared Key is disabled, those methods will continue to fail.
- Check authorization scope if the service principal already uses Entra ID
- A valid token can still fail if the role assignment is missing or assigned at the wrong scope.
- Ensure the service principal has the required role on the subscription, resource group, storage account, or container, depending on how access is scoped.
- For ADLS Gen2, check ACLs if RBAC alone is not sufficient in the access path
- The security principal must appear in an ACL entry for the target file or directory, or be a member of a group that appears there.
- The ACL entry must grant the needed permissions.
- If the sticky bit is enabled on a directory, delete or rename operations can return 403 unless the caller is the child owner, directory owner, or
$superuser.
- Check network restrictions if 403 persists
- Firewall rules, selected networks, disabled public access, or private endpoint/DNS issues can also produce 403 errors.
- If access is restricted, confirm the automation runtime can reach the storage account from an allowed network path.
- Only if security policy allows it: re-enable Shared Key access
- This removes the immediate block on key-based auth, but it weakens the security posture that disabled Shared Key was intended to enforce.
- If re-enabled, requests using account keys will work again.
If the goal is secure automation, the practical path is:
- authenticate the automation with the service principal using Microsoft Entra ID,
- assign the correct Storage Blob Data role,
- verify ADLS Gen2 ACLs where applicable,
- remove any use of account keys, connection strings with keys, or key-based SAS from the script.