Eu tenho uma pergunta sobre o cache SID do SID em um servidor membro do domínio. Recentemente eu me deparo com o problema quando alguns usuários após o seu nome foi alterado no AD tem dificuldades de acessar o aplicativo que eu apoio, e eles também têm nome de usuário antigo mostrado em sites do SharePoint.
Depois de algumas pesquisas / pesquisas do Google, eu encontrei após Microsoft KB 946358 e acabei sendo a causa.
Este artigo é um pouco lacônico e apenas diz que
The cache entries do time out, however chances are that recurring queries by applications keep the existing cache entry alive for the maximum lifetime of the cache entry
e sugere para desativar esse cache em um servidor membro, definindo a chave de registro LsaLookupCacheMaxSize como 0 , o que desativa o cache local do LSA.
Esta é uma opção um pouco estranha, pois pode ter impacto no desempenho e não parece uma solução real. Pesquisando usando LsaLookupCacheMaxSize como uma palavra-chave usada por muitas pessoas nesse problema, mas não encontrei nenhuma explicação final sobre como abordar isso corretamente.
Portanto, confirmo que a desativação do cache local do LSA ajuda, mas não é uma opção para ambientes de produção reais; a reinicialização do servidor também limpará esse cache; não é uma solução muito boa também para reinicializar seu servidor de aplicativos sempre que o usuário tiver sido renomeado. Graças a esta postagem no blog que encontrei solução viável, mas ainda está interessado em resolver isso corretamente.
Como eu vi esse problema com o aplicativo somente no ambiente ao vivo, enquanto o mesmo aplicativo no ambiente de teste não tem esse problema (o usuário renomeado funciona, a entrada antiga não fica presa no cache); para o mesmo domínio, e os mesmos usuários foram usados para testes. Isso está bem de acordo com o texto do MS KB de que alguma atividade do aplicativo pode causar a retenção do registro no cache para sempre, mas o que vem depois? Apenas mais perguntas ...
Como posso reproduzir isso?
LsaLookupCacheExpireTime tem valor padrão de 7 dias , portanto, mesmo o aplicativo não muito ativo o tocará durante esse período e não deverá causar esse problema, certo? Quero dizer, após as consultas do aplicativo, o servidor membro não deve aumentar o TTL da entrada do cache por 7 dias novamente, certo? Caso contrário, todos os registros ficarão no cache para sempre ... E, novamente, o que impede que o servidor do domínio membro vá ocasionalmente para o DC e, se a incompatibilidade do registro for encontrada, elimine o registro errado no cache?
Olhando para a hora das postagens sobre problemas similares (não há postagens / perguntas recentes sobre isso) pode ser que ela tenha sido endereçada por algum patch MS, ou em versões mais recentes do Windows Server (no meu caso eu vi esse problema no Windows Server 2008 SP1 Standard, o ambiente de teste tem o 2008 SP1 Enterprise).
Tenho a ideia de usar o Procmon para monitorar o caminho do cache do LSA e identificar qual aplicativo tocou na entrada do cache com muita frequência, mas não está claro qual poderia ser o próximo passo, pois não entendo exatamente quais são as condições necessárias para manter esse gravar no cache para sempre ... Diminuir cegamente esta atividade / alterar as configurações do aplicativo parece não ser muito boa solução também ....
Em suma, eu quero ser capaz de reproduzir isso, ou seja, entender quais condições causam entrada de cache obsoleta para o usuário renomeado "preso" no cache local. Eu apreciarei se alguém puder lançar alguma luz aqui.
Tags cache active-directory sid