Автор Тема: Проблема с ACL: access to attribute userPassword, value #0 not allowed  (Прочитано 18099 раз)

d06pbiu

  • Новичок
  • *
  • Сообщений: 14
    • Просмотр профиля
Всем доброго времени суток!
Проблема вот в чем:
Был настроен ACL вот так:
     olcAccess: {0}to attrs=userPassword,description by dn="cn=repluser,ou=mycomp,o=org" read by * auth
     olcAccess: {1}to * by * read
Все прекрасно работало, пользователи могли аутентифицироваться/авторизовываться и могли видеть все аттрибуты кроме userPassowrd и description - их мог читать только cn=repluser(для репликации католога на слэйв-сервер).
А потом все прекратилось! Вот что вижу в логе:
    send_search_entry: conn 1009 access to attribute userPassword, value #0 not allowedПри этом getent, ldapsearch работают как надо.
Удаляю ACL - и опа на - аутентифиция/авторизация работает! - ну так нельзя! - пользователю незачем видеть userPassword!
Что за чудеса?( - раньше все с ACL работало...
В чем дело, куда  смотреть?

P.S.
Началось все после переименования ldap-сервера(но не факт).

egor

  • Администратор
  • Старожил
  • *****
  • Сообщений: 486
    • Просмотр профиля
Здравствуйте! Несколько путанный текст у Вас вышел. Речь идет о том, что не работает PAM-аутентификация? Она реализована на библиотеке pam_ldap? От какого пользователя подключаются эта библиотека? Или не работает репликация от имени cn=repluser?

Теоретически (да и практически тоже, я проверил 2 Ваших ACL на тестовом каталоге) всё работает нормально: пользователь проходит аутентификацию и через ldapsearch от имени своего DN (при этом атрибут userPassword ему не показывается), и через pam_ldap с анонимной привязкой, slapacl показывает всё как надо:

# slapacl -f /etc/openldap/slapd.conf -v -D 'uid=egor,ou=Users,dc=mycompany,dc=ru' -b 'uid=egor,ou=Users,dc=mycompany,dc=ru'
authcDN: "uid=egor,ou=users,dc=mycompany,dc=ru"
...
uid=egor: read(=rscxd)
...
userPassword=****: auth(=xd)
...

В общем, всё должно работать. Может у Вас определены ещё какие-нибудь ACL на глобальном уровне? Попробуйте посмотеть, что говорит slapacl -- обычно помогает. Можно поставить loglevel (olcLoglevel) в 128 и посмотреть, что пишется в лог. Если не разберётесь, пришлите более конкретное описание, когда возникает ошибка, от какого DN привязываются Ваши библиотеки и т.п.

Егор

d06pbiu

  • Новичок
  • *
  • Сообщений: 14
    • Просмотр профиля
Спасибо за оперативную помощь Egor!
Проблема в аутентификации - она не работает с предложенными ACL, а вот если я их удаляю, то все работает как надо - вот это-то и странно, потому как до недавнего времени(до переименования сервера - только как это связано?) все прекрасно работало. Дистрибутив Scientific Linux 6.2(RedHat), аутентификация через демона nslcd (пакет nss-pam-ldapd).
Репликация работает!
Но никак у меня не получается понять в чем дело(.

Вот что slapcat выдает:
$ slapacl -F /etc/openldap/slap.d -v -D "uid=testuser,ou=mycomp,o=org" -b "uid=testuser,ou=mycomp,o=org"
authcDN: "uid=egor,ou=users,dc=mycompany,dc=ru"
...
uid=testuser: read(=rscxd)
...
userPassword=****: auth(=xd)
...
description:: secret: auth(=xd)
если делаю slapacl от пользователя repluser - то все аттрибуты доступны для чтения: read(=rscxd) - что говорит, как я понял, что ACL настроены правильно, НО в то же время в логе(olcLogLevel: 128) при попытке подключиться к серверу используя учетки из ldap, вижу вот что:
:=> acl_mask: access to entry "uid=testuser,ou=mycomp,o=org", attr "userPassword" requested
:=> acl_mask: to value by "", (=0)
:<= check a_dn_pat: cn=repluser,ou=mycomp,o=org
:<= check a_dn_pat: *
:<= acl_mask: [2] applying auth(=xd) (stop)
:<= acl_mask: [2] mask: auth(=xd)
:=> slap_access_allowed: read access denied by auth(=xd)
:=> access_allowed: no more rules
: send_search_entry: conn 1014 access to attribute userPassword, value #0 not allowed

а на сервере к которому пытаюсь подключиться в логе /var/log/secure:
sshd[3821]: pam_unix(sshd:auth): authentication failure: logname uid=0 euid=0 tty=ssh ruser= rhost=testhost user=testuser
sshd[3821]: Failed password for testuser from 192.168.0.4 port 51141 ssh2

Далее привожу конф.файлы openldap.
cn=config.ldif:
dn: cn=config
objectClass: olcGlobal
cn: config
olcConfigDir: /etc/openldap/slap.d
olcArgsFile: /var/run/openldap/slapd.args
olcLogLevel: 128
olcPidFile: /var/run/openldap/slapd.pid
olcThreads: 32

olcDatabase={0}config.ldif:
dn: olcDatabase={0}config
objectClass: olcDatabaseConfig
olcDatabase: {0}config
olcAccess: [0] * by * none
olcRootDN: cn=manager,cn=config
olcRootPW: secret

olcDatabase={1}bdb.ldif:
dn: olcDatabase={1}bdb
objectClass: top
objectClass: olcDatabaseConfig
objectClass: olcBdbConfig
olcDatabase:{1}bdb
olcDbDirectory: /var/lib/ldap
olcSuffix: ou=mycomp,o=org
olcAccess: {0}to attrs=userPassword,description by dn="cn=repluser,ou=mycomp,o=org" read by * auth
olcAccess: {1}to * by * read
olcRootDN: cn=manager,ou=mycomp,o=org
olcRootPW: secret
olcSizeLimit: unlimited
olcTimeLimit: 1800
olcDbConfig: {0} set_cachesize 0 268435456 0
olcDbConfig: {1} set_lg_regionmax 262144
olcDbConfig: {2} set_lg_bsize 2097152
olcDbConfig: {3} set_lg_dir /var/tmp/bdb-log
olcDbConfig: {4} set_flags DB_LOG_AUTOREMOVE
olcDbIndex: uid pres,eq
olcDbIndex: cn,sn pres,eq,approx sub
olcDbIndex: objectClass eq
olcDbIndex: contextCSN eq
olcDbIndex: entry UUID eq
olcDbIndex: memberUid eq

cn=module{0}.ldif:
dn: module{0}
objectClass: olcModuleList
cn: module{0}
olcModuleLoad: {0}/usr/lib64/openldap/syncprov.la
olcDatabase={1}bd/olcOverlay={0}syncprov.ldif:
dn: olcOverlay={0}syncprov
objectClass: olcSyncProvConfig
olcOverlay: {0}syncprov
olcSpCheckpoint: 100 5

Что не так? Что поправить? Что еще показать? Буду рад любым предложениям!
« Последнее редактирование: 28 Ноябрь 2012, 19:02:17 от d06pbiu »

egor

  • Администратор
  • Старожил
  • *****
  • Сообщений: 486
    • Просмотр профиля
Здравствуйте! В конфигурации, вроде бы, действительно нет ничего лишнего. Мне кажется, загвоздка в nslcd -- посмотрите в /etc/nslcd.conf, вероятно там не анонимное подключение (имеют место binddn и bindpw) -- тогда либо этого пользователя тоже нужно включить в ACL, либо убрать эти опции для того, чтобы nslcd подключался анонимно. Хотя на 100% ответить не могу -- у меня аутентификация на padl-овских библиотеках, там анонимное подключение реализовано так, что если пользователь выполняет операцию BIND к каталогу, значит его аутентификация прошла успешно =) .

Егор