Forum Discussion
Microsoft EmployeeCannot connect to Fabric Lakehouse SQL endpoint from Azure Function App (MSI) — works locally
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.
Open SSMS or Azure Data Studio.
Connect to the Fabric SQL Endpoint using your working Entra ID user account.
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.
Microsoft EmployeeHi 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!
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.