Plano de fundo: um usuário teve seu nome alterado no Active Directory de Domain\oldname para Domain\newname e logado com êxito na rede com Domain\newname e, ainda assim, Domain\oldname aparece nas colunas LoginName e NTUserName no Profiler.
As permissões do SQL Server do usuário são concedidas por meio de um grupo configurado na segurança do SQL Server.
A pergunta: Alguém observou esse comportamento e sabe por que o SQL Server ainda está pegando Domain\oldname (sp_who2 mostra as mesmas informações)?
BTW, passei um tempo considerável pesquisando antes de postar a pergunta aqui e parece-me que não há problema real com o Profiler/SQL 2008 R2.
Acho que não posso comentar sobre sua pergunta, pois é a primeira vez que uso troca de pilha, mas esse é um grupo de AD em que o usuário está? Às vezes, as pessoas dizem grupo quando querem dizer função SQL, então eu só queria obter alguns esclarecimentos.
A razão pela qual pergunto é porque se o usuário tiver um login no servidor de domínio\usuário antigo quando você alterar o nome no AD para domínio\novousuário, terá que entrar no SQL e alterar o login para domínio\novousuário. Eu fiz isso e funciona perfeitamente bem e você não precisa fazer nada tão drástico quanto reiniciar o SQL. Não sei se o nome da conta mudará para o novo com o tempo, mas acho que não.
Não sei, no entanto, o que acontece quando o usuário faz parte apenas de um grupo AD que tem permissões e não tem login no servidor. Daí a necessidade de esclarecimento para que eu possa analisar isso.
Eu encontrei o mesmo problema em uma instância do SQL Server 2012 (SP2 aplicado). Ainda não encontrei a causa raiz, mas veremos o mecanismo de cache do AD, conforme sugerido por StanleyJohns.
Por acaso, encontrei uma solução simples que funcionou para mim sem reiniciar o servidor. Criei um login autenticado do Windows para o nome de usuário antigo (sim, funcionou) e o descartei - problema resolvido.
Após o create / drop, não consegui criar o mesmo login uma segunda vez, então parece que o "drop login" é outra maneira de forçar o nome de usuário antigo a sair do cache do AD.
O SQL Server pode levar algum tempo para resolver a alteração
. Ele armazena em cache com base no "sid" que permanece inalterado. Nenhum dano feito embora.
Não sei as regras exatas, mas já vi isso acontecer. No extremo, será limpo após uma reinicialização do SQL Server se for importante
Além disso, verifique sys.server_principals e os sys.database_principals relevantes para quaisquer entradas. Isso pode acontecer se os usuários possuírem quaisquer objetos (por exemplo, CREATE TABLE sem um qualificador de esquema).
Como ela é membro do AD Group, ela ainda tem acesso. Seu antigo nome de usuário que aparece no SQL Server pode ser do cache de login.
Você pode tentar fechar todas as conexões que o antigo nome de login possui, pois ele pode armazenar em cache o SID para o login dela. Como o login acabou de ser renomeado no AD, não acho que isso vá alterar o SID, portanto, o mapeamento ainda está lá para o SQL Server funcionar com o nome antigo.
As alterações do AD levarão algum tempo para se propagar. Além disso, o token de autenticação é armazenado em cache e é isso que está fornecendo acesso, enquanto ainda mostra o nome de login mais antigo.
Você pode tentar limpar o cache:
net use * /delete /yna linha de comando.Ou tente forçar a atualização das credenciais do AD:
control userpasswords2na linha de comando. Em seguida, vá para a guia 'Avançado' e selecione "Gerenciar senhas", isso permitirá que você modifique as senhas de rede salvas.Isso evitará que você precise reiniciar o servidor.
No meu caso, a única coisa que funcionou foi descartar o usuário e adicioná-lo novamente. Observe que você deve verificar e remover a propriedade dos trabalhos SQL, bem como o DBO de qualquer banco de dados.