Проблемы с настройкой аутентификации ldap

[[email protected]]

Добрый день, коллеги!
С недавних пор перестала работать аутентификация LDAP (установил обновление из репозитариев http://repo.zabbix.com/zabbix/2.2/ubuntu precise main)
После того как аутентификация перестала работать, с помощью команды в MySQL, вернулся к внутренней аутентификации.

Попробовал снова включить через web-интерфейс аутентификацию LDAP, возникла ошибка
ldap_bind(): Unable to bind to server: Can't contact LDAP server [authentication.php:116 → CLdapAuthValidator->validate() → CLdap->checkPass() → ldap_bind() in /usr/share/zabbix/include/classes/class.cldap.php:112]
LDAP: cannot bind by given Bind DN.
Имя пользователя или пароль некорректны!

При этом пароль ни в домене ни локально не менялся.
Сбросил на всякий случай пароль на новый (копированием из блокнота, дабы не допустить ни каких ошибок)
Пробую включить аутентификацию и все равно тоже самое.

Помогите пожалуйста. Google не сумел помочь. Самое обидное что все работало.

[Jimson]

Ничего не смыслю в LDAP. но сразу бросается в глаза что вы не дали информации со стороны LDAP сервера - что он пишет в логах в ответ на попытки zabbix к нему приконектится?

[DRVTiny]

Не могли бы вы скопировать сюда собственно DN, от имени которого пытаетесь делать BIND?
Насколько я понимаю, у Вас AD, а у пользователей AD зачастую бывает весьма неточное или даже в корне неверное представление о том, что такое DN и как он кодируется...
Попробуйте к тому же установить ldap-utils, в частности, ldapwhoami, и выполнить такой запрос к серверу AD:

ldapwhoami -x -D 'DN' -w 'PASSWORD' -H ldap://adserver.example.com:3389
или
ldapwhoami -x -D 'DN' -w 'PASSWORD' -H ldap://adserver.example.com

Собственно, я не понимаю, почему AD слушает и стандартный LDAP-порт и некий 3389, но по-моему отвечать он должен и там, и там.
На запрос ldapwhoami вы должны получить просто свой DN, если всё ОК, либо сообщение об ошибке, если что-то не так.

[[email protected]]

Ничего не смыслю в ldap. но сразу бросается в глаза что вы не дали информации со стороны ldap сервера - что он пишет в логах в ответ на попытки zabbix к нему приконектится?

На сервере в логах нет ничего

[Deks]

А пакет php5-ldap установлен?

[[email protected]]

А пакет php5-ldap установлен?

Да конечно.
Как я уже писал до обновления авторизация отлично работал

[[email protected]]

Не могли бы вы скопировать сюда собственно DN, от имени которого пытаетесь делать BIND?
Насколько я понимаю, у Вас AD, а у пользователей AD зачастую бывает весьма неточное или даже в корне неверное представление о том, что такое DN и как он кодируется...
Попробуйте к тому же установить ldap-utils, в частности, ldapwhoami, и выполнить такой запрос к серверу AD:

ldapwhoami -x -D 'DN' -w 'PASSWORD' -H ldap://adserver.example.com:3389
или
ldapwhoami -x -D 'DN' -w 'PASSWORD' -H ldap://adserver.example.com

Собственно, я не понимаю, почему AD слушает и стандартный LDAP-порт и некий 3389, но по-моему отвечать он должен и там, и там.
На запрос ldapwhoami вы должны получить просто свой DN, если всё ОК, либо сообщение об ошибке, если что-то не так.

Хост LDAP - ldap://dc-01.company.local
BaseDN - DC=company,DC=local
Атрибуты поиска - sAMAccountName
Имя для подключения (Bind DN) - [email protected]

[DRVTiny]

>BaseDN - DC=company,DC=local
Внутри этого BaseDN обязательно есть контейнер, который содержит собственно пользователей. Если сервер каталогов обслуживает большую компанию поиск от самого корня может отвалиться тупо по таймауту. Сделайте BaseDN более конкретным, указывающим конкретно на тот контейнер, в котором находятся пользователи. Например, BaseDN="CN=Domain Users,DC=company,DC=local"

>Атрибуты поиска - sAMAccountName
Логично.

>Имя для подключения (Bind DN) - [email protected]
Очень сомнительный вариант. Бинд по такому с позволения сказать "email'у" работает только в Active Directory, и то в общем не факт, что работает во всех случаях. Найдите собственно DN для этого [email protected] и пользуйтесь только им.

[DRVTiny]

>cannot bind by given Bind DN.
Я сейчас наверное залезу в исходники Zabbix, но уже итак есть сильное подозрение, что Zabbix просто стал проверять ещё до передачи LDAP-серверу тот факт, что переданный ему якобы BindDN действительно соответствует синтаксису DN. У вас же реально некий "email"-адрес, который вы по-хорошему можете использовать для авторизации либо в рамках SASL (и тогда в итоге SASL передаст LDAP-серверу некий auth-DN), либо - в серверах каталогов, реализованных в CommuniGate и Windows Server и равным образом отличающихся наплевательским отношением к стандартам.

[DRVTiny]

Из процедуры checkPass в файле frontends/php/include/classes/class.cldap.php :

                if (!empty($this->cnf['bind_dn']) && !empty($this->cnf['bind_password'])) {
                        // use superuser credentials
                        if (!ldap_bind($this->ds, $this->cnf['bind_dn'], $this->cnf['bind_password'])) {
                                error('LDAP: cannot bind by given Bind DN.');

                                return false;
                        }

Проверки записанного в конфигурации DN'а нет, так что, возможно, дело в версии библиотеки php5-ldap. Кстати, там можно сообщение об ошибке увидеть, просто в zabbix это не использовали.

Кстати, судя по комментарию в коде ("use superuser credentials") код писали люди, которые сами в LDAP мало что понимают. Это с одной стороны хорошо конечно (нет дотошных проверок и какой-нибудь извращённой логики работы с LDAP-каталогом), а с другой стороны - из-за этого код получился весьма топорным.

[Nassz]

Возможно ли добавить Юзер фильтры в аунтификацию забикса, что бы можно было сделать enabledService=zabbix