Grupos aninhados no Linux com winbind

Question

Temos vários servidores RHEL6 conectados ao Active Directory usando o winbind. Todos os servidores são configurados de forma idêntica usando uma ferramenta de gerenciamento de configuração. No entanto, os servidores produzem resultados diferentes ao consultar grupos usando o comando groups e / ou sudo. Getent e winbind, no entanto, retornam resultados consistentes corretos em todos os servidores.

user.name1 e user.name2 são membros do grupo test.group1. test.group1 é um membro do grupo test.group2

A execução dos seguintes comandos é consistente em todos os servidores:

# getent group test.group1 
test.group1:*:16126:user.name1,user.name2

# getent group test.group2
test.group2:*:16125:user.name1,user.name2

# wbinfo --group-info test.group1 
test.group1:*:16126:user.name1,user.name2

# wbinfo --group-info test.group2
test.group2:*:16125:user.name1,user.name2

No entanto, o servidor A retorna incorretamente:

# groups user.name2
test.group1

O servidor B retorna corretamente:

# groups user.name2
test.group1
test.group2

A configuração do Samba se parece com:

   winbind use default domain = true
   winbind offline logon = false
   winbind separator = + 
   winbind enum users = Yes
   winbind enum groups = Yes
   winbind nested groups = Yes
   winbind expand groups = 10
   server string = Linux Server
   strict locking = no
   wins server = 192.168.0.1
   idmap config * : range = 10000-50000000
   idmap config * : backend = rid
   idmap config SENT : range = 10000-50000000
   idmap config SENT : default = yes 
   idmap config SENT : backend = rid
   idmap uid = 10000-50000000
   idmap gid = 10000-50000000

O nsswitch.conf se parece com:

passwd:     files winbind
shadow:     files winbind
group:      files winbind

Eu arriscaria um palpite para dizer que a resposta está em algum lugar no PAM ou talvez em um erro de pesquisa do winbind. Quaisquer pensamentos ou sugestões de onde procurar? Winbind / servidores foram reiniciados, arquivos tdb reconstruídos. O problema pode ser intermitente também.

Editar:

Finalmente, vamos dar uma olhada nessa questão. Eu reconstruí a autenticação usando SSSD em vez de winbind e o mesmo ocorre

sssd.conf

[sssd] 
config_file_version = 2 
domains = sent.local 
services = nss, pam 
debug_level = 1

[nss] 

[pam] 

[domain/sent.local]
id_provider = ad 
auth_provider = ad 
access_provider = ad

default_shell = /bin/bash 
fallback_homedir = /home/domain/%u

use_fully_qualified_names = False

Agora, temos alguns resultados interessantes, os usuários que nunca foram administradores de domínio têm o mesmo resultado de antes, até que pré-armazenemos em cache os grupos dos quais sabemos que são membros, por exemplo:

[root@test-smg1 - (11:46:40) sssd]#  id test.user5
uid=1084806380(test.user5) gid=1084800513(domain users) 
groups=1084800513(domain users)

[root@test-smg1 - (11:46:43) sssd]#  getent group testg2
testg2:*:1084806126:test.user5,test.user4,test.user3,test.user2

[root@test-smg1 - (11:46:46) sssd]#  id test.user5
uid=1084806380(test.user5) gid=1084800513(domain users) 
groups=1084800513(domain users),1084806126(testg2)

[root@test-smg1 - (11:46:49) sssd]#  getent group testg2-nest
testg2-nest:*:1084806125:test.user4,test.user3,test.user2,test.user5

[root@test-smg1 - (11:46:54) sssd]#  id test.user5
uid=1084806380(test.user5) gid=1084800513(domain users) 
groups=1084800513(domain users),1084806126(testg2),1084806125(testg2-nest)

Isso me faz pensar que o problema pode estar mais na direção do diretório ativo e desta implementação específica do ADs do que um problema do lado do linux. Tornar um usuário membro dos administradores de domínio faz com que todos os grupos sejam exibidos corretamente. Remover o usuário dos administradores de domínio deixa o usuário nesse estado "fixo".

    

Answer 1

Parece que é um problema muito específico em nossa configuração do AD, "A participação no grupo de leitura" está marcada para usuários autenticados para usuários que atualmente trabalham e desmarcada para aqueles que não estão. Adicionar esse direito corrige o problema (embora o winbind considere um tempo considerável para a mudança).

    

Answer 2

Eu tenho o mesmo problema no winbind.
Aqui estão alguns detalhes de análise do meu caso:
- vários usuários são afetados por esse problema (total de 800 usuários). - apenas um pequeno grupo está faltando (wbinfo -r; id) (alguns ainda são atribuídos) à conta problemática - provavelmente não é causado pela permisso de usuário problemática no AD
- lista de usuários em grupo está completa (grupo getent; infelizmente não encontrei maneira de listar usuários do grupo por wbinfo)
- todos os meus servidores usam a mesma versão do samba e o problema aparece em todos eles com o mesmo usuário.
Vou tentar configurar o SSSD para confirmar, esse problema está relacionado ao AD do que ao SAMBA.