Context
For a number of actions (for example: in order to accept to execute a "password change" or a "password reset" query), an Active Directory requires that the connection between the client and the server is secure.
"secure" connections include for example :
connections established through LDAPS
plain + StartTLS connections
SSPI encrypted connection
We have code for an LDAP client, which uses a sub library to establish a connection. Depending on the parameters used when creating the connection, it may either be a plain connection, or a "secure" connection, using one of the medium listed above.
We want to run password modify/password requests on that connection, but before running the actual query, we would like to check whether the connection is secured.
We have access to the code of the sub library, so we can modify the code of that library to have a boolean which indicates whether we went through one of the encrypted paths, I would however like to know whether there is a way, using an LDAP query, to determine whether the current connection is deemed "secure".
Question
Is there a way to check, through a request to the AD server, whether the current connection is considered "secure" from the server's point of view ?
No, there's no query you can make to determine whether the connection is encrypted.
Depending on the library you're using, it may be able to tell you after the fact if the encryption is encrypted, but usually you would specify it up front, so you can just keep track of whether you did it.
Related
At first, please note that I am aware that this question has already been asked several times. However, the accepted (and non-accepted) solutions given so far did not work in my case, so something substantial must have changed since then, which hopefully justifies asking again.
Having said this:
I am currently trying to upgrade an Access 2010 .adp application to Access 2019 .accdb. The application includes a lot of VBA code which uses ADO objects to connect with and operate on Microsoft SQL server (currently: 2008 R2, but will be upgraded soon).
I'd like to keep the most part of the code, which means to stick with ADO, so the way to go is the new OleDB SQL server driver (which has been undeprecated / newly released in 2018). The SQL server runs on another machine than my client application.
I am not able to establish a connection to SQL server from VBA. When executing the following code snippet
Dim cnTemp As Connection
Set cnTemp = New Connection
cnTemp.CursorLocation = adUseServer
cntemp.Open "Provider=MSOLEDBSQL;Server=dbserver.example.com;Initial Catalog=MyDB;Authentication=SqlPassword;User ID=sa;Password=secret;DataTypeCompatibility=80;"
I get the following error when the last line is executed:
SSL Provider: The certificate chain was issued by an authority which is not trusted.
OK, no problem, after all we have found all the other questions dealing with the same issue, all suggesting the same solution: Add Trust Server Certificate=True; to the connection string.
Well, tried that, but -to my surprise- still the same situation. Then I tried some other variants like TrustServerCertificate=True; or using true instead of True, but to no avail. I also tried adding Use Encryption for Data=True; which didn't help either (that could be expected). Furthermore, I tried some of the snippets I had found when researching the problem, but which are not documented by Microsoft as being valid in ADO connection strings (like Encrypt=true or Trusted_Connection=true;); of course, that made the situation worse, raising other error messages.
I have understood that I could solve that problem by putting the SQL server certificate into the client's trusted root certificate store, or by having SQL server use a certificate which has been issued by a known, trusted CA (e.g. Let's Encrypt).
However, I'd strongly like to know why adding Trust Server Certificate=true; to my connection string does not make the error go away and what I have to put in there to disable certificate validation (and by the way, I would be grateful if we wouldn't start a discussion about why this would be bad; this is just development and testing in a trusted, closed network, and I am aware of possible risks).
The reason TrustServerCertificate=True in the connection string is not honored is twofold. One is that it isn't a valid ADO classic (ADODB) connection string keyword. According to the ActiveX Data Objects (ADO) Connection String Keywords documentation, the keyword/value pair should be Trust Server Certificate=True (note spaces). The keyword is ignored entirely without the spaces and not trusted as a result.
However, this change alone will not trust the certificate because of the Authentication-SqlPassword specification. When the Authentication keyword is specified, the documentation footnote calls out:
To improve security, encryption and certificate validation behavior is
modified when using Authentication/Access Token initialization
properties or their corresponding connection string keywords. For details, see Encryption and certificate validation link.
The referenced link includes this important note:
Certificate validation can also be controlled through the Value field
of the
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\MSSQLServer\Client\SNI18.0\GeneralFlags\Flag2
registry entry. Valid values are 0 or 1. The OLE DB driver chooses the
most secure option between the registry and the connection
property/keyword settings. That is, the driver will validate the
server certificate as long as at least one of the registry/connection
settings enables server certificate validation.
So even with Trust Server Certificate=True, the cert will be validated when this registry value is set to 0.
One solution is to simply remove the Authentication=SqlPassword specification as long as you don't need the improved security provided by not trusting the server certificate:
cntemp.Open "Provider=MSOLEDBSQL;Server=dbserver.example.com;Initial Catalog=MyDB;User ID=sa;Password=secret;Trust Server Certificate=True;DataTypeCompatibility=80;"
At first, I'd like to state that all credit goes to #Dan Guzman. It's his answer / comment which provided the solution.
However, I'd like to add some background, based on research I've done since posting my question.
The problem is that Microsoft's documentation obviously is wrong. Please have a look at the following document:
https://learn.microsoft.com/en-us/sql/connect/oledb/applications/using-connection-string-keywords-with-oledb-driver-for-sql-server?view=sql-server-2017#table3_1
It is located in the section SQL Server 2017 -> OLE DB -> Applications -> Using connection string keywords with OLE DB Driver for SQL server, so it should be the right one. It is divided into three sections; in the context of this question, the last table is what we're interested in, because only this one relates to connection strings with ADO.
That last table explicitly shows that Authentication=SqlPawword is valid in ADO / OLE DB connection strings (reformatting mine, no content altered):
Authentication SSPROP_AUTH_MODE Specifies the SQL or Active
Directory authentication used. Valid values are:
(not set): Authentication mode determined by other keywords.
ActiveDirectoryPassword: Active Directory authentication using login ID and password.
ActiveDirectoryIntegrated: Integrated authentication to Active Directory using the currently logged-in user's Windows account
credentials.
NOTE: It's recommended that applications using Integrated Security (or Trusted_Connection) authentication keywords or their corresponding
properties set the value of the Authentication keyword (or its
corresponding property) to ActiveDirectoryIntegrated to enable new
encryption and certificate validation behavior.
SqlPassword: Authentication using login ID and password.
NOTE: It's recommended that applications using SQL Server authentication set the value of the Authentication keyword (or its
corresponding property) to SqlPassword to enable new encryption and
certificate validation behavior.
It also says (again, formatting mine, no content altered):
Trust Server Certificate SSPROP_INIT_TRUST_SERVER_CERTIFICATE
Accepts the strings "true" and "false" as values. The default value
is "false", which means that the server certificate will be validated.
Every reasonable human being will understand this in the sense that Trust Server Certificate=true will disable certificate validation.
But when you look here
https://learn.microsoft.com/en-us/sql/relational-databases/native-client/applications/using-connection-string-keywords-with-sql-server-native-client?view=sql-server-2017
you'll notice that this document is structured like the first one, and that the last table does not mention the Authentication parameter.
However, this document is located in SQL Server 2017 -> Development -> SQL Server Native Client -> Applications -> Using Connection String Keywords. That means that it is not relevant for our case because it relates to SQL server native client (and not OLE DB), but it provides the correct information.
So we have the right document which provides the wrong information and an irrelevant document which provides the right information. Congratulations, Microsoft, you have made me waste a whole day again ...
Furthermore, I have found the following document:
https://learn.microsoft.com/en-us/sql/connect/oledb/features/using-azure-active-directory?view=sql-server-2017#encryption-and-certificate-validation
Reading the title ("Using Azure Active Directory"), it should relate to Azure only. However, I suspect that the following section relates to local SQL server installations as well (formatting mine, no content altered):
Certificate validation
To improve security, the new connection properties/keywords respect
the TrustServerCertificate setting (and its corresponding connection
string keywords/properties) independently of the client encryption
setting. As a result, server certificate is validated by default.
Note
Certificate validation can also be controlled through the Value field
of the
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\MSSQLServer\Client\SNI18.0\GeneralFlags\Flag2
registry entry. Valid values are 0 or 1. The OLE DB driver chooses the
most secure option between the registry and the connection
property/keyword settings. That is, the driver will validate the
server certificate as long as at least one of the registry/connection
settings enables server certificate validation.
So it could well be that we also have to change values in the registry to finally disable certificate validation when connecting to SQL server via ADO / OLE DB.
What does it do? How does it work? Why am I supposed to test the database connection before "borrowing it from the pool"?
I was not able to find any related information as to why I should be using it. Just how to use it. And it baffles me.
Can anyone provide some meaningful definition and possibly resources to find out more?
"test-on-borrow" indicates that a connection from the pool has to be validated usually by a simple SQL validation query defined in "validationQuery". These two properties are commonly used in conjunction to make sure that the current connections in the pool are not stale (no longer connected to the DB actively as a result of a DB restart, or timeouts enforced by the DB, or whatever other reason that might cause stale connections). By testing the connections on borrow, the application can automatically reconnect to the DB using new connections (and dropping the invalid ones) without a manual restart of the app and thus preventing DB connection errors in the app.
You can find more information on jdbc connection pool attributes here:
https://tomcat.apache.org/tomcat-8.0-doc/jdbc-pool.html#Common_Attributes
I need a way to identify whether a given port at a given address is running an instance of Microsoft SQL Server, IBM DB2 Server, or neither, from Python.
My first thought is that I can use Python's telnet library, telnetlib, like this:
import telnetlib
import socket
def checkDBServerType(address, port):
try:
tn = telnetlib.Telnet(address, port)
except socket.error:
return None
tn.write(<something>)
if <something-else> in tn.read_eager():
return "MSSQL"
else:
return "IBMDB2"
The issue is, I have no idea what to send. The user will also be providing my program with a username, password, and database name, so those are also available if that helps.
Also, this is my first post on ServerFault although I've used StackOverflow regularly and SuperUser sometimes. Is this the proper venue for my question, or would it be more appropriate on StackOverflow? (I can't decide if server admin type people or programmer type people would be more likely to be able to help.)
Since you're just looking for a heuristic, I'd say that merely being able to connect to the default port would be a good first cut. So, for instance, if you can connect to TCP 1433, you can reasonably say that that machine is running a default instance of SQL Server. It's not perfect of course (i.e. you could get false positives or false negatives), but it's pretty good. Only you can answer whether it's good enough for you.
You can't simply "talk" to a database server and expect it to tell you what kind of software it's running; there is no standard common protocol to connect to database servers, and although the query language (SQL) is quite standardized, the underlying connection is based on a protocol which is specific to each database system; these protocols are also generally not text-based, thus you can't simply open a socket to a database server and write something on it; also, they are usually never used directly by client applications: every DBMS provides a set of connection libraries which neatly encapsulate them, so that you don't have to understand how to talk to the database server and can focus on actually querying its data.
Your best bet would be to grab the client connection libraries for SQL Server and DB2 and ask each of them to connect to the remote server; whetever one succeeds first will tell you what kind of server is sitting on the remote end.
I recently made a small app for a friend and then made it a public app, in doing so I forgot that it connects to my MS SQL DB and checks for values. Someone used Red Gate .Net Reflector to get my password and destroy it all. I've contacted their ISP and they are looking into it, apparently this person has a static ip with them.
So this is a lesson learned at a heavy price for me. How can I prevent this from happening again? How can I get away from the unsafe connection string they were able to use?
Never hard code connection strings. Use the configuration section provided for it (connectionStrings), and if really paranoid, encrypt it.
If you are using a shared database, you should not even have a connection string on the client, but create a service point (for example a webservice) that will connect to the database on their behalf. The client can connect to this and your connection string is safe behind your service, which is in your control and on your server.
Don't expose a database connection, but have your app communicate through a webservice, or similar, that only has methods and privileges, to do what the app needs.
If you absolutely need the database connection, make sure the user only has read permissions on the database.
Encrypting the connection string is a start, but your program will have to know how to decrypt it for it to be useful. If your program can decrypt it, an attacker will also be able to - you can only affect the amount of work he needs to put in it.
Therefore, in my opinion, you should expose a read-only service.
If it's a public app, you need to provide individual logins for each user or have a proxy sitting between the database and the application which authenticates the users and talks to the database.
Encrypting the connection string wouldn't help much, I think it can be easily decrypted with built-in tools or with Crack.net.
If you're suuuper paranoid, prompt the sysadmin for the password each time the application starts (maybe an admin interface.) That way it's only memory resident.
I love this question. Like driis said, even with encrypted connection strings you need to store a password (or key, or whatever) to decrypt your encrypted connection string. Just more layers of the same problem.
Using connection strings and encrypted sections in you config will won't stop this type of attack, it's only designed to make the config file unreadable on a machine other than which it is installed.
The only safe way is to create a web service that connects to your database to retrieve the data, and then make sure that the web service logon only has the minimum permissons required, or force the user of the web service to logon and them impersonate that user for the database connection.
It appears you don't have firewall protection to stop external connections directly to your database so I wonder what other even more dangerous ports you may have exposed to the internet???
Using a firewall to limit access to your server to http, and https protocols would reduce the chances of a successful attack.
I guess everything is possible but I am wondering how easy is it for someone to hijack a connection string with a network packet analyzer or equivalent tool.
A winforms application fetches data directly from an MSSQL server.
(Supposing there are no webservices in the middle for extra protection)
1) Is it possible for someone with an analyzer to read the connection string as clear text?
2) The connection string could be protected with an SSL certificate?
3) The SSL certificate should be installed on the SQL server?
4) I already own an SSL certificate https Could I install it also for the SQL server?
5) The speed of the the return data, will be reduced due to SSL?
Thanks in advance
Yes. If they're on the same network as the packet sniffer (henceforth "the sniffer") and the connection string is in plain text it's easy. Using a switch instead of a hub will not make it any harder to do this.
still possible using a man-in-the-middle attack. Channel binding is designed to detect and prevent this, along with careful examination of the certificate received by the client. Client certificates would help strengthen this as well
yes it should
as long as the host name matches the sql server exactly it should work, otherwise you'll need a new cert.
it probably will reduce the speed but not by much. Benchmark it and see if the slowdown still gives acceptable performance; there's no other way to predict the impact with any degree of reliability.
One other thing: if the connection string is encrypted I can still analyze the packet to find your server's location and if the data being passed back and forth isn't encrypted I can still read it even if I can't connect to the sql server. I can also potentially modify it. This is why it's unusual for a SQL connection to exist over the internet and why it's usually either connecting to a DB on the same server, connecting via a local network, connecting via a VPN, or encrypting the whole data stream.
If it isn't encrypted, it can be read, yes. Note that the SQL Native Client may often perform a non-SSL based encryption (depending on lots of factors), but yes, it can also be encrypted with SSL; see technet. And yes, it slows things down slightly. The requirements for the certificate are all in the technet article. But please don't expose your db server to the internet...