Eu tenho uma situação interessante aqui. Estamos basicamente tentando migrar alguma infraestrutura do SQL Server para um novo hardware, e uma das caixas (instância única, cluster de 2 nós) está executando 2008R2. Os outros são 2012 e 2014, mas não apresentam esse problema.
Há um aplicativo que se conecta a um servidor chamado, digamos, "OLD-SQL"; e digamos que o IP seja 11.22.33.44. Este é o nome da caixa SQL herdada que executa a instância padrão, SQL 2008R2 e Windows Server 2008R2. A configuração/config/string/qualquer coisa da conexão do aplicativo não pode ser alterada no momento.
A nova caixa SQL definida para substituir aquela é denominada, digamos, "NEW-SQL"; e digamos que seu IP seja 11.22.33.55. Também executando SQL 2008R2 (mesma compilação SQL). O sistema operacional é o Windows Server 2012 R2 (sistema operacional mais recente). Ambas as caixas são, na verdade, instâncias em cluster com 2 nós cada (cluster de failover antiquado, nada sofisticado).
Portanto, para ajudar na migração, por enquanto, para fins de teste/QA, fizemos o seguinte: 1. Configure o arquivo Hosts na máquina de controle de qualidade do cliente para redirecionar o nome "OLD-SQL" para 11.22.33.55 (novo servidor). 2. Criei um SQL Server Alias no servidor NEW-SQL (usando SQL Config Mgr.), denominado "OLD-SQL", apontando para si mesmo , porta 1433, protocolo TCP/IP.
Para testar, tento conectar via SSMS; Eu insiro "OLD-SQL" como o nome do servidor ao qual me conectar. Ele falha com o infame erro "SSPI context" ( https://support.microsoft.com/en-us/kb/811889 ). A mesma coisa acontece com o aplicativo que está sendo testado. O ping da linha cmd resolve bem - ele sabe que "OLD-SQL" resolve para o novo IP 11.22.33.55 com base no arquivo Hosts.
Agora , para realmente jogar uma chave inglesa nas coisas. Volto para o servidor NEW-SQL e adiciono outro Alias, os mesmos parâmetros, mas com o nome "OLD-SQL2". Esse nome é exclusivo dentro da rede de domínio. Volto para minha caixa, altero meu arquivo Hosts para apontar desse nome para o IP (11.22.33.55), vou para o SSMS e tento conectar novamente. ISSO FUNCIONA!
Eu verifico se estou no "servidor certo" fazendo um SELECT @@SERVERNAME, e eis que diz "NEW-SQL". Mas é claro que esse não é o pseudônimo que eu realmente quero; Eu quero ser capaz de dar a ele o alias "OLD-SQL" e ter meu aplicativo redirecionado para "NEW-SQL" por meio da entrada Hosts e do SQL Alias.
Então, o que estou fazendo de errado com o primeiro alias? É só que não posso usar o mesmo nome de um servidor existente na rede, com 2008R2?
Postagem semelhante no SO: https://stackoverflow.com/questions/6406811/alias-not-working-on-sql-server-2008-r2 (não resolveu o problema)
PS: Digo "com 2008R2" especificamente, porque quando tento a mesma configuração (Hosts, SQL Alias) com nossas caixas 2012-2014, elas funcionam muito bem da primeira maneira! (Ou seja, o Alias na caixa "NEW-SQL2012" pode ser "OLD-SQL2012", que é o mesmo de um servidor existente e sem problemas de conexão nem nada.)
PPS: Eu li sobre esses aliases serem mais do lado do cliente, mas é por isso que estou usando o truque do arquivo Hosts. Quando estivermos prontos para a migração "real", vamos usar DNS e outros truques fora do meu conhecimento (esse é o domínio do SysEng) para fazer o redirecionamento de clientes (apps/computadores) para os novos servidores, mas eles disseram por enquanto , para teste, o arquivo Hosts é um bom substituto.
Atualização : A principal diferença entre os setups "funcionais" e os "não funcionais", além das versões do SQL Server, é o fato da antiga instância 2008R2 "SQL-OLD", quando eu conecto usando o setup "pristine" ( sem aliases ou hosts-file-redir.), usa a autenticação Kerberos . Quando me conecto por meio de um alias ou redirecionamento exclusivo, como "OLD-SQL2", ele é registrado como NTLM. E em TODOS OS OUTROS métodos de conexão de trabalho, também é NTLM. O que diabos o Kerberos está fazendo comigo??
Resumindo o que descobrimos no chat.
Ao se conectar pela rede, se o Windows Server estiver registrado no Active Directory (AD) com um Service Principal Name (SPN), os clientes que tentarem se conectar com Autenticação Integrada obterão o token Kerberos do AD para o objeto AD que corresponde ao nome do servidor para anexar à autenticação. O Kerberos não será usado quando o servidor que está sendo conectado não tiver um SPN ou estiver sendo conectado usando autenticação SQL.
Neste caso, como "OLD-SQL" ainda está registrado no AD e possui um SPN registrado spoofing, o DNS no arquivo do host local não funcionará ao usar a Autenticação Integrada/Windows, pois não há nada ajustando qual token é retornado/ usado de AD. Não parece haver uma maneira de fazer com que o cliente saiba usar o token Kerberos para "NEW-SQL" com o servidor "OLD-SQL" original ainda em serviço, exceto para remover o SPN "OLD-SQL" do AD para forçar a autenticação a voltar para NTLM. A falsificação do DNS funciona para aliases nos quais não são nomes de computador reais registrados no AD ou não possuem um SPN registrado, pois o AD não retorna um token para eles, portanto, a autenticação volta a usar NTLM.
Referências
Compreendendo as chaves Kerberos
Registrando um SPN