Здравствуйте, выскажусь более в художественном стиле нежели в техническом. Уж простите, кому не по душе.

Думаю все те, кто первый/второй раз настраивают OpenLDAP (типа вот меня) уже наизусть выучили, что slapd.conf типа deprecated и райт вэй - это использовать LDIF-бэкэнд для хранения конфигурационной базы cn=config, а не генерировать её при каждом запуске считывая slapd.conf.

Выдержка из админгайда на openldap.org:

The old style slapd.conf(5) file is still supported, but must be converted to the new slapd-config(5) format to allow runtime changes to be saved. While the old style configuration uses a single file, normally installed as /usr/local/etc/openldap/slapd.conf, the new style uses a slapd backend database to store the configuration. The configuration database normally resides in the /usr/local/etc/openldap/slapd.d directory. An alternate configuration directory (or file) can be specified via a command-line option to slapd(8).

Я в общем-то даже и согласен с этим, если бы не одно "но". И я вот только щас это прочитал:
openldap.org:

Note: some of the backends and of the distributed overlays do not support runtime configuration yet. In those cases, the old style slapd.conf(5) file must be used. 

Как много в себе скрывает этот маленький ноут.

А именно, кратко изложу свой опыт:
1 - Достаю из пакета версию 2.4.1.1-1 (Debian stable)

2 - Создаю самую минимальную конфигурацию из возможных в slapd.conf, описывая первую базу по минимуму, из бэкэндов и оверлэев кроме hdb ничего. Замечательно.

3 - Конвертирую slaptest'ом. Всё с этого момента забыли и удалили slapd.conf

4 - Создаю базу, завожу группы, пользователей, делаю аутентификацию для linux'ов. Всё хорошо.

5 - Решаю, что хорошо бы использовать Password Policy. Подключаю необходимые схемы, завожу правильные аккаунты, а вот оверлэй не подключается, при попытке его описать в cn=config (а вы помните, как это сделать без slapd.conf? Я нет. Вы slapd.conf уже выбросили? :-) ) Я понимаю, что это НИГДЕ не документировано. Всё, конец.

Щас такие же новички, как и я могут сказать: "Чувак, ну ты олень, посмотри в исходниках модуля, он же маленький, чего там искать-то, грепнул NAME и все дела."
Да. И будут правы, но не до конца. Есть то, что вы будете очень долго искать в исходниках, а именно описание самого класса. И даже если вы его там найдёте, вы готоы делать это часто? :-)

Естественно я теперь беру и использую slaptest чтобы понять, "а как же это выглядело бы если бы я использовал этот оверлэй в самом начале", а выглядело бы это так:

в выхлопе slaptest ЕСТЬ:
ldif с описанием конфигурации моего желанного оверлэя, только вот используется там какой-то странный класс olcPPolicyConfig. Смотрю у себя - нет такого в сакральном хранилище конфигурационных типов и классов, что именуется cn=schema.ldif.

То есть, даже если бы я знал какой класс указать, я должен был бы ещё и записать сам класс в системную схему. В документации этой информации нет. Да ладно в документации, я в гугле не нашёл ничего.

Корень зла - slaptest. Она изначально создаёт очень ограниченную конфигурацию, под то, что вы хотите прямо сейчас и вы не сможете исправить её вручную потом, если захотите подключить модуль или ещё что-нибудь. т.е. будете обречены на постоянное мартышечное передёргивание slaptest'a.

Обидно, коллеги. Потратил уеву тучу времени на фигню. Выдыхаю.

Вообще суть этого поста не в том чтобы жаловаться, а в том чтобы предостеречь других новичков, которые не хотят тратить время на то, чтобы изучать "устаревающий" slapd.conf и хотят эффективно его потратить, на то чтобы разобраться в актуальном. Лично я, советую вам не тратить время на slapd.d, а учить slapd.conf. (Ну "учить" громковато я сказал, всётки там не так всё сложно :-) )
Вот когда, разработчики насильственно уберут его поддержку, а это, сдаётся мне будет ещё оооочень не скоро, тогда и рассудим их. А так они ведь пишут, что не все бэкэнды работают. Только вот забыли написать какие и почему.