Problemas de kerberos RPCSS em estações de trabalho do Windows gravadas

Question

Ao fazer alguns problemas de solução de problemas não relacionados (pelo menos eu penso assim, problemas de impressora compartilhada) me deparei com um conjunto de entradas do log de eventos que me preocupam.

Machine Name:  labcomputer82
Source: Security-Kerberos
Event ID: 4
Event Description:

The Kerberos client received a KRB_AP_ERR_MODIFIED error from the server labcomputer143$. The target name used was RPCSS/imagemaster4.ad.domain.edu. This indicates that the target server failed to decrypt the ticket provided by the client. This can occur when the target server principal name (SPN) is registered on an account other than the account the target service is using. Please ensure that the target SPN is registered on, and only registered on, the account used by the server. This error can also happen when the target service is using a different password for the target service account than what the Kerberos Key Distribution Center (KDC) has for the target service account. Please ensure that the service on the server and the KDC are both updated to use the current password. If the server name is not fully qualified, and the target domain (AD.DOMAIN.EDU) is different from the client domain (AD.DOMAIN.EDU), check if there are identically named server accounts in these two domains, or use the fully-qualified name to identify the server.

Existem três nomes de máquinas usados nesta mensagem. Ele é gerado no labcomputer82, ele está tentando falar com outra estação de trabalho de laboratório chamada labcomputer143, e o serviço em questão (RPCSS) refere-se ao nome da máquina de onde esta máquina foi fotografada (e possivelmente também de labcomputer143, não tenho certeza ). O que me fez levantar ambas as sobrancelhas é que a máquina chamada labcomputer82 está tentando usar um SPN de RPCSS/imagemaster4.ad.domain.edu .

O atributo SPN no objeto de computador no AD parece bem. Tem todos os nomes que deveria ter.

Essas máquinas são criadas usando o Ghost e (pelo menos neste caso específico) o sysprep não foi usado. Dos mais de 3.000 objetos de computador em nosso domínio do AD, cerca de 1.700 deles são assentos de laboratório de computador que são frequentemente visualizados e, a partir de setembro, a maioria foi criada usando o método Ghost / Profile-Copy em vez do método Ghost / sysprep. . Se este relatório de erro é algo importante que o Windows está trabalhando silenciosamente, talvez o kerberos seja corrompido para essas máquinas e está voltando ao NTLMv2, eu gostaria de saber para poder adicionar pressão na minha unidade para a adoção do sysprep.

    

Answer 1

Você deve absolutamente fazer o Sysprep para garantir que cada máquina tenha um ID exclusivo. O Sysprep também faz outras coisas e a falha em fazer o Sysprep pode fazer com que vários componentes do Windows falhem imprevisivelmente.

Apenas olhando a mensagem (menos os detalhes do seu sysprep), isso é o que podemos inferir. Um processo em execução no labcomputer82 estava tentando se comunicar com o imagemaster4. Mas parece que o nome com o qual se resolveu e acabou se comunicando foi identificando-se como labcomputer143. É provável que você tenha problemas de DNS aqui. Talvez uma saída nslookup de imagemaster4 e labcomputer143 deva ser comparada para garantir que eles não usem o mesmo endereço IP.

O SPR RPCSS / imagemaster4.ad.domain.edu que o computador de mesa 82 solicitou foi apresentado ao que o computador de mesa considerava imagemaster4. No entanto, acabou sendo uma máquina / serviço identificando-se como um computador de laboratório143. Obviamente, as senhas de contas de computador para labcomputer143 e imagemaster4 serão diferentes. Assim, o bilhete criptografado usando o imagemaster4 não será descriptografado pelo labcomputer143. Daí o erro.

Eu recomendo 2 coisas. 1. você descarta quaisquer suspeitas sobre o uso do sysprep. Certifique-se de que cada máquina tenha um ID exclusivo para si e se associe no AD com uma conta de computador exclusiva. 2. Leia as entradas do blog de solução de problemas do kerberos no link para entender melhor a solução desses problemas e causas comuns / prováveis.

    

Answer 2

Os detalhes são em grande parte como suspeitas de maweeras. A falta de Sysprep na geração da imagem da unidade deixou o serviço RPCSS convencido de que o SPN era RPCSS/imagemaster4.ad.domain.edu . Quando tentou obter seu TGT, ele estava contatando imagemaster4.ad.domain.edu , que na época era ocupada por um computador chamado labcomputer143 . Que falhou.

Isso estava causando fallback para o NTLM para essas estações.

Como solução alternativa, adicionei uma entrada DNS preemptiva no DNS do domínio para imagemaster4.ad.domain.edu (não atualmente em serviço) para 127.0.0.1. Depois de examinar os logs de eventos de várias estações de trabalho afetadas, eles agora estão funcionando corretamente para o Kerberos. Esta é uma solução alternativa e deixará de funcionar quando o imagemaster4 se unir ao domínio e registrar suas entradas de DNS. Mas pelo menos eu tenho um método agora.

Sysprep para o futuro.