SQL Server and Windows authentication


We want to connect Metabase to a SQL Server database using Windows authentication but cannot get it to work.

We have tried the steps in the second bullet in the answer to this StackOverflow post https://stackoverflow.com/questions/48704324/connect-metabase-to-sql-server, but either get the error:

Timed out after 5000 milliseconds.


com.microsoft.sqlserver.jdbc.SQLServerException: Login failed for user ‘FNHXLC2\limeservice’. ClientConnectionId:0c668eb7-35be-48a9-bd03-c4127ac4ac09

We are running v. 0.32.1 and Chrome.

Would really love some help on this. Thanks!

Hi @magnus
Are you using Dynamic Ports? Check what port you’re using:

And if you’re using the default port, then you have to input the port, since the placeholder otherwise just leaves the port empty.

Thanks for the quick reply!

However I dont think that’s the issue. I have another database on the same SQL Server where I use SQL login and that works perfectly with the default port (1433).

I don’t understand. So you have already setup a datasource in Metabase (connecting to “another”), which works fine, but you cannot create another datasource (connecting to whatever “limeservice” user has access to) ?
Is Metabase running on the same server as MSSQL?
Have you checked the MSSQL logs for more details?

So I have another data source in Metabase to another database on the same SQL server that works. But in that connection I have set up a SQL server login, not using Windows authentication. To be able to run Metabase in a viable way further on, I cannot use a SQL server login, but will be able to use Windows authentication only.

The SQL server is on the same server as Metabase. I can’t see anything in the SQL sever log.

And yes, the “limeservice” user does have the right access to the SQL server an the database.

After doing some searching, it seems like you would need to use Kerberos, and every post is either linking to @jornh’s post on the StackOverflow link you posted or to this issue:

Kerberos is hard work. If you’re not familiar with it, just create a SQL user and forget about the Windows authentication options.

Yes, it would of course be great to be able to simply run as an SQL user. However, our IT policy stops us from this due to security issues (brute force attacks for example) and I think that this is a quite common policy. For me it seems a bit strange that this bug hasn’t been fixed since v. 0.25, when using this setup would be quite common.

In that case, your IT department should be very familiar with Kerberos and it’s their problem!