Within two environments, where database servers with SQL Server 2008 R2 and SQL server 2012 are operated, the Extended Protection and SSL Encryption settings have been enabled. Since then, the applications (SharePoint 2010, SharePoint 2013 und ADFS) are having problems connecting to the databases. Following error message is logged in the SQL Server error logs: “SSPI handshake failed with error code 0x80090346, state 46 while establishing a connection with integrated security; the connection has been closed. Reason: The Channel Bindings from this client are missing or do not match the established Transport Layer Security (TLS) Channel. The service might be under attack, or the data provider or client operating system might need to be upgraded to support Extended Protection. Closing the connection.”.
On the client-side, following error message is logged: “Login failed. The login is from an untrusted domain and cannot be used with Windows authentication.”
Basically, when both settings are enabled, the remote connection, even through SQL Server Management Studio, does not work anymore. This issue can be resolved by disabling one of the two settings.
If "disabling one of the two settings" still results in the connection between the two servers being encrypted, then your objective might have been achieved sufficiently by using only the other.
Related
I am facing below error while connecting to the SQL Server on another server from a .NET application.
An exception has been raised that is likely due to a transient failure. If you are connecting to a SQL Azure database consider using SqlAzureExecutionStrategy. The underlying provider failed on Open. A connection was successfully established with the server, but then an error occurred during the login process. (provider: SSL Provider, error: 0 - An existing connection was forcibly closed by the remote host.)
SQL Server is running on Windows Server 2016 and the application is on Windows Server 2012.
Everything was fine before those security updates but after updates were installed and servers were restarted, I started getting those errors.
Any suggestions on how to resolve this?
You might want look to look at the following article at Microsoft: Applications experience "forcibly closed" TLS connection errors when connecting SQL Servers in Windows
I am running into the same issue and I applied the work around, I am still waiting for the results to confirm the solution. It started happening recently in our production environment, as this happens very randomly while connecting to hundreds of servers it is difficult to spot the issue. First we were reviewing network side for lost packets as we work between different data centers. As nothing strange came back from this investigation I stumbled upon the above article.
Update
I applied the workaround, the Group Policy on the local computer, basically followed the instructions of this Group Policy, enabled the policy, copied all cipher suits, removed the TLS_DHE* and applied it. After that restarted the server. The issue has been resolved.
I'm suddenly having a problem connecting to my local instance of SQL Server 2005 Database engine. I had no problem connecting to this instance a few days ago. I can however connect to Integration Services and Analysis Services. Only the Database engine is giving me this error:
A connection was successfully established with the server,
but then an error occurred during the pre-login handshake.
(provider: SSL Provider, error: 0 -
The Local Security Authority cannot be contacted) (Microsoft SQL Server)
Only thing I did was I installed Visual Studio 2017.
This is a generic error that has many reasons. Usually is things like expired password. To troubleshoot, you should enable Netlogon service logging, follow Enabling debug logging for the Netlogon service:
c:\>Nltest /DBFlag:2080FFFF
Then reproduce your problem then look into the logging file, which is going to be located at %windir%\debug\netlogon.log. Read the file, try to understand what is happening.
Don't forget to turn off the debug logging afterwards:
c:\>Nltest /DBFlag:0
We are developing an application that uses a Windows Azure cloud service, and a SQL Azure database. We have an ASP .NET MVC project that uses database-first to create the entities in our Visual Studio solution. Now we need to deploy the database schema to Azure.
Currently this is not possible because our network blocks outbound access on port 1433, which is the only port SQL Azure is available on. We have asked our security team for permission to open port 1433 outbound, but they have some concerns:
There is unencrypted database traffic (port 1433) allowed at Microsoft's firewall over the internet for Azure. Although there is no sensitive information in the database, management credentials are probably in clear text if database credentials are not encrypted and can lead to defacement risks.
What network ports are opened at the internet firewall for access to the system hosting the website and database?
I believe the concern in the first question is that credentials for managing the Azure DB will be sent over on port 1433 unencrypted during deployment. For the second one, I think the answer is that we can configure endpoints to open whatever ports we want for our cloud service, but they are closed by default.
I did some research, but was unable to find any definitive answers on these questions from Microsoft, which makes me think we are asking the wrong questions. I would be interested in insight from anyone with more experience in this than I have.
SQL Azure only accepts encrypted (SSL) communication per the Security Guidelines and Limitations (Windows Azure SQL Database) article here: http://msdn.microsoft.com/en-us/library/windowsazure/ff394108.aspx
Encryption and Certificate Validation All communications between
Windows Azure SQL Database and your application require encryption
(SSL) at all times. If your client application does not validate
certificates upon connection, your connection to Windows Azure SQL
Database is susceptible to "man in the middle" attacks. To validate
certificates with application code or tools, explicitly request an
encrypted connection and do not trust the server certificates. If your
application code or tools do not request an encrypted connection, they
will still receive encrypted connections. However, they may not
validate the server certificates and thus will be susceptible to "man
in the middle" attacks. To validate certificates with ADO.NET
application code, set Encrypt=True and TrustServerCertificate=False in
the database connection string. For more information, see How to:
Connect to Windows Azure SQL Database Using ADO.NET. SQL Server
Management Studio also supports certificate validation. In the Connect
to Server dialog box, click Encrypt connection on the Connection
Properties tab. SQL Server Management Studio does not support Windows
Azure SQL Database in versions prior to SQL Server 2008 R2.
SQL Azure uses 1433 and 8443. The port requirements for Azure are available here: http://msdn.microsoft.com/en-us/library/windowsazure/jj136814.aspx
If you want to limit firewall traffic to and from specific IP addresses, the Azure datacenter IP ranges are available here: http://msdn.microsoft.com/en-us/library/windowsazure/dn175718.aspx
Some options (in addition to DarrelNorton's answer):
- you can use a dedicated SQL Server VM, then you can use port forwarding and the port issue is not a problem and you have additional firewall options and additional security software you can instal
- dedicated SQL VM allows you to take advantage of TDE (Trans. Data Encryption) in SQL Server or you can do more advanced encryption techniques that are not available in SQL Azure DB
- Dedicated SQL VM you are isolated from other MSFT clients. If you get hacked, you can re provision the VM from scripts
- you can use a Virtual Network connection between the MSFT data center and your local network if you are concerned about security (the VPN is encrypted)
I am unable to connect to my SQL Azure database instance remotely using SQL Management Studio 2012. Firewall exception is in there for my local IP. I can connect successfully and admin the database using the browser based management link in my Azure account.
I just can't seem to connect to the database via SSMS or anything else like VS2012.
Here is the format I'm for my connection in SSMS:
Server Name: myservername.database.windows.net
Authentication: SQL Server Authentication
Login: myusername#myservername
Password: my-password
Connect to: (i've tried) "master", mydatabasename, <default>
Encryption: TRUE
Once again, I DO have the firewall rule active for my local IP address on the server instance of my Azure account.
When I attempt to connect, I receive this error:
A connection was successfully established with the server, but then an
error occurred during the pre-login handshake. (provider: SSL
Provider, error: 0 - the wait operation timed out.) (Microsoft SQL
Server, Error: 258)
When searching for that 258 error, I do not get many results related to SQL Azure. I appreciate any help.
Error 258 is generated due to some of the configuration within your machine if a secure network could be established between two endpoints and if one machine initiate secure channel. This problem could be very much machine specific and not SQL specific that why you did not find any resources on this regard.
Can you try using SQLCMD as described in the following troubleshooting guide and see if that works to isolate SSMS specific issues on the same machine:
http://social.technet.microsoft.com/wiki/contents/articles/1719.windows-azure-sql-database-connectivity-troubleshooting-guide.aspx
IF you capture and analyze network packets traffic you might be able to determine the root cause of connectivity error.
I have setup mirroring only with principle and mirror in untrusted domain environment using certificates. I have successfully tested the mirroring session by doing a manual failover. But I see a lot of login failures in the mirror server saying
Login failed for user 'NT AUTHORITY\LOCAL SERVICE'. Reason:
Failed to open the explicitly
specified database. [CLIENT: ]
SSPI handshake failed with error code 0x8009030c, state 14 while
establishing a connection with
integrated security; the connection
has been closed. Reason:
AcceptSecurityContext failed. The
Windows error code indicates the cause
of failure.
Login failed. The login is from an untrusted domain and cannot be used
with Windows authentication.
I am not using windows authentication for mirroring. Can someone please suggest the way to avoid these errors from appearing in the error log. Also why is the principle server still trying to use windows authentication?
Those failures are not from the mirroring connection. Those errors are from your client trying to connect to the mirror instance.
The first error is from a local service that is attempting to open an explicit database that is offline (perhaps is trying to connect to the mirrored database). The second error is from a client that had failed the SSPI handshake. And the third one is from a client that has succeeded the hansdhake but is not trusted.
You have to verify your client apps connection strings and, your agent jobs etc etc and see who is attempting these connections.
ok as follows: in the mirror monitoring tool you can set the connection / authentication it should use. Your probably best of removing the connections in the monitoring tool and reregistering them according to the accounts you have set in the endpoints.