I have a SQL Server 2012 Standard hosted on a WIN 2008 R2 DataCenter 64 bit. I have a requirement to set the Force Encryption on the SQL Server to Yes, which is easy to do.
What I am needing help with is for the DoD Certificate requirement, where do I get the DoD Certificate from? and Do I just install it on the server where SQL Server resides?
I found this link , I wonder if I can use this:
http://dodpki.c3pki.chamb.disa.mil/rootca.html
Your hyperlink is not publicly available, however, since the name on the file is rootca.html it may contain information about how to get a root CA Certificate provisioned. When you use SQL Server Configuration Manager to set force encryption to true, you must either configure a certificate to use or the server will used a self signed certificate. The security concern with only setting this option and using a self signed certificate is that it leaves your server vulnerable to a man in the middle attack. The requirements for creating the certificate to be used for encrypting connections are on MSDN. I would recommend at least using a domain certificate generated by the domain certificate authority. You probably need to adhere to standards if this is for the DOD. Once the certificate and related private key are generated, they need to be added to the certificate store of the service account running the SQL Server database engine. After that, it can be selected for use in the configuration manager in the same dialog box as the force encryption option under a different tab. Once this is configured and the service is restarted, you can verify that the connections are encrypted by using the sql statement below:
select * from sys.dm_exec_connections
Related
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.
I've got on the same computer (Win server 2012 R2 Datacenter) a web app being built on ASP.NET and a SQL Server 2017. Goal is to secure sensitive data on the database in case someone gains access to this computer. I've used Always Encrypted feature to encrypt columns with sensitive data and the according certificate is being stored to the \Certificates(Local Computer)\Personal\Certificates location.
Is there a way to prevent (password protect for example) an active windows user to access this certificate and export it?
To achieve your goal "to secure sensitive data on the database in case someone gains access to this computer" you should not consider keeping your certificate in the same machine (or) server.
You need to maintain the certificate in a Centralized Key Stores like Azure Key Vault
Please see my detailed answer here
I have imported an SSL certificate from entrust. The certificate is visible in IIS and the site can be accessed with SSL so I know the certificate is good.
However i want to use the certificate to encrypt the connection to the sql server. The certificate is not shown in sql config manager as i believe the issued to name doesn't match my host name.
My server name is for example zserver.z1 but i access the server with a dns name of dbserver.company.net. As i will be accessing the server with the dns name, is it possible to force the certificate?
When i created the certificate request, i did specify the dns name as my server name but it doesnt show it on the certificate. Maybe i should contact entrust, but i thought there may be a registry fix out there hopefully!
unfortunately i could not make sql read the other certificate, i was able to reapply for certificate without charges for the local server address and this is now viewable in sql config manager.
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 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/