Como faço o login usando o SSPI para o SQL Server 2008 R2 em um servidor em um grupo de trabalho de uma estação de trabalho em outro?

Question

Estamos com problemas para se conectar ao nosso SQL Server (2008 R2) via SSPI.

Nossa equipe mudou recentemente de uma configuração baseada em domínio para uma configuração baseada em grupos de trabalho descentralizada. Cada desenvolvedor tem acesso a uma VPN que, por sua vez, dá acesso a um servidor de banco de dados que executa o SQL Server 2008 R2.

Anteriormente, usamos a autenticação do Windows, efetuando login de nossos computadores associados a domínios com nossos DOMAIN\user.name nomes de usuários, adicionando contas ao servidor SQL remoto (em um grupo de trabalho) com os mesmos nomes de usuário e senhas (mas não o domínio ) para um grupo de segurança do Windows e concedendo permissões de grupo no servidor SQL.

No entanto, desde a mudança do nosso domínio, não conseguimos nos conectar usando o SSPI.

Ao tentar acessar o banco de dados usando a Autenticação do Windows sobre TCP / IP, recebemos a seguinte mensagem de erro:

Login failed. The login is from an untrusted domain and cannot be used with Windows authentication. (Microsoft SQL Server, Error: 18452)

Especificar um logon do SQL Server funciona conforme o esperado, mas o uso do SSPI falha. Verificando o log de eventos no lado do SQL Server, vemos o seguinte:

SSPI handshake failed with error code 0x8009030c, state 14 while establishing a connection with integrated security; the connection has been closed. Reason: AcceptSecurityContext failed. The Windows error code indicates the cause of failure. [CLIENT: 192.168.xxx.xxx].

Nosso provedor de hospedagem gerenciada definiu o nome do grupo de trabalho para um número - vamos fingir que o grupo de trabalho é chamado 12345678 (o nome real é o número da nossa conta). Eu já tentei mudar meu grupo de trabalho local para o mesmo número, mas isso não resolveu o problema.

Muitas das soluções sugeridas por outros usuários fazem referência a uma ferramenta chamada setspn , e usam essa ferramenta para listar e localizar SPNs em uso para nossas contas - usar isso não mostra nada fora do comum.

Estamos trabalhando em torno da limitação usando:

runas /netonly /user:REMOTEPCNAME\user.name "C:\Program Files (x86)\Microsoft SQL Server0\Tools\Binn\ManagementStudio\Ssms.exe"

Estamos presos em ter que usar esse caminho para autenticar?

    

Answer 1

Onze anos atrás, trabalhei em torno de um problema semelhante, mapeando uma letra de unidade em minha estação de trabalho para a máquina remota e fornecendo minhas credenciais na outra máquina. Para você, seria algo como isto (de um shell CMD ou PSH):

net use x: \REMOTEPCNAME\c$ /user:REMOTEPCNAME\john.doe

É evidente que isso usa um "compartilhamento de administrador" ao qual você pode não ter acesso. Isso não foi um problema para mim porque eu era membro do grupo Administradores nessa caixa. Se você não tem acesso de administrador, talvez seja necessário criar um compartilhamento público (por alguém com direitos suficientes) e usá-lo, o que eu acredito que possa funcionar, embora eu não tenha tentado .

Esse truque era uma coisa muito comum naquela época, quando os domínios eram mais raros e o AD era uma coisa nova. Mesmo que não seja uma coisa muito comum, não me lembro de ouvir que a Microsoft havia derrubado ou quebrado essa solução alternativa.

Eu nunca vi os SPNs usados em qualquer situação que não tivesse uma configuração completa do Active Directory. IIRC, os SPNs precisam do Kerberos e o Kerberos precisa de um domínio. Eu suspeito que o chumbo SPN é um arenque vermelho. Boa sorte.