Como os logins funcionam em servidores vinculados (exemplos de T-SQL)

Ao configurar um servidor vinculado no SQL Server, configurar os logons às vezes pode ser confuso. Neste artigo, pretendo fornecer uma visão geral de alto nível de como o SQL Server mapeia logins locais para logins remotos no servidor vinculado.

Quando você usa sp_addlinkedserver para criar um servidor vinculado no SQL Server, um mapeamento padrão entre todos os logons no servidor local e os logons remotos no servidor vinculado é criado automaticamente. O SQL Server usa as credenciais do logon local ao se conectar ao servidor vinculado em nome do logon.

Portanto, se o seu login local tiver um login correspondente no servidor vinculado, com as mesmas credenciais e tiver as permissões apropriadas, você poderá se conectar usando seu login local. Não há necessidade de adicionar um login para o servidor vinculado (supondo que você queira se conectar usando seu próprio login local).

Mas se o seu login local não tiver um login correspondente no servidor vinculado (e com as mesmas credenciais), a conexão falhará.

Nesses casos, você pode usar sp_addlinkedsrvlogin para criar um login para o servidor vinculado para que os logins locais possam se conectar ao servidor vinculado mesmo quando não tiverem um login correspondente no servidor vinculado.

Isso pode resultar em usuários diferentes sendo usados no servidor vinculado, dependendo se eles têm ou não um login correspondente no servidor vinculado.

Para usuários conectados ao SQL Server usando o Modo de Autenticação do Windows, o SQL Server pode usar automaticamente as credenciais de segurança do Windows, desde que a delegação da conta de segurança esteja disponível no cliente e no servidor de envio e o provedor ofereça suporte ao Modo de Autenticação do Windows.

Os exemplos nesta página usam logins do SQL Server (eles não usam o modo de autenticação do Windows). Esses exemplos mostram os resultados que obtenho ao fazer login em um servidor vinculado em diferentes cenários usando logins locais do SQL Server.

Exemplo 1 – Servidor vinculado sem login explícito

Primeiro, criarei um servidor vinculado chamado Homer, mas não criarei nenhum login associado.

EXEC sp_addlinkedserver @server=N'Homer', @srvproduct=N'', @provider=N'MSOLEDBSQL', @datasrc=N'172.17.0.2', @catalog='Music';

Isso cria automaticamente um mapeamento padrão entre todos os logins no servidor local e os logins remotos no servidor vinculado.

Agora, tentarei executar a seguinte consulta de passagem no servidor vinculado usando vários logins locais:

SELECT * FROM OPENQUERY( Homer, 'SELECT CURRENT_USER AS ''CURRENT_USER'', ORIGINAL_LOGIN() AS ''ORIGINAL_LOGIN''');

Os resultados da consulta são os seguintes.

sa

Falha no login do usuário 'sa'.

Detalhes de login :Há um login chamado 'sa' em ambos os servidores, mas eles têm senhas diferentes. Ambos são membros do sysadmin função de servidor.

Lisa

+----------------+------------------+| CURRENT_USER | ORIGINAL_LOGIN ||----------------+------------------|| dbo | Lisa |+----------------+------------------+

Detalhes de login :Há um login chamado 'Lisa' em ambos os servidores e eles têm a mesma senha. Ambos são membros do sysadmin função de servidor.

Milhouse

Falha no login do usuário 'Milhouse'.

Detalhes de login :Este login é apenas no servidor local. Não há login correspondente no servidor vinculado.

Apu

Falha no login do usuário 'Apu'.

Detalhes de login :Este login é apenas no servidor local. Não há login correspondente no servidor vinculado.

Exemplo 2 – Adicionar um login para o servidor vinculado

Em seguida, criarei um login para o servidor vinculado.

EXEC sp_addlinkedsrvlogin @rmtsrvname=N'Homer', @useself=N'FALSE', @locallogin=NULL, @rmtuser=N'Maggie', @rmtpassword=N'BigStrong#Passw0rd';

Esse login corresponde a um login no servidor remoto, portanto, é criado um mapeamento entre eles.

Agora, cada usuário executará a seguinte consulta novamente:

