Synapse Serverless SQL – “Cannot find the CREDENTIAL … because it does not exist or you do not have permission” when querying external table

Question

Synapse Serverless SQL – “Cannot find the CREDENTIAL … because it does not exist or you do not have permission” when querying external table

Victor Buzy 20

Good morning everyone,

We have an issue when we try to query ours tables on SSMS:

Cannot find the CREDENTIAL ...because it does not exist or you do not have permission.

We had to do our migration for this:
Transition your Azure Synapse Analytics workspaces to private links before 1 August 2026**

So we created a new workspace 02, with the same properties than the 01 except the different settings to do the transition

However it looks that we have the same configurations for the 01 and 02 for the Storage Account IAM:

and for the storage account container IAM too:
So we do not understand what to do to be able to query our tables in SSMS.

Could you please help us?

Thanks

Manoj Kumar Boyini 9,180 Reputation points Microsoft External Staff Moderator

2026-03-02T09:56:30.9466667+00:00

Hi Victor Buzy,

I hope you had a chance to review the information shared earlier, and I hope this information has been helpful! If you still have questions, please let us know what is needed in the comments so the question can be answered.
Victor Buzy 20 Reputation points

2026-03-02T14:19:47.29+00:00

Hi Manoj,
Actually everything works if I pass by a Authentification Microsoft Entra MFA, but not with a SQL Server Authentification like before the transition.

I don't know if it is normal but this is what I found

Thanks
Manoj Kumar Boyini 9,180 Reputation points Microsoft External Staff Moderator

2026-03-02T20:07:45.53+00:00
Hi Victor Buzy,

Thanks for confirming the behavior. When using external tables in Serverless SQL, access to ADLS Gen2 requires a database‑scoped credential backed by a Managed Identity. Only Microsoft Entra ID (AAD) users can authenticate in a way that allows them to use this managed identity for storage access.

SQL Server Authentication is not able to use Managed Identity and therefore cannot access external data after the Private Link transition. This is why the queries succeed with Entra MFA authentication but fail with SQL Authentication.

This is expected behavior with Private Link + Serverless SQL, and SQL Authentication cannot be used to access external data sources in this configuration.

If you need SQL logins to work, the only alternatives are:

Use SAS-based credentials instead of Managed Identity, or

Use Entra ID authentication (recommended and most secure approach)

Hope this helps, Please let us know if you have any questions and concerns.
Victor Buzy 20 Reputation points

2026-03-03T15:03:16.39+00:00

Hi,

Thank you for the clarification.

We understand now that the behavior is expected after the Private Link migration. Since Serverless SQL requires a Managed Identity to access ADLS Gen2, and SQL Authentication cannot use Managed Identity, this explains why the queries fail with SQL authentication but succeed when using Microsoft Entra ID (MFA).

We will standardize on Entra ID authentication for accessing external tables in Serverless SQL, as recommended.

Thank you for your support and confirmation.

Best regards, Victor

Answer accepted by question author

1 additional answer

Your answer

Manoj Kumar Boyini 9,180 Reputation points Microsoft External Staff Moderator

2026-03-02T09:56:30.9466667+00:00

Hi Victor Buzy,

I hope you had a chance to review the information shared earlier, and I hope this information has been helpful! If you still have questions, please let us know what is needed in the comments so the question can be answered.
Victor Buzy 20 Reputation points

2026-03-02T14:19:47.29+00:00

Hi Manoj,
Actually everything works if I pass by a Authentification Microsoft Entra MFA, but not with a SQL Server Authentification like before the transition.

I don't know if it is normal but this is what I found

Thanks
Manoj Kumar Boyini 9,180 Reputation points Microsoft External Staff Moderator

2026-03-02T20:07:45.53+00:00

Hi Victor Buzy,

Thanks for confirming the behavior. When using external tables in Serverless SQL, access to ADLS Gen2 requires a database‑scoped credential backed by a Managed Identity. Only Microsoft Entra ID (AAD) users can authenticate in a way that allows them to use this managed identity for storage access.

SQL Server Authentication is not able to use Managed Identity and therefore cannot access external data after the Private Link transition. This is why the queries succeed with Entra MFA authentication but fail with SQL Authentication.

This is expected behavior with Private Link + Serverless SQL, and SQL Authentication cannot be used to access external data sources in this configuration.

If you need SQL logins to work, the only alternatives are:

Use SAS-based credentials instead of Managed Identity, or

Use Entra ID authentication (recommended and most secure approach)

Hope this helps, Please let us know if you have any questions and concerns.
Victor Buzy 20 Reputation points

2026-03-03T15:03:16.39+00:00

Hi,

Thank you for the clarification.

We understand now that the behavior is expected after the Private Link migration. Since Serverless SQL requires a Managed Identity to access ADLS Gen2, and SQL Authentication cannot use Managed Identity, this explains why the queries fail with SQL authentication but succeed when using Microsoft Entra ID (MFA).

We will standardize on Entra ID authentication for accessing external tables in Serverless SQL, as recommended.

Thank you for your support and confirmation.

Best regards, Victor

Answer 1

Hi Victor Buzy,

The error “Cannot find the CREDENTIAL … because it does not exist or you do not have permission” occurs when Serverless SQL cannot find the database‑scoped credential required by your external table.

Since you created a new Synapse workspace during the Private Link transition, the most likely cause is that credentials and external data sources were not recreated in the new workspace. These objects do not migrate automatically even if the storage configuration is the same.

Check if the credential exists

SELECT * FROM sys.database_scoped_credentials;

If missing, recreate it:

CREATE DATABASE SCOPED CREDENTIAL <credential_name>
WITH IDENTITY = 'Managed Identity';

Recreate or update the EXTERNAL DATA SOURCE so it references the correct credential:

SELECT * FROM sys.external_data_sources;

Grant REFERENCES permission

GRANT REFERENCES ON DATABASE SCOPED CREDENTIAL::<credential_name> TO <user_or_group>;

Ensure the workspace‑02 Managed Identity has Storage Blob Data Reader/Contributor on the storage account or container (which your screenshot shows is correct).

The issue is not with your Storage IAM configuration the new workspace simply lacks the required database‑scoped credential and permissions. Recreating the credential, updating the external data source, and granting REFERENCES will resolve the error.

Reference
https://learn.microsoft.com/en-us/azure/synapse-analytics/sql/develop-storage-files-storage-access-control

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

Answer 2

Victor Buzy 20

Actually everything works if I pass by a Authentification Microsoft Entra MFA, but not with a SQL Server Authentification like before the transition.

I don't know if it is normal but this is what I found

Thanks

Share via

Synapse Serverless SQL – “Cannot find the CREDENTIAL … because it does not exist or you do not have permission” when querying external table

1 additional answer

Your answer