Forum Discussion

aniruddhabh's avatar
aniruddhabh
Icon for Microsoft Employee rankMicrosoft Employee
10 months ago
Solved

Cannot connect to Fabric Lakehouse SQL endpoint from Azure Function App (MSI) — works locally

When connecting to the Fabric SQL endpoint ( Both Lakehouse and warehouse ) from the deployed Azure Function App using Managed Identity, the connection fails with SQL error 18456 - Authentication was successful, but the database was not found or you have insufficient permissions. The same code connects successfully from a local run (using DefaultAzureCredential fallbacks), and we can enumerate databases including NLSQLAdventureWorks.
 
'error': 'InterfaceError: ('28000', \\'[28000] [Microsoft][ODBC Driver 18 for SQL Server][SQL Server]Login failed for user 'token-identified principal'.Reason: Authentication was successful, but the database was not found or you have insufficient permissions to connect to it. (18456) (SQLDriverConnect)\\')'
 

What we’ve tried:

  • Verified MSI is enabled and attached.
  • Confirmed connection string matches Fabric SQL endpoint details.
  • Checked Fabric workspace permissions (Contributor role).

Question:
Has anyone successfully connected an Azure Function App to Fabric SQL endpoints using MSI?

  • Do we need additional steps beyond workspace Contributor and “Read all data using SQL database” in Fabric security?
  • Is there a difference in how Lakehouse vs Warehouse endpoints handle MSI principals?
  • Any workaround for the 18456 error when running in Azure?
  • Hi aniruddhabh ,

    This is a classic identity mapping issue specific to non-interactive principals (Service Principals / MSI).

    The Root Cause: The error 18456 with "Authentication was successful" is the smoking gun. It means Entra ID (AAD) validated the MSI token successfully, but the SQL Engine inside Fabric rejected the login.

    • Why it works locally: DefaultAzureCredential falls back to your personal user credentials (e.g., from VS Code or Azure CLI). Since you are a User in the workspace, the SQL engine maps you automatically.

    • Why it fails in Azure: Even though the MSI is a Workspace Contributor, Fabric SQL Endpoints (unlike Azure SQL DB) sometimes do not automatically map Service Principals/MSIs to a database user context effectively, or there is a propagation delay.

    The Fix: You need to explicitly create the MSI as a user inside the SQL Endpoint using T-SQL.

    1. Open SSMS or Azure Data Studio.

    2. Connect to the Fabric SQL Endpoint using your working Entra ID user account.

    3. Run the following commands on the Lakehouse/Warehouse database:

    SQL
    -- Ensure you type the exact name of the Function App MSI
    CREATE USER [Your-Function-App-Name] FROM EXTERNAL PROVIDER;
    
    -- Grant permissions (read or owner depending on need)
    ALTER ROLE [db_datareader] ADD MEMBER [Your-Function-App-Name];
    ALTER ROLE [db_datawriter] ADD MEMBER [Your-Function-App-Name];

    Once the MSI exists explicitly as a database user, the "Database not found" error (which is a generic mask for "Access Denied") will disappear.

    Let us know if that resolves the handshake!


    If my response resolved your query, kindly mark it as the Accepted Solution to assist others. Additionally, I would be grateful for a 'Kudos' if you found my response helpful.
    This response was assisted by AI for translation and formatting purposes.

6 Replies

  • Hi aniruddhabh ,

    This is a classic identity mapping issue specific to non-interactive principals (Service Principals / MSI).

    The Root Cause: The error 18456 with "Authentication was successful" is the smoking gun. It means Entra ID (AAD) validated the MSI token successfully, but the SQL Engine inside Fabric rejected the login.

    • Why it works locally: DefaultAzureCredential falls back to your personal user credentials (e.g., from VS Code or Azure CLI). Since you are a User in the workspace, the SQL engine maps you automatically.

    • Why it fails in Azure: Even though the MSI is a Workspace Contributor, Fabric SQL Endpoints (unlike Azure SQL DB) sometimes do not automatically map Service Principals/MSIs to a database user context effectively, or there is a propagation delay.

    The Fix: You need to explicitly create the MSI as a user inside the SQL Endpoint using T-SQL.

    1. Open SSMS or Azure Data Studio.

    2. Connect to the Fabric SQL Endpoint using your working Entra ID user account.

    3. Run the following commands on the Lakehouse/Warehouse database:

    SQL
    -- Ensure you type the exact name of the Function App MSI
    CREATE USER [Your-Function-App-Name] FROM EXTERNAL PROVIDER;
    
    -- Grant permissions (read or owner depending on need)
    ALTER ROLE [db_datareader] ADD MEMBER [Your-Function-App-Name];
    ALTER ROLE [db_datawriter] ADD MEMBER [Your-Function-App-Name];

    Once the MSI exists explicitly as a database user, the "Database not found" error (which is a generic mask for "Access Denied") will disappear.

    Let us know if that resolves the handshake!


    If my response resolved your query, kindly mark it as the Accepted Solution to assist others. Additionally, I would be grateful for a 'Kudos' if you found my response helpful.
    This response was assisted by AI for translation and formatting purposes.

  • aniruddhabh's avatar
    aniruddhabh
    Icon for Microsoft Employee rankMicrosoft Employee

    Hi burakkaragoz 

     

    Thank you so much for the detailed explanation — it really helped me understand the identity‑mapping behavior for non‑interactive principals like MSI in Fabric SQL endpoints. The root‑cause breakdown and the comparison between local credential fallback vs. Azure MSI were especially useful.

     

    One clarification I wanted to add for others who might face the same issue:


    While the approach you suggested is absolutely correct in principle, the CREATE USER FROM EXTERNAL PROVIDER statement is currently not allowed on Fabric SQL endpoints. During troubleshooting, I observed that the user object actually gets created automatically when permissions (GRANT/DENY) are applied — but the role propagation can take time.

     

    In my case, the issue was resolved after I removed the existing external user entry and re‑applied the required roles. Once the role propagation completed, the MSI authentication started working as expected.

     

    Thanks again for your support — marking this as the accepted solution so it can help others as well!

    • bcho2501's avatar
      bcho2501
      New Member

      Hi aniruddhabh, How did you managed to re-apply the require roles? I tried CREATE USER FROM EXTERNAL PROVIDER which worked but it still did not grant my azure function access. I also tried removing the MSI from the workspace and readding which did not work. My function works locally but not when deployed and get the same error as you that auth succeed but the database could not be found.

  • Hi aniruddhabh,

    Thank you burakkaragoz, for your insights.

    Enable service principal access at the tenant level, add the MSI to the Fabric workspace, and grant it Connect/Read permissions for the SQL endpoint. Because Fabric does not automatically map MSIs, permissions must be explicitly assigned for Warehouse or Lakehouse SQL endpoints.

    Microsoft Entra Authentication in Fabric Data Warehouse - Microsoft Fabric | Microsoft Learn

     

    Thank you.

    • gdingwani's avatar
      gdingwani
      Icon for Microsoft Employee rankMicrosoft Employee

      Hi v-saisrao-msft ,

       

      I am facing the same issue. I added the SPN as a Contributor to the Workspace and configured Read.All role for the SPN on the SQL endpoint. 

      Can you confirm if we need to add SPN explicitely to Microsoft tenant allowed SPNs? If yes, how can we reach out to Fabric Admins for it?

      I would highly appreciate your help. 

      Regards,

      Gauransh

  • Hi aniruddhabh,

    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.