AD O usuário do servidor OpenVPN integrado não consegue se conectar ao MS SQL Server

Question

Eu tenho um ambiente de nível funcional de domínio / floresta do Windows 2008 R2 com um servidor de acesso OpenVPN (v1.8.4.400) que é integrado ao Active Directory e funciona sem problemas. Eu tenho trabalhado com nosso DBA para agilizar o processo de permissões e decidimos que queremos implementar o acesso aos vários bancos de dados MS SQL através da conta de usuário AD e / ou do grupo AD.

Criamos um usuário de teste: [email protected] e atribuímos a conta por meio do SQL Management Studio à função apropriada usando DOMAIN \ dbtest.

Em seguida, conectamos à caixa OpenVPN, autenticada com sucesso, mas quando tentamos nos conectar ao banco de dados SQL, recebemos o seguinte erro:

ATUALIZADO (direto dos registros de erros)

12/13/2013 08:00:02,Logon,Unknown,Login failed. The login is from an untrusted domain and cannot be used with Windows authentication. [CLIENT: 10.0.160.201]
12/13/2013 08:00:02,Logon,Unknown,Error: 18452<c/> Severity: 14<c/> State: 1.
12/13/2013 08:00:02,Logon,Unknown,SSPI handshake failed with error code 0x8009030c<c/> state 14 while establishing a connection with integrated security; the connection has been cclosed. Reason: AcceptSecurityContext failed. The Windows error code indicates the cause of failure. The logon attempt failed   [CLIENT: 10.0.160.201]
12/13/2013 08:00:02,Logon,Unknown,Error: 17806<c/> Severity: 20<c/> State: 14.

Existe alguma maneira de fazer isso funcionar, sabendo que as máquinas remotas conectadas através da VPN não estão associadas ao domínio? As contas com as quais eles estão se conectando são de domínio.

Obrigado antecipadamente!

    

Answer 1

Usamos o servidor OpenVPN-AS com êxito com o SQL Server usando a autenticação do AD por vários anos. Eu suspeito que pode ter mais a ver com o sistema cliente na outra extremidade da conexão OpenVPN - a máquina está conectada ao mesmo domínio em que o servidor VPN está? Se não, ele está associado a um domínio diferente e existe uma relação de confiança entre os dois? Se não estiver associado a nenhum domínio, você ainda precisará adicionar as informações do domínio ao se conectar ao SSMS ou a qualquer cliente ou programa com o qual esteja tentando se conectar, mesmo que tenha criado o mesmo nome de usuário no cliente, como será tentando passar COMPUTERNAME \ dbtest e não DOMAIN \ dbtest por padrão.

Atualizar re: comentários

O servidor OpenVPN-AS não deve modificar como as informações do domínio são passadas - sugiro uma rápida captura do Wireshark em ambas as extremidades e, em seguida, examinar o fluxo com a tentativa de autenticação do SQL. Se o aplicativo usar SSL, isso pode ser mais difícil, mas você ainda poderá ver os detalhes do usuário sendo transmitidos. Além disso, se você tiver a origem para o aplicativo, verifique se ele está configurado para usar Integrated Security=SSPI em vez de ID do usuário e senha na cadeia de conexão. Dependendo da versão do SQL Server, há também um comando Trusted_Connection=True que você pode usar na cadeia de conexão. Este site é um ótimo recurso para criá-los.

Por fim, se o aplicativo estiver se conectando via ODBC, em vez do conector .NET nativo, você poderá criar um log de rastreamento por meio do ícone Data Sources (ODBC) no Painel de controle > Área de Ferramentas Administrativas.

Atualização 2

Você pode precisar ter o seu SQL Server configurado para o modo de autenticação mista. Mas eu ainda executaria a captura Wireshark o mais rápido possível para ver mais de perto o que está sendo passado.