Preciso configurar um diretório LDAP acessível externamente anônimo em um servidor Ubuntu 12.04 e quero manter a autenticação e os dados internos em uma subárvore diferente.
Exemplo do layout LDAP
dc=example.com,dc=com
organizationUnit: ou=hie_ext,dc=example,dc=com
organizationUnit: ou=group1,ou=hie_ext,dc=example,dc=com
inetOrgPerson: cn=user1,ou=group1,ou=hie_ext,dc=example,dc=com
inetOrgPerson: cn=user2,ou=group1,ou=hie_ext,dc=example,dc=com
organizationUnit: ou=group2,ou=hie_ext,dc=example,dc=com
organizationUnit: ou=group_auth,dc=example,dc=com
account: uid=group1,password=XXX,ou=group_auth,dc=example,dc=com
A idéia é que a autenticação uid=group1 seja capaz de adicionar/editar ("escrever" basicamente) as entradas em ou=hie_ext,ou=group1. Eu tentei uma regra ACL como esta:
access to dn.children="ou=hie_ext,dc=example,dc=com"
by set="this/ou & user/uid" write
by * none
Porém, quando testo a permissão de gravação usando slapacl, recebo "PERMITIDO" se testar
"ou=group1,ou=hie_ext,dc=example,dc=com"
mas "NEGADO" quando testo
"cn=user1,ou=group1,ou=hie_ext,dc=example,dc=com"
o que parece um pouco estranho para mim.
Provavelmente estou ignorando algo óbvio (sou bastante inexperiente com LDAP neste momento). Executar a opção "-d trace" no slapacl não ajudou muito, pois não tenho ideia do que estou vendo. :)
Atualizar:
Portanto, embora "-d trace" fosse um pouco vago demais para ser útil para mim, tomei conhecimento de "-d acl", que provavelmente será muito mais útil.
Então, se eu correr
slapacl -f slapd.conf -D"uid=group1,ou=servers,dc=example,dc=com" \
-b "cn=user1,ou=group1,ou=hie_ext,dc=example,dc=com" "sn/write" -d acl
A saída de depuração é esta.
52d544e1 => access_allowed: write access to "cn=test,ou=group1,ou=hie_ext,dc=example,dc=com" "sn" requested
52d544e1 => dn: [1]
52d544e1 => dn: [2] ou=hie_ext,dc=example,dc=com
52d544e1 => acl_get: [2] matched
52d544e1 => acl_get: [2] attr sn
52d544e1 => acl_mask: access to entry "cn=test,ou=group1,ou=hie_ext,dc=example,dc=com", attr "sn" requested
52d544e1 => acl_mask: to all values by "uid=group1,ou=servers,dc=example,dc=com", (=0)
52d544e1 <= check a_set_pat: this/ou & user/uid
52d544e1 => bdb_entry_get: found entry: "uid=group1,ou=servers,dc=example,dc=com"
52d544e1 ACL set[0]=group1
52d544e1 ACL set: empty
52d544e1 <= check a_dn_pat: *
52d544e1 <= acl_mask: [2] applying read(=rscxd) (stop)
52d544e1 <= acl_mask: [2] mask: read(=rscxd)
52d544e1 => slap_access_allowed: write access denied by read(=rscxd)
52d544e1 => access_allowed: no more rules
write access to sn: DENIED
Mas abandonando o cn específico do registro:
slapacl -f slapd.conf -D"uid=group1,ou=servers,dc=example,dc=com" \
-b "ou=group1,ou=hie_ext,dc=example,dc=com" "sn/write" -d 128
E funciona?
52d545ef => access_allowed: write access to "ou=group1,ou=hie_ext,dc=example,dc=com" "sn" requested
52d545ef => dn: [1]
52d545ef => dn: [2] ou=hie_ext,dc=example,dc=com
52d545ef => acl_get: [2] matched
52d545ef => acl_get: [2] attr sn
52d545ef => acl_mask: access to entry "ou=group1,ou=hie_ext,dc=example,dc=com", attr "sn" requested
52d545ef => acl_mask: to all values by "uid=group1,ou=servers,dc=example,dc=com", (=0)
52d545ef <= check a_set_pat: this/ou & user/uid
52d545ef ACL set[0]=group1
52d545ef => bdb_entry_get: found entry: "uid=group1,ou=servers,dc=example,dc=com"
52d545ef ACL set[0]=group1
52d545ef ACL set[0]=group1
52d545ef <= acl_mask: [1] applying write(=wrscxd) (stop)
52d545ef <= acl_mask: [1] mask: write(=wrscxd)
52d545ef => slap_access_allowed: write access granted by write(=wrscxd)
52d545ef => access_allowed: write access granted by write(=wrscxd)
write access to sn: ALLOWED
Não sei por que o analisador ACL obteria um conjunto diferente de valores para "this/ou" entre o primeiro e o segundo exemplos, o que parece ser o que está acontecendo.
Responder1
Parece que eu estava entendendo mal como as ACLs funcionam. Aparentemente, você não pode testar atributos "herdados", que é o que eu estava tentando fazer. Os atributos no DN não fazem parte de um determinado objeto: uma lição valiosa para o LDAPer novato.
A solução foi bem simples quando descobri o que estava fazendo de errado:
Adicionei um elemento "ou" aos registros inetorgperson que correspondiam ao uid dos objetos de autorização[0]. As coisas “magicamente” começaram a funcionar.
by set="this/ou & user/uid" write
[0] O que parece não ser o uso indevido do esquema, já que cada conta de autenticação está vinculada a uma unidade específica. Promessa!