update para o samba 3.6.23-30 no servidor RedHat 6.7 interrompe conexões de clientes em floresta AD

Question

Eu tenho um servidor Samba (versão 3.6.23-30) em execução em uma versão 6.7 do servidor RedHat Enterprise. Ele está associado ao Active Directory e autentica os usuários no AD. O Winbind não está em execução (" Winbind não é usado; usuários e grupos são locais " situação, de acordo com o howto do Samba). Isso funcionou perfeitamente desde muito tempo, até a última atualização do samba 3.6.23-25 para 3.6.23-30 (na verdade várias correções para problemas de segurança, incluindo o Badlock, foram introduzidas 10 dias atrás em 3.6.23-26, mas isso versão nunca foi implantada aqui).

Eu tentei fazer o downgrade do Samba para 3.6.23-25, e isso resolve o problema (mas é claro que não é uma solução, dadas as correções de segurança contidas no 3.6. 23-26):

yum downgrade samba-3.6.23-25.el6_7.x86_64 samba-common-3.6.23-25.el6_7 samba-winbind-clients-3.6.23-25.el6_7 samba-client-3.6.23-25.el6_7 samba-winbind-3.6.23-25.el6_7

Após a instalação da atualização, os usuários não puderam se conectar mais aos compartilhamentos no servidor, recebendo diretamente uma mensagem "Acesso negado":

C:\Users\admin>net use \servername /user:INTRANET\username
The password or user name is invalid for \servername.

Enter the password for 'INTRANET\username' to connect to 'servername':
System error 5 has occurred.

Access is denied.

Isto não é devido a uma senha errada ou algo assim, porque, nesse caso, ele exibe o erro 1326 (nome de usuário ou senha está incorreto). A conexão foi tentada no Windows 7, Windows Server 2012 R2 e até mesmo no Windows XP SP3, com o mesmo resultado.

net ads testjoin diz que esse servidor está associado corretamente ao Active Directory. Eu também tentei sair do AD e voltar, mas isso não melhorou a situação.

A mensagem de erro para o cliente no log smbd (usando um nível de log de depuração) é:

[2016/04/18 14:09:19.133618,  2] ../libcli/auth/credentials.c:289(netlogon_creds_client_check)   credentials check failed
[2016/04/18 14:09:19.133674,  0] rpc_client/cli_netlogon.c:623(rpccli_netlogon_sam_network_logon)   rpccli_netlogon_sam_network_logon: credentials chain check failed 
[2016/04/18 14:09:19.134036,  0] auth/auth_domain.c:331(domain_client_validate)   domain_client_validate: unable to validate password for user username in domain INTRANET to Domain controller AD6. Error was NT_STATUS_ACCESS_DENIED. 
[2016/04/18 14:09:19.135842,  5] auth/auth.c:281(check_ntlm_password)   check_ntlm_password: winbind authentication for user [username] FAILED with error NT_STATUS_ACCESS_DENIED 
[2016/04/18 14:09:19.135917,  2] auth/auth.c:330(check_ntlm_password)   check_ntlm_password:  Authentication for user [username] -> [username] FAILED with error NT_STATUS_ACCESS_DENIED

Agora, se eu iniciar o daemon winbind, o problema de autenticação desaparecerá e os usuários poderão se conectar com êxito ao servidor Samba. No entanto, nesse caso, um segundo problema chato aparece. Tomando um diretório onde um usuário só tem direitos por causa da participação em um grupo (ou seja, o usuário é membro de um grupo UNIX no servidor Samba):

username$ ls -l /export/projects/testproject
drwxrws---.  2 root testgrp     4096 Apr 18 11:24 testproject

Aqui, username é membro do grupo testgrp e pode acessar com êxito o diretório:

username$ ls -l /export/projects/testproject/
-rw-r--r--. 1 root testgrp         0 Apr 18 11:24 test.txt

O mesmo usuário conectado ao servidor Samba pode não acessar o diretório (acesso negado). Antes da atualização (com winbindd desativado ), o acesso funcionava bem. Eu acho que isso tem algo a ver com o fato de que winbindd está em execução, como o testgrp group não mapeia para nenhum objeto AD (ele é exibido na guia Segurança do Windows Explorer como UNIX group \ testgrp ).

Existe alguma maneira de usar grupos locais como aqui com o winbind ativado (e sem a necessidade de criar objetos AD correspondentes)? Eu tentei adicionar isso ao smbd.conf:

