Мне нужно настроить внешне анонимный доступный каталог 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» между первым и вторым примерами, что, похоже, и происходит.
Похоже, я неправильно понимал, как работают ACL. По-видимому, вы не можете протестировать «унаследованные» атрибуты, что я и пытался сделать. Атрибуты в DN не являются частью данного объекта: ценный урок для новичка в LDAPer.
Решение было довольно простым, когда я понял, что делаю не так:
Я добавил элемент «ou» в записи inetorgperson, который соответствует uid объектов авторизации [0]. Вещи «волшебным образом» заработали.
by set="this/ou & user/uid" write
[0] Кажется, это не является неправильным использованием схемы, поскольку каждая учетная запись авторизации привязана к определенному устройству. Обещаю!