Por que suser_name () não refletia uma alteração no nome da conta do AD?

Um dos nomes de nossos usuários foi legalmente alterado, portanto, alteramos o nome de usuário do Active Directory para corresponder - de domínio \ nome antigo para domínio \ nome novo. No entanto, quando suser_sname () é chamado por esse usuário em um procedimento armazenado, ele retorna o nome antigo, não o novo.

A pesquisa no Google me levou ao KB 946358, o que sugere que o nome deles está sendo armazenado em cache no servidor e não atualizado, provavelmente porque suser_name () está chamando LsaLookupSids. No entanto, a solução alternativa nesse artigo envolve a reinicialização do servidor e, mesmo que fosse, eu ainda gostaria de entender o problema.

Se eu mudar meu contexto para o deles, o nome correto voltará:

EXECUTE AS LOGIN = 'domain\newname'
GO
SELECT suser_name()   --returns 'domain\newname'

... Eu teria assumido que isso também chamaria LsaLookupSids e, portanto, retornaria o nome incorreto. Parece provável que eu realmente não entenda os mecanismos em funcionamento aqui.

Algumas observações que podem ser importantes:

Este usuário não possui um login explícito no servidor. Mas eles são membros de um grupo do AD que faz isso. O nome alterado (domínio \ novo nome) aparece no conjunto de resultados para exec xp_logininfo 'domain\ADGroupName', 'members'; domínio \ nome antigo não.
O usuário está chamando suser_name () de dentro de um procedimento armazenado, chamado de uma consulta de passagem em um MDB do Access 2003.
Alteramos muitos nomes de contas de usuários no passado, mas só observamos esse problema na última semana (duas alterações foram feitas na semana passada, ambas parecem exibir o problema).
O servidor está executando o Sql Server 2008 SP3 x64 no Windows 2008 R2 Datacenter edition.

O que está acontecendo? Como DBA, o que devo fazer ou onde devo procurar para resolver isso?

— Warrior Bob
fonte

O serviço MSSQLSERVER (ou qualquer que seja o nome da instância) está fazendo logon como sistema local ou um logon real? O valor pode ser armazenado em cache no registro da conta que está executando a pesquisa. No seu caso, você estava logado e fazendo a solicitação. Eu estou pensando que talvez se você estiver usando uma conta regular para executar o SQL Server (como deveria), talvez faça logon no SQL Server como o logon do "SQL Server", execute o seu EXECUTE ASe SELECT SUSER_NAME()teste. Além disso, você já tentou SUSER_SNAME()alguma das outras 100 variações?

— Solomon Rutzky

Tente criar um logon na instância usando o novo nome. Isso não afetará suas permissões. Execute SUSER_SNAME(), ele deve ser corrigido nesse ponto. Você pode tentar largar o login e ver se ele mantém o novo nome.

— Kenneth Fisher

@srutzky É uma instância padrão do MSSQLSERVER em execução em uma conta de domínio. Infelizmente não tenho a senha para fazer login. Ainda não tentei suser_sname () como usuário, acredito que seja o mesmo que suser_name () se não houver argumentos. Vale a pena tentar embora - obrigado!

— Warrior Bob

O SQL Server corresponde a todas as contas pelo SID - seja SQL ou domínio. Como os SIDs de domínio vêm do diretório ativo, a alteração do nome não altera o SID. Se foi armazenado em cache, o nome antigo será retornado. Se já existir um logon, o nome do logon será retornado, ainda com o mesmo nome ou não, desde que os SIDs correspondam. É o mesmo para usuários de bancos de dados.

— Sean Gallardy

Você pode tentar correr ipconfig /flushdnse ipconfig /registerdnsde uma linha de comando para ver se isso resolve o problema.

— RLF 22/01

Isso pode estar relacionado ao armazenamento em cache com o Kerberos? (apenas um palpite, porém, pode não estar relacionado) http://blogs.technet.com/b/tspring/archive/2014/06/23/viewing-and-purging-cached-kerberos-tickets.aspx

— Normoe
fonte

Não posso dizer com certeza que esse é o problema, mas acredito que isso ou algo parecido. A reinicialização do servidor (que ocorreu por motivos separados) parece ter esclarecido, pelo menos nesse caso. Não está claro se ele voltará a aparecer.

— Warrior Bob

Essa é uma boa sugestão, eu deveria ter pensado nisso! :-) Foi o que fizemos antes para esclarecer os problemas dos kerberos em cache. Que bom que você foi bem sucedido!

— Normoe 22/01