Azure Synapse Studio shows 403 Forbidden for all workspace artifacts despite Subscription Owner access

Hi ,

Thanks for reaching out to Microsoft Q&A.

Yes, this is a known pattern where RBAC (Owner at subs level) does not automatically grant full access inside synapse Studio because synapse uses a separate workspace level RBAC model on top of azure IAM. 403 across all artifacts, including “Access Control,” typically indicates that your identity is not added to synapse RBAC (for ex, synapse admin/synapse contributor), or that RBAC metadata inside the workspace is not initialised or is corrupted. First, have another admin (or use ARM/CLI) explicitly assign you the synapse administrator role at the workspace scope; if even that fails, it strongly points to a workspace provisioning or RBAC sync issue. In such cases, re-running workspace deployment (or updating via ARM), checking MI permissions, and validating that the workspace MSI has proper access to the underlying storage account (ADLS Gen2 RBAC + ACLs) usually resolves it; otherwise, it ends up being a backend issue requiring Microsoft support.

Please 'Upvote'(Thumbs-up) and 'Accept' as answer if the reply was helpful. This will be benefitting other community members who face the same issue.

Hi @Sandeep Kumar Das

Based on the symptoms described, the issue could be related to either Synapse RBAC permissions or workspace connectivity/network configuration.

A few important points:

• Having Owner permissions at the Subscription scope does not automatically grant access to all Synapse Studio artifacts. Synapse uses its own workspace-level access model (Synapse RBAC) in addition to Azure RBAC.
• The fact that Manage → Access Control is also returning 403 Forbidden may indicate a permissions-related issue.
• Microsoft documentation also notes that 403 errors in Synapse Studio can occur due to networking or connectivity configuration issues, including Private Endpoint, DNS, or Public Network Access settings.

For reference:

• Resolve Synapse Studio connectivity issues (403 Forbidden): https://learn.microsoft.com/troubleshoot/azure/synapse-analytics/workspace/synapse-studio/wrk-conn-synapse-studio#failed-to-load-one-or-more-resources-due-to-a-forbidden-issue-with-error-code-403
• Synapse workspace access control overview: https://learn.microsoft.com/azure/synapse-analytics/security/synapse-workspace-access-control-overview
• Connectivity settings for Synapse workspaces: https://learn.microsoft.com/azure/synapse-analytics/security/connectivity-settings
• https://techcommunity.microsoft.com/blog/azuresynapseanalyticsblog/disabling-public-network-access-in-synapse/3692197

Hope this helps, Please let us know if you have any questions.

Hello Sandeep Kumar Das,

Greetings! Thanks for raising this question in Q&A forum.

You have correctly identified this as a Synapse RBAC initialization problem. This is a very common and well-documented scenario, and the root cause is that Azure RBAC and Synapse RBAC are two completely separate permission systems. Being an Owner at the Subscription or even at the Synapse Workspace level in Azure IAM does not automatically grant you any Synapse RBAC roles inside Synapse Studio. The two systems are independent.

Synapse Studio requires its own internal roles, the most important being Synapse Administrator, to access and manage workspace artifacts like Pipelines, Datasets, Linked Services, Triggers, and so on. Since Manage > Access Control is also failing with 403, it confirms that no Synapse RBAC role has been assigned to your account within Synapse at all, which is most likely because the workspace was provisioned via an automated tool (IaC such as Terraform, Bicep, or ARM pipeline) that did not include the Synapse RBAC role assignment step.

Here is exactly how to fix this.

Step 1: Assign the Synapse Administrator role using the Azure portal (not Studio).

Because your Azure IAM Owner role does give you the right to assign Synapse RBAC roles as a recovery mechanism, you can use the REST API or PowerShell to bootstrap the first Synapse RBAC assignment. Since you cannot reach the Access Control blade in Studio right now, use PowerShell:

# Install if not already present
Install-Module -Name Az.Synapse -Force

# Login
Connect-AzAccount

# Set your details
$workspaceName = "sansynapsews"
$resourceGroupName = "<your-resource-group>"
$yourObjectId = "<your-user-object-id>"  # Get from Azure AD > Users > Your profile

# Assign Synapse Administrator role
New-AzSynapseRoleAssignment `
  -WorkspaceName $workspaceName `
  -RoleDefinitionId "6e4bf58a-b8e1-4cc3-bbf9-d73143322b78" `
  -ObjectId $yourObjectId

Note: Use the RoleDefinitionId (the GUID) rather than the role name "Synapse Administrator" because resolving by name requires a workspace read permission that you do not yet have, which causes a secondary failure. The GUID 6e4bf58a-b8e1-4cc3-bbf9-d73143322b78 is the fixed well-known ID for the Synapse Administrator role.

To find your Object ID, go to Azure portal > Microsoft Entra ID > Users > search for your account > copy the Object ID from the Overview page.

Step 2: Wait a few minutes and then clear your browser session.

After the PowerShell command succeeds, Synapse RBAC propagation typically takes 2 to 5 minutes. After waiting, fully close your browser, clear cookies and cached data, then reopen Synapse Studio. Do not just refresh the tab as the old token will still be cached.

Alternatively, try opening Studio in a private or incognito window directly at: https://web.azuresynapse.net

and manually sign in and select your workspace.

Step 3: Verify your Synapse RBAC role in Studio.

Once back in Synapse Studio, go to Manage > Access Control and confirm that your account now shows the Synapse Administrator role at workspace scope. If you can see the Access Control page successfully now, the 403 errors on all artifacts should also be resolved.

Step 4: Verify the workspace Managed Identity has Storage access (if Storage-related errors persist).

If after fixing the Synapse RBAC you still see errors related to Linked Services or Lake Databases pointing to ADLS Gen2, check that the workspace Managed Identity has the Storage Blob Data Contributor role on the associated storage account. Go to your storage account > Access Control (IAM) > verify the Synapse workspace system-assigned managed identity has this role.

Root cause summary for your records:

The workspace creator is normally auto-assigned the Synapse Administrator role in Synapse RBAC when creating the workspace through the Azure Portal or PowerShell. However, when using Terraform, Bicep, or ARM templates, this auto-assignment does not happen, and the Synapse RBAC initialization step must be done explicitly as a post-provisioning step. This is the most common reason for this exact symptom pattern.

If this answer helps you kindly accept the answer which will help others who have similar questions.

Best Regards,

Jerald Felix.