[странное] Dovecot + LDAP

0

1

Mail находится в отдельном ou.

Ищем руками. Работает:

# ldapsearch -b 'ou=Mail, dc=ph, dc=com' -D 'cn=bind, ou=Users, dc=ph, dc=com' -w XXX -s sub -h mainserv.ph.com '(&(objectClass=qmailUser)(uid=someuser))' uid mailMessageStore
…

# extended LDIF
…
uid: someuser
mailMessageStore: /var/mail/someuser/Maildir/

# search result
search: 2
result: 0 Success

# numResponses: 2
# numEntries: 1

Dovecot сконфигурирован так:

# 2.0.11: /etc/dovecot/dovecot.conf
# OS: Linux 2.6.36-gentoo-r5 x86_64 Gentoo Base System release 2.0.1 
base_dir = /var/run/dovecot/
listen = *
login_trusted_networks = 192.168.1.0/24
mail_location = maildir:~/.maildir
managesieve_notify_capability = mailto
managesieve_sieve_capability = fileinto reject envelope encoded-character vacation subaddress comparator-i;ascii-numeric relational regex imap4flags copy include variables body enotify environment mailbox date
passdb {
args = *
driver = pam
}
passdb {
args = /etc/dovecot/dovecot-ldap.conf.ext
driver = ldap
}
plugin/sieve = ~/.dovecot.sieve
plugin/sieve_dir = ~/sieve
protocols = imap
ssl_cert = </etc/ssl/dovecot/server.pem
ssl_key = </etc/ssl/dovecot/server.key
userdb {
driver = passwd
}
userdb {
args = /etc/dovecot/dovecot-ldap.conf.ext
driver = ldap
}
verbose_proctitle = yes
protocol lda {
mail_plugins = sieve
}

dovecot-ldap.conf.ext:

hosts = mainserv.ph.com
dn = cn=bind, ou=Users, dc=ph, dc=com 
dnpass = XXX
debug_level = 255
auth_bind = no
ldap_version = 3
base = ou=Mail, dc=ph, dc=com
scope = subtree
user_attrs = mailMessageStore=home
user_filter = (&(objectClass=qmailUser)(uid=%u))
pass_attrs = uid=user,userPassword=password
pass_filter = (&(objectClass=qmailUser)(uid=%u))

Пытаюсь через телнет залогиниться.

$ telnet mainserv.ph.com 143
Trying 192.168.1.252...
Connected to mainserv.ph.com.
Escape character is '^]'.
* OK [CAPABILITY IMAP4rev1 LITERAL+ SASL-IR LOGIN-REFERRALS ID ENABLE IDLE STARTTLS AUTH=PLAIN] Dovecot ready.
a001 LOGIN someuser password1
a001 NO [AUTHENTICATIONFAILED] Authentication failed.

В базе у меня 2-а совпадающих uid в разных ветках и с разными паролями. Как я выше показал, с password1 не пускает, тогда как с password2, который относится к uid с другим objectClass и находится в другой ветке аутентифицирует нормально.

Кусок выхлопа для случая, когда не работает:

mainserv dovecot: auth-worker: Error: put_filter: "(&(objectClass=posixAccount)(uid=someuser))"
mainserv dovecot: auth-worker: Error: put_filter: AND
mainserv dovecot: auth-worker: Error: put_filter_list "(objectClass=posixAccount)(uid=someuser)"
mainserv dovecot: auth-worker: Error: put_filter: "(objectClass=posixAccount)"
mainserv dovecot: auth-worker: Error: put_filter: simple
mainserv dovecot: auth-worker: Error: put_simple_filter: "objectClass=posixAccount"
mainserv dovecot: auth-worker: Error: put_filter: "(uid=someuser)"
mainserv dovecot: auth-worker: Error: put_filter: simple
mainserv dovecot: auth-worker: Error: put_simple_filter: "uid=someuser"
mainserv dovecot: auth-worker: Error: ldap_build_search_req ATTRS: uid userPassword uidNumber gidNumber cn homeDirectory loginShell gecos descripti

