De 10 de março, Patch Tuesday parece causar problemas de conexão com o cliente do SQL Server

Question

Desde a aplicação do conjunto completo de patches em um desktop Win 7.1 Pro e um servidor do Windows 2012 R2 Datacenter Azure executando o SQL 2014, o SQL Management Studio (versões 2008 e 2014) não se conectará ao servidor do SQL 2014 Azure. A tentativa de conexão do cliente atinge o tempo limite e falha com o erro de servidor SQL 5.

A replicação transacional do SQL Server continua a funcionar normalmente entre a instância local do SQL 2008 e a instância remota do SQL 2014. Além disso, o SQL Management Studio 2014 no servidor remoto (Azure) pode se conectar à instância local do SQL 2008 (no local) sem problemas, bem como ao servidor remoto do SQL 2014 (Azure). Resolução de DNS e conectividade IP em ambas as direções é normal. Eu posso ver que a instância remota do SQL 2014 cria corretamente seu SPN na inicialização. Há um aviso no SQL 2014 de que o fallback do NTLM está sendo usado por alguns clientes.

Não tenho uma instância local do SQL 2014 nem uma instância remota do SQL 2008. Por isso, não tenho certeza se é um fator relevante que o servidor seja remoto, no Azure, sobre VPN ou se eu fosse vendo o mesmo problema com um cliente local corrigido e um servidor SQL local corrigido.

Percebo que o serviço SQL Browser no servidor SQL 2014 remoto está parado e desativado. Não tenho certeza se este foi o caso pré-patch. No entanto estou executando uma instância na porta padrão, não uma instância nomeada, então eu esperaria não precisar do serviço SQL Browser?

Há problemas de autenticação relatados com esta terça-feira de correção relacionada aos compartilhamentos de arquivos de rede do Server 2003. Não vi relatos de problemas gerais de autenticação do AD ou problemas de autenticação do SQL Server. Alguém mais está tendo este problema ou semelhante? Alguma sugestão de qual KB eu deveria tentar reverter? Devo executar o analisador de configuração do Kerberos? Devo iniciar o serviço do navegador do SQL desativado?

Qualquer ajuda apreciada.

Remover o MS15-027 (KB3002657) do servidor e reinicializar o servidor não resolve o problema.
Removendo KB 3046049 no cliente e reinicializar o cliente não resolve o problema. Remover o KB 3046049 no servidor e reinicializar o servidor não resolve o problema, mas o código de erro foi alterado de 5 para 53 (um código de erro mais comum).

Editar: este não é o mesmo problema que A Autenticação do Windows do SQL Server falha após as atualizações de segurança desta noite: O login é de um domínio não confiável embora possa ter a mesma causa raiz. (Parece haver relatórios crescentes de uma variedade de problemas relacionados à autenticação após o patch de terça-feira.) Especificamente no meu caso, a autenticação do Windows está funcionando normalmente, posso RDP nas máquinas com patches e entre as máquinas com patch e o login baseado no AD funciona bem.

Editar: o mesmo problema afeta a autenticação do SQL (não AD). Mensagem de erro idêntica. Isso sugere que isso é um problema de conectividade e não um problema de autenticação.

Não temos nenhum servidor Windows 2003 afetado. Portanto, o problema que estamos vendo não se limita ao Windows Server 2003 (como é relatado para alguns outros problemas similares do March Patch).

    

Answer 1

quarta-feira de manhã de 2015-03-11 depois de março Atualizações do Windows começamos a ter problemas com conexões de software ODBC e Spotlight para nossas instâncias SQL de 2005, 2008, Eles estavam usando credenciais de domínio do Windows. A autenticação do SQL ainda funcionou. Erro: o login falhou para o usuário ''. O usuário não está associado a uma conexão confiável do SQL Server. (Microsoft SQL Server, erro: 18452)

Nosso nível de domínio é 2003 em servidores do Windows 2003 SP2 em vários sites. Em nossos controladores de domínio do Windows 2003, fizemos o backup de todas as atualizações listadas em: link Isso restaurou todas as nossas conexões do Banco de Dados SQL e permitiu que as Operações concluíssem com sucesso o processamento do Sistema Noturno.

Negamos a instalação através do nosso WSUS (Windows Update Server) das duas atualizações seguintes para todos os servidores no nosso domínio de intranet: MS15-027 (KB3002657) e MS15-031 (KB3046049)

Leia abaixo o artigo sobre problemas reportados com estas atualizações: link

support.microsoft.com/en-us/kb/3002657 (seção Ler problemas conhecidos)

Neste momento, não instalaremos nenhuma atualização em nossos controladores de domínio atuais de 2003, já que estamos monitorando problemas adicionais.

    

Answer 2

MS15-27 KB3002657 Isso não está limitado ao Windows 2003 ou ao EMC Epislon, conforme relatado pela Microsoft.

Minha experiência foi:

O mapeamento de uma unidade ou o uso de um caminho unc das estações de trabalho do Windows 7 para vários servidores de arquivos do Windows 2008 (não controladores de domínio) falhariam com mensagens de nome de usuário incorretas.

O problema é que as estações de trabalho do Windows 7 estão em um domínio do Active Directory diferente dos servidores de arquivos do Windows 2008. Adicionamos entradas de DNS estáticas à zona de DNS a que as estações de trabalho do Windows 7 se juntaram para resolver o endereço IP dos servidores do Windows 2008. Portanto, os usuários podem usar o nome abreviado do computador para acessar o compartilhamento de arquivos (Nome abreviado = \ nome_do_servidor \ nome_do_compartilhamento_do_compartilhamento_do_FQDN = \ nome_do_servidor.serverdomain.com \ nome_do_compartilhamento). Esse processo faz com que a estação de trabalho utilize o sufixo dns da estação de trabalho. workstationdomain.com \ sharename. Isso aciona o patch para acreditar que o nome do computador foi falsificado porque o fqdn do nome do servidor está errado.

Para corrigir o problema:

1- Remova as entradas do DNS para os servidores da zona de DNS da estação de trabalho.

2- Implemente nas estações de trabalho via política de grupo uma lista de pesquisa de sufixos dns contendo o sufixo dns da estação de trabalho e o sufixo dns do servidor

Agora, as estações de trabalho ainda podem usar o nome do caminho unc unc e encontrar o nome fqdn correto após passar pela lista de sufixos de pesquisa do DNS.

Provavelmente não somos os únicos que estão fazendo isso dessa maneira.