I need to connect to a secure SQL Server database using Perl DBI. I need to find a way to authenticate the user securely (without fear of eavesdropping, and without storing passwords on the client side). I'm using SQL Server 2008 on Windows Server 2008, and Perl 5.10 on XP.
SQL Server supports encrypted connections via something called the "SQL Server Native Access Client API", but I cannot tell whether this is supported by any DBD driver, or how to use it if it is.
I am reluctant to use the DBD::ODBC driver with SQL Server authentication, because ODBC transmits user IDs and passwords in cleartext.
I can't use the DBD::ODBC driver with Windows authentication (trusted connection), because the server is not on any Active Directory domain that is accessible from the client's network.
How can I secure my connections to the database? Thanks.
I am reluctant to use the DBD::ODBC driver with SQL Server authentication, because ODBC transmits user IDs and passwords in cleartext.
That is not strictly true. If you are using a recentish SQL Server and have not disabled encryption in it then the username/password and connection string are encrypted as follows:
The client contacts the server and tells it what it is capable of (e.g., it can do SSL). If the server then supports SSL it requires the client end to encrypt the connection info and falls back to unencrypted after that. You should also see the "Use Strong encryption for data" checkbox in the DSN.
Two options:
Create an IPSec tunnel between two locations. Some info here:
technet.microsoft.com/en-us/library/cc737154(WS.10).aspx
technet.microsoft.com/en-us/library/cc786385(WS.10).aspx
Enable SSL. I am not sure how well it would be protected.
technet.microsoft.com/en-us/library/ms189067.aspx
I would suggest that you use some kind of secured connection system. It might be IPSec, but it is often viewed as complicated, so you might be better (or faster) off with OpenVPN, which I use, and generally am happy with.
It can be used on virtually any operating system, is fast, and free. You can check it here: http://openvpn.net/
Related
Testing SQL queries with large datasets against Azure SQL server may be costly, so it is better for me to test my code against a local server. I would like to create a new local server with "SQL Server authentication" rather than "Windows authentication", and I would like to keep my default local server that uses Windows authentication.
In lack of better phrasing:... is it "common" to have multiple SQL servers with different authentication methods on the same Windows-10 pc ?
If it is "straight-forward" to do this, then please share "how-to", or share better jargon for web searches. I did not find much information on this when googling "create new local server with sql server authentication"
As you may easily catch from the text: I'm not an IT expert...
Yes, you can use at an instance and solely your will to provide the accesses.
where you can use Windows Authentication mode and mixed mode.
More information about Windows Authentication may be found at: Connecting Using Windows Authentication.
We may utilize SQL Server Authentication to solve your problem by passing the user name and password.
I wanted to read AWS Postgresql from within SQL Server, so
I created a system ODBC connection to Postgresql on the SQL Server machine, tested it, fine.
I then created a Linked Server to connect to postgresql.
In the Security tab (For a login not defined in the list above, connections will), I selected "Be made using the login's current security context".
When using this linked server while connected to SQL Server through windows authentication, it works fine.
If I connect to SQL Server using a SQL Server authenticated account, trying to access postgresql data through that same Linked Server fails authentication.
I fixed that by switching my security setting to "Be made using this security context" and giving the POSTGRESQL login/password (same that I gave at the ODBC level).
Question:
Without repeating the postgresql details at the Linked Server stage, why is it working with Window sauthentication account and not for SQL Server authenticated accounts?
Neither are relevant to Postgresql?...
I made it work but still confused...
I will have to guess a bit to help you, but I hope to give you enough context to understand what is happening so you can debug further.
When you connect to SQL Server using integrated authentication, the domain controller gives out a token to talk to SQL and this is used to authenticate your connection from your client to SQL Server's process. Underneath the covers, Windows can use either NTLM or Kerberos to do this handshake. You can read more about this here in this blog post:
NTLM vs. Kerberos Blog. This protocol choice matters when trying to use linked servers since it has to then authenticate to something else over the network.
At this point, it matters what credentials are used to run SQL Server (usually as a service in the services window to see). If you are running SQL as Local System or Network Service or something else defined by windows (instead of as a specific user on the network), it may or may not have permissions to talk out to your target remote server (whether it be postgres or something else). When you use Kerberos and enable delegation (which the domain admin needs to do), you can have the original integrated auth credentials "flow" over the linked server link to the next connection. NTLM does not do this. Therefore, the usual scenario is to create a map in the local SQL Server of what credentials to use when talking out to a remote linked server.
If you are talking to an ODBC driver, then you are likely using the msdasql (OLEDB to ODBC bridge) provider and then also having to go through its authentication stack. It has been too long for my memory as to whether it even supports integrated auth at all, much less delegation in Kerberos. However, you may be able to debug this problem further if you:
consider which account is running SQL
consider which mechanism is used to do integrated auth to sql and whether that would work with delegation
determine which credentials are used to make the outbound connection to your ODBC target. You should be able to debug much of this through the profiler mechanism as there is a distributed query/linked server set of events IIRC.
I can't speak to your postgres provider specifically, but this should give you some more tools to debug. Hope that helps you get one step further.
Do we require to install Oracle client on local machine if we are using SQL Developer(local machine) for accessing the oracle database on the server(different from local)?
Sometimes yes. For example when your account expires, then there is no way how to change your password via JDBC. This is Oracle specific feature, there it is not supported by JDBC standard.
When DBA creates you account with expiring password, and your password expires, then you have no other way then connecting via OCI to resolve this.
JDBC does not allow you to open a session using two passwords(old one and a now one).
Also errors messages from OCI drivers contain more information then JDBC ones.
We don't require to install Oracle 11g client if we want to access the Oracle database which is present on different machine or server. We just require the tool for accessing the same. For example, SQL Developer. Also we require the credentials such as username, password, hostname, sid, port no.
If you use SQL Server Authentication (2005), are the login details sent in clear text over the wire?
As secure as you want to make it...
you can configure SSL fairly easily, and if you don't have a trusted cert, if you force encryption, SQL Server can create/issue it's own self signed cert for your use...from this write-up
Credentials (in the login packet) that
are transmitted when a client
application connects to SQL Server are
always encrypted. SQL Server will use
a certificate from a trusted
certification authority if available.
If a trusted certificate is not
installed, SQL Server will generate a
self-signed certificate when the
instance is started, and use the
self-signed certificate to encrypt the
credentials. This self-signed
certificate helps increase security
but it does not provide protection
against identity spoofing by the
server. If the self-signed certificate
is used, and the value of the
ForceEncryption option is set to Yes,
all data transmitted across a network
between SQL Server and the client
application will be encrypted using
the self-signed certificate
Whether or not the login credentials are encrypted depends on the encryption capability/configuration of the client and server.
At the protocol level, completely unencrypted SQL logins are allowed, though my guess is that these are rare because I suspect most modern database drivers do not support them.
Details
Clients communicate with Microsoft SQL Server using the Tabular Data Stream (TDS) protocol.
Shortly after a client opens a TDS connection to the server, it informs the server of its encryption capability. The server compares this announcement with its own configuration/capability to determine the encryption state for the connection.
In a nutshell, the encryption state is determined as follows:
If client or server announces that they do not support encryption and the other side does not require encryption, the entire connection—including login—will be unencrypted.
If both client and server announce that they support encryption but do not require it, just the first TDS packet of the login request will be encrypted. The remainder of the connection, including any additional login request packets, will be unencrypted. A properly-designed database driver will ensure that the SQL authentication password is placed in first login packet, but this isn't required at the protocol level.
If either client or server announces that they require encryption, the entire connection will be encrypted (except for a small amount of preliminary data) unless the other side does not support encryption. In that case, the connection will be terminated.
The only way to ensure that login requests are always encrypted is to set the 'require encryption' option on either client or server. There’s no option to disallow completely unencrypted connections without requiring full encryption.
Regardless of whether or not the login or connection is encrypted, the SQL authentication password is always obfuscated but the scrambling is easily reversible.
Further Reading:
Technical details on connection encryption states - MS-TDS 2.2.6.5 PRELOGIN (under heading Encryption)
Password obfuscation formula - MS-TDS 2.2.6.4 LOGIN7 (see last paragraph)
Slightly more in-depth write-up on the topic - SQL Passwords: Encrypted Between Client and Server? (disclaimer: this is a post on my blog)
The credentials are sent in clear text.
You can probably find a number of sources for this, but here's one:
"Secure the channel between the Web server and database server because credentials are passed in an unencrypted format. For example, use SSL or IPSec."
Here's a link to some security best practices for SQL 2005. That doc states in part:
In Windows Authentication mode,
specific Windows user and group
accounts are trusted to log in to SQL
Server. Windows credentials are used
in the process; that is, either NTLM
or Kerberos credentials. Windows
accounts use a series of encrypted
messages to authenticate to SQL
Server; no passwords are passed across
the network during the authentication
process. When SQL logins are used, SQL login passwords are passed across the network for authentication. This makes SQL logins less secure than Windows logins.
Reading this thread made me even more confuse then I was!
Anyway, I did some tests with Wireshark, with or without encrypted connection I was never able to see my password (and my user name I think). What was very visible without encryption is the actual queries.
Perhaps it is the lack of knowledge with Wireshark to retrieve the login credentials, but since I was able to see everything else I'm pretty sure I was looking at the right spot and the password was ALWAYS hidden.
Apart from the fact that passwords are sent in clear text, it is also possible to replace the hash of the password.
I need to transfer data daily from SQL Server (2008) to SQL Server (2005). One of the servers is located at our web host so the data will be transferred over the Internet. On the same network I would use SSIS to transfer the data, but over the Internet this is not a secure option. Is there a secure way of achieving this?
You can use SSL with SQL Server (2000/2005 Instructions / 2008 Instructions) and then force protocol encryption on the connection between both machines. You don't have to use a purchased SSL certificate either, you can use Windows Server Certificate Services to generate one - however if you do so then the CRL must be on a machine that both servers can connect to. An easy way to do this is install Certificate Services on a stand alone machine, perhaps just a VM and the configure it to embed a public DNS name for it's CRL. This doesn't have to be a machine running Certificate Services, just something you own and can upload to. Then you can generate the certificates and publish the CRL and tada, all done.
You will need to ensure the service account SQL is running as has access to the private key of the certificate it is using.
Generally it isn't recommended to have your SQL Servers exposed to the Internet, although that may be out of your control in this case. In your position I would investigate developing some separate Web Services that would perform the transfer of the data. These can then be secured using a variety of methods, such as SSL and WS-Security and other custom user permissions. If that isn't possible then blowdart's answer seems like the way to go.
You can use Service Broker:
Built into SLQ Server engine itself, no need for external process to drive communication.
Compatible protocol SQL 2005 and SQL 2008 communicate over Service Broker out-of-the box.
No need to expose either server to the internet. Through Message Forwarding you can expose
just a SQL Express, with no data on it, to the internet to act as a gateway that lets messages into the back end target.
Communication is encrypted.
Speed, the sample in the link shows how you can exchange over 5000 1k payload messages per second between commodity machines.
Unlike SSIS or replication Service Broker is a general communication framework so it won't provide support to extract the changes and to apply the changes, with conflict resolution and the like. You would have to code that part yourself.