A VPN liga, mas o SQL Server rejeita a autenticação Windows

Os túneis sobem, os servidores respondem ao ping e o início de sessão na base de dados continua a falhar com um erro de autenticação. Essa combinação é comum em ligações VPN e raramente significa que a rede está avariada, porque um ouvinte acessível e um início de sessão aceite são dois resultados diferentes. A identidade que satisfez a gateway não é necessariamente a identidade que o cliente da base de dados apresenta. Descobrir que conta chegou é a tarefa completa.

O sintoma: servidor acessível, início de sessão rejeitado

Um tempo limite diz-lhe que o pacote nunca chegou a um ouvinte. Um erro de autenticação diz-lhe que o ouvinte respondeu e recusou a credencial. Essas duas mensagens enviam-no para equipas diferentes, e misturá-las custa um dia em regras de firewall que nunca foram o problema.

Quando o erro é um início de sessão falhado, pare de olhar para as portas. A questão que resta é que identidade Windows o cliente apresentou, se o servidor aceitou essa identidade e se ela foi resolvida num utilizador da base de dados com permissão.

Duas identidades, um túnel

A conta VPN autentica-se na gateway e, na maioria das implementações, termina aí. O cliente da base de dados apresenta separadamente um token Windows, retirado do processo que o executa, ou um início de sessão SQL se a cadeia de ligação pedir um. Um utilizador VPN local na gateway não tem qualquer relação com o domínio que aloja o SQL Server, e o túnel não cria nenhuma.

Ligar uma máquina pessoal a uma VPN também não a integra no domínio. Mudar o nome de uma conta local e alinhar a sua palavra-passe com a de um utilizador do domínio não é um procedimento de registo, e produz um token que o controlador de domínio não aceitará como esse utilizador.

Alguns clientes nativos de acesso remoto do Windows podem reutilizar a credencial VPN para recursos de rede quando o perfil está configurado desse modo. Esse comportamento pertence a um cliente e a um perfil específicos, não às ligações VPN em geral, por isso verifique-o para o cliente em uso em vez de o assumir.

Leia o modo que o cliente pediu

A cadeia de ligação decide que caminho de autenticação o cliente segue. A segurança integrada usa o token Windows; um par de utilizador e palavra-passe seleciona um início de sessão SQL. São modos separados na configuração do servidor, e apenas um deles pode estar ativado para uma determinada tentativa de ligação.

Server=tcp:sql.lab.example,1433;Database=ops;Integrated Security=SSPI;Encrypt=True;TrustServerCertificate=False;

Mudar para um início de sessão SQL porque o início de sessão Windows falhou é uma solução provisória que esconde a questão da identidade, e normalmente exige na mesma criar um novo início de sessão e palavra-passe. Se a implementação exigir autenticação Windows, mantenha o modo e corrija o caminho da identidade. Um início de sessão SQL também precisa das suas próprias permissões, por isso a solução provisória compra uma segunda conta para manter.

Confirme também que aplicação se está a ligar. Um serviço executado como conta de sistema, uma tarefa agendada e uma janela de consulta interativa podem apresentar três tokens diferentes na mesma máquina, e só o último corresponde ao que o utilizador vê quando executa whoami.

Pergunte ao servidor o que ele viu realmente

O servidor pode dizer-lhe que início de sessão resolveu e como a ligação se autenticou. Execute a consulta dentro da sessão em investigação, porque uma ligação bem-sucedida separada do administrador não prova nada sobre o cliente que falha.

SELECT ORIGINAL_LOGIN() AS original_login,
       SUSER_SNAME() AS current_context;
SELECT auth_scheme, net_transport
FROM sys.dm_exec_connections
WHERE session_id = @@SPID;

A primeira linha distingue o início de sessão que abriu a sessão do contexto de segurança em vigor agora, que diferem sob representação. A segunda indica o esquema de autenticação, pelo que KERBEROS, NTLM e SQL passam a ser factos visíveis em vez de suposições. Uma ligação que relata NTLM onde esperava Kerberos é um problema de resolução de nomes ou de SPN, não um problema de palavra-passe.

O número do erro restringe mais. O estado 5 normalmente significa que o nome de início de sessão não foi resolvido de todo, o estado 8 normalmente significa que a palavra-passe não coincidiu, e o estado 11 significa que a credencial foi aceite mas o acesso ao servidor falhou. Peça ao administrador o estado em vez da mensagem completa, porque a mensagem sozinha é deliberadamente vaga.

Quando a identidade chega e o Kerberos continua a falhar

Se o servidor vê a identidade Windows pretendida e a autenticação integrada continua a falhar, o problema é a própria troca. O Kerberos precisa do nome principal de serviço registado para a conta de serviço SQL e de um cliente que peça o serviço com um nome correspondente. Ligar por endereço IP não pode corresponder a um SPN baseado em nome, e um alias só pode corresponder se também estiver registado. Verifique primeiro o nome que o cliente escreveu, porque uma ligação que funciona por nome de anfitrião e falha por IP descreve exatamente este problema.

Peça ao administrador para rever a identidade registada e a conta de serviço em vez de criar SPN duplicados por tentativa e erro. Registos duplicados produzem falhas intermitentes que são mais difíceis de diagnosticar do que o problema original.

Depois de a autenticação funcionar, o início de sessão ainda precisa de um utilizador da base de dados e de permissões. Um início de sessão VPN bem-sucedido, um início de sessão Windows bem-sucedido e a permissão para ler uma tabela específica são três resultados separados, e cada um merece a sua própria verificação antes de fechar o ticket.