I am trying to connect to our sql server with the following connection string
<add name="siteDB" connectionString="Data Source=xxxxx\sql_2005;Initial Catalog=Intranet;User ID=username;Password=password" providerName="System.Data.SqlClient"/>
but I am getting this error
A connection was successfully established with the server, but then an error occurred during the pre-login handshake
this is only a problem when the Web app is compiled as .net 4, .net 2 seems to work fine
I have tried the following with no success
TrustServerCertificate=True
in the connection string.. no joy
also tried
TCP/IP protocols enabled
named pipes enabled
using a newly set up account with the correct permissions
any ideas?
thanks
nat
You can try this or
this (worked for me once):
1) Remove all SSL certificates and encryption options from IIS – both at the website level (for example from the “Default Web Site”) and at virtual directory level. Basically if you enabled encryption put all the settings back to their original non-encrypted settings.
2) Remove all SSL self-signed certificates from the server. These are the certificates that SelfSSL generated for you. Your server may have genuine certificates – don’t touch these as they may be used by other software and anyway should be harmless.
These certificates need to be removed from all certificates stores. To do this start MMC and (one at a time) add the Certificate Manager snap-in to “My user account”, “Service account” and “Computer account”. Locate every single copy of the self-signed certificates wherever they may be (Personal, Trusted Root Certificates Authorities, etc) and delete them.
3) Now, although you have deleted the actual certificates, SQL Server still continues to use encryption. This is because it has created a copy of the certificate in the registry. You need to locate these and delete them.
These are located in:
HKEY_LOCAL_MACHINE\SOFTWARE\wow6432node\Microsoft\Microsoft SQL
Server\MSSQL.x\MSSQLServer\SuperSocketNetLib
AND/OR
HKEY_LOCAL_MACHINE\SOFTWARE\wow6432node\Microsoft\Microsoft SQL
Server\MSSQL.x\Client\SuperSocketNetLib
4) Restart the server and this should have fixed the initial error and you will find that SQL agent is running and things are back to normal.
As found here.
Related
We have a web application which consists of an IIS web server which is on the internet, and a database server, which IIS accesses over a VPN link.
The problem we have is that we need to store the connectstring somewhere (which obviously can't be in the database).
I note that it is possible to encrypt web.config connect strings using aspnet_regiis :
https://msdn.microsoft.com/en-us/library/dx0f3cf2%28v=vs.85%29.aspx
Can anyone comment on how robust this is. What we do not want is the database being hacked from the internet.
One thing which concerns me is the aspnet_regiis is used to decrypt and encrypt and is installed on the machine itself. So if the machine was compromised and this exe was on there, discovering the passwords would not be that hard.
So assuming that this method of securing a password is not recommended, what other options do I have.
Note that in case it is relevant, IIS is running in the context of IIS APPPOOL\DefaultAppPool account.
Thanks.
You do not encrypt your configuration files to prevent being hacked from the internet. IIS will never serve *.config files. You encrypt configuration files to hide the information therein from server administrators.
If a remote attacker has access to the server and can run arbitrary executables, all bets are off. There's nothing you can do to secure the server after that.
How to prevent the server from being accessed remotely is too broad to answer, check OWASP for general hints.
If possible, give your app pool identity (in your case IIS APPPOOL\DefaultAppPool) access to the SQL Server.
Then use integrated authentication instead of password and username in your connection string:
Server=myServerAddress;Database=myDataBase;Trusted_Connection=True;
There are many versions of this question on stackoverflow. I have tried a lot of the solutions suggested there - but none of these work for me.
I have a VB ASP.NET application running on IIS on Windows Server 2008. It calls a webservice. The Server running the Web Service has a self signed certificate. I have imported the Cert into the Trust Store of the IIS machine. I can see the certificate in IE->Options->Content->Certificates->Trusted Root Certification Authorities.
When the webservice is called, an exception is thrown
The underlying connection was closed: Could not establish trust relationship for the SSL/TLS secure channel.
The same IIS VB ASP.NET Application runs fine on another machine with a similar setup.
These are the different basic things I have checked
The URL used to call the webservice is the same as the CN on the Cert imported into the Trusted Root CA.
Time is synced between the calling machine and the webservice host
The Cert isn't expired.
The IIS machine has Proxy settings in IIS, but Webservice Host machine as added to list of exceptions where Proxy should not be used.
I wrote a small command line test program in VB.NET calling the same webservice which runs fine.
After importing the Cert into the Trusted CA store, I have done a iisreset.
Only thing I haven't tried yet is rebooting the IIS machine - this is production machine & I cannot reboot it for at least a couple of days.
What else can I try?
Internet Explorer certificate settings apply only to the current user. It's highly unlikely that the same user you're logged in as when operating IE is the same as the one being used to host the IIS application. You could add the certificate to the trusted certs for the appropriate service account, but a simpler approach would be to add it to the "Local Computer" trusted certs.
Run Microsoft Management Console (type "mmc" in run dialog) File > Add / Remove Snap-Ins > Certificates, chose "Computer account" for the certificates to manage. This way, any user or service account on the server will see the certificate as trusted.
Alternatively, depending on how you're accessing the web-service, you could add an exception within the application itself. I would recommend code that checks the thumbprint / hash of the certificate though, as opposed to allowing it to connect to any un-trusted certificate.
I need to install a certificate for encryption (replication) between an external vendor and my company.
I cannot get a third party certificate for the FQDN of my server because the net part of that does not match a domain that we own (ie my FQDN is sqlservername.company.root.net but we don't own a domain called company.root.net.). We do own mycompany.com, so I got sqlserver.mycompany.com on the cert and have a DNS entry to alias sqlserver.mycompany.com to sqlservername.company.root.net.
I cannot use a self generated cert since the vendor needs to trust the cert authority.
I have a cert that I have purchased and installed, but SQL Server won't see it since the FQDN doesn't match.
I tried installing it by putting the thumbprint of the cert into the registry directly, but then SQL server won't start with the following errors:
The server could not load the certificate it needs to initiate an SSL connection. It returned the following error: 0x8009030e. Check certificates to make sure they are valid.
Unable to load user-specified certificate [Cert Hash(sha1) "xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx"]. The server will not accept a connection. You should verify that the certificate is correctly installed. See "Configuring Certificate for Use by SSL" in Books Online.
(where the x's above match the thumbprint of the cert without spaces)
TDSSNIClient initialization failed with error 0x80092004, status code 0x80. Reason: Unable to initialize SSL support. Cannot find object or property.
What do I need to do differently to get this working?
You need to use MMC to install your certificate in the certificate store and then use the SQL Server Configuration Manager to link the certificate to your SQL Server service. See https://support.microsoft.com/en-us/help/316898/how-to-enable-ssl-encryption-for-an-instance-of-sql-server-by-using-mi
Then, make sure that the service-account running you SQL Server service has full permission on the certificate. In MMC, right-click on the certificate, select Manage private key, and then grant full access to the service-account running you SQL Server.
You should restart your SQL Server for the changes to take effect.
Before anything else, you must install the certificate in the Windows certificate truststore.
Did you do that?
The error
You should verify that the certificate
is correctly installed
seems to indicate you did not do this.
I was expecting that the hostname verification would be configurable but from here SSL in MS-SQL2008 r2 it seems as an absolute requirement.
To be honest I am not sure if the trick you did with the DNS entry will work.
It seems that some tweeking works for cluster installations ssl for cluster installations
In your case, may be you should have bought the certificate using the IP as subject name and use DNS to resolve to the FQDN you say.
But of course this implies use of a static IP and most likely it would not be feasible as well anyway.....
We are upgrading from an environment where the development web server, the SQL Server 2005, and SQL Server data are all on the same machine, a Windows XP Machine. We are upgrading to having the web server on one Windows 2008 server, the SQL Server on a 2nd Windows 2008 Server, and to Server to a Windows 2008 server, nd the data on a SAN.
Now we are getting the error message:
A connection was succesfully established with the server, but then
an error occured during the login
process. (provider: named pipes
provider, error 0, no process is on
the other end of the pipe.)
The network guy thinks it is a problem with the connection string:
<add name="CNString"
connectionString="Data Source=WEBSERVER;
Initial Catalog=PCIdb;
User ID=sa;Password=pass;"
providerName="System.Data.SqlClient"/>
Can anyone help out here?
Is your SQL Server really called WEBSERVER (DataSource="WEBSERVER") ??
Also, I would never EVER use the sa account in a connection string - NEVER, period. Use an application specific user or something, but do not use the sa account under any circumstances.
This can be caused by any number of reasons, but the first thing to look at is the configuration and setup of the SQL Server itself.
Are named pipes enabled on the server? You can check this through the server configuration manager (on the SQL Server machine itself).
Is the user on the connection string (or the connection pool user if you are using SSPI) setup on the server?
Note:
I do hope the connection string you put up is an edited version of your real one, as there are a couple of issues with it:
Using the sa login - you should never do that as now any SQL exploit can do any damage it wants
Calling a sql server "webserver" - a really confusion naming decision
When it comes to connection strings, look at connectionstrings.com - they hold a good list of valid connection strings to many databases using different providers.
I got that error before...Make sure SQL server services are started
If that's not it, change the authentication mode to both server and windows.
It could be a connectionstring problem. Try comparing your connectionstring to the connectionstrings at http://www.connectionstrings.com but it could also be that the remote connection or the remote server (the webserver in this case) isn't allowed to connect to SQL.
Check if remote connections are allowed and named pipes and/or TCP/IP protocols are enabled on the database server.
But, based on the scenario you've described, I'd say it's the database-end that's refusing the connection (since you've already had a working solution).
I have an asp.net application that should access data from two SQL Servers. One of the SQL Servers is present on the same machine as IIS (let us call it SQLSERVER1) whereas the other SQL server is present on another machine (SQLSERVER2).
The connection strings are trusted for both the SQL servers. Impersonation has been set to true in my web.config file. I am using Windows authentication in both IIS and web.config.
When I try to access data from SQLSERVER2, I get login failed for user(null) error. The user through which I have logged in through Windows exists as a SQL server account in SQLSERVER2.
What could be the possible reason?
NOTE: This is a newbie question IMHO.
NOTE: The IIS used is 6.0 (Windows 2003). It is not set to IIS 5.0 isolation mode.
EDIT:The user getting impersonated is a domain user
Addition:
I also want to state that I get this error message when I access it as a client of the server where IIS is running. In other words, let me say I am working on machine A, the IIS and SQLSERVER1 are on machine B, and SQLSERVER2 is on machine C.
I do not get this error message when I am working on machine B. This is stumping me more.
This is absolutely a delegation problem. As one person pointed out, you need to make sure Kereberos authentication is being used. The old style NTLM isn't going to cut it. Here's more on Kerberos vs. NTLM.
In a nutshell, if you have a webserver and a database and you want the webserver to impersonate the user when making database requests (so that you can set up permissions on the database directly on a per-user or user-group basis) you're performing a double-hop. Credentials must past first from the user's computer to the webserver and again to the database. As you can imagine, the database has to trust the webserver to "do no evil" or this could be an extremely dangerous security hole. As a result, you have to set up what is called in the Windows Server world "delegation"...
Microsoft has a good article about all this here. Further, you can look over an article like this to get an idea of how to set it all up. We've run into this frequently, and it can be a pain at first, especially since as a developer you're probably not in control of the servers directly (especially production ones) and you'll have to spend a lot of time with the server guys down the hall.
You're probably running into this problem because non-Kerberos based impersonation (NTLM) is only valid on the local machine (the webserver). If you want to be able to use those credentials to access another machine, you're going to need to make sure you're using Kerberos.
Try this: http://support.microsoft.com/kb/810572
Your authentication to the webserver is not passed through to the sql server. The web server is authenticating to the SQL Server using the account that your application pool is running under.
You should check that the machine account for SQLSERVER1 has trusted for delegation enabled. Otherwise SQLSERVER2 won't trust the impersonation running on SQLSERVER1. This is in addition to confirming that Kerberos is used to set up the impersonation in the first place. This also assumes that the servers and the users are all members of the same domain.
BTW, are sure you want to do things this way, you end up creating a lot more connections because they end up being unique to a user?
Have you tried to access the database on server2 using SQL SErver administrator from Server1 and made a successful connection?
If not then this could be because by default SQL Server installs itself with tcp turned off by default.
You will need to make sure that this is turned on for server2 to allow server1 to connect.
server1 has no problems connecting due to the fact it can use the shared memory connection.