(полностью можно посмотреть тут: http://dpaste.org/9iA4/ )

Я вообще в удивлении: это баг или мои руки?

Такое впечатление, что dovecot плюёт на subtree и указанный базовый dn.

В рассылке dovecot ничего не нарыл.

Ссылка

←	Не работает SMTP в CentOS

iptables DNAT c SNAT

→

Опять не те логи приложили. Включаем debug уровня 254 на ldap сервере и смотрим в логи:

1) Кто биндится
2) Какой запрос исполняется
3) Что возвращается

Обычно сразу все становится понятным.

~~zgen~~ ★★★★★
(24.03.11 05:46:54 MSK)

Я вообще в удивлении: это баг или мои руки?

Есть причины тому, чтобы не использовать

auth_bind = no

~~zgen~~ ★★★★★
(24.03.11 05:52:09 MSK)

Ссылка

Ответ на: комментарий от zgen 24.03.11 05:46:54 MSK

Странное что-то вытворяется:

Применяется этот фильтр (я, кстати, пытался в конфигах искать его, не нашёл, видимо, зашит жёстко в код):

2011-03-24T10:30:59.349734+03:00 mainserv slapd[1917]:     filter: (&(objectClass=posixAccount)(uid=someuser))
2011-03-24T10:30:59.349751+03:00 mainserv slapd[1917]:     attrs:
2011-03-24T10:30:59.349756+03:00 mainserv slapd[1917]:  uid
2011-03-24T10:30:59.349760+03:00 mainserv slapd[1917]:  userPassword
2011-03-24T10:30:59.349764+03:00 mainserv slapd[1917]:  uidNumber
2011-03-24T10:30:59.349768+03:00 mainserv slapd[1917]:  gidNumber
2011-03-24T10:30:59.349771+03:00 mainserv slapd[1917]:  cn
2011-03-24T10:30:59.349775+03:00 mainserv slapd[1917]:  homeDirectory
2011-03-24T10:30:59.349784+03:00 mainserv slapd[1917]:  loginShell
2011-03-24T10:30:59.349788+03:00 mainserv slapd[1917]:  gecos
2011-03-24T10:30:59.349792+03:00 mainserv slapd[1917]:  description
2011-03-24T10:30:59.349796+03:00 mainserv slapd[1917]:  objectClass

а потом, найдя в другой ветке:

access_allowed: read access to "uid=someuser,ou=IT,ou=Users,dc=ph,dc=com" "homeDirectory" requested

, начинает по одному просить данные, которые относятся к нему.

Разумеется, находит, но не то, что надо, а после этого начинается поиск тут:

2011-03-24T10:31:01.376287+03:00 mainserv slapd[1917]: => access_allowed: search access to "cn=Васисуалий Лоханкин,ou=Mail,dc=ph,dc=com" "objectClass" requested
2011-03-24T10:31:01.376292+03:00 mainserv slapd[1917]: => dn: [2] ou=mail,dc=ph,dc=com
2011-03-24T10:31:01.376297+03:00 mainserv slapd[1917]: => acl_get: [2] matched
2011-03-24T10:31:01.376302+03:00 mainserv slapd[1917]: => acl_get: [2] attr objectClass
2011-03-24T10:31:01.376315+03:00 mainserv slapd[1917]: => acl_mask: access to entry "cn=Васисуалий Лоханкин,ou=Mail,dc=ph,dc=com", attr "objectClass" requested
2011-03-24T10:31:01.376320+03:00 mainserv slapd[1917]: => acl_mask: to value by "cn=bind,ou=users,dc=ph,dc=com", (=0)
2011-03-24T10:31:01.376332+03:00 mainserv slapd[1917]: <= check a_dn_pat: uid=root,ou=users,dc=ph,dc=com
2011-03-24T10:31:01.376337+03:00 mainserv slapd[1917]: <= check a_dn_pat: ^uid=([^,]+),ou=IT,ou=Users,dc=ph,dc=com
2011-03-24T10:31:01.376348+03:00 mainserv slapd[1917]: => acl_string_expand: pattern:  ^uid=([^,]+),ou=IT,ou=Users,dc=ph,dc=com
2011-03-24T10:31:01.376354+03:00 mainserv slapd[1917]: => acl_string_expand: expanded: ^uid=([^,]+),ou=IT,ou=Users,dc=ph,dc=com
2011-03-24T10:31:01.376447+03:00 mainserv slapd[1917]: <= check a_dn_pat: cn=bind,ou=users,dc=ph,dc=com
2011-03-24T10:31:01.376452+03:00 mainserv slapd[1917]: <= acl_mask: [3] applying read(=rscxd) (stop)
2011-03-24T10:31:01.376457+03:00 mainserv slapd[1917]: <= acl_mask: [3] mask: read(=rscxd)
2011-03-24T10:31:01.376460+03:00 mainserv slapd[1917]: => slap_access_allowed: search access granted by read(=rscxd)
2011-03-24T10:31:01.376464+03:00 mainserv slapd[1917]: => access_allowed: search access granted by read(=rscxd)

