Fiz algumas pesquisas SSISDB
e encontrei um usuário AllSchemaOwner
que não está associado a nenhum login do SQL Server:
SELECT p.name, p.type_desc
FROM SSISDB.sys.database_principals as p
LEFT JOIN sys.sql_logins as l ON p.sid = l.sid
WHERE p.principal_id > 4 and p.type = 'S' and l.sid is Null;
No entanto, existem muitos objetos no banco de dados, que foram criados com as credenciais dessa conta.
Eu tentei executar um desses procedimentos e foi executado com sucesso.
Quando tentei recriar esse cenário em meu banco de dados de teste, ele me retornou um erro:
USE [master]
GO
CREATE LOGIN [Test2] WITH PASSWORD=N'test', DEFAULT_DATABASE=[master], CHECK_EXPIRATION=OFF, CHECK_POLICY=OFF
GO
USE [MyTestDB]
GO
CREATE USER [test3] FOR LOGIN [test2]
GO
SELECT 1 as test INTO tbl_Test;
GO
GRANT SELECT ON tbl_Test TO [test3]
GO
CREATE PROCEDURE sp_Select_TEST
WITH EXECUTE AS 'Test3'
AS SELECT * FROM tbl_Test;
GO
EXECUTE sp_Select_TEST;
GO
DROP LOGIN [test2];
GO
EXECUTE sp_Select_TEST;
GO
DROP PROCEDURE sp_Select_TEST
GO
DROP TABLE tbl_Test
GO
DROP USER [test3];
Msg 15517, Level 16, State 1, Procedure sp_Select_TEST, Line 0 [Batch Start Line 29]
Cannot execute as the database principal because the principal "test3" does not exist, this type of principal cannot be impersonated, or you do not have permission.
Então, a pergunta é: como é possível que o procedimento criado com uma opção WITH EXECUTE AS 'AllSchemaOwner'
seja executado com sucesso enquanto o login do SQL Server não existe para esse usuário?
Finalmente encontrei uma resposta:
você pode criar um usuário de banco de dados, que não terá um login SQL e não poderá autenticar, mas terá permissões e pode ser especificado na
WITH EXECUTE AS
cláusula para procedimentos e funções armazenados.A maneira simples de criar esse usuário é apenas usar a cláusula
WITHOUT LOGIN
durante a criação do usuário: