Tengo que configurar un directorio LDAP accesible externamente y anónimo en un servidor Ubuntu 12.04 y quiero mantener la autenticación y los datos internos en un subárbol diferente.
Ejemplo del diseño 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
La idea es que la autenticación uid=group1 podrá agregar/editar ("escribir" básicamente) las entradas en ou=hie_ext,ou=group1. Probé una regla ACL como esta:
access to dn.children="ou=hie_ext,dc=example,dc=com"
by set="this/ou & user/uid" write
by * none
Sin embargo, cuando pruebo el permiso de escritura usando slapacl, obtengo "PERMITIDO" si lo pruebo con
"ou=group1,ou=hie_ext,dc=example,dc=com"
pero "DENEGADO" cuando pruebo contra
"cn=user1,ou=group1,ou=hie_ext,dc=example,dc=com"
lo cual me parece un poco loco.
Probablemente estoy pasando por alto algo obvio (a estas alturas estoy bastante verde con LDAP). Ejecutar la opción "-d trace" para slapacl no ayudó mucho, ya que no tengo idea de lo que estoy viendo. :)
Actualizar:
Entonces, si bien "-d trace" era demasiado confuso para ser de alguna utilidad para mí, me di cuenta de "-d acl", que probablemente será mucho más útil.
Entonces si corro
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
La salida de depuración es 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
Pero dejando el cn específico del 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
¿Y 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
No estoy seguro de por qué el analizador de ACL obtendría un conjunto diferente de valores para "this/ou" entre el primer y el segundo ejemplo, que parece ser lo que está sucediendo.
Respuesta1
Parece que no entendí bien cómo funcionan las ACL. Aparentemente, no se pueden realizar pruebas con atributos "heredados", que es lo que estaba tratando de hacer. Los atributos en el DN no son parte de un objeto determinado: una lección valiosa para el LDAPer novato.
La solución fue bastante simple una vez que descubrí qué estaba haciendo mal:
Agregué un elemento "ou" a los registros de inetorgperson que coincidían con el uid de los objetos de autorización [0]. Las cosas empezaron a funcionar "mágicamente".
by set="this/ou & user/uid" write
[0] Lo cual no es un mal uso del esquema como parece, ya que cada cuenta de autenticación está vinculada a una unidad específica. ¡Promesa!