Como definir um atributo olcAccess para que gidNumber = 0 + uidNumber = 0 funcione como olcRootDN?

Question

Estou atualizando um servidor Ubuntu 14.04 OpenLDAP para o 16.04 e me deparando com um problema. Há um script de importação (localhost) que usa o ldapdelete -r -Y EXTERNAL -H ldapi:///... para remover algumas UOs e, em seguida, preenchê-las novamente com novas informações. Isso está falhando devido ao que suspeito ser um atributo olcAccess ausente / alterado. Alguém sabe por que isso não está funcionando?

Eu executei uma linha do script manualmente com este resultado:

# ldapdelete -r -Y EXTERNAL -H ldapi:/// "ou=people,dc=my,dc=org"
SASL/EXTERNAL authentication started
SASL username: gidNumber=0+uidNumber=0,cn=peercred,cn=external,cn=auth
SASL SSF: 0
ldap_delete: Insufficient access (50)
        additional info: no write access to parent

Eu posso usar o olcRootDn para remover as UOs com sucesso, mas isso requer colocar a senha rootdn em algum lugar que eu prefiro não fazer.

# ldapdelete  -x -D "cn=admin,dc=my,dc=org" -W -h ldap1 "ou=people,dc=my,dc=org"
Enter LDAP Password: 

# ldapdelete  -x -D "cn=admin,dc=my,dc=org" -W -h ldap1 "ou=people,dc=my,dc=org"
Enter LDAP Password: 
ldap_delete: No such object (32)
        matched DN: dc=my,dc=org

Eu executei slapcat para exibir os atributos olcAccess - parece que as entradas dn-exact=... devem fornecer as permissões corretas, mas isso deve estar incorreto.

dn: olcBackend={0}hdb,cn=config
objectClass: olcBackendConfig
olcBackend: {0}hdb

dn: olcDatabase={-1}frontend,cn=config
objectClass: olcDatabaseConfig
objectClass: olcFrontendConfig
olcDatabase: {-1}frontend
olcAccess: {0}to * by dn.exact=gidNumber=0+uidNumber=0,cn=peercred,cn=external
 ,cn=auth manage by * break
olcAccess: {1}to dn.exact="" by * read
olcAccess: {2}to dn.base="cn=Subschema" by * read
olcSizeLimit: 500

dn: olcDatabase={0}config,cn=config
objectClass: olcDatabaseConfig
olcDatabase: {0}config
olcAccess: {0}to * by dn.exact=gidNumber=0+uidNumber=0,cn=peercred,cn=external
 ,cn=auth manage by * break

dn: olcDatabase={1}hdb,cn=config
objectClass: olcDatabaseConfig
objectClass: olcHdbConfig
olcDatabase: {1}hdb
olcDbDirectory: /var/lib/ldap
olcSuffix: dc=my,dc=org
olcAccess: {0}to attrs=userPassword by self write by anonymous auth by * none
olcAccess: {1}to attrs=shadowLastChange by self write by * read
olcAccess: {2}to * by * read
olcLastMod: TRUE
olcRootDN: cn=admin,dc=my,dc=org
olcRootPW: {SSHA}(removed)...
olcDbCheckpoint: 512 30
olcDbConfig: {0}set_cachesize 0 2097152 0
olcDbConfig: {1}set_lk_max_objects 1500
olcDbConfig: {2}set_lk_max_locks 1500
olcDbConfig: {3}set_lk_max_lockers 1500
olcDbIndex: objectClass eq
olcDbIndex: cn,uid eq
olcDbIndex: uidNumber,gidNumber eq
olcDbIndex: member,memberUid eq

    

Answer 1

De acordo com sua configuração do banco de dados {1} hdb , a ACL apropriada para o usuário do sistema raiz está ausente. Você deve adicionar:

olcAccess: {0} para * por dn.exact = gidNumber = 0 + uidNumber = 0, cn = peercred, cn = externo  , cn = auth gerencia por * break

Esta ACL deve ser a primeira para este banco de dados (índice {0})

A mesma ACL que está no banco de dados {- 1} frontend é anexada à lista de ACLs de {1} hdb . Isso significa que foi adicionado no final desta lista , ou seja, depois de "olcAccess: {2} para * por * leia" um. a diretiva "to * by * read" faz com que o mecanismo de ACL pare o processamento com apenas leitura correta.

Do guia do administrador do OpenLDAP (consulte 5.2.5.2. ) :

Note: Access controls defined in the frontend are appended to all other databases' controls.