SELECT * FROM OPENQUERY( Homer, 'SELECT CURRENT_USER AS ''CURRENT_USER'', ORIGINAL_LOGIN() AS ''ORIGINAL_LOGIN''');

Os resultados da consulta são os seguintes.

sa

+----------------+------------------+| CURRENT_USER | ORIGINAL_LOGIN ||----------------+------------------|| Maggie | Maggie |+----------------+------------------+

Detalhes de login :Há um login chamado 'sa' em ambos os servidores, mas eles têm senhas diferentes. Ambos são membros do sysadmin função de servidor.

Lisa

+----------------+------------------+| CURRENT_USER | ORIGINAL_LOGIN ||----------------+------------------|| Maggie | Maggie |+----------------+------------------+

Detalhes de login :Há um login chamado 'Lisa' em ambos os servidores e eles têm a mesma senha. Ambos são membros do sysadmin função de servidor.

Milhouse

+----------------+------------------+| CURRENT_USER | ORIGINAL_LOGIN ||----------------+------------------|| Maggie | Maggie |+----------------+------------------+

Detalhes de login :Este login é apenas no servidor local. Não há login correspondente no servidor vinculado.

Apu

+----------------+------------------+| CURRENT_USER | ORIGINAL_LOGIN ||----------------+------------------|| Maggie | Maggie |+----------------+------------------+

Detalhes de login :Este login é apenas no servidor local. Não há login correspondente no servidor vinculado.

Portanto, todos os logins locais puderam se conectar ao servidor vinculado. Mesmo os logins que não possuem um login remoto correspondente no servidor vinculado foram capazes de se conectar. Isso ocorre porque todos eles usaram o login Maggie. Obrigado Maggie!

Exemplo 3 – Restringir o Login

Agora vou atualizar o login do servidor vinculado para que fique restrito ao Milhouse.

Mas para fazer isso, precisarei remover o servidor vinculado e criá-lo novamente. Se eu não fizer isso, o SQL Server usará os mapeamentos existentes e obterei os mesmos resultados acima.

