From Windows using SQL Server Management Studio (SSMS), I can only connect to a SQL Server on a different domain as follows:
C:\> runas /netonly /user:differentDomainName\aUserName "C:\Program Files (x86
)\Microsoft SQL Server\110\Tools\Binn\ManagementStudio\Ssms.exe -S anIpAddress"
How can I accomplish this connection via JDBC? I've tried using the following connection string with Microsoft's sqljdbc 4.2 driver:
jdbc:sqlserver://anIpAddress:1433;database=MAIN;user=differentDomainName\\aUserName;password=pass
I receive the following error:
com.microsoft.sqlserver.jdbc.SQLServerException: Login failed for user 'differentDomainName\aUserName'
This is the same error that I receive if I start SSMS without using runas and typed differentDomainName\aUserName for Login name in the "Connect to Server" dialog box of SSMS 2012.
Additional Information: The JDBC connection will be established within a application running on Linux. So, running the application using runas is not an option unfortunately.
Another attempt:
I've also tried to use jTDS 1.3.1 with the following connection string:
jdbc:jtds:sqlserver://anIpAddress:1433;databaseName=MAIN;domain=differentDomainName;user=aUserName;password=pass
since aUserName is set up only for Windows authentication. Unfortunately, this produces the following exception:
o.a.tomcat.jdbc.pool.ConnectionPool : Unable to create initial connections of pool.
Followed by
java.sql.SQLException: I/O Error: DB server closed connection.
Permission information: I'm unable to modify anything on the SQL Server machine including any configuration within SQL Server. The "aUserName" account maps to a SQL Server read only Windows authentication only user.
When you connect with MS JDBC driver, you don't specify the password for the user (at least not in the connection string you provided). If your intention was to use integrated security, you should indicate this in the connection string, but then you process has to be authenticated already for differentDomainName\aUserName
Integrated security & JDBC:
https://msdn.microsoft.com/en-us/library/ms378428%28v=sql.110%29.aspx?f=255&MSPPError=-2147217396#Connectingintegrated
Since your plan is to access SQL server from linux, I doubt that you could make integrated security work for that scenario, so you should plan to provide the password in the connection string. I'm not sure if you can provide username/password for a domain user in the connection string (I think you can), but if you switch to a user with SQL server auth, it will certainly work. This should be a fallback option, as SQL server auth is less secure.
Related
I have a windows authentication user created on SQL server. I am trying to connect SQL server using that user, but I am getting java.sql.SQLException: The login is from an untrusted domain and cannot be used with Integrated authentication. error.
I am using jtds-1.3.jar. My connection url is jdbc:jtds:sqlserver://xyz.net:1433;instance=dev;databaseName=XYZ;integratedSecurity=true;useNTLMv2=true;domain=XYZ.net
I have checked the connection and traffic is allowed between my client machine and server. I tried setting intgratedSecurity= false as suggested in other answers but that did not work.
What properties of user should I check to know that user is correctly configured on SQL sever for JDBC connectivity?
Finally, got this connection working. It turns out the best way to connect to SQL server using jTDS driver is to create SQL server user avoid creating windows user. And stick to SQL server based user.
The message The login is from an untrusted domain and cannot be used with Integrated authentication can be misleading. For example you can get it by entering the right username with the wrong password.
Without knowing the exact configuration of your SQL server is difficult to say but I would try with a simpler connection string:
jdbc:jtds:sqlserver://xyz.net:1433;databaseName=XYZ
I don't use jTDS directly but the version embedded inside Aqua Data Studio and we don't use named instances but, anyway, I provide the configuration I use with freeTDS in a Linux box as an example of a simple configuration that works perfectly against an cluster instance of SQL Server 2014.
In /etc/freetds/freetds.conf:
[conn1]
host = host.dom.ain
port = 1433
tds version = 7.4
Query from the command line using tsql:
/usr/bin/tsql -S conn1 -U DOMAIN\\USER << SQL_DATA
SELECT getdate();
GO
QUIT
SQL_DATA
Password:
locale is "es_ES.utf8"
locale charset is "UTF-8"
using default charset "UTF-8"
1> 2>
11-11-2022 01:26
(1 row affected)
Someone have success to connect a Dockerized .NET Core API 2.2 with SQL Server located in external client cloud server through Kerberos?
Here we're facing these issues:
Scenario 1:
If we use a connection string like this:
Server=tcp:SERVER_IP_ADDRESS,1433; Database=DB_NAME; User Id=USER; Password=PASSWORD;
then, it takes a long time and throws the exception like this:
SqlException: A connection was successfully established with the server, but then an error occurred during the login process. (provider: TCP Provider, error: 0 - Success)
Scenario 2:
If we use a connection string like this:
Server=tcp:SERVER_IP_ADDRESS,1433; Database=DB_NAME; User Id=USER; Password=PASSWORD; Trusted_Connection=True;
then, the exception is:
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.
ErrorCode=InternalError, Exception=Interop+NetSecurityNative+GssApiException: GSSAPI operation failed with error - Unspecified GSS failure.Minor code may provide more information (SPNEGO cannot find mechanisms to negotiate).
So, our hands are tied and we don't know where to run.
Can u help us?
Thanks in advance.
If you don't need strictly kerberos to authenthicate, just use sql user nad password.
To do that create a user on sql server only (not in windows, use ssms to do it or sql script) and use that user, not the windows one.
It seems that you don't use sql server authentication, at least you don't use sql server user but a windows one and sql server tries to authenthicate that user in AD instead authenticating it locally on sql server.
However if you want to use Windows auth, you probably would need to use windows containers and gMSA accounts, see https://learn.microsoft.com/en-us/virtualization/windowscontainers/manage-containers/gmsa-run-container
My Perl IIS web application is getting an SSL Error when the Perl DBI tries to connect to my MS SQL Server database version 11.0.7001 (that's what is listed in SQL Server Manager). The Perl application runs under IIS, and my IIS Basic User Settings Connection is set to Specific User (Domain Administrator).
The SQL Sever database resides on the same system as IIS. The distribution of Perl is Strawberry Perl; IIS' version is 8.5.9600.16384.
I can connect to the database using the SQL Server Manager locally on the server as well as remotely from my workstation. The connection type is SQL username and password. The IIS application listens on port 8085. The IIS permissions are not restricted, and there is no SQL server connection string as part of IIS.
The first page of the application loads, but this first page does not try to connect to the SQL Server database.
I have been looking at Stackoverflow posts -- like this one -- for a while, and have tried some of the suggestions like making a system DSN (which tests correctly), instead of a DSN string in Perl.
None of the suggestions have helped, and many but not all of the posts are dealing with security and certificates, not an application that is behind a firewall. In other words, I do not have security turned on.
To the best of my knowledge there is no security turned on for this application, and Named Pipes and TCP/IP were already turned on, as was suggested in one of the posts I read.
Here is the error:
[Microsoft][ODBC SQL Server Driver][DBMSLPCN]ConnectionOpen (SECCreateCredentials()). (SQL-01000) at ../../include/DbArgs.pm line 266.
DBI connect('driver={SQL Server};server=arlsql\arlsql;database=BuildingPermit;uid=user;pwd=pwd','',...) failed: [Microsoft][ODBC SQL Server Driver][DBMSLPCN]SSL Security error (SQL-08001) [state was 08001 now 01000]
Any suggestions on what to try next would be appreciated.
Edit 1/6/2020
I need to add that my C# client application using .Net ODBC objects successfully accesses the same database on which the web-based Perl DBI code fails. The username and password are the same for the client application as that used in the Perl CGI.
The IIS user for this application runs as the domain administrator, but when creating the DBI connection uses the same username and password. The database is set up for SQL username and password, and, as stated previously, there is no security set, at least that I can tell.
This does not answer the question but is instead a workaround. I consider the following a workaround, because I would still like to know why the DBI call failed with a specific user.
I switched my IIS Basic User Settings Connection from Specific User (Domain Administrator) to Application User (pass-through authentication).
After making this change and restarting IIS, the Perl DBI connection worked, but why?
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 am trying to connect to SQL Server 2008 from a remote server using 'sa' username and its password (I can log in normally with this username and password from my own computer - so "SQL Server and Windows authentication mode" is chosen).
In the SQL Server log file on my computer I see this error:
Login failed for user 'sa'. Reason: An attempt to login using SQL
authentication failed. Server is configured for Windows authentication
only.
I thought it might be a remote connection problem, so I checked that the remote connection in the properties is enabled, in the configuration manager I enabled TCP/IP and Shared Pipes and restarted the service afterwards and I created a firewall rule for port 1433. I also tried to turn off the firewall in case that it is being blocked somehow, but I got the same error.
How this error appears only when accessing SQL Server from a remote server?
How can I fix it?
From the SQL Server management studio, right click on your server (after connect) in the Object Explorer window and choose Properties.
On Security item, make sure that SQL Server And Windows Authentication mode is selected.
The most obvious solution for me seems to allow SQL Server authentication on the server if it's really necessary to use sa for access (what it should not normally).
To answer the "why" we need more information. Which program do you use to access the server. Is the connection string really identical for both accesses?
Just guessing: From your local machine you use integrated security=true somehow (which causes user and password to be ignored), and your local windows user is allowed to access the server. From remote you use integrated security=false so that you can't logon using user/password, as the server is configured to only accept Windows authentication.
I had the exact same problem today. I was not able to connect to SQL server remotely using username/password, but it worked with windows authentication, and logging in locally also worked.
The reason it didn't work here was that I was using a password that was too short on the sa user. Apparently it does enforce password policy if logging on locally, but remote connections are blocked.
You can either change the password to a longer/more complex one, or disable the password policy enforcement for the sa user.
Short how-to:
In SQL Server Management Studio, open Security -> Logins, find "sa" -> Properties -> Change password or uncheck this box:
In my situation, I have SQL Server 2008 and SQL Server 2012 installed. So, in server name field, I need a concrete name (for example: 10.141.133.125\SQLServer2012). That's it!
Hope this useful for you!