Getting Status: 403 (Key based authentication is not permitted on this storage account.) when using a service principal

MrFlinstone 766 Reputation points
2026-09-18T08:47:51.5266667+00:00

Hi,

When I run a script that reads the contents of a Gen 2 data lake storage account using my Entra account, it works fine however I am trying to automate a process, the automation process uses a service principal for authentication, when it runs I get the error

Process failed: Key based authentication is not permitted on this 
storage account.
Status: 403 (Key based authentication is not permitted on this storage account.)

The storage account has shared access key disabled for security reasons, from the research i have done it appears this is the root cause of the error. I would like to understand if there are any workarounds.

Thanks in advance.

Azure Data Lake Storage
Azure Data Lake Storage

An Azure service that provides an enterprise-wide hyper-scale repository for big data analytic workloads and is integrated with Azure Blob Storage.

0 comments

2 answers

Sort by: Most helpful
Most helpful Newest Oldest
  1. SHOUMIK CHAKRAVARTY 660 Reputation points
    2026-09-19T04:48:39.4866667+00:00

    Hello @MrFlinstone - The 403 error code narrows this. Troubleshoot 403 errors in Azure Blob Storage lists KeyBasedAuthenticationNotPermitted as an authentication failure, and keeps authorization failures separate, where a principal has valid credentials but not enough permission. A service principal that authenticated with Entra and lacked a role would give you AuthorizationPermissionMismatch instead.

    Since that's the error you're getting, the request must be arriving with a key attached rather than a token, which puts roles and ACLs off the table for now. What you're looking for is whatever in the automation is still supplying that key.

    Places to look: a connection string with AccountKey= in config or an environment variable, az storage commands without --auth-mode login since they use keys by default, a client built from a shared key credential rather than a token credential, or a SAS generated from the account key.

    On workarounds, you don't need one. Disabling shared key doesn't block service principals, it blocks keys. Entra auth against an account with shared key disabled is the supported setup, which is why your own account works fine.

    You will need a data plane role on the principal once the credential is fixed, Storage Blob Data Reader or Storage Blob Data Contributor depending on what the script does.

    Help make this community better for everyone: if this answer resolved your issue, please accept it or leave an upvote. If not, share more details in a comment so we can continue the discussion and find the right solution.

    Was this answer helpful?

    0 comments

  2. AI answer

    2026-09-18T08:48:16.1133333+00:00

    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:

    1. 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
    2. 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.
    3. 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.
    4. 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.
    5. 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.
    6. 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.
    AI-generated content may be incorrect. Read our transparency notes for more information.

    Was this answer helpful?

Your answer

Answers can be marked as 'Accepted' by the question author and 'Recommended' by moderators, which helps users know the answer solved the author's problem.