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
NASC473CD
falhou na autenticação. Os nomes das contas referenciadas no banco de dados de segurança sãoNASC473CD$
.
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_ticket
o crontab para ver se isso ajuda (e agora está sendo atualizado a cada hora).
Atualização 25/02/2014
Ainda sem sucesso. log.wb-DOMAINNAME
mostra 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-DOMAINNAME
mostra:
[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_DENIED
quando o samba tenta usar o NETLOGON
recurso, 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 join
comando.) "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:
- http://support.microsoft.com/kb/810977, a ID do evento 5722 está registrada no controlador de domínio baseado no Windows Server
- http://blogs.technet.com/b/asiasupp/archive/2007/01/18/típico-sintomas-quando-secure-channel-is-broken.aspx
- http://www.dekart.com/howto/howto_logon/howto_logon_samba/trust_accounts/