Protegendo o acesso do userPassword com o OpenLDAP no RHEL

Question

Eu configurei um servidor OpenLDAP no RHEL 5.4 e estou configurando outros servidores para autenticar contra ele. Eu tenho ambos ldap com StartTLS e ldaps configurados e funcionando.

Em minhas máquinas clientes, meu /etc/nsswitch.conf inclui:

passwd:     files ldap
shadow:     files ldap
group:      files ldap

Eu posso efetuar login com sucesso em um cliente com um usuário que é definido apenas no LDAP (ou seja, não está encontrando em / etc / passwd e está solicitando informações de usuário com êxito do LDAP e autenticando em relação ao hash de senha armazenado no LDAP ).

Meu problema é quando tento bloquear o acesso a atributos no servidor LDAP, especificamente, em /etc/openldap/slapd.conf , os usuários do ldap não podem mais efetuar login:

access to attrs=userpassword
        by self write
        by anonymous auth
        by * none

Estou registrando o slapd e parece (minha interpretação, corrija-me se estiver errado) que o pam_ldap está tentando ler todos os atributos no poxixAccount objectClass:

    filter: (&(objectClass=posixAccount)(uid=cthompson))
    attrs:
  uid
  userPassword
  uidNumber
  gidNumber
  cn
  homeDirectory
  loginShell
  gecos
  description
  objectClass

No meu log do openldap, não recebo nenhum erro de acesso ou acl, mas obtenho:

access_allowed: search access to "uid=cthompson,ou=People,dc=domain,dc=com" "objectClass" requested
access_allowed: search access to "uid=cthompson,ou=People,dc=domain,dc=com" "uid" requested

Existe algo que precisa ser configurado para que, em vez de ler o atributo userPassword, o pam_ldap tente "auth" (para que as solicitações sejam manipuladas pela regra de acesso "by anonymous auth"?

    

Answer 1

pam_ldap não deve estar tentando ler o valor userPassword para efetuar o login. Ele faz o login fazendo uma ligação LDAP com o DN recuperado.

É possível que os parâmetros de pesquisa que os usos pam_ldap sejam mais abrangentes & ele tenta puxar userPassword como resultado, mas se sua ACL estiver configurada corretamente (parece bem para mim), ela não terá esse valor em seus resultados.

Apenas para o caso de suas ACLs não serem bem (eu sou conhecido por perder coisas estupidamente óbvias antes), aqui está a lista de ACL funcional do meu ambiente LDAP de produção:)

# Access and Security Restrictions
# (Most restrictive entries first)
access to attrs=userPassword
    by self write
    by dn.sub="ou=sync,dc=mydomain,dc=com" read
    by anonymous auth
by users none

access to * by * read

O trailing access to * by * read é importante, não o vi nos seus exemplos, por isso não tenho a certeza se está em falta ou foi apenas omitido do seu fragmento.

A linha sync é para meu serviço de sincronização LDAP e não é necessária se você não estiver fazendo replicação ...