Назад | Перейти на главную страницу

Openldap RootDN и другой пользователь admin работают по-разному при изменении userPassword

Используя OpenLDAP (2.4.44) в CENTOS 7 и настроив сквозную передачу {SASL} на другой удаленный LDAP для некоторых пользователей, использующих поле userPassword. Это может быть изменено (перезаписано) на использование локального пароля {CRYPT}, а не сквозной передачи SASL, по разным причинам. У нас есть сценарий, который изменяет это как действие, запрошенное администратором, то есть с {SASL}user@abc.qwe.com на {CRYPT} skfghdfghdhwsiy (и один другой способ с {CRYPT} на {SASL}, который не вызывает проблем). Однако заметили, что сценарий всегда вызывает «неудачный» вход на удаленный сервер LDAP SASL. Мы могли бы жить с этим одним неудачным входом в систему, но, к сожалению, впоследствии любые изменения пароля (локальный Openldap) для этого пользователя также будут пытаться войти через SASL (Зачем?) и после нескольких попыток блокирует пользователя на удаленном сервере LDAP, подключенном к SASL. Пользователь admin в скрипте это НЕ RootDN, но специальный пользователь «admin» с разрешениями ACL для изменения userPassword для данного пользователя. Вещи, которые я разработал:

Есть какие-нибудь подсказки или объяснения того, как это работает?

Спасибо

Пока не уверен в причинах, но обнаружил, что удаление (удаление) поля userPassword (как одна операция), а затем установка его (как {SASL} или {CRYPT} по мере необходимости) во второй операции с помощью 'admin' (не RootDN) пользователь (правильно) не вызывает SASL / другой LDAP, поэтому нет сбойных паролей на удаленном LDAP.

Это единственная операция, которая вызвала проблему, но неясно, почему это так, но, по крайней мере, есть рабочее решение.

Потратил несколько дней на это перед публикацией! Почему вы всегда находите «ответ» сразу после публикации! Спасибо