In the infrastructure we've got following machines:
1. Websphere application server (on SUSE Linux Enterprise Server 12 SP4)
2. DB2 server (on SUSE Linux Enterprise Server 12 SP4)
Customer wants to deactivate the TLS 1.1 and below everywhere within the infrastructure.
I know where to disable it in WAS Admin console on server 1, but I don't know where to disable it in other places. Please advice. Thank you!
You need to set the Db2 instance configuration parameter ssl_versions to TLSv12. For example, when using the command line processor, while logged in as the instance owner:
db2 update dbm cfg using ssl_versions TLSv12
You will need to restart the instance for the change to take effect.
Reference
Related
I am developing a web application that has to be connected with the ORACLE database.
Presently I am working on macOS X and I have downloaded Oracle Instant Client.
I am able to run sqlplus, but while logging in the interface I get the following error:
SQL*Plus: Release 12.2.0.1.0 Production on Sun Jul 8 10:55:48 2018
Copyright (c) 1982, 2017, Oracle. All rights reserved.
Enter user-name: hr
Enter password:
ERROR:
ORA-12541: TNS:no listener
For your information, I have downloaded nothing except the client software by Oracle and installed it according to the official installation documentation.
I really need to work on sqlplus for the database.
PLEASE HELP.
Also, could you please tell me how can I use sqlplus in my machine?
Instant client does not provide you with a Oracle database to work with, they are just tools to connect to a database.From the documentation of Instant Client
Oracle Instant Client enables applications to connect to a local or
remote Oracle Database for development and production deployment. The
Instant Client libraries provide the necessary network connectivity,
as well as basic and high end data features, to make full use of
Oracle Database.
So, prior to using an instant client, you need to have an Oracle database somewhere(local or remote).If you have a database server on a remote host, you may connect it using the easy connect syntax.
sqlplus user/pwd#//remote_hostname:1521/remote_dbname
If you have a tnsnames.ora file in your $TNS_ADMIN preconfigured to contain the list of database instances available, you may simply use this to connect
sqlplus user/pwd#tns_entry_for_DB
Putting the tns entry in command line also works.
sqlplus user/pwd#(DESCRIPTION=(ADDRESS=(PROTOCOL=TCP)(Host=remote_hostname)(Port=1521))(CONNECT_DATA=(SID=remote_dbname)))
Moreover,Oracle doesn't provide you database software versions beyond 10gr2 to install locally on a Mac.
If you want to install and connect to a local database version 12.2 in Mac, One option is to host a virtual machine for Linux/Windows or run a docker container. Please read my post here for details: Oracle SQL for Mac OS X
I have a Red HAT system on oracle virtual box that I've been trying to set a mssql server up.
-Also tried doing everything on SUSE vm but I've been probably doing the same thing wrong on that one aswell.-
I have the server up but was unable to connect the mssql server in linux from windows terminal or SSMS.
Get this as a terminal response on windows
ODBC Driver 13 for SQL Server does not support connections to SQL Server
2000 or earlier versions.
and below one on SSMS
Not associated with a trusted server connection
Not sure if I have some network configuration info wrong on vbox myb?
Might be using the wrong ip addr trying to connect aswell.
I use localhost to connect on virtual box.
Tried to connect by localhost ip, public ip and
sudo ip addr show eth0 | grep "inet"
command as well.
Any idea what could be the issue since I am quite sure both the sql server versions are up to date.
Solved upon changing network attached to on virtual box settings to bridged adapter with promiscuous mode on.
In case anyone gets stuck on this
Trying to setup an ODBC connection for UPS to access our SQL server, from our shipping client computer.
I have scoured as much as I can an ran across:
runas /netonly /user:domain\account "c:\windows\system32\odbcad32.exe"
Now, using this method, on my current client computer, I was able to setup an odbc connection successfully using SQL Native Client 11 (5058). I am using Win 10. Our shipping computer, with multiple manifest systems on it, is still using Win 7, but otherwise is setup the same on the domain.
Using the same process as above, the connection ultimately times out, and states that the server is not online/not available/not allowing remote connections.
Is there a step I'm missing? Both clients have same rules for firewall, both are using the same user/password in the runas cmd. The only difference between the two clients is Win 10 vs. Win 7, and the current logged in user is different (but that shouldn't matter with the runas cmd?)
Thanks!
So after several days/hours of trying various solutions and suggestions from all over the interwebs, I came across this solution/tips.
In SQL Server Configuration, checking the network configuration protocols/clients/aliases. In my case, there was an aliases established for 32-bit, and not 64-bit. I disabled the 32-bit one.
I then found suggestions to us the ip (which I had tried in the past, with no success), but this time, after ensuring all the tcp/ip protocols were enabled and the 32-bit aliases was disabled, I was able to connect the 32-bit to the 64-bit SQL server, using the xxx.xxx.xxx.xxx address of the server.
Test came back successful!
I'm trying to switch off TLS 1.0 on my SQL Server 2012 server in order to comply with PCI standards.
Initially I had some trouble with the SQL Server service not starting.
I've found help online on other sites and discussions but I'm having mixed results:
This is what I've done so far:
I have downloaded SQL Server 2012 Cumulative Update 7 (CU 6 also works) and the SQL Server Service then starts correctly.
I had a problem not being able to sign in to the DB instance through SQL Server Enterprise Manager which was fixed by installing .Net 4.6.
Next problem, client computer running IIS Application is unable to connect to SQL instance because of a 'handshaking SSL error'. I followed advice and installed the latest SNAC native client.
This was difficult to track down and the latest version available as a download from Microsoft was from 2014. I then obtained sqlnclient.msi dated 9/7/2015 revision number {E6CB4138-3D1C-4ADC-95C4-88322B60FC14} from a sub folder generated by the extract of CU 7 - "Path to Extract Folder \1033_enu_lp\x64\setup\x64".
I've updated this version of the Native client on my IIS server (and .Net 4.6) and I'm still unable to connect remotely to the SQL instance. If I enable TLS 1.0 I'm able to connect.
The exact error I'm getting is 'A connection was sucessfully established with the server, but then an error occurred during the pre-login handshake'.
My diagnosis is I don't have the correct version of SNAC on my machine compatible with TLS 1.2 and the CU 7 as the client and server cannot handshake. However, this sqlnclient.msi was extracted from the CU 7 and I cannot find a more up to date copy.
Has anyone else experienced this problem? What version of the SNAC are you using? Where did you get it?
Thanks
As of January 29th, Microsoft SQL Server supports TLS 1.2 for SQL Server 2008, SQL Server 2008 R2, SQL Server 2012 and SQL Server 2014 and major client drivers like Server Native Client, Microsoft ODBC Driver for SQL Server, Microsoft JDBC Driver for SQL Server and ADO.NET (SqlClient).
Blog post about the release: http://blogs.msdn.com/b/sqlreleaseservices/archive/2016/01/29/tls-1-2-support-for-sql-server-2008-2008-r2-2012-and-2014.aspx
List of builds that support TLS 1.2 along with the client and server component download locations (KB3135244): http://support.microsoft.com/kb/3135244
Did you get the client update from the KB (https://support.microsoft.com/en-us/kb/3052468)
Package name: 2012_SP2_SNAC_CU6_3052468_11_0_5592_x64
Download link: http://support2.microsoft.com/hotfix/KBHotfix.aspx?kbnum=3052468&kbln=en-us
What is the provider name in your IIS site?
You will need the KB3052468 update both for the client and the server. They are available on the hotfix download link provided.
I have several servers with SQL Server 2008 R2 instances on them, and alias doesn't work on any of them.
Clients connect to these servers using TCP/IP without any problem, telnet works on IP/Port I use for my alias, the firewall exceptions are created, basically everything works fine, except when I create an alias, I can not connect through it to my server using either TCP/IP or named pipes (local or one of other servers).
I've installed latest cumulative updates, which updates native client too (which I think is the source of problem) and I still have the problem. The stranger part is, if I create an alias on a server with sql server 2005 (native client 9), I can connect to my 2008 r2 instances. Any suggestions?
After you are sure, that it's not firewall problem, TCP/IP problem, and you can connect to server regularly without using alias and only have a problem to connect with alias, I have this problem on Vista and Windows 7.
Solution is to set up proper port inside of "SQL Server Network Configuration" inside "SQL Server Configuration Manager".
Here are the steps:
Go to Computer Management -> Service and Application -> SQL Server Configuration Manager -> SQL Server Network Configuration
Notice that you can also open directly SQL Server Configuration Manager (not from Computer management)
Then in SQL Server Network Configuration, if it is not already enabled, enable TCP/IP protocol.
Right click to open properties of TCP/IP protocol
Then on IP Adresses Tab you will have couple of records.
For every one put TCP Port = 1433
If you use x64 operating system, you have two "SQL Server Network Configuration" nodes, one for 32bit and the other for 64bit. Be sure that you have checked those port on both of them.
Good luck
For me it was the sequence of creating the aliases that was important. See this link: W2K8 R2 SQL Alias will not connect
I started by deleting everything, CliConfig aliases and Configuration Manager Native Client config aliases. Then re-create, adding the CLICONFG version first.
run CLICONFG - create your TCP alias (will default to the x64
version if you're on a 64-bit O/S)
From SQL Server Configuration
Manager create the alias under "SQL Native Client 10.0
configuration"
Try to connect using SSMS - it worked for me. If it doesn't you could go on to try the 32-bit set-up. I did this anyway as the application I'm developing which uses the alias is x86.
%SystemRoot%/SysWow64/CliConfg.exe (32-bit version on 64-bit O/S)
"SQL Native Client 10.0 Configuration (32bit)" under the
configuration manager tool.
For me, the answer was to use the 32-bit CLICONFG. Both Management Studio and the application I was trying to install were 32-bit applications on a 64-bit server. Moral of the story is to create both 64-bit and 32-bit aliases.
Are you using named instances? And if so have you checked that the port is statically assigned?
If you are using default instances are you running on a x64 platform? There are aliases for 32bit and 64bit so SSMS on the same box as the database engine would use the alias under the 32 bit section even though the box is 64bit
For me this was caused by me creating the alias on a 64 bit machine but the software running as a 32 bit application.
When in Sql Server Configuration Manager ensure the alias is set under both the following sections:
SQL Native Client {VersionNo} Configuration
SQL Native Client {versionNo} Configuration (32bit)
That way it will be available regardless of processor platform. Of course if you only want the alias available for one platform for some reason, set the appropriate one and not the other.
Try it with the IP address, like 127.0.0.1 instead of your machine name, localhost or .(dot).
In my case it only worked when I placed the port on the connection [server]\[instance],[port]. Example: DBSERVER\OPERATIONS,1433
Also, check that your alias uses listeners that are enabled (is your alias configured to use TCP while your server is only listening via Shared Memory?)