Handling “Access to the resource is forbidden” in Azure SQL Database links.

The error “Access to the resource is forbidden” occurs when Excel or Power Query successfully discovers an Azure SQL Database endpoint, but the Azure resource manager or database engine rejects the connection request. Unlike generic network drops, this specific error indicates that your request reached Azure, but security boundaries—such as firewall rules, credential context scopes, or missing database permissions—blocked access.

Quick Answer

To fix “Access to the resource is forbidden” in Azure SQL Database links, add your client public IP address to the Azure SQL Server Firewall rules in the Azure portal. In Excel, clear cached credentials under Data > Get Data > Data Source Settings, select the specific target database rather than the root server, and reconnect using valid database-level credentials.

---

Primary Root Causes in Azure SQL Links

Connecting Excel to Azure SQL requires passing through multiple distinct authorization layers:

1. Azure SQL Server-Level Firewall: Blocks any public IP not explicitly defined in an active firewall rule.
2. Credential Target Scope: Power Query frequently attempts to authenticate against the server’s master database by default. If your account is a “contained database user” provisioned only inside a specific user database, Azure rejects the server-level probe with a forbidden error.
3. Stale Data Source Settings in Excel: Excel caches credentials based on the root server name (myserver.database.windows.net). If credentials expire, change, or initially authenticate under the wrong provider (such as an organizational account instead of a Database User), Power Query silently reuses the invalid token on every refresh.

For broader connection error patterns, review Troubleshooting SQL Connection Failures: Fixing ODBC and Provider Errors.

---

Step-by-Step Troubleshooting Path

Step 1: Whitelist Your Client IP Address in Azure

If your current public IP is not registered on the Azure SQL virtual server, the gateway immediately rejects the connection.

1. Log in to the Azure Portal.
2. Navigate to your SQL server resource (not just the individual SQL database).
3. Under the Security heading on the left menu, select Networking.
4. Under the Public access tab, review the Firewall rules list.
5. Click Add your client IPv4 address to register your current external IP.
6. If the connection originates from an Azure-hosted service (such as Power BI or an Azure VM running Excel), check the box for Allow Azure services and resources to access this server.
7. Click Save and allow 1 to 2 minutes for the rule to propagate across Azure gateways.

If your organization blocks direct IP access and enforces strict server firewall alerts, see Fixing “Client IP address is not allowed to access the server” (Azure Firewall).

Step 2: Clear Stale Cached Credentials in Excel

Power Query preserves credential tokens across workbooks. If an incorrect authentication type was selected during the initial connection setup, it must be cleared.

1. In Excel, go to the Data tab.
2. Click Get Data > Data Source Settings.
3. Select Global permissions.
4. Scroll through the list, locate your Azure SQL Server address (.database.windows.net), and click Clear Permissions (or Delete).
5. Close the dialog and initiate your query refresh again.

For detailed instructions on managing stored access tokens, consult Managing Data Source Settings: How to clear and reset Global Permissions.

Step 3: Target the User Database Directly (Contained User Fix)

A very common mistake when connecting Excel to Azure SQL is leaving the Database field blank in the connection dialog.

When you leave the database name blank:

• Excel attempts to connect to master.
• Azure SQL users are typically created as contained users inside a dedicated business database (e.g., SalesDB).
• Because the contained user does not exist in master, Azure issues an access forbidden or login failure.

To fix this:

1. Go to Data > Get Data > From Database > From SQL Server Database.
2. In the Server box, enter the full server name: your-server.database.windows.net.
3. In the Database (optional) box, do not leave it empty. Enter the exact name of the specific database (e.g., FinanceReporting).
4. When prompted for credentials, select the correct tab:
   • Use Database for standard SQL logins (sa, reporting users).
   • Use Microsoft account for Microsoft Entra ID (Azure Active Directory) single sign-on.
5. In the Select which level to apply these settings to dropdown, choose the Database URL instead of the Server URL.

---

Deeper Escalation: Diagnostic Next Steps

If the firewall is open and credentials are cleared, but access remains forbidden:

• Validate Database Object Permissions: Ensure your database user has explicit permissions to read data. The account must possess at least db_datareader membership or explicit SELECT grants on the target schemas or views: -- Run by an administrator in the target database ALTER ROLE db_datareader ADD MEMBER [YourUserOrEmail];
• Authentication Method Conflicts: If your tenant enforces Conditional Access policies or MFA, standard basic SQL logins may be restricted, or organizational logins may require modern interactive auth. See Troubleshooting “Login failed for user”: Windows vs. SQL Authentication..
• SSL Handshake Complications: Azure SQL strictly enforces TLS encryption. If resolving the access permission error exposes an untrusted certificate chain warning from your local machine, refer to Solving SSL Provider errors: “The certificate chain was issued by an untrusted authority.”.