Erro de login de autenticação do Windows SQL Server 2008: o login é de um domínio não confiável

Ao tentar me conectar a uma instância do SQL Server 2008 usando o Management Studio, recebo o seguinte erro:

Falha na autenticação. O login é de um domínio não confiável e não pode ser usado com a autenticação do Windows. (Microsoft SQL Server, Erro: 18452)

Posso fazer o login usando a autenticação SQL sem problemas. Estou recebendo esse erro de repente. Eu tenho a autenticação de modo misto ativada.

Alguém tem alguma experiência com isto?

Informações adicionais: versão de 64 bits do SQL Enterprise Edition no Windows 2003 Server

Outra razão para isso acontecer (aconteceu comigo) ... é a senha do usuário expirar. Não percebi isso até que tentei acessar remotamente o servidor real e fui solicitado a alterar minha senha.

Para mim, isso aconteceu quando editei um drivers/etc/hostsarquivo em branco e adicionei uma entrada para um site local, mas esqueci de adicionar127.0.0.1 localhost

O problema foi causado por um servidor Active Directory inativo, que obviamente não conseguiu autenticar a conta do Windows. Obrigado pela sua ajuda.

Para qualquer outra pessoa que se depara com isso, eu tinha o seguinte em meu arquivo hosts:

127.0.0.1   localhost
127.0.0.1   customname

e eu precisava que fosse assim:

127.0.0.1   localhost
127.0.0.1   localhost   customname

"O problema foi causado por um servidor Active Directory inativo, que obviamente não conseguiu autenticar a conta do Windows"

Não é "claro - porque se o AD não estiver disponível, a autenticação Kerberos volta para NTLM (as credenciais da conta de domínio são armazenadas em cache localmente, pode-se fazer o login com ele mesmo se AD / Kerberos não estiver disponível). Acho que você tem possivelmente 2 condições simultâneas para que essa falha aconteça:

• SQL Server não é local (em outra máquina)
• A confiança está configurada "somente Kerberos"

ou outras configurações específicas de rede / servidor / AD / máquina de segurança

Tive esse problema para uma instância do servidor em minha máquina local e descobri que era porque estava apontando para 127.0.0.1 com algo diferente de "localhost" em meu arquivo hosts. Existem duas maneiras de corrigir esse problema no meu caso:

1. Limpe a entrada ofensiva apontando para 127.0.0.1 no arquivo hosts
2. use "localhost" em vez do outro nome que no arquivo hosts que aponta para 127.0.0.1

* Isso só funcionou para mim quando eu estava executando a instância do sql server em minha caixa local e tentando acessá-la da mesma máquina.

Certifique-se de não estar conectado a uma VPN em outro domínio \ usuário . Ou, pelo contrário, certifique-se de que está conectado, se for necessário.

Corrigi este problema na máquina, desativando a configuração de verificação de loopback:

1. Edite o registro do Windows: Iniciar -> Executar> Regedit
2. Navegue até: HKLM \ System \ CurrentControlSet \ Control \ LSA
3. Adicione um valor DWORD chamado “DisableLoopbackCheck”
4. Defina este valor para 1

tente usar um login válido diferente usando o comando RUNAS

runas /user:domain\user “C:\Program Files\Microsoft SQL Server\90\Tools\Binn\VSShell\Common7\IDE\ssmsee.exe” 

runas /user:domain\user “C:\WINDOWS\system32\mmc.exe /s \”C:\Program Files\Microsoft SQL Server\80\Tools\BINN\SQL Server Enterprise Manager.MSC\”" 

runas /user:domain\user isqlw 

Para mim, foi porque eu não adicionei a conta para ter as funções que queria usar no próprio banco de dados SQL. E também devido a tentativas de senha incorretas via problema de bloqueio de cópia e pasta de conta.

Ok, uma resposta completamente fora de mim. Eu estava recebendo este erro de um ambiente de desenvolvimento hospedado no VM VirtualBox. Três servidores; SharePoint, banco de dados SQL e controlador de domínio. O servidor SharePoint não pôde se conectar ao banco de dados de configuração. Eu ainda poderia me conectar via ODBC para autenticação Sql usando a conta SA, mas não a autenticação do Windows. Mas esse usuário ficaria feliz em entrar no SSMS no próprio servidor sql. Também recebi uma mensagem de erro melhor do ODBC e também verificando as mensagens de login com falha no servidor sql:

select text from sys.messages where message_id = '18452' and language_id = 1033

Não posso levar o crédito por isso porque pedi ajuda a um de nossos administradores de sistemas corporativos e ele diagnosticou em cerca de 5 minutos olhando algumas capturas de tela que enviei a ele. O problema era que o relógio do Controlador de Domínio estava configurado incorretamente! Não pude acreditar. Os servidores são configurados para rede Host Only, portanto, não há internet para sincronizar o relógio. Isso também explica por que voltar para um instantâneo anterior quando sei que o sistema estava funcionando não resolveu o problema.

Edit: Instalar o Guest Additions no servidor sincroniza o relógio do convidado com o host.

Há uma configuração no driver jTDS chamada USENTLMV2 que é definida como falsa por padrão. Definir isso como 'true' no meu software db (DBVisualizer) resolveu.

Outro cenário em que você pode ver isso é quando está tentando se conectar a outro servidor SQL a partir de uma sessão SSMS que já estava conectada enquanto você alterava sua senha. A sequência de eventos pode ser algo como:

