Glad to see the amount of homework you did. A good example to be followed! Looks like a very nice summary of the current (Feb 2018) status of SQL Server support, and problems people ran into - in particular if Windows Authentication is needed.
Anyways I’m a bit pressed for time righ now - so will try to answer direct questions quick and then maybe get back later if needed:
It depends on if you are:
a) happy to live with an SQL user defined locally on the SQL server:
it’s yes 1- SQL server user setup is needed (unless you already have one) 2- No kerberos setup shouldn’t be needed
b) or want/need it to work with a Windows domain user account
1- I’m in doubt myself. Didn’t get to the bottom of it in the Connect to SQL Server via Windows Authentication thread you linked to above. 2- yes kerberos in your linux client with Metabase server is needed
Hope that gives you the options to choose from.
Yes that’s the rough steps if you want/need Windows Authentication.
Agree - better guidance/simpler setup is needed. But if anyone came up with a more clear guide I’m not aware of it. Last effort I was involved in with Windows Auth you already linked here, it’s just that it ended without Connect to SQL Server via Windows Authentication - but only a local SQL Server user “bailout”, which is understandable if it suited the bill.
Thanks you very much! For us it was right to use sql user auth instead of windows auth, so with sqlserver user sa I’ve been able to solve the problem!
No need to configure kerberos then!
Yes a guidance in the metabase site would be helpful, I’ve been trying things many time and after all it was pretty simple to configure just with sql auth. So it would be great for the people to know thast if they require windows auth they will need the kerberos thing!
One little addition - if you’re not using the default instance on SQL Server, you’ll need to specify the port to use. Ideally, change the port used on the SQL instance to a fixed port, then use that in the database setting in Metabase.
While SQL uses 1433 by default, this is only for the default instance. Any additional instances use a dynamic port.
On the bright side, I use SQL Server a lot and I’ve never come across an installation that only uses Windows security, so shouldn’t be forced down the painful Kerberos route.
I’ve also never faced a SQL Server installation which only uses Windows security. But I believe that MS Axapta users may choose that route.
Thank you for the port info by the way. Yesterday my demonstration failed for this port settings. Now I understood my problem.