idmap config * : backend = tdb
idmap config * : range = 1000000-1999999

mas não melhora nada, também porque acho que isso é mapear os usuários / grupos do AD para os do Linux, e não o contrário.

Ou, em alternativa, qual poderia ser o problema de "acesso negado" ao executar o Samba sem winbindd ? Isso é um bug introduzido pela atualização (e, portanto, deve ser enviado como um relatório de bug ao RedHat), ou melhor, um recurso devido a alguma mudança no modelo de segurança? / p>     

Answer 1

Eu enfrentei o mesmo problema: a autenticação do AD sem o winbind foi interrompida por mim.

A razão pela qual eu parei de winbind originalmente foi porque não conseguiu encontrar os grupos locais (embora pareça encontrar o mapeamento de usuário correto). Aqui está um trecho de log com o winbind ativado:

[2016/04/22 16:15:20.654780, 5] Auth/token_util.c:527(debug_unix_user_token)
UNIX token of user 1154
Primary group is 496 and contains 0 supplementary groups

Como você pode ver, o ID do usuário está correto (1154), mas os grupos não são encontrados, exceto o principal (que também está correto).

Parece que encontrei uma solução para corrigir esse problema: você deve adicionar a opção

username map script = /bin/echo

no /etc/smb.conf. Esta solução foi proposta aqui: link , mas não testado.

Como eu entendi nas man pages, essa opção força um mapeamento diferente após a autenticação do AD. Usando o comando echo, mapeie o nome para si mesmo, para que ele funcione sempre que o nome de usuário local for igual ao nome de usuário do AD. O resultado é o seguinte:

[2016/04/22 16:21:20.996130, 5] auth/token_util.c:527(debug_unix_user_token)
UNIX token of user 1154
Primary group is 496 and contains 4 supplementary groups
[... list of the groups ...]

Então, para resumir:

• ative o winbind para permitir a autenticação do AD;

• adicione username map script = /bin/echo no arquivo conf.

Não acho essa solução ideal, mas isso pode ser uma solução enquanto se espera algo melhor.

    

Answer 2

Sim, esse é um bug do Samba upstream, que foi apresentado aos usuários do RHEL nas atualizações mais recentes do pacote Samba. A Red Hat está ciente do problema e tem um patch candidato para consertá-lo, mas a partir de hoje (27 de abril) ainda não lançou uma atualização com o patch. Veja link e link para procurar atualizações sobre isso.

Nesse meio tempo, alguns usuários podem rodar o winbindd como uma alternativa, caso sua configuração permita; caso contrário, fazer o downgrade para a versão anterior como você fez é a única outra opção.

    

Answer 3

Então, isso pode não ser o lugar certo para colocar isso, mas eu não tenho pontos de reputação para comentar. Eu também estou tendo esse problema com o Scientific Linux 6.7 e atualizado na última quarta-feira em nossos sistemas. Eu encontrei que o problema está na resolução de nomes netbios (nmb). Se o usuário especificar o nome de domínio totalmente qualificado do diretório ativo, eles terão acesso, caso contrário, se usarem o nome netbios do domínio, veremos a mensagem "NT_STATUS_ACCESS_DENIED".

Eu também descobri que as caixas de janelas do domínio ingressado são capazes de acessar os compartilhamentos de samba, mas acredito que é porque eles têm um token atual do kerberos.

Atualização: Descobri que especificar o nome de domínio totalmente qualificado estava realmente engajado em um tíquete Kerberos e concedendo acesso. Descobri em uma máquina Ubuntu que a instalação do krb5-user permitiu o Nautilus para obter um tíquete Kerberos e, em seguida, permitir acesso não estava funcionando sem ele), então suponho que essa seja a parte que os clientes Apple / Mac e Windows estavam fazendo e que eu ainda não havia percebido ..

Embora esta não seja a resposta, espero que ajude. Respeitosamente, -Glen

    

Answer 4

Como afirmado em várias das respostas e comentários, este foi realmente um bug no pacote Samba após a inclusão das correções do Badlock. Como uma solução temporária, a solução fornecida por Tabs (usando winbindd e definindo uma diretiva username map script = /bin/echo no arquivo de configuração) estava funcionando perfeitamente. Agora, o pacote recentemente atualizado (samba-3.6.23-35) corrige o bug , tornando a solução desnecessária.