I am trying to create / modify a system data source for my application which needs to connect to our Microsoft SQL Express 2014 database through an ODBC data source.
The connection used to work before we enabled the SSL encryption flow but,
now that we have an encrypted link, the connection does not work anymore.
Here are some details:
We run Microsoft SQL Server express 2014 SP1 with the latest cumulative update (CU #3) (which was necessary so that we could deactivate SSL 3.0 and TLS 1.0 and run only with TLS 1.1 and TLS 1.2)
The database instance is a named instance, configured to run with a TCP/IP connection and a fixed port.
We enabled the "Force Encryption" option and configured the certificate through the "Sql Server Configuration Manager"
We can successfully establish a connection to the database either using Management Studio or the SQL command line utility
We disabled all usage of SSL/TLS prior to version TLS 1.1 done through Microsoft Schannel. This required us to update SQL Express 2014 SP1 to the latest cumulative update (CU #3)
The ODBC data source we try to configure (through ODBC data source Administrator) is a "System DSN" and uses the "SQL server" driver and target the exact same server name as the one working in management studio (and whose server name corresponds to the machine FQDN which is reflected in the certificate CN value)
The Version indicated for the SQL Server ODBC driver is "Microsoft SQL Server ODBC Driver Version 06.03.9600"
I am testing the connection directly through the ODBC data source Administrator tool.
The first test I runs are run on the exact same machine as the one hosting the database server.
We get two consecutive error message in the Microsoft SQL Server Login:
Connection failed:
SQLState : '01000'
SQL Server Error: 771
[Microsoft][ODBC SQL Server Driver][TCP/IP Sockets]ConnectionOpen(SECDoClientHandshake()).
Connection failed:
SQLState : '08001'
SQL Server Error: 18
[Microsoft][ODBC SQL Server Driver][TCP/IP Sockets]SSL Security error.
I went through all the literature I could find but cannot find a solution.
EDIT 27/01/2016 16:30
Following erg suggestion, I tried to use the last MS SQL Server Native Client version (11.00.2100 on my system), but it still does not resolve the issue. I experience another issue though (whether or not I force the strong encryption on the client side results in the same error):
Running connectivity tests...
Attempting connection
[Microsoft][SQL Server Native Client 11.0]TCP Provider: An existing connection was forcibly closed by the remote host.
[Microsoft][SQL Server Native Client 11.0]Client unable to establish connection
TESTS FAILED!
So, I finally got it working after struggling a little bit more.
First of all, it appears that there is another CU available (CU4) for SQL Server Express 2014 SP1.
I did download it and install it, but it did not resolve my problem: as soon as I deactivated TLS 1.0 and below version ODBC did not work.
Strangely, though the CU3 and installation of .NET 4.6 allowed me to successfully log in in Management Studio, when I tried to execute
the xp_readerrorlog query, it actually failed.
What I did to solve my issue was to follow malthus's answer on another related stack overflow question
https://dba.stackexchange.com/questions/93127/sql-server-service-won-t-start-after-disabling-tls-1-0-and-ssl-3-0 (3rd answer from the top).
I therefore activated the local security policy on my computer and managed to get the links to my SQL db working.
Now, I got IIS working along my own service and client working.
BTW, if somebody needs a more user friendly way of activating SSL/TLS version(s) and cryptographic algorithms on Windows, I stumbled uppon a nice GUI application which does not required to use regedit for it:
https://www.nartac.com/Products/IISCrypto. It's free and I am not a a Nartac Software employee, manager or shareholder.
I hope this will help!
EDIT Feb 25, 2016
It looks like the latest cumulative update (CU5 available at
https://support.microsoft.com/en-us/kb/3130926) removes the need to
activate the FIPS option for the System Cryptography.
I discovered this since I had to deactivate FIPS to enable another required
functionnality while still relying on a TLS 1.2 connection. Indeed, it
appears that activating the FIPS option for the System Cryptography prevents
.NET Framework to successfuly make use of some system algorithms (such as
SHA256Managed).
In addition, according to some discussions seen around the web (i.e.
http://blogs.technet.com/b/secguide/archive/2014/04/07/why-we-re-not-recommending-fips-mode-anymore.aspx)
it is not recommended to activate FIPS (except to strictly comply with
some governmental recommendations) since it breaks applications
relying on non-FIPS validated implementations of cryptographic
algorithms, which, however are provided in Microsoft system libraries.
Related
We're using "Always Encrypted" feature in SQL Server to encrypt a few columns. Encryption works fine on MVC/SQL side. Only issue we have is with the SQL reporting server. Able to run the reports when the data source connection string is
Server=mssqlserver;Database=MYDATABASE;Integrated Security=true
But when I try to run the reports from the MVC application, it automatically adds the Column Encryption Setting=enabled to the connection string
Server=mssqlserver;Database=MYDATABASE;Integrated Security=true;Column Encryption Setting=enabled
When I enter the credentials and click 'Test Connection', it throws an error
Keyword not supported: 'column encryption setting'
Because of the above error, it cannot make a connection to the data source 'MYDATABASE'. Tried giving permission to the reporting server service account and the account used
to connect to the database to access the keys to encrypt/decrypt but no luck. How can I fix this issue? We're using SQL Server 2017.
This error is to do with the version of SSRS you are running. Under the covers, SSRS uses .net framework to connect to data sources. This version does not understand the keyword provided.
From the screenshot it looks like SSRS 2008R2, this targets .net 3.5. Always Encrypted (AE) is not supported until 4.6 (SSRS 2019). As far as I am aware you cannot change SSRS's target framework.
To get around this issue I suggest either:
1. Install an alternate data source provider that supports AE (i.e. Microsoft ODBC Driver for SQL Server 17.4 or above), then update the data source's connection string to use this
2. Upgrade SSRS to 2019
Hope this helps
I searched through all threads on the web available, but none could help me.
I am trying to connect to SQL Server engine from SQL Developer. In order to do that I enabled Named Pipes and TCP/IP from SQL Configuration Manager.
Then I tried different drivers:
I tried Microsoft JDBC driver for SQL Server - I cannot choose in connection manager SQL Server database type, so it does not work..
I tried jTDS driver instead, and it worked - I can choose SQL Server database type, but then all I get is an error informing that it cannot connect to Microsoft SQL Server on localhost (I tried localhost, name of my computer, none of which worked).
Is there anything more I can do?
EDIT
This is what I have so far:
SECOND EDIT
I had more problems:
With error saying
Status: Failur-I/O Error: SSO Failed: Native SSPI library not loaded. Check the java.library.path system property
Using windows authentication, I still got asked for username and password.
(All details and solutions in my answer below)
We only support the jTDS driver for SQL Server and Sybase ASE connections, so that's the way to go.
After that, it's up to you to get a correct connection string to your SQL Server system.
Make sure you have the right port in addition to your 'localhost' network location for your SQL Server instance.
This is using version 19.1 of SQL Developer to connect to a SQL2012 instance overseas..
Actually there were more problems, which I'll post here along with solutions:
In order to ba able to connect SQL Server database type from SQL developer it is needed to install jTDS driver, as already mentioned. Other types are not supported by SQL Developer.
Next thing was to configure with SQL Configuration Manager (the easiest way IMO) SQL Server to listen on IP port 1433, not dynamic, as was previously set. In order to do that in configuration manager I had to go to SQL Server Network Configuration and make appropriate changes. More here.
Next I had problem:
Status: Failur-I/O Error: SSO Failed: Native SSPI library not loaded. Check the java.library.path system property
Which was the fault of missing file, solution was placing file ntlmauth.dll to the /jdk/bin in SQL Developer directory.
I chose Windows authentication, which apparently is not supported by jTDS, so I needed to create user in SQL Server, which I use to connect SQL Server from SQL Developer.
After all that, I had it working.
I have an IIS web application which connects to a SQL Server like this:
set objConn = Server.CreateObject("ADODB.Connection")
objConn.Open("DRIVER={SQL Server};SERVER=servername;DATABASE=dbname;UID=username;PASSWORD=pwd)
Recently I started getting the following error:
[Microsoft][ODBC SQL Server Driver][DBNETLIB]SSL Security error
When I asked my server admin what this meant, he said that they had recently removed TLS 1.0 from the IIS server my web application is mounted on. He made sure the new SQL ODBC 13 drivers were installed on the web server, but it did not help.
Although the web app has never had a DSN before, we created one for it using the ODBC 13 driver. When I tried connecting like this:
objConn.Open "DSNname"
I got the following error:
[Microsoft][ODBC Driver Manager] The specified DSN contains an architecture mismatch between the Driver and Application
I looked up ConnectionStrings.com to see if there were a way of specifying a different driver. I tried this:
objConn.Open("DRIVER={SQL Server Native Client 13.0};SERVER=servername;DATABASE=dbname;UID=username;PASSWORD=pwd)
And this is the error message that was produced:
[Microsoft][ODBC Driver Manager] Data source name not found and no default driver specified
Don't know what else to do. Any ideas?
We had to update 3 servers that are running several Classic ASP websites. The main reason was we need to implement Twillio API SMS messaging wich required TLS 1.0 and TLS 1.1 to be disabled/removed.
It took several days and we had the websites go up and down through the process.
I wrote a blog post to document the process for other team members. I hope it helps.
https://dhali.com/programming/tls-1-2-with-classic-asp/
Here are the outlined steps:
https://www.ssllabs.com/ssltest to get the current TLS Configuration
Using IISCrypto Tool we updated the Registry Files on the server
Ran https://www.ssllabs.com/ssltest to prove TLS 1.0 and 1.1 removed
Update ODBC to the latest ver supports TLS 1.2 [Microsoft® ODBC Driver 13.1 for SQL Server]
Update the connection string to use the current ODBC SQL 13 driver
The specified DSN contains an architecture mismatch between the Driver and Application
You can create either a 32bit DSN or a 64bit DSN. You need to create one matching the bitness of your program. Probably 32-bit.
Is there any relation between TLS_RSA_WITH_AES_128_GCM_SHA256 cipher and SQL Server?
When TLS_RSA_WITH_AES_128_GCM_SHA256 is disabled, ASP.NET application cannot connect to SQL Server. Although SQL Server is still running, SQL Server Management Studio also cannot connect to database. The following error is shown in SSMS.
A connection was successfully established with the server, but then an error occurred during the login process. (provider: SSL Provider, error: 0 - No process is on the other end of the pipe.) (.Net SqlClient Data Provider)
Read TLS 1.2 support for Microsoft SQL Server, identify the SQL Server version you use, download and apply the relevant components from the article linked, try again:
Use the following table to determine whether your current version of SQL Server already has support for TLS 1.2 or whether you have to download an update to enable TLS 1.2 support. Use the download links in the table to obtain the server updates that are applicable to your environment.
As a result of TLS 1.0 being phased out, we're starting to implement additional security on our servers. Primarily, explicitly disabling TLS 1.0 client and server (and SSL 1/2/3), and explicitly enabling TLS 1.2 and 1.1. In addition, we're restricting the ciphers available for use when connecting over TLS 1.2/1.1.
We followed the article Remus posted to the letter (https://support.microsoft.com/en-us/help/3135244/tls-1-2-support-for-microsoft-sql-server), and used additional resources to ensure we weren't missing anything (this was a good one: https: //blogs.sentryone.com/aaronbertrand/tls-1-2-support-read-first/). We also forced .NET Framework to use TLS 1.2->1.1->1.0 search order by adding the SchUseStrongCrypto registry keys on our servers (https://technet.microsoft.com/en-us/library/security/2960358.aspx).
Despite the above, we were unable to connect to SQL 2014 or SQL 2016 instances on a Windows Server 2016 environment when attempting to connect from a Windows Server 2012 R2 environment. We had a SharePoint installation in Windows 2012 R2 that was unable to connect to its database, and we were unable to connect to the instances with SSMS on this same server. Connecting via SSMS from a Windows 10 or another Server 2016 installation worked. Here's the error we were getting:
sql server Error Number: 10054 Severity: 20 State: 0
A transport-level error has occurred when sending the request to the server. (provider: TCP Provider, error: 0 – An existing connection was forcibly closed by the remote host.)
Once we allowed a TLS_RSA cipher for use on both servers, we were able to connect (didn't matter which cipher we used, we used the first one in this list):
TLS_RSA_WITH_AES_256_GCM_SHA384
TLS_RSA_WITH_AES_128_GCM_SHA256
TLS_RSA_WITH_AES_256_CBC_SHA256
TLS_RSA_WITH_AES_128_CBC_SHA256
TLS_RSA_WITH_AES_256_CBC_SHA
TLS_RSA_WITH_AES_128_CBC_SHA
I'm unable to find any resource which explicitly states which ciphers are required for communication to SQL Server, I'm assuming the above list isn't comprehensive. I'd like a definitive resource of some sort, but wanted to post this in case it helps someone.
My server is windows 2008 server r2.
I found the following error on my server after disable tls 1.0 and SSLv3.
[DBNETLIB][ConnectionOpen (SECCreateCredentials()).]SSL Security
error.
Currently, only TLS 1.2 is enabled on my server, and at the client side the TLS 1.2 is set on
Is it posible if [DBNETLIB] is running on TLS 1.2?
There might be chances that ODBC 11.0 earlier version is been installed. In this case the connection string should be
Driver={ODBC Driver 11 for SQL Server};Server=myServerAddress;Database=myDataBase;Trusted_Connection=yes;
And also check TLS 1.2 is enabled
After disabling TLS 1.0 and 1.1 on Windows Server 2016 we were able to get our ASP Classic scripts database connections working again in the following way:
Download and install Microsoft OLE DB Driver for SQL Server (MSOLEDBSQL)
Replace Provider=SQLOLEDB; with Provider=MSOLEDBSQL; in all connection strings for the ASP Classic scripts
Done! (no restart needed)
Note: The previous (same name but different abbreviation) Microsoft OLE DB Provider for SQL Server (SQLOLEDB) and SQL Server Native Client OLE DB provider (SQLNCLI) remains deprecated and it is not recommended to use either for new development work. (source)
I had to do several things. The server was Windows 2016 Standard testing with a .txt file I changed to .UDL. This server was trying to connect to our Sql Server 2008 R2 SP3
On the 2016 box I installed SQL Server Native client 10.0
Get that here : https://www.microsoft.com/en-us/download/details.aspx?id=57606
Finally on the sql server box I had to install patch KB4057113 to enable TLS1.2
Note when testing the connection by opening the .UDL file don't forget to change the provider to SQL Server Native Client 10.0
Similiar to Jonas Appelgran's answer, but some slight changes to solve our issue.
Download and install install Microsoft OLE DB Driver for SQL Server (MSOLEDBSQL)
Replace Provider=SQLOLEDB; with Provider=MSOLEDBSQL19; in all connection strings for the ASP Classic scripts (note the version of the driver was needed)
At this point, was still getting the following error:
SSL Provider: The certificate chain was issued by an authority that is
not trusted.
After some research, I found that I also needed to either trust the server certificate or set the encryption to false in the connection string:
Trust Server Certificate=True;
and/or
Use Encryption for Data=False;
Need to update these depending on your situation but it was an internal intranet application only for us so either option was fine. (Otherwise you would need to create and install either a self-signed certificate or one from your organization's CA.)
Open Regedit (Wind+R > regedit)
Locate HKLM\SOFTWARE\Microsoft\MSSQLServer\MSSQLServer\SuperSocketNetLib
Create a new word value and name it "Certificate" set the value to this: "Certificate=0"
Also modify the default REG_SZ and set the value to "Certificate=0"
Restart the MSSQL service
Hope this helps since worked for me.