Início / dba / Perguntas / 285495
Accepted
Cell-o
Asked: 2021-02-17 05:37:02 +0800 CST

SQL Server - Falha no logon. O login é de um domínio não confiável e não pode ser usado com autenticação do Windows [duplicado]

  • 772

Estou recebendo o erro abaixo ao tentar conectar o SQL do servidor remoto. O login local está funcionando bem. Alguém pode ajudar nisso. Desde já, obrigado.

"Falha no login. O login é de um domínio não confiável e não pode ser usado com autenticação do Windows. [CLIENT: 10.186.12.10]"

Meu ambiente:

Cliente - já testou domínio AD/DNS ingressado

SQL Server remoto - já ingressou no domínio AD/DNS do prod

Eu tenho executado dentro do ambiente isolado do servidor AD/DNS de teste. Nenhuma relação entre o servidor AD/DNS de teste e o servidor AD/DNS prod. Nome de domínio de teste: contoso.com Caso contrário, nome de domínio PROD: contoso.com

Testar Servidor AD/DNS: 10.190.10.1 Prod Servidor AD/DNS: 10.150.10.1

Eu também tenho que ingressar na máquina do cliente AD/DNS do prod? Quero dizer, existe alguma solução alternativa?

Desde já, obrigado,

Última atualização:

Resolveu meu problema.

sql-server

3 respostas

  1. Acredito que o problema é que o domínio da máquina cliente não é confiável pelo servidor remoto ao fazer login via Autenticação do Windows no SSMS . Você ainda poderá fazer logon com suas credenciais do AD de seu cliente SSMS local, alternando o modo de autenticação de autenticação do Windows para Azure Active Directory-senha .

    Se você encontrar o erro subsequente " A cadeia de certificados foi emitida por uma autoridade que não é confiável ", você pode dizer ao SSMS para confiar manualmente clicando no botão "Opções" na janela Login. Em seguida, na guia "Propriedades de conexão", marque a caixa de seleção "Certificado de servidor confiável". Em seguida, clique no botão "Conectar".

    Exemplo de captura de tela

    • 0
  2. Best Answer

    Se você estiver apenas usando o SSMS, poderá iniciá-lo usando as credenciais de domínio remoto via CMD, atualizando o caminho da instalação do SSMS

    c:\windows\system32\runas /netonly /user:Doamin\ExampleUser "C:\Program Files (x86)\Microsoft SQL Server\140\Tools\Binn\ManagementStudio\Ssms.exe"

    Ou você pode inserir as credenciais no Windows Credential Manager (pode ser feito por meio da interface do usuário ou CMD)

    cmdkey /add:"Server:1433" /user:"Domain\ExampleUser" /pass:"P45sW0rD!"
    • 0

  3. Quando o cliente tenta se conectar, ele passará seu tíquete Kerberos existente, aquele criado a partir de seu controlador de domínio no teste AD quando o usuário fez login.

    O SQL Server passará o tíquete para seu próprio DC, que falhará. Como o domínio de produção não tem relação de confiança com o domínio de teste, não há como o DC confiar no que esse tíquete representa.

    Para que isso funcione sem mover máquinas entre domínios, você precisa configurar uma relação de confiança entre os dois domínios do AD. Em seguida, o DC de produção pode verificar o ticket com o outro DC.

    Há muitas maneiras de criar relações de confiança. É importante ressaltar que eles podem ser unidirecionais, portanto, você não precisa ter os dois domínios confiando um no outro. Você também pode configurar um Forest Trust, que pode ser mais fácil de gerenciar.

    Os dois DCs precisam poder se comunicar, portanto, talvez seja necessário abrir portas e configurar registros DNS .

    Eu sugiro que você fale com seu administrador de sistema ou com quem administra seu domínio AD, se houver.

    • -2

relate perguntas