Forum Discussion
Advocate IVODBC driver connect to Fabric
Hey schneiw
You're doing everything right, using the non-interactive "Microsoft Entra ID Password authentication" option, credentials are correct, MFA is excluded, and it even works fine in SSMS. So honestly, you'd expect the ODBC driver to behave the same way, just take the username and password and connect. But instead, it throws that annoying “InteractionRequired” error anyway. Really confusing. From what I’ve seen, and based on that GitHub issue you linked, it does seem like the ODBC driver (especially version 18) is acting up in scenarios like this. Even though you're not using interactive auth, it's still trying to trigger something interactive behind the scenes, which kind of defeats the purpose. It feels like the driver is either not fully honoring the selected auth method or maybe it’s hitting some unexpected behavior when used in linked server setups or background processes.
__________________________________________________________________________________________________________________________If this post helps, then please consider Accepting it as the solution to help the other members find it more quickly.
Regards,
Akhil.
Hi schneiw
Thanks for sharing the detailed info and the error message screenshot that definitely helps narrow things down!
What you're running into here is a common limitation with using Entra ID (Azure AD) Username/Password auth in non-interactive tools like the ODBC driver. Even though the credentials are correct (and work fine in SSMS), the issue is that the ODBC driver doesn't support interactive prompts and many Entra ID accounts these days are behind MFA or Conditional Access policies that require those interactive steps. That’s why you’re seeing the "InteractionRequired" and 'Found unknown spec version 'pii' errors.
According to my experience couple of ways you could approach this using Azure AD Service Principal (App Registration), SQL-authenticated user and Using ActiveDirectoryPassword with Entra ID.
Using Azure AD Service Principal.
If possible, consider using Azure AD Service Principal (App Registration) with a client secret. This method is designed for non-interactive scenarios like yours (ODBC + linked server) and doesn’t rely on a user login or MFA. You’d set it up in Azure, assign it access to your Fabric SQL endpoint, and then use ActiveDirectoryServicePrincipal as the authentication type in your ODBC connection.
Using SQL-authenticated user.
If allowed in your environment, creating a SQL-authenticated user (with username/password) directly in the Fabric SQL endpoint and using that for the ODBC connection can also work this avoids Entra ID altogether.
Using ActiveDirectoryPassword.
Using ActiveDirectoryPassword with Entra ID credentials usually won’t work reliably unless MFA and Conditional Access are turned off, which isn’t typical in most orgs anymore.
________________________________________________________________________________________________________________________
If this response helps, consider marking it as “Accept as solution” and giving a “kudos” to assist other community members.
Reagrds,
Akhil.
Advocate IVI see that message relating to "...converted from Unexpected to InteractionRequired. But look at these two connection options. One states to use a usernam and password whereas the other refers to Interation. I am not using the one referin to Interaction, so it should just use the username and password, unless its bugged?
I also found this link that seems to point the ODBC driver being bugged, can you confirm? Connection Issue with Microsoft Fabric Data Warehouse using MSODBC 18, sqlsrv 5.12.0, and pdo_sqlsrv 5.12.0 · Issue #1535 · microsoft/msphpsql