De minha própria investigação, se você tiver todas as configurações normais de PAM / nsswitch.conf
, você pode fazer isso, mas apenas adicionando o usuário local ao grupo no banco de dados LDAP diretamente usando ldapmodify
no atributo memberUid
no servidor LDAP (consulte aqui ):
$ ldapmodify -D <admin DN> -h <ldaphost> -W
password: [enter password]
dn: cn=vipb,ou=groups,dc=example,dc=com
changetype: modify
add: memberUid
memberUid: fred
^D
Note que a linha em branco é necessária.
Em seguida, você tem que invalidar o cache do NCSD no servidor 2:
$ nscd --invalidate=group
Você pode verificar a associação ao grupo no servidor 2 emitindo:
$ id -nG fred
CAVEAT: O uso do LDAP como um banco de dados do usuário depende do esquema detalhado neste padrão de rascunho: rfc2307bis -02 . Existem três versões do padrão até agora. Entre as coisas que são ajustadas entre as versões estão os atributos member e memberUid; isso significa que sua configuração do LDAP pode não funcionar muito bem. Uma instalação totalmente compatível com bis-02 deve conter e oferecer suporte a ambos os atributos: memberUid
(para membros de logons locais do grupo LDAP, sem um dn) e member
(para usuários LDAP com um dn completo ) dentro de um determinado grupo. Eles também devem permitir que um ou ambos estejam vazios, permitindo grupos vazios. Sua milhagem pode variar - você precisará verificar o esquema do seu servidor.
Ferramentas como o webmin podem ser úteis para manipular os usuários e grupos LDAP e o banco de dados LDAP; mas novamente eles podem não jogar muito bem com rfc2307bis-02. Por exemplo, o módulo Usuários e Grupos LDAP do Webmin, lida com o membroUnidade, mas não com o membro.
Onde as coisas ficam realmente escuras, o memberof
support. Alguns sistemas (por exemplo, o início do ownCloud) dependem do memberof
support para descobrir de que grupos um usuário é membro sem precisar consultar o banco de dados LDAP duas vezes. Freqüentemente, memberof
só funciona para um dos atributos e, depois, somente depois de alterar a configuração do LDAP.