A conexão confiável com o SQL falha após a conexão a uma VPN

Question

Eu tenho um servidor de desenvolvimento com uma instância do SQL 2008 EXPRESS em execução. O domínio é chamado DEVAD e a instância é ativada para memória compartilhada, pipes nomeados e TCP / IP.

Meu computador da estação de trabalho está em um domínio diferente chamado AD.

Eu tenho relações de confiança de domínio configuradas entre o AD e o DEVAD, e posso conectar-me à instância DEVAD usando minhas credenciais do AD, por meio de programas SSMS ou .NET.

Infelizmente, no momento em que me conecto a outra rede por meio de uma VPN usando credenciais para um domínio diferente, recebo o seguinte erro "Falha no login. O login é de um domínio não confiável e não pode ser usado com a autenticação do Windows. , Erro: 18452) ".

Minha conexão VPN tem a opção "Usar gateway padrão na rede remota" desmarcada para IPv4 e IPv6.

Alguma idéia de como impedir que a conexão VPN quebre a confiança?

Atualização: tenho uma VPN adicional à qual me conecto ocasionalmente e não tenho problemas para conectar-me ao SQL ao mesmo tempo quando esta está ativa.

Eu fiz alguns testes nslookup no host SQL com várias VPNs conectadas e não conectadas. Meu problema VPN acaba com um tempo limite de DNS, o que pode significar que o DNS na VPN está configurado incorretamente e reduz a solicitação, em vez de dar uma resposta de domínio inexistente (como minha outra VPN faz) e deixar o sistema entrar com a consulta de um DNS que saiba sobre isso.

    

Answer 1

Eu também estava tendo o mesmo problema e encontrei a solução aqui:

link

Você precisará localizar o arquivo .pbk de conexões VPN.

Você pode encontrá-lo aqui:

C:\Users\{WindowsLogin}\AppData\Roaming\Microsoft\Network\Connections\Pbk

Ou se você tiver definido para permitir que todos os usuários usem a conexão, você poderá encontrá-la aqui:

C:\ProgramData\Microsoft\Network\Connections\Pbk

Edite-o com um editor de texto e encontre a linha que diz:

UseRasCredentials=1

Desative-o, definindo-o como 0

UseRasCredentials=0

    

Answer 2

Você já descobriu isso? Eu acho que sei qual é o seu problema.

1. É possível que a VPN problemática seja um túnel completo e, em caso afirmativo, pode ser que até mesmo desmarcar a opção "usar gateway padrão na rede remota" não ajude. Com a VPN de túnel completa, quando você estiver usando a VPN, todo o seu tráfego estará na rede VPN, goste ou não. Você pode testar isso acessando um site como o ipchicken.com antes de se conectar à VPN e, em seguida, atualizar a página novamente depois de se conectar. Se o IP mudar, você estará em um túnel completo.

2. Como você está tentando se conectar ao SQL Server? Você está usando um aplicativo ou o SQL Server Management Studio? Se você puder executar o programa a partir de uma linha de comando, você pode ter sorte usando o comando runas windows com a opção / netonly. Ele permite que você faça login em um domínio, mas execute um programa como um usuário de domínio diferente. Assim:

   runas / user: MYDOMAIN \ MYUSER / netonly "C: \ Arquivos de Programas (x86) \ Microsoft SQL Server \ 100 \ Ferramentas \ Binn \ VSShell \ Common7 \ IDE \ Ssms.exe"

Substitua o domínio, o nome de usuário e o caminho do SQL Server Manamgent Studio pelos valores apropriados.

Quando ele solicitar a senha, digite a senha do usuário do domínio que você especificou. Ele não autenticará o usuário neste momento. Então, quando você abrir o SSMS, conecte-se ao DB em questão como faria normalmente, e se ele não puder se conectar com os creds normais, ele deve tentar usar os que você inseriu com o comando runas.