Forum Discussion

melsheikh's avatar
melsheikh
Microsoft Employee
1 month ago
Solved

Fabric Snowflake connector returns "Invalid credentials" with Key-Pair despite valid key pair

The Fabric Snowflake connector fails with "Invalid credentials" when using Key-Pair authentication, in both Dataflow Gen2 and the Copy job. The same key pair authenticates successfully outside Fabric (Snowflake Python connector returns a valid session), which proves the credentials, private key, username, account, and warehouse are all correct. The failure occurs both on the cloud connection and through an on-premises data gateway (routing via a different network), which rules out a network/OCSP cause and points to a defect in the connector's key-pair handling.

Environment

  • Snowflake trial account UAE Region
  • DESC USER confirms HAS_KEYPAIR = TRUE, RSA_PUBLIC_KEY_FP populated, no MFA, no auth/network policy
  • Fabric region: UAE, Connector Implementation 2.0, on-prem data gateway (latest version)

Steps to reproduce

  1. Create a Snowflake connection (Dataflow Gen2 or Copy job), Authentication kind = Key-pair, upload unencrypted PKCS#8 private key.
  2. Server tried in both forms: XXXXX-XXXXXX.snowflakecomputing.com and XXXXX.uae-north.azure.snowflakecomputing.com.
  3. Result: "Invalid credentials." Same result with an on-premises data gateway.

Proof credentials are valid The identical private key + account + user authenticate successfully via snowflake-connector-python (returns CURRENT_USER=myuser, CURRENT_ACCOUNT=myaccount, CURRENT_ROLE=ACCOUNTADMIN). Data was successfully loaded Snowflake → Lakehouse via a Fabric Notebook using the same key.

 

Expected: Key-pair connection succeeds (as it does in every non-Fabric client). Actual: "Invalid credentials" in both native connectors, cloud and gateway.

Screenshots:

  1. Dataflow Gen2 connection dialog, Key-pair + gateway + "Invalid credentials":

2. Copy job connection dialog — Key-pair + gateway + "Invalid credentials":

 

3.DESC USER MELSHEIKH showing HAS_KEYPAIR = TRUE / RSA_PUBLIC_KEY_FP

 

Is there any known issue regarding Fabric Dataflow Gen2 and Fabric Copy job connection to Snowflake?

  • melsheikh's avatar
    melsheikh
    17 days ago

    Thank you v-saisrao-msft​ , I found the issue, in the connection it converted the server name to lower case although I added it in upper case, so when I used the lower case in the dataflow gen2 connection the connections I created in Settings > Manage Connections and Gateways appeared in the dropdown list. Thank you for your support

