☰

OpenLDAP - нотация «set» ACL не соответствует должным образом

tag-icon • tag-icon ubuntu ldap openldap access-control-list
OpenLDAP - нотация «set» ACL не соответствует должным образом

Мне нужно настроить внешне анонимный доступный LDAP-каталог на сервере Ubuntu 12.04 и я хочу хранить данные аутентификации и внутренние данные в другом поддереве.

Пример макета 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

Идея в том, что uid=group1 auth сможет добавлять/редактировать (по сути, писать) записи в ou=hie_ext,ou=group1. Я попробовал правило ACL, подобное этому:

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

Однако, когда я проверяю разрешение на запись с помощью slapacl, я получаю «РАЗРЕШЕНО», если я проверяю

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

но "ОТКАЗАНО" когда я тестирую против

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

что мне кажется немного странным.

Я, вероятно, упускаю из виду что-то очевидное (на данный момент я совсем зеленый с LDAP). Запуск опции "-d trace" для slapacl не сильно помог, поскольку я понятия не имею, что именно вижу. :)

Обновлять:

Итак, хотя «-d trace» был слишком громоздким, чтобы быть полезным для меня, я узнал о «-d acl», который, вероятно, будет гораздо полезнее.

Так что если я побегу

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

Вывод отладки следующий.

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

Но отбрасываем 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

И это работает?

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

Я не уверен, почему анализатор ACL получает разный набор значений для «this/ou» в первом и втором примерах, что, по-видимому, и происходит.

решение1

Похоже, я не понял, как работают ACL. По-видимому, вы не можете тестировать "унаследованные" атрибуты, что я и пытался сделать. Атрибуты в DN не являются частью данного объекта: ценный урок для новичка в LDAP.

Решение оказалось довольно простым, как только я понял, что я делал неправильно:

Я добавил элемент "ou" в записи inetorgperson, который соответствовал uid объектов авторизации[0]. Все "волшебным образом" начало работать.

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

[0] Что не является неправильным использованием схемы, как кажется, поскольку каждая учетная запись аутентификации привязана к определенному устройству. Обещаю!

Связанный контент