Using SSIS for SQL Server (2012 or later) Standard Edition, I want to connect to a remote Oracle database using Windows authentication.
In my tests, this works fine when using sqlplus:
sqlplus /#MyRemoteConnection
In SSIS (using either ADO.NET or OLE DB Connection Managers), the connection
succeeds when specifying the user id and password.
The connection fails when specifying the "/" user (without a password) in the SSIS connection.
Is authentication through Windows supported at all for SSIS connections to Oracle?
If yes, how do I do this?
If Windows authentication is not supported, are there other tools which allow me to connect from SQL Server Standard Edition (that's why e.g. Attunity cannot be used)?
All suggestions are highly appreciated!
Yes, Windows authentication from SQL Server Standard Edition to Oracle is supported.
A valid ADO.NET connection string (e.g. using Visual Studio (SSIS), or the Import Wizard in SQL Server Management Studio) may look like this:
Data Source=<host name>:<port number>/<database name>;Integrated Security=SSPI;
An example:
Data Source=my_host_name.com:1521/ORCL;Integrated Security=SSPI;
For Windows Authentication, "Integrated Security"
needs to be set to "yes", "True" or "SSPI".
A valid OLE DB connection string looks like this:
Data Source=<host name>:<port number>/<database name>;User ID=/Provider=OraOLEDB.Oracle.1;
Example:
Data Source=my_host_name.com:1521/ORCL;User ID=/Provider=OraOLEDB.Oracle.1;
Please note:
The port number is optional and can be omitted if the standard port number (normally 1521) is used.
When using SSIS, the Connection Manager may complain with the message
"The given path's format is not supported."
This happens if the port number is specified in the connection string.
The connection string (including the port number) will work nevertheless, if the connection string is filled by a variable in an expression.
Further requirements:
On the file system (both on the client and the server), there has to exist a file sqlnet.ora.
This file has to contain the string
SQLNET.AUTHENTICATION_SERVICES= (NTS)
On the database server, and when using a full Oracle client,
the file sqlnet.ora should be located in the ORACLE_HOME\Network\Admin directory.
ORACLE_HOME normally is defined in the registry, under
HKEY_LOCAL_MACHINE\SOFTWARE\ORACLE
If an Instant Client has been installed, the file sqlnet.ora can be put in the "network\admin" subdirectory under the directory where the Instant Client is located.
Please note that the Instant Client will not look into the registry to use (or evaluate) ORACLE_HOME.
Therefore sqlnet.ora files located there won't be read when trying to connect to the Oracle server!
(That's the reason why my connections failed all the time.)
Another option is to specify a directory for sqlnet.ora by setting the environment variable TNS_ADMIN, e.g. in the Windows Control Panel.
Example:
TNS_ADMIN=C:\TNS_ADMIN
Then, put the file sqlnet.ora into this directory.
On the Oracle server, the Windows user needs to exist.
Example:
create user "OPS$MYDOMAIN\MY_USER_NAME" identified externally;
grant create session, alter session to "OPS$MYDOMAIN\MY_USER_NAME";
(additional privileges may be required.)
Then it should be possible to connect to Oracle as Windows user MY_USER_NAME,
using Windows Authentication.
Related
I need to connect to a remote database (Oracle) using a MS SQL Server (2019) linked server. What I did so far:
Installed Oracle Instant Client x64 and the ODBC drivers on the machine where the SQL server is running
Created a symlink to the central TNSNAMES.ORA (on a file share in the network) inside the Oracle Instant client folder.
Set the necessary environment variables
Created an ODBC connection to the database on the Oracle server on this machine
Restarted MS SQL Server
Created a linked server (Microsoft OLEDB Provider for ODBC Drivers) in the SQL instance
When connecting to the SQL Server using sqlcmd on this machine (I did not install SSMS there), I can query the linked database using OPENQUERY(). I can also read the file TNSNAMES.ORA using this command (note, the given file is the symlink, but it displays the contents of the linked file, as it should):
SELECT * FROM OPENROWSET(BULK 'C:\InstantClientx64\tnsnames.ora', SINGLE_CLOB) TNSNames
So far, everything is fine.
Now, when I connect to the SQL Server from my workstation using SSMS, i get the following error when trying to read TNSNAMES.ORA using the command above:
Cannot bulk load because the file "C:\InstantClientx64\tnsnames.ora" could not be opened. Operating system error code 5(Access is denied.).
I created a file test.txt in the instant client folder containing something like "Am I allowed to read this?" - and I was, no problems.
I started procmon on the server to find out what happens. When using the above command on the SQL server, I get a REPARSE (because it's a link!), and then SUCCESS, the file is displayed in the sqlcmd console.
When using this command in SSMS (on my local workstation), first appears the REPARSE (OK), then ACCESS DENIED.
In both cases it is the same user account which is displayed as "Impersonating" in the procmon's details. There is definitely no problem with a firewall, and the read permissions on the tnsnames.ora file on the network share are granted for Everyone. I am also able to create an ODBC item on the local workstation, and can connect and query the database from here.
I have done this in the past I don't know how often, and never had problems. What am I missing?
Why are you trying to read the tnsnames.ora file via SQL? The Oracle libraries will (should) internally open it and use it when your app connects to the DB.
The default location for network config files is shown in the Instant Client installation doc. In your case it will be C:\InstantClientx64\network\admin. Unless you have set the TNS_ADMIN variable, then start by creating this subdirectory and putting tnsnames.ora in it.
(A future version of Instant Client on Windows will create the network\admin subdirectory automatically, similar to the way it is created with the Linux Instant Client packages).
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.
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.
While making a database connection in pentaho report designer using JDBC, I am getting the following error :
Error connecting to database [database_name] : org.pentaho.di.core.exception.KettleDatabaseException:
Error occured while trying to connect to the database
Error connecting to database: (using class net.sourceforge.jtds.jdbc.Driver)
Network error IOException: Permission denied: connect
org.pentaho.di.core.exception.KettleDatabaseException:
Error occured while trying to connect to the database
I can't comment unfortunately, and without more information my answer will be a shot in the dark, therefore I will attempt to describe the perfect connection that you can use to connect to SQL Server 2008 via JTDS.
Put the jar that came with the JTDS package here: pentaho\report-designer\lib\jdbc.
If you wish to take advantage of the Windows Authentication, also grab the ntmlauth.dll file and put it in either System32 (for 64 bit Windows) or SysWOW64 (for 32 bit Windows, that's up to your configuration*). Fire up report designer.
New database connection:
Give it a connection name.
Set connection type to MS SQL Server, Native JDBC connection. The "MS
SQL Server(Native)" connection did not work for me.
Host name: the server's name where the Database sits. Server1, for
example.
Database Name: Take a wild guess what this might be. Yup, here you
enter your database name. Northwind, for example.
Instance name: Instance name, if you have any. Not mandatory.
Port number: default SQL server port is 1433.
User name / password: define one that has access to the database.
Leave it blank if you listened to me earlier and put the .dll file in
the right directory to use Windows Authentication.
Rejoice.
IN CASE you ever need the connection string and driver for SQL server connection:
driver: net.sourceforge.jtds.jdbc.Driver
URL (or string): jdbc:jtds:sqlserver://HostName:1433/databaseName
*let's not get caught up on the obviously challenged naming convention. I know, I know.