Início / dba / Perguntas / 313928
Accepted
sada
Asked: 2022-06-30 23:14:03 +0800 CST

Falha no login ao criar o servidor vinculado

  • 772

Eu quero criar um servidor vinculado no servidor de banco de dados B para o servidor de banco de dados A em um servidor de desenvolvimento onde apenas o SQL Management Studio está instalado. Todos os três servidores estão no mesmo domínio. A mensagem de erro

Falha no login do usuário 'NT AUTHORITY\ANONYMOUS LOGON'. (Microsoft SQL Server, Erro: 18456)

quando eu quero criar o servidor vinculado.

Não entendo porque porque consegui criar o servidor vinculado em outro servidor onde é verdade que um servidor SQL está instalado, mas acho que não teve nada a ver com isso.

Tentei cuidar desse problema, mas não consegui resolver.

ATUALIZAR

https://www.sqlservercentral.com/blogs/how-to-resolve-user-error-in-kerberos-configuration-manager

sql-server linked-server

1 respostas

  1. Best Answer

    Você deve criar um script para o objeto Linked Server e adicionar esse script ao seu post, para que tenhamos mais o que fazer.

    Quando vejo a mensagem de erro:

    Falha no login do usuário 'NT AUTHORITY\ANONYMOUS LOGON'. (Microsoft SQL Server, Erro: 18456)

    E eu sei que pelo menos 3 servidores estão em jogo (como você mencionou " Todos os três servidores estão no mesmo domínio "), então imediatamente meu primeiro pensamento é verificar a configuração adequada do SPN e a delegação do Kerberos . No mencionado SPN Books Online, na seção Linked Servers and Delegation , ele até menciona " A delegação com servidores vinculados requer autenticação Kerberos ".

    Eu experimentei esse erro muitas vezes no passado porque meus SPNs não foram configurados corretamente ou porque a delegação Kerberos não foi configurada entre os dois servidores que estou tentando usar um servidor vinculado. A delegação configura uma relação de confiança entre esses servidores, de modo que você tenha permissão para acessar o servidor Ade um servidor vinculado no servidor Bquando estiver fazendo a conexão com o servidor Bde um terceiro servidor C. Isso é conhecido como salto duplo e uma relação de confiança deve ser estabelecida com delegação para permitir que uma conexão Kerberos passe por toda a autenticação do Windows de servidor Cpara servidor A, como medida de segurança.

    O acima assume que no seu objeto Linked Server, na seção Security, você escolheu " Be made using the Login's current security context " que tenta passar pelo contexto de segurança do usuário autenticado atual.

    Como alternativa, se você alterou isso para "Ser feito usando este contexto de segurança" e inseriu as credenciais para um logon SQL (em oposição a um logon de autenticação do Windows) que tem acesso a server A, isso também resolveria seu problema. Porque agora, ele não tentaria mais passar pelo contexto de segurança do usuário autenticado no momento, mas usaria o do login SQL especificado. Isso faz com que não seja mais um salto duplo, do ponto de vista da segurança.

    A desvantagem dessa solução é que você precisa garantir que o SQL Login escolhido tenha o acesso apropriado no servidor Aque suporta todos os seus casos de uso do Servidor Vinculado. Qualquer pessoa que use esse Linked Server agora estará acessando o servidor Acomo o logon SQL para o qual você inseriu as credenciais em seu objeto Linked Server. Você precisa ter cuidado ao traçar a linha entre o provisionamento excessivo e insuficiente das permissões do SQL Login no servidor A.

    Se você quiser ir com a primeira opção de configuração adequada de delegação Kerberos e precisar de ajuda adicional, poderá encontrar informações mais informadas postando em ServerFault , pois é mais um tópico de infraestrutura/segurança do que de banco de dados.

    • 1

relate perguntas