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 для данного пользователя. Вещи, которые я разработал:

• Это проблема LDAP (не SASL). Проблема заключается в том, что OpenLDAP вызывает SASL, когда {SASL} не установлен в userPassword.
• Если пользователь RootDN openLDAP вводит {CRYPT} userPassword, проблем нет - поэтому я предполагаю, что RootDN имеет некоторые особые полномочия / не запускает что-то при обновлении userPassword?
• Если пользователь 'Admin' с разрешениями на управление userPassword меняет, возникают проблемы, и проблема сохраняется при всех изменениях пароля ... до
• Там кажется точкой, когда он перестает (неправильно) переходить на SASL. Тайм-аут / кеш. Еще не сузил и не доказал.

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

Спасибо