Estou executando um procedimento do banco de dados X para o banco de dados Y.
No banco de dados Y deve haver uma inserção do usuário.
Nesta imagem, a primeira coluna é o Login, a segunda é o papel que tem todas as permissões necessárias (tem o INSERT na tabela que precisamos).
O logon está atribuído corretamente à função e a função possui todas as permissões necessárias.
mas quando executo o procedimento, recebo aqueles famosos erros:
Msg 229, Level 14, State 5, Procedure PROCEDURENAME, Line 165 [Batch Start Line 2]
The INSERT permission was denied on the object 'XXXXXXXXXXX', database 'DB', schema 'dbo'.
Msg 229, Level 14, State 5, Procedure PROCEDURENAME, Line 484 [Batch Start Line 2]
The INSERT permission was denied on the object 'YYYYYYYYYYYYYY', database 'DB', schema 'dbo'.
Msg 229, Level 14, State 5, Procedure PROCEDURENAME, Line 527 [Batch Start Line 2]
The INSERT permission was denied on the object 'YYYYYYYYYYYYYY', database 'DB', schema 'dbo'.
Msg 229, Level 14, State 5, Procedure PROCEDURENAME, Line 570 [Batch Start Line 2]
The INSERT permission was denied on the object 'YYYYYYYYYYYYYY', database 'DB', schema 'dbo'.
Criei outro Login de teste, dei exatamente as mesmas permissões e funcionou.
Como posso descobrir o que está bloqueando a inserção para este login? Eu até fiz um rastreamento para ver se encontro mais erros, nada no eventviewer também.
O login não tem permissões explícitas. é apenas a associação da função com as permissões.
As permissões de função estão corretas:
EDITAR:
eu tentei de tudo desde recriar o login do windows e refazer todas as permissões. O que notei é:
Consegui criar um login (sql login com senha) e funcionou.
Tentei como teste apenas inserir os dados na tabela com o login original do windows, falhou, então removi da ROLE e dei a permissão INSERT para ela e AINDA FALHA. mesmo com permissão de inserção no banco de dados, ele falha ao inserir dados.
Testar com um logon do SQL Server não ajudará se o problema for com um logon do Windows. Isso ocorre porque os logins do Windows têm a capacidade de autenticar por meio de várias fontes (próprio e/ou um ou mais grupos do Windows).
Como o login do Windows é autenticado?
sys.sys.server_principals),sys.server_principals, mas é membro de um ou mais grupos que tem entrada emsys.server_principals),Para logins do Windows, todos os
GRANTs eDENYs em todos os meios possíveis de autenticação são examinados. Mesmo se houver um logon explícito criado no SQL Server para esse logon do Windows, isso não será cancelado ou terá precedência sobre quaisquer permissões associadas a quaisquer grupos do Windows dos quais eles sejam membros que também sejam listados como logons. Pode ser que haja associação em um ou mais grupos do Windows/AD que tenham umaDENYou alguma outra restrição, e essas tenham precedência sobreGRANTs. Listar grupos por meioNET USER {login}do prompt de comando.OP respondeu:
Isso não remove o problema, mas identifica a causa do problema para que agora possa ser resolvido.
Uma solução possível seria usar o Module Signing (link para o meu site de informações), embora eu tivesse que testar para ver como ele lidaria com um
DENYpara ter precedência. De qualquer forma, você não precisaria mexer com as funções e permissões diretas para objetos, então provavelmente ainda melhor, mesmo que ocorra o mesmo problema causado peloDENY.Use o
ScriptLoginPermissionsprocedimento armazenado, implante-o em qualquer banco de dados de usuário:https://github.com/aleksey-vitsko/Database-Administrator-Tools/blob/master/Permissions%20-%20ScriptLoginPermissions.sql
Execute-o especificando o nome do login:
Além de mostrar todas as permissões para esta conta, este SP também mostrará a associação ao grupo, incluindo grupos AD/Windows
Então você deve verificar se algum dos grupos do AD, tem permissão DENY na tabela em questão.
Execute o SP especificando o nome do grupo desta vez: