Erros de confiança de domínio do Samba em uma interface específica

Question

Temos um domínio do Windows que também tem um servidor membro do RHEL. Todos os servidores têm uma conexão de rede primária com a LAN, mas alguns servidores também têm links dedicados privados para o servidor RHEL, que serve como uma cabeça para o armazenamento de SAN.

Este servidor em particular está executando o Samba 3.5.15 e está sendo executado no modo de autenticação ADS.

Os usuários podem acessar compartilhamentos neste servidor sem um problema na conexão LAN de nossos servidores Windows, mas se um usuário tentar acessar os compartilhamentos pelo link privado (isto é, um endereço 192.168.1.2 para o servidor RHEL) os usuários obtêm um erro "A relação de confiança entre esta estação de trabalho e o domínio primário falhou."

Quando vejo os registros, recebo muitos erros que você vê em qualquer lugar on-line - uma dessas situações em que nada se encaixa especificamente na minha situação. No entanto, aqui estão elas, talvez alguém veja algo que eu não faço:

Eu recebo esses dois erros juntos três vezes:

Failed to get schannel session key from server DC for domain DOMAIN

connect_to_domain_password_server: unable to open the domain client session to machine DC - NT_STATUS_ACCESS_DENIED

Então eu recebo esses dois erros:

domain_client_validate: Domain password server not available

check_ntlm_password: Authentication for user <the user trying to access the share> FAILED with error NT_STATUS_TRUSTED_RELATIONSHIP_FAILURE

Esse conjunto de erros é repetido três vezes cada para cada tentativa de acesso.

    

Answer 1

Este pode ser um caso altamente específico, e gostaria de ter uma resposta melhor, mas passei mais algumas horas hoje e notei que o Winbind estava desligado. Eu sei que o winbind estava rodando no passado, já que eu estava obtendo autenticações bem-sucedidas com o wbinfo -a. Naquela época, ainda não conseguíamos acessar o Samba por meio de links privados.

Independentemente disso, depois de ativar o Winbind, os links privados começaram a funcionar magicamente. Com certeza, voltando a desligá-los, quebrou-os novamente.

O tempo todo, no entanto, consegui acessar compartilhamentos através da conexão LAN principal. Eu ainda darei 50 pontos para qualquer um que possa explicar por que isso é: D

    

Answer 2

Como o Active Directory está usando o Kerberos para autenticação, parece que os erros podem estar relacionados ao nome reverso do IP privado que não corresponde ao nome com o qual o servidor RHEL ingressou no domínio. Se você definir o DNS reverso de 192.168.1.2 para corresponder ao nome do host do servidor, poderá resolver seus problemas.