Для AD чаще используется сервисная учётка, то бишь первый подход. А для OpenLDAP - второй.

Да, так пароль обычно и проверяется. В AD можно сразу логин указывать, а в случае openldap нужно сначала через сервисную учетку найти DN пользователя, а затем уже забиндиться с DN и паролем

Оверлей memberOf может не использоваться и это вполне нормально. memberOf, по сути, является автоматической денормализацией при записи в базу и не всегда её делать — хорошая идея. Не говоря уже о том, что, вообще, это AD-специфическая фича, которая есть не во всех реализациях службы каталогов.

Насчет совета использовать reOpenLDAP, нужно учитывать, что автор на него забил и коммитов по существу туда не было уже почти 3 года.

может быть, автор добился того, что его система работает нормально ...

9 issues, которые проявляются отказами при записи в случае master-master, и чинятся повтором операции - весьма впечатляющий показатель. А в остальном сервер реализует спецификацию в полном объёме - чего ещё требуется, что развивать-то?

rethinkdb тоже вроде забросили и куча незакрытых багов на гитхабе, но у меня есть знакомый, который до сих пор в проде крайную версию гоняет с 3 серверами и базой данных в 500 гигабайт, и пока менять базу не собирается, так как по его словам всё работает...

хотя да, там тоже иногда ошибки бывают при записи, и тоже надо повторять операцию

Ты сам-то веришь, что для сложной сетевой БД с MVCC и ACID, разрабатываемой одним человеком и написанной на Си, такое может случиться?

Ну, разумеется, гоняет. Куда он теперь денется-то? :)

Особенно, учитывая, что разработка заглохла после того, как разработчики ушли из компании, в которой пилили форк по заказу Мегафона.

Пофиксить эти баги, например? :)

Снова всем привет! Появилась у нас тут с коллегой идея автоматизировать выдачу доступов юзерам на фаерволе. Идея в том, чтобы в лдап атрибутах юзера хранить список ip адресов юзера. Так же возможно там же, в атрибутах юзера хранить и разрешенные юзеру маршруты. Потом некая поделка идет в лдап, дергает всех включенных юзеров и строит на основе этих данные ipset'ы. Вопрос к знатокам: знаю что сделать это относительно просто, но вот бест ли это практикс так делать? Так же по самой реализации вопрос, (юзаю фрииипу) можно просто использовать существующие аттрибуты типа pager, или лучше создать свой? Вот тут пишут что лучше использовать существующие... В общем прошу по этому поводу совета как лучше поступить и стоит ли вообще так делать или лучше сложить всю эту в инфу в отдельную базу...

Лучше храните это обычной РСУБД. Либо уложите эти данные в стандартные схемы.
Обычно (хоть и есть исключения), как только у вас возникает потребность делать собственную схему, скорее всего, это тот момент, когда вам становится нужен не LDAP, а что-то другое.

freeipa же, стоит воспринимать, вообще, не как LDAP. Да, там внутри есть служба каталогов, но это просто внутренний компонент freeipa, которая сама по себе является законченным решением, и так уж получилось, что в качестве БД она использует 389ds с собственной схемой.

Пытаться что-то добавлять в каталог freeipa — это всё равно, что добавлять свои кастомные таблицы и связи в БД, например, gitlab-а. Чисто технически тебе никто не помешает, конечно, но это гарантированный способ познать боль при поддержке такого кастома во внутренней БД стороннего софта.

про внутреннюю бд поясните пожалуйста, не понял

Это как MS AD, выглядит как LDAP, но лучше не лезь туда)

В AD как раз лезть можно :)

ну вот например в схеме нет ip, зато есть pager, в итоге можно вот что-то такое нарисовать:

~$ ldapsearch -v -H ldap://ipa -D uid=admin -W -LLL -b "cn=users" "(uid=user)" pager|grep pager
ldap_initialize( ldap://ipa/??base )
Enter LDAP Password: 
filter: (uid=user)
requesting: pager 
pager: 192.168.0.111/24
pager: 10.1.0.115/32
pager: 10.1.0.88/fa:ce:fa:ce:fa:ce

Да везде можно, но зачем?)