This may well be a stupid question, but regardless...
If I use Sql Management Studio to connect to a remote database using a SQL user/password (outside of our network) - how secure is this connection? Is data encrypted when it is transferred?
This is a great question.
By default, there is no encryption between you and the server. However, you can configure the sql server to accept encrypted connections.
If you've ever set up IIS to use https with a local certificate, the process is very similar. Create a certificate on the server, export the cert to your machine and install. Click connect, select your server, click options and check encrypt connection.
Read more here:http://msdn.microsoft.com/en-us/library/ms191192.aspx
Related
I have a client for which I am setting up a new SQL Server Express and (on a different computer) connecting their Access front end to that SQL Server. I created an account on SQL Server, changed authentication to SQL Server. I am able to log on to that account with no issues locally (through SQL Server Management Studio) on the server itself, but when I go back to the client machine and try to create either an ODBC connection or connect directly in Linked Table manager, I get the error below. Looking at the error log in SQL Server I can see no failed logins. In Access and/or ODBC I use Servername\SQLEXPRESS, choose SQL authentication and type in the username/password that I created. But it's still being stubborn.
I'm kind of at my wits end with this one. I checked to make sure that login is enabled, that the created database is mapped to this user, but I'm out of answers. Anyone have any ideas? I'm sure it's something really stupid that I'm overlooking, I've used SQL Server for a long time but I'm not an experienced DB Administrator I'm sure it's something really simple I'm overlooking, but I've done this hundreds of times before. And Windows Authentication won't work because it's on a different computer.
To connect to a named instance on SQL Server Express with Servername\SQLEXPRESS, you need:
SQL Server Browser service running,
and its UDP port 1434 open in the firewall.
https://learn.microsoft.com/en-us/sql/sql-server/install/configure-the-windows-firewall-to-allow-sql-server-access
SQL Server Browser service
UDP port 1434
The SQL Server Browser service listens for incoming connections to a named instance and provides the client the TCP port number that corresponds to that named instance.
The fixed TCP port for your instance open in the firewall.
You set this in SQL Server Configuration Manager
https://learn.microsoft.com/en-us/sql/database-engine/configure-windows/configure-a-server-to-listen-on-a-specific-tcp-port
This looks more like a network setting rather than server issue.
Check if all necessary permissions, configuration and settings on your machine running the server are OK to accept external connections.
Usually its the server that is rejecting the connection for security reasons.
I'm attempting to remotely connect to my SQL Express 2016 server through MS SQL on my local machine however am having extreme difficulties with the authentication.. Well I assume it is an authentication issue as when I attempt connect to connect to it I receive the error message:
The remote computer refused the network connection.
When connecting through the sqlcmd I am using Windows authentication and have no issue, however to connect to it remotely I need to use SQL authentication and have no memory of creating an account so am wondering if there's a default login and password?
I believe this is the issue however it is quite likely i'm doing something stupid so any assistance would be appreciated!
You can create an account that can be used to connect to that SQLExpress instance by using SQL Server Management Studio. Expand the database you wish to create a login for in the Object Explorer. Under the Security folder, you can create a new login by right clicking the Logins folder.
Also make sure that your machine has its firewall configured to allow remote connections, the server has remote connections enabled, and that you are allowing logins for Windows Auth and SQL Server Auth.
You can allow remote connections for a server by opening the SQL Server Configuration Manager. Under the SQL Server Network Confiuration Node, Select Protocols for MYSERVERNAME. Ensure that TCP/IP is enabled.
Here's a guide on setting up the firewall: https://technet.microsoft.com/en-us/library/ms175043(v=sql.110).aspx
You can enable SQL Server Authentication by right clicking your server name in the object explorer in SQL Server Management Studio and going to the Security tab. look for the "Server Authentication" option.
Using information from some consultants about 2 years ago we set up a SQL Server 2012 box to always have an encrypted connection (at least we thought so). A week ago the SSL certificate expired and everything continues to work fine which is puzzling.
We forced encryption by doing the following:
Obtain an SSL certificate and install it on the SQL Server via MMC. Explicit instructions for this step are here.
Open SQL Server Configuration Manger and expand the SQL Server Network Configuration node in the left pane.
Right click Protocols for MSSQLServer and choose properties.
Go to Certificate tab and choose the installed SSL cert from the drop down.
Go to the Flags tab and set force encryption to Yes.
Now, since the SSL cert expired, there is no longer any cert selected in the drop down when I visit step 3 above. However, I put WireShark on the DB server and use SSMS to request some data. The TDS (Tabular Data Stream) packets are still encrypted? When I put WireShark on a different DB Server I set ForceEncryption to NO, those TDS packets are not encrypted as expected.
So my questions are:
How are the TDS packets still encrypted if the cert is expired?
Even when the cert was valid, why didn't I have to select Options > Encrypt Connection to connect to my encrypted DB server? I thought setting ForceEncryption=Yes required ALL client connections to specify Encrypt in their connection string (or the SSMS checkbox)?
If Web APIs are the only method of accessing my DB, and they do so over SSL, is it even necessary to encrypt the SQL Protocol?
1)How are the TDS packets still encrypted if the cert is expired?
you don't need a valid certificate in order to encrypt, you can still encrypt using an expired certificate.
2)Even when the cert was valid, why didn't I have to select Options > Encrypt Connection to connect to my encrypted DB server? I thought setting ForceEncryption=Yes required ALL client connections to specify Encrypt in their connection string (or the SSMS checkbox)?
Do not enable the Force Protocol Encryption option on both the client and the server,
if you enabled force encryption on SQL server you don't need to do it on any client-side
3)If Web APIs are the only method of accessing my DB, and they do so over SSL, is it even necessary to encrypt the SQL Protocol?
To enable SSL you need the certificate to be installed on SQL server so in order to access the DBusing SSL you are doing the same job.
Thank you
I'm not sure if this is possible.
My office Pc sits on the corporate network and to access anything outside this network I have to provide my username and password to get though the proxy.
We have recently purchased a hosted server external to this network so that we can host demo applications that can be access from anywhere. However when we need to connect to the server to update or work on the database we need to use a PC that is not on our network as there is no way to provide my username and password as either part of a connection string or in the management console.
The external server is running SQL Server 2008.
Any advise would be much appreciated as I'm not sure if this is even possible.
Thanks!
You can create an http tunnel between the server and the computer from which you want to access the SQL server.
Use HTTPtunnel GNU package for the organization HTTP tunnel.
Here an example of a HTTP tunnel to connect to the MySQL server.
To connect to SQL server you must specify the appropriate port.
try to use TeamViewer.
1. Installed on the server TeamViewer ... during the installation process specify a fixed password for remote access. remember or write ID (9 digits)
2. on your work computer install teamviewer.
connect to remote server ID and password.
Is the data transferred between two SQL Servers protected (encrypted) by default? If not, is there a way to accomplish this?
I have two SQL Server 2005 databases running on separate servers, separate machines, separate networks. How can I ensure that data transmitted from one server to another is secure? I have tried researching the subject but am unable to find anything.
Many thanks,
Sebastian
Encrypt Via SQL Server
Provision a certificate on both machines.
Configure any non-server clients to trust the certificate's root signing authority. See How to enable SSL encryption for an instance of SQL Server by using Microsoft Management Console.
Configure the server(s) to force all incoming connections to use SSL so that any clients that do not support this will fail to connect. In SQL Server Configuration Manager, set the ForceEncryption parameter to "Yes" in the Protocols section.
OR, instead of the prior step, you can add Encrypted=yes to the provider/connection string for the connection/linked server. If, for example, you register the linked server using sp_addlinkedserver it might look something like this:
EXEC master.dbo.sp_addlinkedserver
#server = N'LinkedServerName',
#srvproduct = N'',
#provider = N'SQLNCLI',
#datasrc = N'Server\InstanceName',
#provstr = N'Encrypt=yes;',
#catalog = 'DatabaseName'
;
I do NOT recommend that you use the option TrustServerCertificate=True because this will disable the client from validating the identity of the server it is connected to.
Also, if using ODBC, the encryption property can be specified in a DSN.
Note that while servers don't require certificates to be installed since you can configure them to automatically create and sign their own certificates, it is best to manually install them, because you can run into problems with the self-created certificates since they change on each restart.
The best security is when the client specifically requests channel encryption, because this not only encrypts the data but the client also attempts to validate the identity of the server via the certificate, helping to mitigate a man-in-the-middle attack.
Encrypt Via The Network
Another option is to set up a secure tunnel (such as a VPN) between the two servers' networks, and ensure that the routing for traffic between them is entirely through said tunnel. This is 100% secure as well, as long as you are sure the traffic goes over the right route.
I realize this is a very old thread, but there's something in here that I just found out is potentially misleading.
"3. Configure the server(s) to force all incoming connections to use SSL so that any clients that do not support this will fail to connect. In SQL Server Configuration Manager, set the ForceEncryption parameter to "Yes" in the Protocols section."
The ForceEncryption parameter on the SQL server side does not fail clients that do not have Encrypt = True set on the client end. Importantly, you can create insecure connections to the SQL server instance even when ForceEncryption is set to "Yes" on the server.
You can validate this by setting ForceEncryption = Yes on the server side, then by connecting to that SQL server using SSMS and choosing not to encrypt the connection on the client side.
You can check the encryption state of the client connection by visiting the Properties of the server in Object Explorer, then clicking on View Connection Properties (right click on the servername in Object Explorer, then click Properties).
You can then see that the value for the Encypted property is set to No.
You can then do a select or other SQL statement to confirm that you are able to access data from the server side, without encryption. I believe that in order to have full end-to-end encryption, you must set encryption on both the client and the server side.
Here is a Microsoft link explaining this issue.
And a screenshot in case that link doesn't work.
And another Microsoft link saying the same thing.
And another screenshot in case that link doesn't work.