1. RDP para Server-A (seu SQL Server), abra o SSMS e faça login
2. RDP para Server-B no mesmo domínio e altere sua senha
3. Retorne à sessão RDP no Servidor-A e por meio do SSMS, tente adicionar outro banco de dados a um grupo de disponibilidade AlwaysOn existente. Ao se conectar a réplicas, você obtém o erro de "domínio não confiável" -login

Para resolver, basta fazer logoff e fazer login novamente

Você pode estar enganado sobre o nome de usuário que usa localmente. Esse foi o meu caso no Windows 10 Home. Quando olho para os usuários no painel de controle, vejo o nome usrpc01 . No entanto, quando digito net config workstation, parece que o nome do usuário é spc01 . Parece que alguém renomeou o usuário, mas o nome interno permaneceu inalterado.

Sem saber como consertar o nome de usuário do Windows (e o nome da pasta sob C:\Users, que também se refere ao nome interno original), adicionei uma nova conta de usuário no meu servidor db.

Tenho tentado fazer logon em um SQL Server 2008 de uma conta de domínio. O SQL Server 2008 está hospedado em um computador de grupo de trabalho diferente que não faz parte do domínio. Por mais estranho que pareça, no servidor de grupo de trabalho em que o SQL Server 2008 está sendo executado, tive que ir para Propriedades do Sistema | Nome do computador (guia) | Alterar (botão) | Alteração do nome do computador | Mais ... (botão) e digite o "sufixo DNS primário deste computador" (estava em branco, então digite o sufixo desejado para sua rede) e marque a caixa "Alterar sufixo DNS primário quando a associação do domínio mudar". Isso permitiu que o processo de autenticação do Windows fosse concluído ao fazer logon no SQL Server 2008.

Tive que usar o netonly para fazer isso funcionar no Windows moderno:

runas /netonly /user:domain\user "C:\Program Files (x86)\Microsoft SQL Server\110\Tools\Binn\ManagementStudio\ssms.exe"

Outro motivo> alguém mudou a senha do usuário SQL padrão

isso aconteceu comigo alguns minutos atrás, ao mudar para um novo controlador de domínio ...

Eu digitei errado no arquivo hosts em C:\Windows\System32\drivers\etc

[Microsoft][SQL Server Native Client 11.0][SQL Server]Login failed. The login is from an untrusted domain and cannot be used with Windows authentication.

Certifique-se de ter uma entrada como abaixo

127.0.0.1   localhost
127.0.0.1   localhost   servername

Eu estava usando um alias para uma instância do SQL Server que apontava para "127.0.0.1". Mudá-lo para "localhost" resolveu o problema.

Se o seu Sql Server estiver rodando em um servidor que não faz parte de um domínio e na string de conexão você usa um nome de domínio totalmente qualificado (por exemplo, xyz.mypc.com) com Integrated Security = True, você pode ter que mudar para um o endereço IP, MachineName (SERVER01) ou o ponto (.) no caso de ser hospedado localmente.

Isso funcionou para mim, usar o fqdn resultou no erro acima.

para habilitar a autenticação do Windows, os dois computadores precisam estar no mesmo domínio. para permitir que os estúdios de gerenciamento passem as credenciais atuais e se autentiquem no sql box

Para mim, tenho que me desconectar (mudar o grupo de trabalho / domínio) do Domínio e reconectar.

E outro motivo possível: A nova conta local criada no servidor de banco de dados tinha o sinalizador: "O usuário deve alterar a senha no próximo login" definido.

Aqui está o que consertou para mim: Propriedades de conexão de rede Clique em: "Internet Protocol Version 4 (TCT / IPv4)". Clique no botão "Propriedades". Clique no botão "Avançado". Selecione a guia "DNS". Exclua o texto em "Sufixo DNS para esta conexão".

Também não consegui me conectar remotamente ao servidor SQL. Tanto o servidor SQL quanto o servidor remoto estavam no mesmo domínio. E havia me pedido uma mudança de senha alguns dias antes. Reiniciar o servidor SQL e o servidor remoto do qual eu estava tentando acessar o servidor SQL funcionou para mim.

No nosso caso, foi o fato de que o desenvolvedor estava executando o pool de aplicativos em sua própria conta e redefiniu sua senha, mas se esqueceu de alterá-la no pool de aplicativos. Duh ...

No meu caso, o servidor foi desabilitado no controlador de domínio. Entrei na UO COMPUTADORES no diretório ativo, cliquei com o botão direito do mouse no servidor, habilitei-o e fiz um gpupdate / force do servidor SQL. Demorou um pouco, mas finalmente funcionou.

No meu caso, no arquivo host, o nome da máquina está codificado com um IP mais antigo. Eu substituo o IP antigo pelo novo, o problema está resolvido.

Localização do arquivo host

WindowsDrive: \ Windows \ System32 \ drivers \ etc \ hosts

Modificações feitas 159.xx.xx.xxx MachineName

Nenhuma das opções acima funcionou para mim. O que tive de fazer foi: No SQL Server Management Studio, na tela de login, selecione Opções >> Na seção Rede, altere o protocolo de rede para Pipes nomeados.

Além disso, o que tive que fazer para que funcionasse com a <default>configuração foi desabilitar a rede wireless (a máquina também estava conectada à LAN com fio).

Minha correção foi alterar o arquivo web.config para correlacionar com meu novo nome de servidor para conexão SQL (a segurança de TI acabara de renomear netdom em minha caixa de desenvolvimento.