I am working on .NET6 WebApi project on Ubuntu/Windows and the connection to the SQL Server DB is configured to use windows authentication. On windows I can use this connection string Data Source=DB-Name;Initial Catalog=Cat1;Integrated Security=SSPI. On Linux, we have ruled out using Kerboros for authentication and instead, we want to find a connection string similar to jdbc:jtds:sqlserver://DBName:Port;domain=ABC_XYZ;useNTLMv2=true for java apps. Is this possible using SQL client, ODBC, OLEDB or any other supported clients for .net6? Using the JDBC connection string, I can connect to the desired databases in the Jetbrains Rider.
The .Net SqlClient does not support NTLM with provided credentials, there's a tracking issue here. Only Kerberos, SQL Auth, and (for Azure SQL) AAD auth.
JDBC is the only Microsoft driver that supports NTLM on Linux.
Related
I currently am using ejabberd connected to a Microsoft SQL Server database. I am using a SQL Server login with username/password, per the documentation here: https://docs.ejabberd.im/admin/configuration/database/#microsoft-sql-server
How can I configure the ejabberd SQL Server storage to use SQL Server integrated security instead? I've not found documentation yet to address this.
A couple of ideas I have are to have the ejabberd service run as a kerberos/AD account, and configure the sql_server option as an ODBC connection string and use the integrated security option. Or to define the sql_username as the integrated login name, but remove the sql_password option.
Has anyone else tried doing this?
A .Net Core 2.2 application running in a Linux Docker container fails to authenticate to SQL Server on a different machine using SQL Authentication. The error message is:
Cannot authenticate using Kerberos. Ensure Kerberos has been initialized on the client with 'kinit' and a Service Principal Name has been registered for the SQL Server to allow Kerberos authentication.
We have configured the connection string to use SQL Authentication (user name and password). We have tried setting trusted_connection=false, but the connection still attempts to use Kerberos authentication.
The (redacted) connection string is:
"server=ourfullyqualifiedserver.domain,1433;database=our-database;user=sql-user;password=sql-password;"
I would expect to be able to connect to SQL Server from the container using SQL Authentication, but it is still attempting to use Kerberos. Why, and how do we make the connection use SQL Server Authentication?
You may have to add "Trusted_Connection=false;" to your connection string.
And also, use the Server IP with the Port that you exposed to the server.
It turns out that the connection string in the base appsettings.json configuration file was not being overwritten by the environment-specific settings file (appsettings.Development.json). Our DevOps group set the environment variable for the container and it correctly connected using the SQL Server credentials.
We hosted a .Net core 2.2 API in Red Hat Open shift container platform. API is using Entity Framework connecting to a SQL Server db on Windows Server, but both the container platform, SQL Server are on the same domain.
Now the API is unable to establish connection with the SQL server db. We tried with SQL Auth, but still the API hosted on container pod is trying to establish sql connection using kerberos, which has following issue.
System.Data.SqlClient.SqlException: Cannot authenticate using Kerberos. Ensure Kerberos has been initialized on the client with 'kinit' and a Service Principal Name has been registered for the SQL Server to allow Kerberos authentication.
Need some inputs on What are the additional setup, configurations required to connect SQL Server from open shift container platform ?
Right now there are no environment variables, config maps, additional drivers for SQL configured in the open shift container platform.
The problem with mine was the connection string. I had to remove "Trusted_Connection=true"
I want to access a remote Microsoft SQL Server 2012 database from a Java web application (JSP and surrounding classes) using Microsoft JDBC Driver 4.0. I was told the username/password for the database, but would prefer not storing the verbatim password as part of the web application's configuration.
Does Microsoft SQL Server 2012 support another authentication method where I could pass e.g. some kind of service token instead from a remote (not necessarily Windows-based) host, and more generally, what are best practices for storing and configuring database access configuration parameters in such a scenario?
From a Windows box in an Active Directory (AD) environment, you can use integrated security. This will connect to SQL Server using the AD security credentials of the current process (Windows account).
Specify integratedSecurity=true instead of user name and password in the connection string. See Building the Connection URL for more information.
SQL Server also supports Kerberos authentication using the Microsoft JDBC driver for Linux as specified with the authorizationScheme connection string keyword.
I have account set up on SQL Server such that it uses my Windows authentication to connect to SQL Server.
Is there a way I can set up trusted connection to connect to MS SQL in Grails.
I am using :
Grails 2.0.1
SQL Server 2008
Unix
Thanks
If you're using the jTDS JDBC driver (if not, I would suggest it over the MS driver), the README.SSO file included in the jTDS distribution describes how to configure trusted/single-sign-on authentication. There is a native DLL that needs to be made available to the JVM for SSO to work. Note that the DLL is Windows-only, so you wouldn't be able to host your Grails app on Unix.
Another possibility would be to specify your Windows AD domain, username and password in your jTDS connection string. See http://jtds.sourceforge.net/faq.html#urlFormat specifically, the domain property:
domain
Specifies the Windows domain to authenticate in. If present and the user name and password are provided, jTDS uses Windows (NTLM)
authentication instead of the usual SQL Server authentication (i.e.
the user and password provided are the domain user and password). This
allows non-Windows clients to log in to servers which are only
configured to accept Windoes authentication...