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


110

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


1
qual é a conta de login do Windows usada para se conectar ao servidor sql?
Gulzar Nazim

1
é minha conta de domínio que uso desde sempre
jinsungy

2
alguma mudança recentemente, como uma mudança de senha? às vezes as credenciais são armazenadas em cache.
Gulzar Nazim

1
nenhuma mudança recentemente .. a única coisa que aconteceu foi apenas uma reinicialização de nossos servidores ..
jinsungy

Respostas:


49

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.


Só tive esse problema. Surpreendentemente, ainda consegui me conectar ao Analysis Server: O
GôTô

Posso confirmar ... isso estava causando o mesmo problema para mim também. Atualizar a senha resolveu instantaneamente o problema de conexão!
wjhguitarman

1
Aconteceu para mim (Win 10), embora a minha senha não tivesse expirado, eu apenas a alterei através de 'Ctrl-Alt-Del'. Eu reiniciei e estava bem novamente. Extremamente irritante, alterar a senha também afetou a capacidade de funcionamento do Outlook e do OneDrive.
aSystemOverload

Obrigado, salvei minha vida
user3201809

Mudei minha senha com Ctrl-Alt-Del, (Win10) e comecei a receber este erro. Reiniciar não resolveu.
Ymagine Primeiro de

38

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


1
Funcionou para mim também. De alguma forma, eu tive alguma entrada no arquivo hosts que não deveria estar lá (eu não coloquei lá e não me lembro de ter instalado nenhum software que pudesse fazer isso). Removê-lo resolveu o problema
LazyOne de

2
Para o Windows, você pode uupdate este arquivo fazendo isso rackspace.com/knowledge_center/article/...
oaamados

1
Você salvou meu dia! Obrigado
Houari

29

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


18

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

16

"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


2
Também vi esse problema com servidores nomeados AD em uma máquina local FWTW
Keith Hoffman

1
Portanto, o que devo fazer se o servidor SQL não for local?
Behnam Heydari

Onde e como alterar a configuração de "confiança", que atualmente é "apenas Kerberos"?
TPAKTOPA

10

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.


10

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.


Nossa, nunca teria pensado !! Obrigado! (Eu estava conectado à VPN da empresa no MBP, usando SSMS no VMWare)
jenjenut233

Isso ajudou no meu caso. Tive que usar o nome de domínio na conexão VPN.
arni de

Esse era o meu problema. Eu estava prestes a deixar como uma resposta, mas encontrei a sua primeiro. Fez todo o sentido assim que o vi. obrigado
billpennock

4

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

3

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 

Tentei fazer isso com outra conta do Windows no mesmo domínio e obtive o mesmo erro.
jinsungy

tente obter os logs de eventos do servidor e do cliente. acho que precisamos de mais detalhes.
Gulzar Nazim

3

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.


3

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.


Eu também tive problemas de autenticação de AD este ano, que eventualmente foram atribuídos à configuração incorreta do relógio em um de nossos controladores de domínio. Tive que usar o Wireshark para provar ao nosso departamento de TI que era um problema de rede, mas assim que os fiz ver ... eles consertaram o relógio e tudo estava bem.
Ty H.

3

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.


3

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


3

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.


1

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.


1

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"


1

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 ...


Aconteceu comigo. Eu mudei minha senha um tempo atrás e esqueci (as credenciais foram salvas)
aproximadamente

1

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

1

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.


1

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.


0

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


3
Isso é impreciso. Eles não precisam estar no mesmo domínio. Eles podem estar em domínios diferentes se uma conta com o mesmo nome e senha for configurada em ambos os domínios.
Cody Schouten

0

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


Você quer se conectar usando uma conta local ao SQL Server remoto no grupo de trabalho? Isso funcionará apenas se as contas de Convidado (ou alguma outra comum) com a mesma senha estiverem habilitadas na máquina do SQL Server, na máquina de conexão e no próprio SQL Server como login.
Gennady Vanin Геннадий Ванин

Quero dizer, desligue-se e depois volte a interagir com o grupo de domínio. Em seguida, tente fazer login novamente usando autenticação do Windows (credenciais de domínio) em MSSQL remoto.
f01

0

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.


0

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".


0

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.


0

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 ...


0

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.


0

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


0

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).


0

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.

Ao utilizar nosso site, você reconhece que leu e compreendeu nossa Política de Cookies e nossa Política de Privacidade.
Licensed under cc by-sa 3.0 with attribution required.