Por que o SQL Server por VPN ainda recorre ao NTLM?

A sua ligação funciona, o início de sessão é aceite e o SQL Server usa NTLM enquanto todos esperavam Kerberos. Esse resultado não é um defeito da VPN, porque um túnel apenas fornece um caminho; o esquema foi decidido pelo nome pedido pelo cliente, pelo principal registado no diretório e pelo tíquete que o cliente conseguiu realmente obter. Três condições têm de se verificar ao mesmo tempo, e a própria sessão diz qual cedeu. Leia isto antes de alguém editar um nome principal de serviço.

A sessão indica o esquema que realmente obteve

O esquema de autenticação pertence a uma ligação e não a um servidor ou túnel, pelo que a verificação tem de correr dentro da sessão que lhe interessa. Execute a consulta abaixo a partir do mesmo cliente, ferramenta e conta que produziram o relatório, e registe o nome de destino e o transporte junto ao resultado.

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

Uma linha de uma janela local do SSMS no anfitrião da base de dados descreve uma ligação completamente diferente, razão pela qual a consulta tem de correr do lado do cliente. Guarde a saída com um carimbo temporal, porque a próxima pessoa que a ler perguntará quando foi obtida. Quando várias aplicações partilham um ponto final, recolha uma amostra de cada uma, porque uma diferença de origem de dados entre duas aplicações é muitas vezes toda a história.

Primeira condição: o nome corresponde ao SPN?

O Kerberos autentica um serviço com nome, pelo que o cliente pede ao diretório um tíquete para um principal específico. Para o fornecedor TCP, a forma documentada é MSSQLSvc/ seguida do nome de anfitrião totalmente qualificado e, para uma instância predefinida, da porta. Uma instância com nome registra MSSQLSvc/db01.corp.example:SQLPROD, onde o sufixo é o nome da instância em vez de um número. Atingir o serviço de escuta através de um alias, de um CNAME que resolve noutro local ou de um endereço IP simples altera o nome pedido, e um pedido sem um principal correspondente não tem tíquete para devolver.

É por isso que uma aplicação funciona numa rede e recorre a outra: uma resposta DNS, um registo de alias ou uma entrada hosts alteraram o nome usado pelo cliente. Compare o nome pedido com o que o diretório contém antes de mexer no registo.

Segunda condição: o SPN está na conta correta?

Um SPN tem de pertencer à conta que executa o serviço SQL, não à conta do cliente e não, por acidente, a um objeto de computador. O SQL Server pode registar os seus próprios SPN no arranque quando a sua conta de serviço tem permissão para os escrever, o que é prático e também explica como aparece um duplicado após uma mudança de conta de serviço.

Pergunte ao diretório pelo nome que espera e depois liste o que a conta possui realmente. Qual objeto detém a entrada importa mais do que saber se o nome existe em algum lugar da floresta. Uma divergência significa que o início de sessão nunca foi o problema, e o guia de SPN da Microsoft documenta os formatos e os casos em que um administrador de domínio tem de criar a entrada.

setspn -Q MSSQLSvc/db01.corp.example:1433
setspn -L CORP\svc-sql01

Acrescentar outra entrada não é uma experiência segura. Um duplicado ou um registo em conflito pode quebrar clientes que funcionavam, por isso inspecione a propriedade antes da alteração e volte a verificá-la depois.

Terceira condição: o cliente consegue obter um tíquete?

Um SPN correto é inútil se o cliente não conseguir alcançar um controlador de domínio ou não tiver um contexto de credenciais utilizável. A troca precisa do KDC e do DNS através da VPN, e um túnel que apenas encaminha a porta SQL falha exatamente neste passo. A acessibilidade tem de ser testada a partir da mesma máquina e da mesma conta, não da firewall que está à frente delas.

Inspecione a cache de tíquetes na máquina e sob a conta que executa a aplicação. Uma lista de toda a máquina a partir de uma janela elevada não diz nada sobre um serviço a correr como outro utilizador, e uma cache vazia para esse utilizador é uma constatação e não um incómodo.

klist
klist -li 0x3e7

Depois decida o que uma recessão pode fazer. Se a política exigir Kerberos, o NTLM tem de ser recusado explicitamente, porque uma recessão silenciosa transforma um erro de configuração numa ligação funcional que viola o requisito. Se o NTLM continuar aceitável para algumas aplicações, nomeie-as e deixe de tratar cada sessão NTLM como um incidente.

Mudar o lançador é uma variável, não uma correção

Iniciar o SSMS com outra credencial pode curar uma identidade de saída indesejada, o que é uma classe real de problema. Não prova nada sobre o nome de destino, o registo ou o caminho do tíquete, e não altera o que o servidor aceitou.

Mantenha a comparação controlada: mesmo ponto final, mesmo fornecedor, um contexto de execução conhecido e depois uma nova ligação cujo esquema inspeciona. Confirme o início de sessão aceite e as suas permissões de base de dados em separado, porque o acesso e a autenticação falham por motivos diferentes.

Quando o Kerberos é exigido, registe por que razão o primeiro caminho recuou, aplique uma correção e volte a executar a consulta a partir do mesmo cliente. Uma consulta bem-sucedida após uma mudança de lançador é evidência de acesso, e ainda não é evidência de que o requisito de autenticação foi cumprido.