Temos um TS809U que nos unimos ao domínio. As ações e direitos de acesso funcionam como deveria com os usuários do domínio e tudo é exatamente como deveria ser. Mas depois de algumas semanas / um mês, os usuários e grupos do domínio desaparecem do TS809, e eu tenho que voltar manualmente ao domínio novamente. Depois de reingressar no domínio, o processo se repete dentro do mesmo período de tempo e eu tenho que voltar ao domínio novamente.
Não há erros nos logs na interface da Web e ele mostra o NAS ingressando no domínio com êxito. Eu atualizei o TS809U para o último firmware 4.0.3 (de 3.x) na esperança de que isso pudesse resolvê-lo, mas o problema ainda persiste.
Alguém já se deparou com isso antes e saberia qual poderia ser o problema ou como solucionar o problema 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:
The session setup from the computer NASC473CD failed to authenticate. The name(s) of the account(s) referenced in the security database is NASC473CD$.
The following error occurred:
Access is denied.
O tempo entre o desaparecimento das entradas e a reaparição parece ser de 14 dias. Nosso domínio é (ainda) baseado no Windows Server 2003.
Atualizar
Atualização: O problema surgiu novamente, mas os registros realmente não mostraram nada de interessante. wbinfo -t (testando o segredo de confiança) não funcionou e (sem surpresa) também não wbinfo -c (alterando o segredo de confiança) . Eu descobri que a atual loja de bilhetes kerberos5 não tinha sido atualizada e a validade dos tickets do kerberos havia expirado, o que pode estar conectado. Eu adicionei agora /sbin/update_krb5_ticket ao crontab para ver se isso ajudará (e agora ele está sendo atualizado a cada hora).
Atualização 2014-02-25
Ainda não há sucesso. log.wb-DOMAINNAME mostra que aparentemente estamos sendo recusados, provavelmente devido a credenciais expiradas ou a segredos inválidos. Não tenho certeza de como progredir, pois a lista de tickets do kerberos ( klist ) mostrou um ticket válido quando 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 ao se referir a usuários). Pelo menos, o problema parece ser que o servidor responde com ACCESS_DENIED quando o samba tenta usar o recurso NETLOGON tanto quanto eu entendo. No entanto, descobri que um dos servidores DNS no TS809 estava configurado para um servidor externo - e não um servidor no domínio. Eu atualizei os servidores DNS para apontar para nossos AD DC-s para ver se esse poderia ser o motivo (se ele cair para o externo, ele receberá o host não encontrado em vez de tempos limite para hosts internos baseados em domínio) .
Atualização 2015-03-04. Script automatizado de junção implantado como uma solução alternativa.
Ainda não estamos perto de determinar uma solução duradoura, mas atualmente estamos vendo tempos limite toda semana. Este parece ser o mesmo tempo que um ticket 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 reingressa no servidor, se necessário. (Usando o net rpc join command do Samba.) "Username" é um usuário no domínio que tem acesso para ingressar em computadores no domínio (criamos um usuário para o qnap apenas para este 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 o cron (procure por qnap cron no Google sobre como configurar o cron corretamente). Isso funcionou decentemente nos últimos meses.