March 10th Patch Tuesday appears to cause SQL Server client connection problems

Question

Since applying the full set of patches on a Win 7.1 Pro desktop and a Windows 2012 R2 Datacenter Azure server running SQL 2014, SQL Management Studio (2008 and 2014 versions) won't connect to the SQL 2014 Azure server. The client connection attempt times out and fails with SQL server error 5.

SQL server transactional replication continues to work normally between local SQL 2008 instance and the remote SQL 2014 instance. Also, the SQL Management Studio 2014 on the remote (Azure) server can connect to the local (on site) SQL 2008 instance with no problem, as well as to the remote (Azure) SQL 2014 server. DNS resolution and IP connectivity in both directions is normal. I can see that the remote SQL 2014 instance correctly creates its SPN at startup. There is a warning on the SQL 2014 that NTLM fallback is being used by some clients.

I don't have a local instance of SQL 2014 nor a remote instance of SQL 2008. So I'm not sure if it's a relevant factor that the server is remote, on Azure, over VPN, or if I would be seeing the same problem with a patched local client and patched local SQL server.

I notice the SQL Browser service on the remote SQL 2014 server is stopped and disabled. I'm not sure if this was the case pre-patch. However I am running one instance on the default port, not a named instance, so I would expect I don't need the SQL Browser service?

There are reported authentication problems with this Patch Tuesday relating to Server 2003 network file shares. I haven't seen reports of general AD authentication problems, or SQL Server authentication problems. Is anyone else having this problem or similar? Any suggestions of which KB I should try to rollback? Should I run the Kerberos configuration analyser? Should I start the disabled SQL Browser service?

Any help appreciated.

Removing MS15-027(KB3002657) from the server and rebooting the server does not resolve the problem.
Removing KB 3046049 on the client and rebooting the client does not resolve the problem. Removing KB 3046049 on the server and rebooting the server does not resolve the problem, but the error code changed from 5 to 53 (a more common error code).

Edit: this is not the same problem as SQL Server Windows Authentication fails after tonight's security updates: The login is from an untrusted domain though it may have the same root cause. (There seem to be increasing reports of a variety of authentication related problems after Tuesday's patch.) Specifically in my case, windows authentication is working normally, I can RDP into the patched machines and between the patched machines and AD based login works fine.

Edit: The same problem affects SQL authentication (non AD). Identical error message. That suggests this is a connectivity problem and not an authentication problem.

We don't have any Windows 2003 servers affected. So the problem we are seeing is not confined to Windows Server 2003 (as is reported for some other similar March Patch issues).

Answer 1

Wednesday Morning 2015-03-11 after March Windows updates we started having issues with ODBC and Spotlight software connections to our 2005, 2008 SQL instances, They were using windows Domain credentials. SQL authentication still worked. Error: Login failed for user ''. The user is not associated with a trusted SQL Server connection. (Microsoft SQL Server, Error: 18452)

Our Domain level is 2003 on windows 2003 SP2 servers multiple sites. On our Windows 2003 Domain Controllers we backed out all updates listed in : https://technet.microsoft.com/library/security/ms15-Mar This restored all our SQL Database connections and allow Operations to successfully complete Nightly System processing.

We have denied installation via our WSUS(Windows Update Server) of the following 2 windows updates for all Servers on our Intranet Domain: MS15-027(KB3002657) and MS15-031(KB3046049)

Read below article on reported issues with these updates: http://www.infoworld.com/article/2895022/security/problems-reported-with-microsoft-patch-kb-3002657-and-a-warning-on-kb-3046049.html#tk.rss_security

support.microsoft.com/en-us/kb/3002657 (Read Known Issues section)

At this time we will not install any updates on our current 2003 Domain controllers as we are monitoring for further issues.

Answer 2

MS15-27 KB3002657 This is not limited to Windows 2003, or EMC Epislon as reported by Microsoft.

My experience was:

Mapping a drive or using a unc path from Windows 7 workstations to multiple Windows 2008 file servers (Not domain controllers) would fail with incorrect username messages.

The issue was the Windows 7 workstations are in a different Active Directory Domain than the Windows 2008 file servers. We had added static dns entries into the DNS zone the Windows 7 workstations were joined to that resolve the ip-address of the Windows 2008 servers. So the users can use the short computer name to access the fileshare (Short name = \servername\sharename FQDN long name = \servername.serverdomain.com\sharename) This process causes the workstation to tack on the workstation dns suffix of \servername.workstationdomain.com\sharename. This triggers the patch to believe the computer name has been spoofed because the fqdn of the servername is wrong.

In order to correct the issue:

1- Remove the dns entries for the servers from the workstation dns zone.

2- Deploy to the workstations via group policy a dns suffix search list containing both the workstation dns suffix and the server dns suffix

Now the workstations can still use the short unc path name and it finds the correct fqdn name after going through the dns search suffix list.

We are probably not the only ones that were doing it this way.