Tenho certeza de que alguns de vocês lidaram com o mesmo problema. Espero que alguém tenha uma resposta melhor do que o que estou fazendo agora.
Então, você tem alguns usuários em um diretório LDAP e um dia você diz "ei! Eu posso autenticar contra isso por SSH!" E isso é bom.
Então, um dia, você percebe que deseja que apenas determinados usuários entrem em uma máquina. Digamos que os desenvolvedores só possam entrar nas caixas de desenvolvimento, não em prod. Você faz algum googling e encontra pam_groupdn que vai na sua configuração LDAP ( /etc/ldap.conf ) assim:
pam_groupdn CN=developers,OU=groups,DC=yourcompany
E, novamente, é bom. Você faz um outro grupo para prod, outro para QA, etc. Talvez um dia você tenha um segundo grupo de desenvolvedores de produtos, então eles terão seu próprio grupo. Seja o que for.
Então, um dia, você terá um servidor no qual tanto os desenvolvedores quanto o controle de qualidade precisam fazer login. Uh ... Acontece que pam_groupdn não aceita vários valores. O que você faz? Bem, se você não está pensando muito, você diz "oh, eu apenas farei um grupo de desenvolvedores e QAs".
pam_groupdn CN=developers-and-QA,OU=groups,DC=yourcompany
Isso não é bom, mas tudo bem, certo?
Então, um dia, você recebe outro desenvolvedor e percebe que precisa adicioná-lo a 15 grupos, porque há developers-and-QA , product1-and-product2 , developers-who-have-access-to-prod e assim por diante. Porcaria.
Tem que haver uma maneira melhor de fazer isso, certo? Eu enviei um email para os desenvolvedores de pam_ldap e eles disseram que, infelizmente, não há como fazer com que pam_groupdn receba vários valores (sem interferir no código).
Alguém deseja compartilhar como eles gerenciam grupos de grupos no LDAP sem recorrer a copiar / colar?
Se você estiver usando o NSS, poderá definir o parâmetro AllowGroups em /etc/ssh/sshd_config . Caso contrário, você deve procurar em listas dinâmicas :
dn: cn=devandqa,ou=groups,dc=company,dc=com
cn: devandqa
objectClass: groupOfNames
labeledURI: ldap:///ou=groups,dc=company,dc=com?memberUid?one?(|(cn=developers)(cn=qa))
Algo parecido. Você também precisa incluir o esquema e incluir a sobreposição, etc .... Então é um começo.
Uma solução de trabalho é aplicar um pam_filter em vez de pam_groupdn em /etc/ldap.conf :
# Filter to AND with uid=%s
pam_filter |(member=CN=developers,OU=groups,DC=yourcompany)(member=CN=QA,OU=groups,DC=yourcompany)
"Filtrar para e com uid =% s" significa que o Filtro enviado para o servidor LDAP será assim: &(uid=<your username>)(<your pam_filter>)
O usuário precisa ser membro de developers ou QA . Se ele não for membro de um desses grupos, haverá uma mensagem de erro na resposta do servidor LDAP e a senha nem será enviada para o servidor LDAP.
Funciona para o meu ambiente RHEL 5.8.
Para diferentes variações de filtro, verifique no Google por "sintaxe do filtro ldap" ...
Minha solução aqui é bem feia, mas um pouco menos feia do que a que você descreve acima: o grupo que eu especifico em pam_groupdn é um grupo "classe de máquina", por exemplo. cn=database,ou=NY,dc=mydomain,dc=com
Os grupos qualificam quem deve ter acesso a uma classe específica de sistemas em um site específico (no exemplo acima, database servers em NY ).
Isso só funciona em virtude do fato de que, no meu ambiente, conceder ao usuário acesso a uma máquina em uma determinada classe é praticamente inútil (porque todos são efetivamente idênticos), por isso, se eu permitir que alguém faça login db01 não há nenhuma razão para que eles não devam ter permissão para efetuar login em db02 . (A qualificação "site" nasce da lógica que eu posso contratar alguém para gerenciar a Califórnia, mas eu posso não querer que eles façam login nas máquinas de NY.)
Esse design envolve algumas duplicações nos grupos, o que dificulta a revogação global do acesso (por exemplo, minha conta é listada em cada grupo em cada site: para bloquear meu usuário, você teria que editar todos os grupos e revogar minha associação), mas dá aos grupos uma estrutura lógica / gerenciável que só cresce quando novos sites / classes de máquinas são adicionados.
Supondo que você tenha algum sistema de gerenciamento de configuração como o fantoche, é possível criar uma solução baseada em PAM (por isso, é mais geral que AllowGroups em sshd_config) usando o pam_listfile. Faça com que o puppet gerencie algo como /etc/allowed_groups para cada servidor / grupo de servidores e adicione à sua configuração do PAM:
required pam_listfile.so onerr=fail item=group sense=allow file=/etc/allowed_groups
Como a solução SSH, você supõe que o LDAP esteja conectado ao NSS.
Se você estiver usando o RHEL6 +, o arquivo conf está localizado em /etc/pam_ldap.conf e não em /etc/openldap/ldap.conf . Se você colocar a entrada pam_groupdn lá, ela funcionará conforme planejado. A melhor maneira de fazer isso seria copiar seu ldap.conf para pam_ldap.conf ou criar um link simbólico.
Tags authentication ldap linux pam-ldap