EXEC sp_dropserver 'Homer', 'droplogins';EXEC sp_addlinkedserver @server=N'Homer', @srvproduct=N'', @provider=N'MSOLEDBSQL', @datasrc=N'172.17.0.2', @catalog ='Música';EXEC sp_addlinkedsrvlogin @rmtsrvname=N'Homer', @useself=N'FALSE', @locallogin='Milhouse', @rmtuser=N'Maggie', @rmtpassword=N'BigStrong#Passw0rd'; 
 Então neste caso eu uso @locallogin='Milhouse' (em vez de @locallogin=NULL como no exemplo anterior). Isso adicionará um mapeamento de login para apenas um login local (Milhouse). 
 
 Cada usuário executa a seguinte consulta novamente:
 SELECT * FROM OPENQUERY( Homer, 'SELECT CURRENT_USER AS ''CURRENT_USER'', ORIGINAL_LOGIN() AS ''ORIGINAL_LOGIN''');
 
 Os resultados da consulta são os seguintes. 
 sa
 Msg 18456, Level 14, State 1, Line 1Falha no login do usuário 'sa'.
 
 Detalhes de login :Há um login chamado 'sa' em ambos os servidores, mas eles têm senhas diferentes. Ambos são membros do sysadmin função de servidor. 
 Lisa
 +----------------+------------------+| CURRENT_USER | ORIGINAL_LOGIN ||----------------+------------------|| dbo | Lisa |+----------------+------------------+
 
 Detalhes de login :Há um login chamado 'Lisa' em ambos os servidores e eles têm a mesma senha. Ambos são membros do sysadmin função de servidor. 
 Milhouse
 +----------------+------------------+| CURRENT_USER | ORIGINAL_LOGIN ||----------------+------------------|| Maggie | Maggie |+----------------+------------------+
 
 Detalhes de login :Este login é apenas no servidor local. Não há login correspondente no servidor vinculado. 
 Apu
 Msg 18456, Level 14, State 1, Line 1Falha no login do usuário 'Apu'.
 
 Detalhes de login :Este login é apenas no servidor local. Não há login correspondente no servidor vinculado. 
 
 Portanto, a principal conclusão aqui é que, mesmo quando você restringe o login a apenas um login local, isso não impede que outros logins locais se conectem ao servidor vinculado. Se eles tiverem um login correspondente no servidor vinculado, eles poderão acessá-lo usando seu próprio mapeamento de login que foi criado quando sp_addlinkedserver foi executado. 
 Exemplo 4 – Restringir na verdade a apenas um login
 
 Se você realmente deseja restringi-lo a apenas um login e não mais, você pode usar sp_droplinkedsrvlogin para descartar todos os mapeamentos de login que sp_addlinkedserver cria antes de executar sp_addlinkedsrvlogin . 
 EXEC sp_dropserver 'Homer', 'droplogins';EXEC sp_addlinkedserver @server=N'Homer', @srvproduct=N'', @provider=N'MSOLEDBSQL', @datasrc=N'172.17.0.2', @catalog ='Música';EXEC sp_droplinkedsrvlogin 'Homer', NULL;EXEC sp_addlinkedsrvlogin @rmtsrvname=N'Homer', @useself=N'FALSE', @locallogin='Milhouse', @rmtuser=N'Maggie', @rmtpassword=N 'BigStrong#Passw0rd';
 
 Agora vamos executar a consulta mais uma vez a cada login:
 SELECT * FROM OPENQUERY( Homer, 'SELECT CURRENT_USER AS ''CURRENT_USER'', ORIGINAL_LOGIN() AS ''ORIGINAL_LOGIN''');
 
 Os resultados da consulta são os seguintes. 
 sa
 Mensagem 7416, Nível 16, Estado 1, Linha 1 O acesso ao servidor remoto é negado porque não existe mapeamento de login.
 
 Detalhes de login :Há um login chamado 'sa' em ambos os servidores, mas eles têm senhas diferentes. Ambos são membros do sysadmin função de servidor. 
 Lisa
 Mensagem 7416, Nível 16, Estado 1, Linha 1 O acesso ao servidor remoto é negado porque não existe mapeamento de login.
 
 Detalhes de login :Há um login chamado 'Lisa' em ambos os servidores e eles têm a mesma senha. Ambos são membros do sysadmin função de servidor. 
 Milhouse
 +----------------+------------------+| CURRENT_USER | ORIGINAL_LOGIN ||----------------+------------------|| Maggie | Maggie |+----------------+------------------+
 
 Detalhes de login :Este login é apenas no servidor local. Não há login correspondente no servidor vinculado. 
 Apu
 Mensagem 7416, Nível 16, Estado 1, Linha 1 O acesso ao servidor remoto é negado porque não existe mapeamento de login.
 
 Detalhes de login :Este login é apenas no servidor local. Não há login correspondente no servidor vinculado. 
 Configuração do Login Remoto
 
 A conexão bem-sucedida ao servidor vinculado é apenas a primeira etapa do processo. Uma vez conectado, sua capacidade de fazer coisas será afetada pelas permissões do usuário remoto para o qual seu login está mapeado. 
 
 Por exemplo, se Maggie foi criada no servidor remoto assim:
 CRIAR LOGIN Maggie COM SENHA ='BigStrong#Passw0rd';USE Music;CRIAR USUÁRIO Maggie PARA LOGIN Maggie;GRANT SELECT ON DATABASE::Music TO Maggie;
 
 Tudo o que ela pode fazer é executar SELECT declarações contra o banco de dados 'Música'. Portanto, qualquer pessoa que se conectar ao servidor vinculado usando o login de Maggie estará limitada apenas a isso. 
 
 É uma boa prática conceder apenas as permissões necessárias, mas não mais. 
 Documentação oficial
 
 Este artigo teve como objetivo fornecer uma visão geral de alto nível de como os logons funcionam com servidores vinculados. Existem muitos outros cenários que não abordei aqui. 
 
 Se você estiver interessado em saber mais, confira os seguintes links para a documentação da Microsoft:
  sp_addlinkedserver 
 sp_addlinkedsrvlogin 
 sp_testlinkedserver 
  sp_droplinkedsrvlogin 
  sp_dropserver 
 OPENQUERY()