OpenLDAP - notação “set” de ACL não correspondendo corretamente

1

Tenho que configurar um diretório LDAP acessível anonimamente externamente 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 será capaz de adicionar / editar ("basicamente") as entradas sob ou = hie_ext, ou = group1. Eu tentei uma regra da ACL assim:

access to dn.children="ou=hie_ext,dc=example,dc=com"
    by set="this/ou & user/uid" write
    by * none

Quando eu testo permissão de gravação usando slapacl, recebo "PERMITIDO" se eu testar

"ou=group1,ou=hie_ext,dc=example,dc=com"

mas "NEGADO" quando testo contra

"cn=user1,ou=group1,ou=hie_ext,dc=example,dc=com" 

que parece um pouco maluco para mim.

Eu provavelmente estou negligenciando algo óbvio (estou bastante verde com o LDAP neste momento). Executar a opção "-d trace" para slapacl não ajudou muito, já que não tenho ideia do que estou vendo. :)

Atualização:

Assim, enquanto "-d trace" era um pouco exagerado para ser de alguma utilidade 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 é essa.

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 largando o registro específico cn:

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 isso 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 estaria recebendo um conjunto diferente de valores para "this / ou" entre o primeiro e o segundo exemplos, o que parece ser o que está acontecendo.

    
por GeminiDomino 13.01.2014 / 19:40

1 resposta

0

Parece que eu estava mal entendendo como as ACLs funcionam. Aparentemente, você não pode testar os atributos "herdados", que é o que eu estava tentando fazer. Atributos no DN não fazem parte de um dado objeto: uma lição valiosa para o newer LDAPer.

A solução foi bem simples quando descobri o que estava fazendo de errado:

Eu adicionei um elemento "ou" aos registros inetorgperson que correspondem ao uid dos objetos de autorização [0]. As coisas "magicamente" começaram a funcionar.

by set="this/ou & user/uid" write

[0] Qual não é o uso incorreto do esquema que parece, já que cada conta de autenticação está vinculada a uma unidade específica. Promessa!

    
por 14.01.2014 / 19:45