I am trying to establish a secure connection to a SQL Server database over the internet. In the link below a configuration "Encrypting Specific Connections" is described:
https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/SQLServer.Concepts.General.SSL.Using.html
I have read elsewhere that mutual authentication (server authenticating the client based on certificate) is not supported by SQL Server. Is the described configuration equivalent to mutual authentication or something completely else?
If it is something else, are there other security features of RDS (apart from ip whitelisting) that can increase security over username and password?
Edit: The connection will be encrypted, so when i say increase security i mean in the sense that would work as a second factor of authentication.
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 am currently new to managing databases hence the question. From my lecture notes, it states that
A user logs into the network, Windows or otherwise.
The user opens a nontrusted connection to SQL Server using a username and password other than those used to gain network access. It’s called a nontrusted connection because SQL Server doesn’t trust the operating system to verify the user’s password.
SQL Server matches the username and password entered by the user to an entry in the sys.syslogins table.
My question is that how does the user open a nontrusted connection to SQL? I'm confused. What does it mean by SQL Server doesn’t trust the operating system to verify the user’s password.
Trusted connection is a legacy term and really a misnomer mostly because of how developers think of apps connecting to a database rather than how a database actually handles connection requests. SQL Server doesn't actually trusts connections. It trusts a 3rd party that you designated to authenticate a user and present the appropriate token it will then use for authorization. Just so happens Windows is the only 3rd party you can tell it to trust but it doesn't have to be.
Important things to distinguish in the process are authentication and authorization. Both SQL Server and Windows can authenticate a login attempt but only SQL Server can authorize access to objects/data. They are distinct though related parts.
When you connect using integrated authN, your security token is passed to SQL Server which then does basic checks for login mapping to establish connection. If successful, it goes on to do what it needs to for authZ(e.g. database context switch, authorization, etc...). It only cares that you have a valid token from a trusted source. In this case, it's Windows (simplifying the AD, Kerberos, etc... processes behind this). It doesn't further authenticate, it trusts that Windows has done the right checks already. Note that it doesn't have to be a network or domain user. Even local users can be setup for integrated authN but that's generally not a good idea.
If you connect with SQL Server credentials, after the pre-login handshake, your credentials are then passed to SQL Server for authorization where it'll check for login, compare password hash, policies (if any), etc... Essentially, the user authentication checks that Windows would have done when you login to a host but the security scope is SQL Server only. Until this authN is done, you are not logged in. These steps occur because the connection attempt is made with un-validated credentials rather than a secure token issued by a trusted party. Once it successfully completes authN then it goes down the same code path as before for authZ.
I've done a small TCP/IP server which acts quite like an ftp server.
On the client side, I'm using an API to connect and to exchange data against the server.
This server will be on an active-directory ecosystem, so the client.
What kind of API should I use to implement a SSO/AD authentication on my server ?
(Everything is written in C)
I've seen that SqlServer is doing this through the Trusted connection term. Perhaps a simplier to do things ?
Should I lead to SSPI exchange loop ?
Yes, you need to init a security context from the client and accept that contect from the server, loop until the security context has been established. If you are concerned about your private, you can encrypt the entire traffic with Kerberos.
Now an application is connected to a database server in the same LAN and performs selects and inserts.
The database will be moved to a remote location accessible throughout internet. Performance degradation will be addressed reducing the number of operations to the db. It is not possible to use vpn or configure access-in rules based on client IP on the firewall of the net where the database server will be moved. So it seems to me it is necessary to create a database front end in order to protect it. I suppose one way to achieve this goal is to create a web service.
Are there easier alternatives?
I'm new to web services: it should run into Glassfish server while the client would be a c# application.
I read a bit about securing a web service but I'm a confused.
One method I found in internet is to use Glassfish built-in authentication mechanism and configure web.xml limiting the access to the web service URL to a group of users.
It seems an easy approach, are there any drawbacks?
Is it easy to use this type of authentication in the C# client?
Other existing web services wants a parameter key in the request. Then this key is compared with valid ones and if the check is successful the request will be accepted.
Is this approach more secure than the previous one?
Another alternative is to use WSIT but at a first glance it seems over-complicated and all the security mechanisms need a server certificate.
Anyway it looks more secure; does it fit well with JAX-RS and restful web services?
You can use L2TP or PPTP VPN in this case.
Let me show you first Network topology.
Client (accessing firewall with L2TP or PPTP )-----> Firewall (L2TP or PPTP VPN Server)---> Firewall LAN where your Server placed.
In above case all Client come from VPN so its secure and On firewall you have to Configure VPN to LAN rule with client base rule.
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.