Atualizar

Atualizar

Temos um TS809U que associamos ao domínio. Os compartilhamentos e direitos de acesso funcionam como deveriam com os usuários do domínio e tudo está como deveria ser. Mas depois de algumas semanas/um mês, os usuários e grupos do domínio desaparecem do TS809 e tenho que reingressar manualmente no domínio novamente. Depois de ingressar novamente no domínio, o processo se repete dentro do mesmo período e tenho que ingressar novamente no domínio.

Não há erros nos logs da interface web e mostra que o NAS ingressou no domínio com sucesso. Atualizei o TS809U para o firmware 4.0.3 mais recente (de 3.x) na esperança de que isso resolvesse o problema, mas o problema ainda persiste.

Alguém já encontrou isso antes e gostaria de saber qual poderia ser o problema ou como solucioná-lo ainda mais?

A única mensagem que consegui encontrar no visualizador de eventos que faz referência ao NAS é um 5722 que pode apontar na direção do comentário abaixo:

A configuração da sessão do computador NASC473CDfalhou na autenticação. Os nomes das contas referenciadas no banco de dados de segurança são NASC473CD$.
Ocorreu o seguinte erro:
Acesso negado.

O tempo entre o desaparecimento e o reaparecimento das entradas parece ser de 14 dias. Nosso domínio (ainda) é baseado no Windows Server 2003.

Atualizar

Atualização: o problema surgiu novamente, mas os logs não mostraram nada de interessante.wbinfo -t(testando o segredo de confiança)não funcionou e (sem surpresa) nemwbinfo -c(alterando o segredo de confiança). Descobri que o atual armazenamento de ingressos Kerberos5 não havia sido atualizado e a validade dos ingressos Kerberos havia expirado, o que pode estar conectado. Agora adicionei /sbin/update_krb5_ticketo crontab para ver se isso ajuda (e agora está sendo atualizado a cada hora).

Atualização 25/02/2014

Ainda sem sucesso. log.wb-DOMAINNAMEmostra que aparentemente nosso acesso está sendo recusado, provavelmente devido ao tempo limite de credenciais ou segredos inválidos. Não tenho certeza de como progredir, pois a lista de tickets do Kerberos ( klist) mostrava um ticket válido quando isso ocorreu.

log.wb-DOMAINNAMEmostra:

[2014/02/25 03:05:20.545176,  3] winbindd/winbindd_pam.c:1902(winbindd_dual_pam_auth_crap)
  could not open handle to NETLOGON pipe (error: NT_STATUS_ACCESS_DENIED)
[2014/02/25 03:05:20.545198,  2] winbindd/winbindd_pam.c:2003(winbindd_dual_pam_auth_crap)
  NTLM CRAP authentication for user [DOMAINNAME]\[MACHINE$] returned NT_STATUS_ACCESS_DENIED (PAM: 4)
[2014/02/25 03:05:20.548424,  3] winbindd/winbindd_pam.c:1841(winbindd_dual_pam_auth_crap)
  [20497]: pam auth crap domain: DOMAINNAME user: MACHINE$

(as mesmas mensagens de erro ocorrem quando se refere aos usuários). Pelo menos o problema parece ser que o servidor responde ACCESS_DENIEDquando o samba tenta usar o NETLOGONrecurso, pelo que entendi. No entanto, descobri que um dos servidores DNS no TS809 estava configurado para um servidor externo - e não para um servidor no domínio. Atualizei os servidores DNS para apontar para nossos AD DC-s para ver se esse poderia ser o motivo (se cair para o externo, o host não será encontrado em vez de tempos limite para hosts internos baseados em domínio) .

Atualização 04/03/2015. Script de reingresso automatizado implantado como uma solução alternativa.

Ainda não estamos mais perto de determinar uma solução duradoura, mas atualmente vemos tempos limite a cada semana. Parece ser o mesmo horário de um tíquete Kerberos válido, mas não consegui encontrar nenhuma configuração que o altere.

No entanto, criei um pequeno script que verifica se perdemos a lista de usuários do domínio e entra novamente no servidor, se necessário. (Usando o Sambanet rpc joincomando.) "nome de usuário" é um usuário no domínio que tem acesso para ingressar computadores no domínio (criamos um usuário para o qnap apenas para esse fim):

COUNT=`wbinfo -g | grep DOMAINNAME | wc -l`

if [ "$COUNT" -lt "1" ]
then
    /usr/local/samba/bin/net rpc join -Uusername%password
fi

Este script é executado no qnap com cron (pesquise qnap cron no Google para saber como configurar o cron corretamente). Isso funcionou decentemente nos últimos meses.

Responder1

Parece-me um problema com a senha da conta da máquina. Por Design em um Domínio 2k3 a redefinição é gerada a cada 30 dias, mas a redefinição da senha da conta da máquina pode ser acionada pelo cliente sempre que desejar.

Normalmente, o Membro primeiro cria a nova senha e depois a transfere para o DC.

Por alguma razão, parece que seu qnap está gerando uma nova senha depois de duas semanas, mas não é capaz de enviá-la ao DC por causa de um canal seguro quebrado.

Não conheço os recursos oferecidos pelo qnap, você poderia fazer login via ssh? Eu acho que é um sistema baseado em Unix?! Talvez haja uma opção para desativar a senha da conta da máquina. O trust não vai parar de funcionar depois desses 30 dias.

Talvez interessante: Coleção de links:

informação relacionada