но похоже нашлось то, что надо:

2011-03-24T10:31:01.376917+03:00 mainserv slapd[1917]: => acl_mask: access to entry "cn=Васисуалий Лоханкин,ou=Mail,dc=ph,dc=com", attr "userPassword" requested
2011-03-24T10:31:01.376921+03:00 mainserv slapd[1917]: => acl_mask: to value by "cn=bind,ou=users,dc=ph,dc=com", (=0)
2011-03-24T10:31:01.376930+03:00 mainserv slapd[1917]: <= check a_dn_pat: anonymous
2011-03-24T10:31:01.376934+03:00 mainserv slapd[1917]: <= check a_dn_pat: uid=root,ou=users,dc=ph,dc=com
2011-03-24T10:31:01.376938+03:00 mainserv slapd[1917]: <= check a_dn_pat: ^uid=([^,]+),ou=IT,ou=Users,dc=ph,dc=com$
2011-03-24T10:31:01.376947+03:00 mainserv slapd[1917]: => acl_string_expand: pattern:  ^uid=([^,]+),ou=IT,ou=Users,dc=ph,dc=com$
2011-03-24T10:31:01.376969+03:00 mainserv slapd[1917]: => acl_string_expand: expanded: ^uid=([^,]+),ou=IT,ou=Users,dc=ph,dc=com$
2011-03-24T10:31:01.377013+03:00 mainserv slapd[1917]: <= check a_dn_pat: *
2011-03-24T10:31:01.377019+03:00 mainserv slapd[1917]: <= acl_mask: [4] applying none(=0) (stop)
2011-03-24T10:31:01.377027+03:00 mainserv slapd[1917]: <= acl_mask: [4] mask: none(=0)
2011-03-24T10:31:01.377031+03:00 mainserv slapd[1917]: => slap_access_allowed: read access denied by none(=0)
2011-03-24T10:31:01.377039+03:00 mainserv slapd[1917]: => access_allowed: no more rules
2011-03-24T10:31:01.377044+03:00 mainserv slapd[1917]: send_search_entry: conn 1009 access to attribute userPassword, value #0 not allowed

Соответственно, посмотрел /etc/openldap/slapd.conf:

access to attrs=userPassword
  by anonymous auth
  by dn="uid=root,ou=Users,dc=ph,dc=com" write
  by dn.regex="^uid=([^,]+),ou=IT,ou=Users,dc=ph,dc=com$" write
++by dn="cn=bind,ou=Users,dc=ph,dc=com" read
  by * none

и добавил временно строку, помеченную ++. Да, стало аутентифицироваться. Но

1. Если аутентифицироваться с паролем не из ou=Mail, то используются те данные, что не нужны и, даже, вредны для дела. Кроме того, такое положение может сбивать пользователей с толку.

2. Если использовать пароль из ou=Mail, то всё равно, почему-то используются данные не из него.

К примеру, возьмём внутреннюю переменную dovecot'а — home. Я указал, как сказано выше, что он вот такой:

user_attrs = mailMessageStore=home

, однако, запроса этого атрибута нет в логах вообще.

Отчего — непонятно, как и непонятно поведение dovecot по умолчанию.

Есть причины тому, чтобы не использовать

auth_bind = no

?

Причина одна: я невнимательно прочитал описание этой опции и решил, что на данном этапе она мне будет вредна. После уточнений я убрал вышеуказанную строку с ++ из slapd.conf и включил auth_bind=yes.

HolyBoy ★
(24.03.11 11:48:41 MSK) автор топика