Estou tentando alternar entre contextos de usuário, mas ORIGINAL_LOGIN()
retorna alguma conta mágica do AD em vez da conta da máquina local com a qual me conectei. Isso torna impossível alternar de volta para o contexto do chamador original. Estou me conectando como um usuário local do Windows.
SELECT ORIGINAL_LOGIN(), SYSTEM_USER
retorna:
MicrosoftAccount\[email protected] | localMachine\localUser
O login com o qual me conectei é de fato localMachine\localUser
. Nem tenho certeza de onde vem a conta, o Windows meio que inventou isso sozinho.MicrosoftAccount\[email protected]
Agora considere este procedimento armazenado:
CREATE OR ALTER PROCEDURE spTest WITH EXECUTE AS OWNER AS
BEGIN
-- Do high-privilege things ...
EXECUTE AS LOGIN = ORIGINAL_LOGIN(); -- Fails!
-- Impersonate caller, check some permissions
REVERT;
-- Do more high-privilege things ...
END
GO
EXEC spTest;
A EXECUTE AS LOGIN
representação invariavelmente falha com:
Could not obtain information about Windows NT group/user 'MicrosoftAccount\[email protected]', error code 0x54b.
Obviamente, since não é usado ou configurado em lugar nenhum. Isso o torna completamente inútil para nós, e não tenho ideia de como alternar temporariamente de volta para o contexto do chamador.MicrosoftAccount\[email protected]
ORIGINAL_LOGIN()
Note que o código acima é apenas para demonstração. A base de código real é significativamente mais complexa com cadeias de chamadas de procedimento armazenado e gatilhos envolvidos.
Como posso ORIGINAL_LOGIN()
retornar o login original?
Não estamos exatamente usando o Azure/Entra AD, ou pelo menos não de propósito. Mas o novo Windows realmente tenta arduamente amarrá-lo ao framework Azure/Entra AD, quer você goste ou não.
exec xp_logininfo
somente expõe localMachine\localUser
. Não há nada que o vincule à conta do Azure/Entra AD. A solução funciona bem quando não há Azure/Entra AD envolvido.
Se possível, gostaria de desabilitar completamente o recurso Azure/Entra AD para SQL Server. Nem sei por que o SQL Server o escolhe em vez de localMachine\localUser
.
Se houver máquinas Windows Client envolvidas que hoje em dia são quase forçadas a usar contas do Microsoft Live, você sempre encontrará esse problema.
Até onde sei, esse comportamento não está documentado e exigiria um relatório de bug/caso de suporte para que algum engenheiro tentasse entender o que realmente está acontecendo, e muito menos consertar.
Da perspectiva do SQL Server, a conta do Microsoft Live é a identidade original que abriu a conexão. Você pode ver isso em
select * from sys.dm_exec_sessions
. Daí todas as chamadas paraORIGINAL_LOGIN
ir para a identidade do Microsoft Live.Receio que você precise encontrar uma lógica ou fluxo diferente para realizar o que pretende.