SQL Protocols : SQL Server

Selectively using secure connection to SQL Server

SQL Protocols — Mon, 19 Oct 2009 21:48:00 GMT

Secure connection to SQL Server can be enforced by different ways, e.g. forcing encryption by using “ForceEncryption” property under the Network Configuration in the server. But this setting will force all clients to use encryption and any client that is not able to use an encrypted connection will fail.

If you need to connect to SQL Server selectively here is how to achieve this:

You can take advantage of the two client settings, “Force Protocol Encryption” and “Trust Server Certificate” and two connection string parameters, “Encrypt” and “Trust Server Certificate”. The table below describes different combinations of these flags and the corresponding behavior.

	Force Protocol Encryption client setting	Trust Server Certificate client setting	Connection string/connection attribute Encrypt/Use Encryption for Data	Connection string/connection attribute Trust Server Certificate	Result

1.	No	N/A	No (default)	Ignored	No encryption occurs.
2.	No	N/A	Yes	No (default)	Encryption occurs only if there is a verifiable server certificate, otherwise the connection attempt fails.
3.	No	N/A	Yes	Yes	Encryption always occurs; certificate is not validated by the client.
4.	Yes	No	Ignored	Ignored	Encryption occurs only if there is a verifiable server certificate, otherwise the connection attempt fails.
5.	Yes	Yes	No (default)	Ignored	Encryption always occurs, but certificate is not validated by the client.
6.	Yes	Yes	Yes	No (default)	Encryption occurs only if there is a verifiable server certificate, otherwise the connection attempt fails.
7.	Yes	Yes	Yes	Yes	Encryption always occurs, but certificate is not validated by the client.

If you are not using a server certificate you can go for #5, though #4 with Server certificate is recommended to prevent Man-In-Middle type network attacks. Alternatively you can also use connection string parameters, depending on whether you are using verifiable Server Certificate or self signed server certificate chose #2 or #3. The last two options use both client settings and connection string parameters.

The above connection string values are for OLEDB, for ODBC the connection string values are “true”/”false” instead of “yes”/”no”. For more info please refer to http://msdn.microsoft.com/en-us/library/ms130822%28SQL.90%29.aspx

If you still get error messages like “SSL Security error” and you are using a verifiable server certificate you need to follow the link below to export the server certificate and import it back in the client.

http://support.microsoft.com/kb/316898 (follow the steps for "Enable encryption for a specific client")

Bhaskar Bhattacharyya, SQL Server Protocols
Disclaimer: This posting is provided "AS IS" with no warranties, and confers no rights

We would like to hear your opinion...

dpblogs — Fri, 02 Oct 2009 22:41:00 GMT

Dear SQL Server developers and users:

It is this time of the year when we, in the SQL Connectivity product team, take a step back, review the priorities and goals for the long term and identify areas that will benefit from investments.

We view you and your organization as a key stakeholder in this process and would like to gather your inputs in this survey, which should take no more than 5-10 minutes and a few other surveys that we will conduct in the next few months. The feedback you provide is very valuable and be rest assured that each and every response will be read and will provide the background for some of the key decisions that we will make that will benefit our user community - developers, DBAs, and all those who use SQL Server or are looking for ways to expand the scope of the power of SQL Server within your organizations.

This survey will be open for your submissions until October 21, 2009 and can be found here.

Thanks

Zlatko Michailov

Program Manager, SQL Server Protocols

Microsoft Corp.

Troubleshooting SQL Server Cluster Installations

SQL Protocols — Tue, 17 Jun 2008 05:49:00 GMT

On a Windows Cluster it is possible to install a SQL Server Cluster, which will be a separate entity with disctinct Virtual Server Name, IP address, and pipe name. The nodes of the SQL Cluster must be able to communicate with one another. This communication may fail if the TCP port on which SQL Server is listening is not excepted from firewalls on the machines. This port can be found by using the Configuration Manager utility by viewing the properties of the TCP protocol or by checking the SQL Server errorlog, typically located at "Program Files\Microsoft SQL Server\MSSQL.x\MSSQL\LOG". Here MSSQL.x is the instance ID of the clustered instance in question.

If the Cluster instance being installed is a named instance, a service called SQL Browser is used in order to figure out the port or pipe SQL Server is listening on. For SQL Server Cluster installations, this service is running by default. If this service is not running, it will not be possible to communicate with the remote nodes. To manipulate this service, open services.msc, find SQL Browser, and make sure its state is Automatic and Running. SQL Browser listens on a UDP port, which must also be excepted from firewalls on the machines. Even if SQL Browser is running, in case any of the nodes has firewall ON, it is necessary to add exceptions for UDP port 1434.

These issues with SQL Browser (service not running or TCP and UDP port not excepted from firewall) can also block remote connectivity to non-clustered instances.

More about Windows Firewall impact on APIs for SQL Server enumeration can be read at http://blogs.msdn.com/sql_protocols/archive/2005/09/24/473502.aspx. More about Firewall impact on SQL Server Cluster can be found at http://blogs.msdn.com/sql_protocols/archive/2006/02/27/unable-to-connect-to-a-sql-server-named-instance-on-a-cluster.aspx.

Stoyko Kostov, SQL Server Protocols
Disclaimer: This posting is provided "AS IS" with no warranties, and confers no rights