Как установить атрибут olcAccess, чтобы gidNumber = 0 + uidNumber = 0 работал как olcRootDN?

Я обновляю сервер OpenLDAP Ubuntu 14.04 до 16.04 и столкновение с загвоздкой. Существует сценарий импорта (localhost), который использует ldapdelete -r -Y EXTERNAL -H ldapi: /// ... чтобы удалить некоторые OU, а затем заново заполнить их новой информацией. Это не удается из-за того, что я подозреваю, что атрибут olcAccess отсутствует / изменен. Кто-нибудь знает, почему это не работает?

Я выполнил строку из сценария вручную и получил следующий результат:

# 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

Я могу использовать olcRootDn для успешного удаления OU, однако для этого потребуется указать пароль rootdn где-нибудь, что я бы предпочел не делать.

# 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

Я запустил slapcat , чтобы просмотреть атрибуты olcAccess - похоже, dn-точный = ... записи должны предоставлять правильные разрешения, но они должны быть неправильными.

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
1
задан 16 October 2018 в 20:23
1 ответ

В соответствии с вашей конфигурацией базы данных {1} hdb , соответствующий ACL для корневой системы пользователь отсутствует. Вы должны добавить:

olcAccess: {0} к * по dn.exact = gidNumber = 0 + uidNumber = 0, cn = peercred, cn = external ,cn = auth manage by * break

Этот ACL должен быть первым для этой базы данных (индекс {0})

Тот же ACL, что и во внешнем интерфейсе {- 1} база данных добавлена ​​ к списку ACL {1} hdb . Это означает, что добавлен в конец этого списка , то есть после "olcAccess: {2} до * by * read". директива «to * by * read» вызывает остановку обработки механизма ACL только с правом чтения.

Из руководства администратора OpenLDAP (см. 5.2.5.2. ):

Примечание. Элементы управления доступом, определенные во внешнем интерфейсе, добавляются ко всем другие элементы управления базами данных.

1
ответ дан 3 December 2019 в 23:11

Теги

Похожие вопросы