Difficulty connecting to SQL Server

I’ve been trying to connect metabase to a MS SQL Server but continually get “Login failed for user…” and I’m not sure what I am doing wrong.

The facts:
Metabase v0.34.3 running in RHEL7 docker instance
Microsoft SQL Server 2016 running on Windows Server 2016 using a Always On availability group listener

The user I am using to connect to the DB is a AD user permissioned for the DB. I can connect to the DB, and make SELECT statements via SQL Server Managment Studio

I’ve tried setting integratedSecurity to true or false, applicationIntent to ReadOnly, and a few others but I always get “Login failed for user…”

What am I missing?

Hi @spacebob
Try using https://dbeaver.io/ or similar, maybe it will help you figuring out which options to set.
Also, check the SQL Server log for any details, since it sometimes will show information on why logins fails.

Just for testing, try a SQL user account instead. That will indicate whether the problem is to do with AD authentication or something else.

Our DBA’s are seeing the follow errors in the SQL Server log when trying to connect w/ Metabase:

Login failed for user 'DOMAIN\username'. Reason: Attempting to use an NT account name with SQL Server Authentication. [CLIENT: ##.##.###.##]

So I am thinking it is not treating the provided credentials as AD credentials, but as SQL Login credentials. I do know the Metabase app is running as a different user than what we are trying to login with.

Is there another open I need to tweak in order to have it use the credentials correctly?

We ended up having to use an SQL Account to connect to the MS SQL Server DB since running Metabase as the same AD account wasn’t an option for us.

Would anyone on this thread be able to contribute answers to the following:

  • What permissions does a local SQL Server database user need?

  • What permissions does the SQL Server login require?

I am about to create a new db user and login for metabase, and would like to give it minimal necessary permissions.

I setup a simple login and db user that was able to do a select on the db from SSMS, still trouble - and was essentially out of time to give this a quick try. Perhaps another day.