Forum Discussion
Native Snowflake Key Pair Authentication Fails via On-premises Data Gateway
We’re seeing an issue with the native Snowflake connection using Key Pair authentication through the On-premises Data Gateway.
The same username and PKCS#8 private key work successfully with the Snowflake ODBC driver. However, when creating a managed connection using Connection Type: Snowflake and Authentication: Key Pair, it fails with:
Unable to update connection credentials. Invalid connection credentials.
Gateway logs only show a generic AccessUnauthorized / credential authentication error, and no authentication attempt reaches Snowflake.
Has anyone experienced this with native Snowflake Key Pair authentication through the On-premises Data Gateway, or is there any additional gateway-side configuration required?
Thank you PauReis for the time spent on this, we rolled out the proxy related issues as well.
I have identified the root cause: the issue was related to the default warehouse configuration on the Snowflake service account.
For Power BI native Snowflake Key Pair authentication, the service account needs a valid default warehouse mapped to the user, even when the username has access to multiple warehouses.
Once the default warehouse was correctly configured, the Key Pair connection worked successfully.
7 Replies
Thank you PauReis for the time spent on this, we rolled out the proxy related issues as well.
I have identified the root cause: the issue was related to the default warehouse configuration on the Snowflake service account.
For Power BI native Snowflake Key Pair authentication, the service account needs a valid default warehouse mapped to the user, even when the username has access to multiple warehouses.
Once the default warehouse was correctly configured, the Key Pair connection worked successfully.
v-abhinavmuCommunity Support
Hi fayezeinodini,
Thanks for the detailed update and for confirming the root cause. Glad to hear that configuring the default warehouse for the Snowflake service account resolved the Key Pair authentication issue. This is useful information for others who may encounter a similar situation.
Thank you.
- PauReis
Resolver II
Hi fayezeinodini,
Thanks for coming back with the actual cause. That one is worth flagging for whoever finds this thread next, because a default warehouse sits a long way from where the error text points you.
There is one loose end worth tying off, since it is what sent this thread toward proxy and driver theories, my own reply included. Your early observation was that no authentication attempt reaches Snowflake. A missing default warehouse gets resolved during session setup, after the key pair has already been verified, so the login itself succeeds and Snowflake should have recorded it. The likely reason you saw nothing is that LOGIN_HISTORY has a latency of up to 120 minutes, so checking it shortly after a failed attempt returns an empty result that reads exactly like proof nothing arrived.
If you hit something similar again, give that view a couple of hours and then check IS_SUCCESS and FIRST_AUTHENTICATION_FACTOR for the service account. Seeing a successful key pair login sitting next to a Power BI error saying the credentials are invalid is the quickest way to tell that the problem is on the session side rather than the credential, which would have pointed at the warehouse straight away.
- v-abhinavmu
Hi fayezeinodini,
Thanks for reaching out to the Microsoft Fabric Community forum.According to Microsoft’s current documentation, Key Pair authentication is supported for the Snowflake connector and uses the ADBC driver. Microsoft specifically notes that when Key Pair authentication is used, the ADBC driver is used regardless of the connector Implementation setting.
For the on-premises data gateway, Microsoft lists January 2025 as the minimum supported version for the Snowflake connector and recommends using the latest gateway version.
Regarding the “Invalid connection credentials” message, Microsoft recommends verifying that the credentials are correct and that they can successfully connect to the data source using the selected authentication method.
Microsoft also notes that gateway connection tests can sometimes fail when optional parameters required by a connector are omitted. For Snowflake, the documented examples include the warehouse and role parameters.
Based on this guidance, I would first verify that the gateway is up to date and review the Snowflake connection configuration, including the selected Key Pair authentication, warehouse, and role settings.
For more details, please refer to the below official Microsoft documentation:
Power Query Snowflake connector - Power Query | Microsoft LearnTroubleshoot on-premises data gateways - Power BI | Microsoft Learn
I hope this helps. Please feel free to reach out if you have any further questions.
Thank you. - PauReis
Hi fayezeinodini,
One thing before you chase the gateway version, because I think your ODBC test is pointing you the wrong way.
Key Pair doesn't share a code path with the ODBC driver. The connector docs are blunt about it: "if you're using Key Pair authentication, the ADBC driver is always used regardless of this setting." So getting that key working through the Snowflake ODBC driver proves the key material is fine and tells you nothing about the path that's actually failing.
Since nothing is reaching Snowflake, I'd look at how the key is being read rather than at anything on the Snowflake side. There's one detail in the docs that catches people out here: "The passphrase input field automatically appears only if necessary, based on the type of certificate uploaded. After the user uploads a certificate, the system detects whether it's encrypted or unencrypted and conditionally displays the passphrase dialog."
So that box is conditional, and it's driven by detection rather than by you. If your key is encrypted and the box never appeared, the gateway is trying to load an encrypted key with no passphrase. That fails on the gateway before any connection is attempted, which is exactly the shape you're describing, a generic AccessUnauthorized with nothing on the wire.
Quick check, open the key file and read the first line. BEGIN ENCRYPTED PRIVATE KEY means it needs a passphrase, BEGIN PRIVATE KEY means it doesn't. If it's the encrypted one and you were never asked for a passphrase, try an unencrypted PKCS#8 copy and see if the behaviour changes.
Did the passphrase field ever appear?
Thank you PauReis,
My privateKey is not encrypted and the box doesnt appear.
I tried to create a new connection as well, but got the same error.- PauReis
Hi fayezeinodini,
That rules the passphrase out, so it's worth pinning down what's left. The line in your first post that matters most is that no authentication attempt reaches Snowflake. If nothing is leaving the gateway, nothing on the Snowflake side can be causing it. The user, the public key on that user, the role and the warehouse are all off the table, and that's most of what gets suggested for this error.
That leaves the gateway machine, and there's one difference between your working ODBC test and the failing connection that's easy to walk past. Key Pair always runs on the ADBC driver, and that driver is the Go one rather than the .NET stack the rest of the gateway uses. It doesn't inherit the machine's proxy configuration. Microsoft's connector page is direct about it: "The driver uses environment variables for the proxy settings." The driver's own reference names them, HTTP_PROXY, HTTPS_PROXY and NO_PROXY.
So if that server reaches the outside through a proxy, your ODBC driver gets out and the ADBC path doesn't, and what you'd see is exactly what you're seeing: a credential error raised locally, with nothing arriving at Snowflake. Worth checking whether those variables exist as system variables on the gateway box for the account the service runs as. They're read when the process starts, so the gateway service needs a restart after you add them. One thing to know before you go down that road, from the same reference: NO_PROXY doesn't support wildcards, so a bypass entry can't cover a whole domain.
Does that machine go out through a proxy, or straight out?