Использование Ppolicy в одноранговом кластере поставщика может вызвать условие обновления потребителя.

Мой ldap состоит из кластера из трех провайдеров, которые реплицируются друг на друга, и группы потребителей, реплицирующихся от них, и у нас установлена ​​политика ppolicy как для наших провайдеров, так и для потребителей, хотя в настоящее время мы не используем ее для обеспечения соблюдения каких-либо конкретных политик. автоматически.

Недавно я обнаружил ситуацию, когда скрипту не удавалось войти в систему с учетной записью службы, отличной от rootDN, ко всем трем экземплярам провайдера в короткие сроки. Поставщики, кажется, могут быстро во всем разобраться, но потребители иногда обнаруживают некоторую несогласованность ContextCSN, и когда это происходит, потребители переходят в состояние ОБНОВЛЕНИЯ, вызванное обновлениями операционных атрибутов в записи dn учетной записи службы у всех трех поставщиков почти в момент в то же время. В производственной среде это может вызвать задержку из-за дополнительной загрузки ЦП и сетевого трафика при одновременном обновлении всех потребителей.

Единственная соответствующая документация, которую мне удалось найти для этого варианта использования, находится по адресу https://linux.die.net/man/5/slapo-ppolicy:

Обратите внимание, что текущее предложение политики паролей IETF не определяет, как эти рабочие атрибуты будут вести себя в среде репликации. Как правило, попытки аутентификации на подчиненном сервере влияют только на копию рабочих атрибутов на этом подчиненном сервере и не влияют на какие-либо атрибуты входа пользователя на главном сервере. Изменения рабочих атрибутов, возникающие в результате попыток аутентификации на главном сервере, обычно реплицируются на подчиненные устройства (а также перезаписывают любые изменения, возникшие на подчиненном сервере). Такое поведение не гарантируется и может быть изменено при появлении официальной спецификации.

И связанная с этим возможность потребителей отправлять обновления вверх по цепочке репликации с использованием наложения цепочки:

ppolicy_forward_updates Укажите, что изменения состояния политики, возникающие в результате операций привязки (таких как сбои записи, блокировка и т. д.) на потребителе, должны пересылаться главному устройству, а не записываться непосредственно в локальную базу данных потребителя. Этот параметр полезен только для потребителя репликации, а также требует соответствующей настройки параметра updateref и наложения цепочки.

tl;dr Ppolicy записал операционные атрибуты в dn сервисной учетной записи для всех экземпляров моего провайдера в то же время, когда мой SA использовал неправильный пароль для входа во все они одновременно, и заставил всех моих потребителей обновиться одновременно. Мой вопрос: является ли наложение ppolicy по своей сути небезопасным для кластера провайдеров? Прямо сейчас я рассматриваю эти варианты, чтобы избавиться от риска случайного повторного запуска потребительского ОБНОВЛЕНИЯ:

• Удалите наложение ppolicy из реплицируемого бэкэнда (я все еще проверяю, есть ли что-нибудь, для чего мы на самом деле его используем, но если в этой конфигурации оно по своей сути небезопасно, то его нужно удалить)
• Переместите все учетные записи служб в другую базу данных, в которой не установлена ​​ppolicy.

Спасибо!