17 Replies

  • TalH01's avatar
    TalH01
    Regular Visitor

    It is working for me perfectly. I couldn't reproduce your issue using Copy Job.
    Please verify that you are using the exact same value for the Username (case sensetive) otherwise you would get the invalid credentials error.

  • ShivekMaharaj's avatar
    ShivekMaharaj
    Power Participant

    Hi melsheikh​,

    Since the same key works through the Snowflake Python connector, I would try one test connection without the gateway using the same Fabric settings. Microsoft’s Snowflake connector capability matrix confirms that key-pair authentication is supported with an on-premises gateway, so this does not appear to be an unsupported combination.

    That test should help isolate the path:

    • If the cloud connection succeeds, I would focus on the gateway host, its network route, clock synchronization, and any Snowflake network policy applied to the gateway’s outbound IP.
    • If both fail, I would check the exact Snowflake LOGIN_NAME, account hostname, and uploaded private key again.

    I would also retrieve the underlying Snowflake login failure rather than relying on Fabric’s generic Invalid credentials message. Snowflake documents how to use SYSTEM$GET_LOGIN_FAILURE_DETAILS in its key-pair authentication troubleshooting guidance, which can help distinguish an account mismatch, login-name mismatch, public-key fingerprint mismatch, invalid signature, or token timing issue.

    One detail worth checking on the gateway server is its system clock. Snowflake rejects a JWT when the issue time is too far out, so clock skew can appear as an authentication failure even when the key itself is correct.

    AI-assisted drafting: AI was used to help structure and phrase this response. I reviewed and validated the technical content before posting.

    • melsheikh's avatar
      melsheikh
      Microsoft Employee

       

      This is what I get, seems like Fabric connection attemp didn't pass to snowflake

      • v-saisrao-msft's avatar
        v-saisrao-msft
        Community Support

        Hi melsheikh,

        Have you had a chance to review the solution shared by Pulendar1? If the issue persists, feel free to reply so we can help further.

         

        Thank you.

  • v-saisrao-msft's avatar
    v-saisrao-msft
    Community Support

    Hi melsheikh,

    Have you had a chance to review the solution we shared earlier? If the issue persists, feel free to reply so we can help further.

     

    Thank you.

  • Hi melsheikh ,

     

    I have done this worked as expected using dataflow and Pipeline.

    One step you need do is --> First create the gateway connection using Keypair and then try use it in pipeline or Dataflowgen2. 

     

    **Also, Can you share the steps ,how you connected using Key Pair from Notebook. I am looking for that 🙂 

     

    Key Pair authentication was successfully configured and validated through the On-Premises Data Gateway. The test pipeline execution completed successfully, confirming that the Snowflake connection using Key Pair authentication is working as expected via the gateway.

    Regards,

    Pulendar

    • ShivekMaharaj's avatar
      ShivekMaharaj
      Power Participant

      Hi Pulendar1​,

      Thanks for testing that and sharing the screenshot. That is useful confirmation.

      You are right, Microsoft’s current Snowflake connector capability matrix lists Key-pair authentication as supported with an on-premises data gateway for Dataflow Gen2, Pipelines and Copy jobs, so the gateway + Key-pair combination itself is supported.

      That makes melsheikh​'s case more interesting.

      Since the same key works outside Fabric, and Key-pair through the gateway is also working in your test, I would now compare the two gateway environments rather than the Snowflake user/key itself.

      A few things I would check next:

      1. Gateway version on the failing environment versus the one where your test succeeded.
      2. Whether both are using the same Snowflake connector implementation/driver path.
      3. Whether the exact same private key file is being uploaded, including encryption/passphrase handling.
      4. Gateway logs around the failed connection attempt to see whether Fabric is failing before Snowflake authentication is actually attempted.
      5. Whether there is any difference in outbound network path, proxy, TLS inspection or Snowflake network policy between the two gateway servers.

      The fact that melsheikh​ previously saw no corresponding Snowflake login attempt is probably the most useful clue here. If that still holds, I would focus on what is happening between Fabric and the gateway connector, before the request ever reaches Snowflake.

      I would also make sure the gateway is fully current before going much further, since Key-pair support across these Fabric experiences is relatively recent.

      Thanks again for validating the gateway path. That rules out one of the bigger unknowns in this thread.

      AI-assisted drafting: AI was used to help structure and phrase this response. I reviewed and validated the technical content before posting.

    • melsheikh's avatar
      melsheikh
      Microsoft Employee

      Hi Pulendar1 
      This is the notebook that works, where I was able to connect to snowflake from Fabric notebook

      import snowflake.connector
      
      con = snowflake.connector.connect(
      account="OHHHHPJ-NT42852", user="MELSHEIKH",
      private_key_file="/lakehouse/default/Files/rsa_key.p8",
      warehouse="COMPUTE_WH", role="ACCOUNTADMIN",
      insecure_mode=True)
      
      cur = con.cursor()
      cur.execute("SELECT * FROM SNOWFLAKE_SAMPLE_DATA.TPCH_SF1.CUSTOMER LIMIT 1000")
      cols = [c[0] for c in cur.description]
      rows = cur.fetchall()
      con.close()
      
      spark.createDataFrame(rows, schema=cols) \
      .write.mode("overwrite").saveAsTable("customer_from_snowflake")
      
      print("Done — table 'customer_from_snowflake' written to the Lakehouse.")

       

      And this is what I get when we try to connect to Snowflake from Fabric copy job. Invalid credentials.

       


      We also tried with gateway and without gateway option. 

       

      Am I missing something?

       

      • Pulendar1's avatar
        Pulendar1
        Helper I

        Hi melsheikh ,

        Thank you for sharing the script! Are you using snowflake with Privateend point or public network?

        Also, regarding the copy job --> ***First create datasource in the gateway using Keypair and ensure successfully stored the datasource.

        Step 2 : Then Create copy job while searching the source choose Gateway connection which you created in the step 1. It should work.

         

  • melsheikh's avatar
    melsheikh
    Microsoft Employee

    Thanks for your response, the username has the exact same value yes (case sensetive)
    The exact same connections parameters works fine in Fabric notebook, the issue is in Copy Job and Dataflow Gen2

  • Greetings, 

    I encountered this exact issue and wanted to share the solution that worked for me, as this appears to be one of the few discussions covering it.

    In my scenario, I was using a Service Account (SA) to maintain the connection for our organization. When attempting to connect through Fabric using key-pair authentication, I consistently received an "Invalid credentials" error.

    What made this particularly confusing was that the same key-pair worked without any issues in a standalone Python script. Additionally, I could not find any login attempts in the SF history when testing through Fabric, which suggested the authentication process was failing very early.

    During my testing, I observed the following:

    • Personal account using Microsoft authentication: Successful
    • Service account using Microsoft authentication: "Invalid credentials"
    • Service account using key-pair authentication: "Invalid credentials"

    I compared the configuration of both accounts and eventually discovered that the service account did not have a default role or default warehouse assigned

    After configuring both a default role and a default warehouse for the service account, the connection succeeded, including when using key-pair authentication.

    If you're experiencing an "Invalid credentials" error in Fabric, despite the same key-pair working elsewhere, it may be worth checking whether the account has a default role and default warehouse configured. In my case, this was the root cause of the issue.

    Hope this will work for you as well!