I am using jTDS driver to connect to a SQL Server database. I don't want to provide my Windows Domain username and password but would like to make use of Trusted_connection property in my connection string. However it seems as per this jTDS driver FAQ page there is no property named Trusted_connection supported by jTDS driver.
Given the application and SQL Server database are on the same host and I have ntlmauth.dll installed correctly, how do I take advantage of Trusted_connection property so that I don't have to specify username/password?
Is it that jTDS automatically makes use of Domain username and password as soon as it spots useNTLMv2 and domain properties being used as shown in the following connection url?
jdbc:jtds:sqlserver://DBHostName:Port/DatabaseName;useNTLMv2=true;domain=DomainName
NB: I could test this myself if only I have access to the code of the application.
As described in the file README.SSO, you need not specify any credentials.
In order to set up the jTDS driver to use Windows Single Sign On, users
will have to connect without providing a user name and password. This will
only work on Windows.
Driver example:
// No user name or password in URL or as parameters
DriverManager.getConnection(
"jdbc:jtds:sqlserver://localhost:1433/LionKing");
You need not specify the useNTLMv2 parameter either, if you do it determines the version of NTLM that will be used, not IF NTLM will be used or not.
Related
I have a database created in SQL Server with the following configuration:
Also, I am trying to connect to the database named EDS.
For that I created the following details:
Should i have domain in the string or should it be in the username?
When i go to the database properties i see the owner has.
Also, is the url correct on the instance part according to the image? it looks like it is not able to go to that particular instance.
Also, this is the configuration for the connection (using Windows Authenticaton)
When I put in the username I am getting the following error log:
com.microsoft.sqlserver.jdbc.SQLServerException: Login failed for user '. ClientConnectionId:e812971f-b03c-4210-9dbd-de0791bcc304
When specifying the location of the SQL Server instance, one normally provides serverName\instanceName or serverName:portNumber, not both. That is, either
jdbc:sqlserver://INNOWAVE-99\SQLEXPRESS01;databaseName=EDS
or
jdbc:sqlserver://localhost:1433;databaseName=EDS
(assuming that the SQLEXPRESS01 instance has been explicitly configured to listen on port 1433, which is not usually the case for a SQL Express instance).
As mentioned in the documentation for Building the Connection URL
If both a portNumber and instanceName are used, the portNumber will take precedence and the instanceName will be ignored.
There is no domain= property defined for the connection URL for Microsoft's JDBC driver for SQL Server. Logging in to the SQL Server instance with Windows domain credentials is done implicitly using the integratedSecurity=true connection property (and not explicitly providing a username and password); details here.
I'm also having the same problem. Working for me too without port number.
Don't forget to give semicolon at the end of the connection.
Connect to the default database on the local computer by using integrated authentication:
jdbc:sqlserver://localhost;integratedSecurity=true;
Connect to a named database on a remote server:
jdbc:sqlserver://localhost;databaseName=AdventureWorks;integratedSecurity=true;
Connect on the default port to the remote server:
jdbc:sqlserver://localhost:1433;databaseName=AdventureWorks;integratedSecurity=true;
Connect by specifying a customized application name:
jdbc:sqlserver://localhost;databaseName=AdventureWorks;integratedSecurity=true;applicationName=MyApp;
Reference Link : mssql document
Is there a way to specify the authentication method (SQL Server or Windows Authentication) when connecting to SQL Server with DataGrip?
I have tried configuring using both the SQL Server(jTDS) and the SQL Server(Microsoft) drivers and don't see an option on either.
With the jTDS Driver:
This is dependent on the settings for the connection/data source.
i.e. To set up a connection for Windows Authentication:
In the "General" tab, if specify your Windows/AD Username in the User field.
on the "Advanced" tab, in the DOMAIN property, specify the domain for the Windows account you put in Step 1.
You may need to set USENTLMV2=true if Kerberos authentication isn't enabled on your network
If you don't specify the domain in step 2, it will assume you are doing a SQL Server Authentication login attempt.
With the Microsoft Driver:
I couldn't get this to work on OS X, but most people seem to have no issues on Windows.
In the "Advanced" tab for the data source, set integratedSecurity to true.
n.b. you may have to also set this property for the actual Driver as well, on OS X i was getting continually "This driver is not configured for Integrated Authentication", but that could be OS X thing.
Hope this helps.
I was able to connect on MacOS in Intellij 2018.2 using the Microsoft 7.0.0 SQL Server jdbc driver.
(First, I'm assuming you have Kerberos working. To check that, run:
klist | grep krbtgt
If you have a Kerberos ticket, you should see:
Aug 29 12:17:34 2018 Aug 29 22:17:34 2018 krbtgt/DOMAIN.COMPANY.COM#DOMAIN.COMPANY.COM
I used this article on Connecting using ActiveDirectoryIntegrated Authentication Mode to troubleshoot this. Note that I did not have to do "Step 2: Configuring KDC in krb5.conf". )
Make sure to set the jdbc driver to use integrated security and Java Kerberos.
Picture of Advanced tab in Project Data Sources
Picture of Advanced tab in Project Data Sources showing authentication scheme
Then, on the general tab, make sure to change the drop down menu next to the URL, to "URL only" and put in a URL of the form:
jdbc:sqlserver://databaseserver.domain.company.com;database=testdatabase;integratedSecurity=true;authenticationScheme=JavaKerberos;encrypt=true;trustServerCertificate=true;
Picture of General tab in Project Data Sources
If you leave the drop down next to URL on "default", it will attempt to use a user name/password, which is not what you want if you're using integrated authentication. Also, please make sure you know what you're doing if you leave "trustServerCertificate=true;" in the URL. In production, you should properly setup your certificates, but that's not in the scope of what's being asked here.
Since Sonarqube 5.2 is released, the jTDS JDBC driver is no longer supported. We used this driver to connect to our SQLServer instance, but we'll have to switch to the Microsoft SQLServer driver. We're running Sonarqube on Ubuntu and use an Active Directory account to connect to the SQLServer database. Because we're running on Ubuntu we can't use integrated security, so the credentials have to be supplied in the JDBC configuration for Sonarqube. This would result in the following properties:
sonar.jdbc.url=jdbc:sqlserver://sqlserverhost.my.domain.com:1433;databaseName=sonar;selectMethod=cursor
sonar.jdbc.username=someuser
sonar.jdbc.password=somepassword
This results in SQLServer in a "Login Failed" with the message "Could not find a login matching the name provided."
The next thing I tried was to connect with a username containing the domain, resulting in these properties:
sonar.jdbc.url=jdbc:sqlserver://sqlserverhost.my.domain.com:1433;databaseName=sonar;selectMethod=cursor
sonar.jdbc.username=DOMAIN\\someuser
sonar.jdbc.password=somepassword
This however also results in a "Login Failed" in SQLServer, the message here is "Attempting to use an NT account name with SQL Server Authentication."
What am I missing?
UPDATE:
The Sonarqube log can be found here: http://pastebin.com/AGB9bTQG
I can think of one thing which is different from the jTDS connection url:
the jTDS connection url contained ";domain=my.domain.com", which the Microsoft SQLServer driver doesn't seem to support. Therefore I tried the DOMAIN\someuser setup which SQLServer refused.
The driver is completely different from the jtds driver. In order to use it, you'll need to specify the authenticationScheme=JavaKerberos parameter (please refer to https://msdn.microsoft.com/en-us/library/gg558122(v=sql.110).aspx and http://blogs.msdn.com/b/psssql/archive/2015/01/09/jdbc-this-driver-is-not-configured-for-integrated-authentication.aspx)
The problem here is that your Linux machine is most likely not in the same domain, so you'll need to configure kerberos on your Linux machine too. Your best bet would really be mixed mode.
The connection string format has changed. No more :1443 or selectMethod
sonar.jdbc.url=jdbc:sqlserver://sqlserverhost.my.domain.com;databaseName=sonar
The connection string setting needs to be in the format:
sonar.jbc.url=jdbc:sqlserver://{server}:{port #};databaseName={db name}
e.g.
sonar.jbc.url=jdbc:sqlserver://localhost:36549;databaseName=Sonar
Check in SQL Server Configuration Manager that TCP/IP protocol is enabled and to find the port number for the SQL instance you want to connect to. Note that the database name in the connection string is case sensitive and must match what appears in SSMS.
Re: Windows Auth to SQL Server - you need to either use a SQL Server Auth user, or comment out sonar.jdbc.username and sonar.jdbc.password so that the SonarQube makes the connection under the credentials of the user running the SonarQube service; I don't think it supports impersonation.
Our solution was to have a SQL Server account created with permission to the database and use that instead of using the AD/Windows account.
I'm having to support multiple database types for my tenant-enabled web application. Among others, I have successfully supported Microsoft's SQL Server, by using the net.sourceforge.jtds.jdbc.Driver class with a connection String like "jdbc:jtds:sqlserver://192.168.1.189:1433/ApplicationName". This works, but it requires that the user explicitly defines a user in the SQL Server instance and enables SQL Server authentication.
Now, inevitably, requirements changed, and we're supposed to support connecting to SQL Server via Windows Authentication. Evidently this requires some sort of change to the connection string, since the data base server must somehow be able to distinguish whether the credentials passed into the data base connection are for a user defined in the SQL Server installation or in the Windows OS. But what is it?
Acting on advice from the internet, if progressed as far as extending the connection string with ;useNTLMv2=true;domain=WORKGROUP. That seems to make the data base server aware that I want to authenticate as a Windows user, but the actual log-in fails with
The login is from an untrusted domain and cannot be used with Windows authentication. (code 18452, state 28000)
Now im my testing set-up, both the J2EE app and the SQL server instance are in fact on the same machine (although in production they may not be), and still this computer isn't trusted enough to log on to itself? Evidently I'm missing a big part of the puzzle here. What does one have to do to convince an SQL Server instance that the user who started it can in fact log on to it via JDBC?
Edit
Since we have already sunk too much unsuccessful effort trying to integrate our web application with a full Microsoft infrastructure stack (SQL Server, Active Directory, Domain Name Service...), I have to restrict this question:
Does anyone know a way to access an SQL Server installation with a user account defined as a "Windows User" via JDBC form a J2EE application, without having to use Active Directory, a Windows machine running the web application and a proprietary DLL? The bounty is for any solution of that sub-problem. The entire problem is clearly too broad to be answered in one forum post.
I ran into the error
The login is from an untrusted domain and cannot be used with Windows
authentication
when a 2012 SQL Server DB instance was recently upgraded to 2016. In order to use AD based authentication with the JTDS driver and SQL Server 2016, it seems necessary to specify both the useNTLMv2=true and the domain=example.com suffix in order to establish a connection. The name of the domain is absolutely necessary and I confirmed that through testing. This is with JTDS driver version 1.3.1.
Example of a working connection string using AD based authentication to SQL Server 2016 DB with JTDS 1.3.1:
jdbc:jtds:sqlserver://sqlserver2016db.example.com/MY_DB_NAME;domain=example.com;prepareSQL=2;useNTLMv2=true
UPDATE
Recently (due to the pandemic lockdown), I found myself also having to connect to SQL Server using Windows authentication from a non-domain computer (over VPN). This can be accomplished by starting the Windows process initiating the SQL Server connection, e.g. Eclipse / Spring Tool Suite, with the following command:
C:\Windows\System32\runas.exe /netonly /user:domain\user "path_to_executable.exe"
Source: https://www.mssqltips.com/sqlservertip/3250/connect-to-sql-servers-in-another-domain-using-windows-authentication/
In discovering that gem, I also discovered that encryption needed to be used. Here are the settings I'm using (in addition to now running the executable with /netonly and a domain account):
spring.datasource.url=jdbc:jtds:sqlserver://fqdn_of_server_including_domain/DBNAME;domain=mydomain;useNTLMv2=true;ssl=require;prepareSQL=2;
spring.datasource.username=domainaccountname_without_domain_prefix
spring.datasource.password=password
spring.datasource.testOnBorrow=true
spring.datasource.hikari.connection-test-query=SELECT 1
spring.jpa.database-platform=org.hibernate.dialect.SQLServerDialect
What you describe certainly appears to be feasible. I have SQL Server 2008 R2 Express running on a stand-alone server and I was able to connect using a Windows username/password on that server via jTDS 1.3.1 from a separate Windows machine and from an Xubuntu 14.04 box.
On the machine running SQL Server I created a Windows user named 'kilian'. In SQL Server itself I created a SQL Login for NT AUTHORITY\Authenticated Users. Then in the database (named 'myDb') I created a User named 'AuthenticatedUsers' for that SQL Login. Just to keep things simple I gave that user db_owner rights on the database.
There is no SQL Login for 'kilian' and no database User with that name.
Then, from the other two machines (the Windows workstation and the Xubuntu box) I just ran this:
package com.example.jtdstest;
import java.sql.*;
public class JtdsTestMain {
public static void main(String[] args) {
try (Connection con = DriverManager.getConnection(
"jdbc:jtds:sqlserver://192.168.1.137:52865/myDb" +
";domain=whatever",
"kilian",
"4theBounty")) {
try (Statement s = con.createStatement()) {
String sql = "SELECT LastName FROM Clients WHERE ID=1";
try (ResultSet rs = s.executeQuery(sql)) {
rs.next();
System.out.println(rs.getString("LastName"));
}
}
} catch (Exception e) {
e.printStackTrace(System.out);
}
}
}
Additional notes:
I did not have to include useNTLMv2=true. I was able to connect with or without that parameter.
I did have to include domain= to tell the SQL Server not to use SQL authentication, but the actual value I supplied made no difference. (I literally used 'whatever', which was not the name of the server or the name of the workgroup to which it belongs.)
Alternative Method
The alternative solution is to utilize integrated security. This enables your application to connect to the database as the user in which the application is currently running as. This is enabled by adding integratedSecurity=true; into the connection string properties. If you run into any trouble, make sure the sqljdbc_auth.dll is accessible via classpath or within your app library.
Security Note
You're probably already aware, but just have to say make sure not to grant access to "Authenticated Users" to your database as previously suggested as part of the demonstration. Identify which user account your application runs as and grant access to only that specific user in your database server.
Sources / Additional Info
MSDN Doc on JDBC Connection String Configuration (http://technet.microsoft.com/en-us/library/ms378428(v=sql.110).aspx)
The main problem is the windows authentication with a full java solution (no DLL). So you could use one of the libs below:
NTLM authentication: http://ioplex.com/jespa.html
spring based Kerberos authentication: http://projects.spring.io/spring-security-kerberos/
another integrated windows auth lib is SPNEGO (don't know much about this one)
So once your app is authenticated with one of the lib above, your JDBC should run fine using "integratedSecurity=true;" and if needed "authenticationScheme=JavaKerberos".
Firstly you should write the jdbc connection like this:
String url ="jdbc:sqlserver://PC01\inst01;databaseName=DB01;integratedSecurity=true";
then
you need to enable the SQL Server TCP/IP Protocol in Sql Server Configuration Manager app. You can see the protocol in SQL Server Network Configuration.
I can see two possibilities,
1. You are using a local system account which the server won't understand
In this case, switch to a domain account.
Windows authentication has different credential requirements and you might not be meeting those.
In this case try changing the password to match the requirements.
It is very well possible that both are happening.
see this other SO post that describes how to connect to a SQL Server with Windows Authentication from a Linux machine through JDBC
This is my NiFi setup for jTDS driver:
Database Connection URL: jdbc:jtds:sqlserver://192.168.1.189:1433;DOMAIN=domain_name
I didn't need to add useNTLMv2=true, but most people need to, so if it doesn't work you can try also:
jdbc:jtds:sqlserver://192.168.1.189:1433;DOMAIN=domain_name;useNTLMv2=true
Database Driver Class Name: net.sourceforge.jtds.jdbc.Driver
Database User: domain_user_name (**without** #domain)
Password: domain_password
Validation query: select 1
One of the possible reasons for this error to appear is when you configure you data source to use windows authentication and SQL Server is using Extended Protection mode together with SSL (i'm not sure if SSL is required though). This mode requires the client to send additional information - signed service principal name (SPN) and channel binding token (CBT). See more information about Extended Protection Mode here. Currently both JTDS JDBC and Microsoft JDBC drivers do not support this mode. I couldn't find an official statement from JTDS, but there is an open ticket for Microsoft drivers.
In order to configure Extended Protection mode, go to SQL Server Configuration Manager, select properties on SQL Server Network Configuration -> Protocols for %your instance% and change Extended Protection option.
I have always thought that in order to connect to SQL server using windows authentication with explicitly specified credentials, you must LogonUser, Impersonate, then connect.
It seems to me that this link suggests that it's possible to connect to SQL server without all this hassle, simply by specifying "uid=...;pwd=..." in connection string. I tested this method just to be sure it doesn't work, and - lo and behold - it didn't. If that blog post wasn't on msdn.com, I would have just dismissed it as noob talk, but it is.
Does anyone have an idea what am I missing?
EDIT1: Many respondents misunderstood what I was referring to. Here's a copy/paste of what I was talking about. It's not integrated SQL, nor it's an ASP.NET impersonation made by IIS:
string sql4 = String.Format(
#"Data Source={0};Integrated Security=SSPI;uid=<uid>;pwd=<pid>", server);
// Database + Windows Authentication + Username/Password
There are two distinct kinds of security with SQL Server. "Windows Authentication", and "SQL Server Authentication". When you see uid and pwd you're seeing the latter. The uid in this case is not a Windows principal - the OS knows nothing about it.
So the answer to your question is, no, you can't pass Windows user name and password in the connection string to log in to SQL Server.
It depends - if you connect from a command-line or Winforms app DIRECTLY to your SQL Server, you EITHER specify "Integrated Security=SSPI;" and then use your Windows credentials as logon credentials, OR you specify "user id=....;pwd=....." - but that's then a SQL logon - NOT your Windows logon.
You mention "impersonate and then connect" - that seems to indicate ASP.NET - that's a totally different story again. If you impersonate, then you're basically using your Windows credentials, e.g. the web server will "impersonate" you and log on as you (using your Windows credentials). In that case, again, no "uid=....;pwd=....." needs to be specified (if it is, it will be ignored).
As that link you mentioned clearly shows - if you can connect directly, and you specify "Integrated Security=SSPI;", then this takes precedence over any uid=...;pwd=.... which you might also specified and logs you in using your Windows credentials; those extra uid=...;pwd=.... pieces are ignored.
Marc
The article and point in question relates to SQL security, not integrated security. You can pass the credentials for a SQL user and log in in this manner if SQL authentication (mixed mode) is enabled. If the SQL server is set up to use integrated security only then this will not work. It will also not work to allow logging in using Windows logon credentials.
In our shop, we routinely use connection strings like you describe. No problemo. But your sql server database must be set up to use sql security, not windows authentication.
A sample connection string (from web.config) in our app looks like:
<connectionStrings>
<add name="ConfigurationData" connectionString="server=DevServer;
database=travel_expense_management_dv;uid=userid;pwd=password!;"
providerName="System.Data.SqlClient" />
</connectionStrings>
On the other hand, the DBA guru for our shop set me up a personal database on the main server that had integrated security with my Windows logon. I didn't need uid and pwd because it took my authentication info from context.
Yes, as you say, the article mentions this:
string sql4 = String.Format(#"Data Source={0};Integrated Security=SSPI;uid=<uid>;pwd=<pid>", server); // Database + Windows Authentication + Username/Password
But if you carefully read few lines later, it says this:
string sql4 -> Logs in with Windows login, ie. takes precedence over the username/password.
:)
This is very old but maybe someone has the same issue.
You can connect using WindowsAuthentication and specifying user id and password on your connection string, but not on every device. You can achieve this for example on WinCE devices (https://technet.microsoft.com/en-us/library/aa275613(v=sql.80).aspx).
I don't know if you can do the same thing on other OS just with the connection string (without doing the impersonation thing).
Hope it helps.
just a contribution also for some who was still encountering problem like this. Based on my experience if you don't specify any user/password in you connectivity it will automatically connect to db using windows authentication. Meaning it will get the userid and it's credential of the user who logged on to the machine. The system will allow you to connect to database if it identifies that your userid exist/created in the database. But once you specify your userid and password in your connectivity it bypass the windows authentication and use sql server authentication instead.