Respostas:
Você provavelmente já sabe disso, mas tenha paciência comigo.
Os computadores têm senhas no AD, assim como os usuários. Não sabemos a senha do nosso computador e ela muda regularmente via lógica interna.
A resposta curta é que a senha do computador não é mais válida e, portanto, o AD não confia mais nesta máquina para logins.
Por quê? Quão? Muitas coisas causam isso. Algo interferiu no processo de alteração da senha ou fez com que a máquina voltasse para uma senha antiga. Os possíveis culpados incluem:
Espero que ajude.
Estendendo-se à resposta de Katherine:
Uma estação de trabalho perderá a confiança do controlador de domínio se sua conta tiver sido substituída. É perfeitamente possível (com as permissões corretas) adicionar um computador com um nome que já exista no domínio, mas isso fará com que o computador anteriormente conhecido como esse nome perca a confiança no Controlador de Domínio.
Um motivo pode ser o desvio do relógio. Se o relógio da estação de trabalho se afastar mais de 5 minutos do servidor, ele perderá a conexão com o Domínio. Isso pode ser causado por hardware escamoso, ou quando o sistema é desligado por um longo período de tempo, ou às vezes quando um laptop geralmente está longe da rede, etc.
O processo de senha do computador AD (documentado aqui) não mudou muito e certamente não é a causa raiz de problemas de canais quebrados. (na verdade, é o CLIENTE que altera a senha e a senha está isenta da política de expiração de senha. Agora, dependendo do sistema operacional do cliente, é onde as coisas ficam interessantes. 1 motivo para o bloqueio é o XP. Se for XP e abaixo, o cliente mudará é senha - e tente comunicar a nova senha ao controlador de domínio. Em 7 ou superior, o cliente não tentará até ter uma conexão com um controlador de domínio. Os problemas de replicação de domínio podem causar falhas no canal. O caso mais comum são as imagens de um sistema onde o mesmo nome foi reutilizado.Os problemas de sincronização de tempo também podem causar problemas com o canal, e na maioria dos casos você pode avaliar o que aconteceu (se você quiser) ativando o log de logon de rede (https://support.microsoft.com/en-us/kb/109626 ) e examinando os logs para saber por que o canal não foi configurado. Falha na sysprep de uma imagem também parece causar um problema (não descobri exatamente o motivo, mas desmembrar e voltar a parecer sempre resolve o problema)
A outra maneira seria usar o ADUC e redefinir a conta do computador (se ela ficar fora de sincronia com o domínio), simplesmente clique com o botão direito do mouse no nome do computador e escolha "Redefinir conta" (cerca de 80% das vezes isso solucionará o problema) )
O "porquê" é que, no Microsoft Windows 2003, eles estenderam sua implementação de diretório para incluir forçar as estações de trabalho a redefinirem suas senhas a cada 30 dias. Eu sei bem, ele quebrou muitas instalações do SAMBA que eu mantinha na época.
Normalmente, essa redefinição de senha é totalmente automática, mas já vi muitos casos em que esse design simplesmente não funciona. Quando desligo um notebook por um tempo e tento fazer login com uma conta não armazenada em cache, recebo imediatamente essa mensagem de erro, independentemente do SO Microsoft pós-2000 que eu uso.
Portanto, a maneira mais fácil de manter uma rede funcionando de maneira transparente nessa situação projetada no modo de falha é modificar ou desativar essa configuração de política no nível do Domínio: Diretivas de Grupo / Configurações do Windows / Configurações de Segurança / Configurações de Segurança / Diretivas Locais / Opções de Segurança, e procure: Membro do domínio: idade máxima da senha da conta da máquina Membro do domínio: desativar as alterações da senha da conta da máquina
Eu espero que isso ajude.