Autenticação Kerberos não funciona com servidores vinculados no SQL Server 2012

8

Estou configurando um ambiente DEV / TEST usando 2 servidores SQL executando o SQL Server 2012 no Windows Server 2012. Estamos saindo do SQL Server 2005 no Windows Server 2008, onde já o temos instalado e funcionando corretamente.

No SQL Server 2012, a autenticação Kerberos não está funcionando.

Cada servidor possui sua própria conta do Active Directory que possui os direitos "Escrever nomes principais de serviço" e "Ler nomes principais de serviço" concedidos por meio de Usuários e Computadores do Active Directory. Sempre que eu me conecto aos servidores do SQL Server 2005 e executo:

SELECT net_transport, auth_scheme 
FROM sys.dm_exec_connections 
WHERE session_id = @@SPID;

Entendo:

net_transport    auth_scheme
TCP              KERBEROS

Quando executo a mesma consulta nas minhas novas instâncias do SQL Server 2012, vejo:

net_transport    auth_scheme
TCP              NTLM

Se eu usar SetSPN -Q MSSQLSvc/*a consulta de Nomes Principais de Serviço no Domínio Ativo, vejo os servidores de 2005 e 2012 listados, exatamente da mesma maneira que não o nome do servidor.

Por exemplo:

MSSQLSvc/SERVERa2005.domain.inet
MSSQLSvc/SERVERa2005domain.inet:1433
MSSQLSvc/SERVERb2005.domain.inet
MSSQLSvc/SERVERb2005domain.inet:1433
MSSQLSvc/SERVERa2012.domain.inet
MSSQLSvc/SERVERa2012domain.inet:1433
MSSQLSvc/SERVERb2012.domain.inet
MSSQLSvc/SERVERb2012domain.inet:1433

O que mais eu preciso fazer para habilitar a autenticação Kerberos no SQL Server 2012? O Books Online parece não ter mais nada a dizer, exceto que os SPNs precisam ser configurados. Quais claramente são. Os logs de erro do SQL Server nas duas máquinas de 2012 dizem:

2012-12-10 14:55:47.630 The SQL Server Network Interface library 
                            successfully registered the Service Principal Name (SPN)
                            [ MSSQLSvc/SERVERa2012.domain.inet ] for the SQL Server
                            service. 

2012-12-10 14:55:47.630 The SQL Server Network Interface library 
                            successfully registered the Service Principal Name (SPN) 
                            [ MSSQLSvc/SERVERa2012.domain.inet:1433 ] for the SQL 
                            Server service. 

2012-12-10 14:55:47.590 SQL Server is attempting to register a Service 
                            Principal Name (SPN) for the SQL Server service. 
                            Kerberos authentication will not be possible until a 
                            SPN is registered for the SQL Server service. This is an
                            informational message. No user action is required.
sql-server sql-server-2012 linked-server kerberos Max Vernon
fonte
2
Minhas falhas favoritas do Kerberos são causadas por computadores cujos relógios se afastaram "demais". Verifique se eles estão sincronizados com o horário oficial do domínio.
darin strait
11
Verifique também se o fuso horário está correto.
precisa

Respostas:

8

Lidar com o Active Directory é sempre muito divertido. A coisa mais importante aqui é perceber que você está lidando com dados distribuídos que podem levar tempo para se propagar pela rede.

Os servidores SQL em questão tiveram seu nome alterado como parte de um procedimento de atualização; substituímos uma máquina existente (SQL01) executando o SQL Server 2005 por uma nova máquina (SQL03) executando o SQL Server 2012. SQL03 era o nome da nova máquina quando eu a configurei inicialmente no domínio. O SQL01 tinha um SPN existente associado a uma única conta de domínio que usamos para vários servidores SQL executando 2005. Como é uma prática recomendada executar apenas uma única máquina em qualquer conta de domínio, criei uma nova conta e configurei o SQL03 para executar com essa nome da conta. Depois de tirar o SQL01 original fora de serviço e renomear SQL03 para SQL01, houve um conflito de SPN.

Usei o utilitário SetSPN.exe para excluir o SPN conflitante (na conta de domínio antiga) - e ele ainda não funcionou. Nesse ponto, não fiz mais nada e passei para outros itens. Quando voltei, cerca de 30 minutos depois, a autenticação KERBEROS estava funcionando. Eu simplesmente precisava esperar a alteração do SPN se propagar entre nossos controladores de domínio.

Eu usei SetSPN -L DOMAIN\Accounte comparei essa saída SetSPN -Q MSSQLSvc/Machine.domain.inet:1433para encontrar os SPNs duplicados e, em seguida, usei SetSPN -D MSSQLSvc/Machine.domain.inet:1433 DOMAIN\Accountpara remover os SPNs antigos.

Max Vernon
fonte