Temos um estranho problema de samba que afeta apenas um usuário. Nossa configuração do samba é a seguinte:
Servidor Red Hat Enterprise Linux versão 5.4 (Tikanga) - Servidor Samba
Versão do Samba 3.0.33-3.14.el5 - versão do Samba
Padrão de controlador de domínio WIN2008R2 - Windows DC
Windows 7 64 bit - PCs clientes
O usuário mencionou que enfrentou esse problema depois de forçar o desligamento de seu PC algumas semanas atrás. Por direito, para todos os usuários quando acessamos \sambaservername no windows ele mostrará todos os compartilhamentos no servidor samba, mas para este usuário uma vez que ele inicialize seu PC ele não será capaz de acessar \sambaservername , mensagem de erro
Windows cannot access
\sambaservername
Solução atual para resolver o problema:
Tente acessar um compartilhamento em \sambaservername , por exemplo, \sambaservername\sharedfolder1 . Mas, mesmo quando fizer isso, ele irá primeiro solicitar um erro no começo, a mensagem de erro é a seguinte
Logon failure: unknown user name or bad password.
o usuário precisa inserir as credenciais novamente e ele pode acessar o compartilhamento. Depois disso, ele poderá acessar \sambaservername sem problemas. Mas quando ele reiniciar seu computador, o problema persistirá.
Solução de problemas feita até agora:
Garanta as seguintes configurações:
Vá para: Painel de controle → Ferramentas administrativas → Diretiva de segurança local Selecione: Políticas locais → Opções de segurança
"Segurança de rede: nível de autenticação do LAN Manager" → Enviar LM & Respostas NTLM "Segurança de sessão mínima para o SSP do NTLM" → desmarque: Exigir criptografia de 128 bits
Aconselhe o usuário a redefinir sua senha e tente novamente, mas o problema ainda persiste
Tentei minha conta no PC dos usuários, não há problemas. Tentei conta do usuário em outro servidor Windows 7 PC incluindo o meu mas o problema ainda persiste. O Windows XP não tem esse problema.
Assegure-se de que não haja crendenciais armazenadas no PC com Windows 7. Verifiquei o gerenciador de credenciais no Painel de Controle, assim como digite este comando rundll32.exe keymgr.dll, KRShowKeyMgr
Reinicie o daemon winbindd no servidor samba, mas sem sucesso.
Eu suspeito que isso se deva a algum problema de armazenamento em cache, mas não tenho certeza de onde está o problema. Sempre que o usuário tiver erro ao acessar \sambaservername , os seguintes erros serão registrados no servidor samba:
[2012/10/10 17:10:26, 1] smbd/sesssetup.c:reply_spnego_kerberos(316)
Failed to verify incoming ticket with error NT_STATUS_LOGON_FAILURE!
[2012/10/10 17:10:27, 1] smbd/sesssetup.c:reply_spnego_kerberos(316)
Failed to verify incoming ticket with error NT_STATUS_LOGON_FAILURE!
[2012/10/10 17:10:27, 1] smbd/sesssetup.c:reply_spnego_kerberos(316)
Failed to verify incoming ticket with error NT_STATUS_LOGON_FAILURE!
[2012/10/10 17:10:27, 1] smbd/sesssetup.c:reply_spnego_kerberos(316)
Failed to verify incoming ticket with error NT_STATUS_LOGON_FAILURE!
[2012/10/10 17:10:27, 1] smbd/sesssetup.c:reply_spnego_kerberos(316)
Failed to verify incoming ticket with error NT_STATUS_LOGON_FAILURE!
[2012/10/10 17:10:27, 1] smbd/sesssetup.c:reply_spnego_kerberos(316)
Failed to verify incoming ticket with error NT_STATUS_LOGON_FAILURE!
[2012/10/10 17:10:27, 1] smbd/sesssetup.c:reply_spnego_kerberos(316)
Failed to verify incoming ticket with error NT_STATUS_LOGON_FAILURE!
[2012/10/10 17:10:27, 1] smbd/sesssetup.c:reply_spnego_kerberos(316)
Failed to verify incoming ticket with error NT_STATUS_LOGON_FAILURE!
[2012/10/10 17:10:27, 1] smbd/sesssetup.c:reply_spnego_kerberos(316)
Failed to verify incoming ticket with error NT_STATUS_LOGON_FAILURE!
[2012/10/10 17:10:27, 1] smbd/sesssetup.c:reply_spnego_kerberos(316)
Failed to verify incoming ticket with error NT_STATUS_LOGON_FAILURE!
Mas após a solução alternativa, não haverá mais erros. Eu suspeito que depois de ler o artigo abaixo, algumas alterações precisam ser feitas no diretório \var\samba\cache :
Existem vários usuários usando o servidor samba e gostaria de resolver esse problema sem nenhum impacto.
Eu vi o seguinte artigo:
"logon offline do winbind (G) Este parâmetro é projetado para controlar se o Winbind deve permitir o login com o módulo pam_winbind usando Credenciais em Cache. Se ativado, o winbindd armazenará credenciais de usuário de logins bem-sucedidos criptografados em um cache local.
Padrão: logon offline do winbind = false
Exemplo: logon offline do winbind = true "
Alguma ideia de como excluir a entrada de um usuário no cache local?
Não tenho certeza se o comando nbtstat -R (que "limpa e recarrega o cache remoto tabela de nomes. ") ou o nbtstat -RR one (que " envia pacotes de lançamento de nomes para WINs e depois inicia a atualização. ") pode fazer qualquer coisa para impor o tipo de atualização que procura para ...
Se você quiser conferir o manual, procure aqui ..
Verifique se o ntpd está sincronizado com o controlador de domínio. Eu tive o mesmo problema até hoje notei uma diferença de tempo de 45 minutos entre o servidor ofensivo e o controlador de domínio. Uma vez que eu corri o ntpdate funcionou bem.
Na minha experiência, isso geralmente é o resultado do desvio de tempo no controlador de domínio ou, no seu caso, com apenas um cliente tendo um problema, a máquina cliente de conexão. Como o Kerberos inclui parâmetros relacionados ao tempo na solicitação do servidor de autenticação e na resposta do servidor de autenticação (AS_Req e AS_rep), uma discrepância ampla fará com que o token de sessão seja rejeitado.
AS_Req inclui o tempo de vida do token solicitado: AS_REQ = (PrincipalClient, PrincipalService, IP_list, Lifetime)
AS_Rep inclui o registro de data e hora do DC e a vida útil aplicada: AS_REP = {PrincipalService, Timestamp, Lifetime, SKTGS}
Portanto, se a variação de tempo estiver fora do tempo de vida, a conexão será rejeitada.
CONJUNTO: Eu não consegui confirmar com a documentação que a vida útil é especificada em minutos, mas acho que é porque eu tive uma máquina que trabalhava intermitentemente e a única razão pela qual eu conseguia pensar era que estava certo na fronteira da vida. Então, por cerca de 30 segundos, funcionaria e, em seguida, o minuto mudaria e as conexões seriam rejeitadas.