veja link para uma possível solução (defina LsaLookupCacheMaxSize 0)
veja também o link (como os SIDs e os nomes das contas podem ser mapeados no Windows)
Um usuário no Active Directory teve uma alteração no nome da conta do SAM, mas um aplicativo da Web que está executando o IIS ainda o reconhece sob o antigo nome da conta SAM. Presumo que seja porque os principais do AD estão em cache.
As variáveis do servidor IIS na solicitação indicam a incompatibilidade:
Como o principal pode ser removido do cache no servidor para que ele escolha o novo nome da conta do SAM (de preferência sem reinicializar o servidor ou aguardar a duração da expiração do cache de 720 minutos)?
Você foi apontado na direção certa com o KB946358. O cache LSA está sendo limpo quando o servidor é reiniciado ou pode ser desativado completamente (mas isso exigirá a reinicialização primeiro). Estou muito interessado em encontrar etapas de reprodução precisas para isso. Veja minha pergunta sobre isso - Ainda sem resposta até agora, mas contém uma solução que não requer reinicialização para corrigir o usuário renomeado. Você precisa executar o seguinte script PS em seu servidor, no qual você tem uma data obsoleta no cache do LSA uma vez após renomear:
$objuser = new-object system.security.principal.ntaccount "domain\<new account name>"
$objuser.translate([system.security.principal.securityidentifier])
Fonte: link < br> Eu tentei esta solução e confirmo que funciona. Também pode encontrar o seguinte uma leitura interessante sobre este assunto: link
Eu apreciarei se alguém puder explicar como eu posso reproduzir isso ou pelo menos me dar uma ideia de como posso recriar a situação quando "consultas recorrentes por aplicativos mantêm a entrada de cache existente ativa para o tempo de vida máximo do cache entrada." (esta é uma explicação breve e lacônica da causa do problema em KB946358 )