Наложения применяются к базам данных, соответственно записи наложений добавляются в качестве дочерних записей к записи той пользовательской базы данных, к которой мы хотим их применить. Записи наложений строятся на общем объектном классе olcOverlayConfig (обязательный атрибут olcOverlay), а также специфичном для конкретного наложения объектном классе, который всегда является потомком olcOverlayConfig и представляет собой контейнер для специфичных атрибутов данного наложения.
Для одной базы данных можно определить несколько наложений. Если Вы определяете несколько наложений для базы данных, возможно, будет иметь значение порядок применения наложений. Как и для большинства других записей каталога cn=config, упорядочивание наложений производится добавлением индекса X-ORDERED в фигурных скобках к значению атрибута olcOverlay, образующему RDN наложения. Соответственно, все те правила, которые применяются к атрибутам X-ORDERED, действительны и для наложений.
Наложения различаются не только своим функционалом, но и тем, какое количество действий требуется произвести для их добавления. В общем случае нужно выполнить следующие шаги:
frontend);Ко всем этим пунктам (кроме третьего) можно добавить "при необходимости", поскольку модуль наложения может быть статически вкомпилирован в slapd, дополнительного набора схемы может не требоваться, наложение может не иметь настроек или записей в пользовательской базе данных. Кроме того, порядок применения перечисленных шагов может быть плавающий. Так что относитесь к этому алгоритму творчески и выполняйте только те шаги, которые действительно необходимы.
В качестве примера рассмотрим наложение ppolicy, добавление которого охватывает все шаги нашего алгоритма.
Первый шаг, — загрузка динамического модуля для наложения ppolicy, — подробно описан нами ранее в качестве иллюстрации добавления еще одного динамического модуля к имеющимся. Если наложение ppolicy было статически вкомпилировано в slapd на этапе сборки, этот шаг не требуется.
Второй шаг, — добавление набора схемы данных для наложения ppolicy, — подробно описан нами ранее в качестве иллюстрации добавления еще одного набора схемы к имеющимся.
Для наложения ppolicy мы добавляем к записи определения пользовательской базы данных olcDatabase={1}mdb,cn=config дочернюю запись, основанную на объектном классе olcPPolicyConfig. В простейшем виде LDIF для добавления записи наложения будет выглядеть так:
dn: olcOverlay=ppolicy,olcDatabase={1}mdb,cn=configobjectClass: olcPPolicyConfigolcOverlay: ppolicy
Можно добавить запись в таком виде, а затем добавлять необходимые настройки наложения, модифицируя добавленную запись. А можно сразу определить атрибуты с настройками наложения при добавлении записи.
Обычно для наложения ppolicy определяют так называемую политику по умолчанию, то есть ту политику паролей, которая будет применяться к записям пользователей, для которых явно не задано никакой другой политики паролей. Политики паролей определяются в виде записей в пользовательской базе данных, основанной на объектном классе pwdPolicy и его атрибутах. Определим простой LDIF для политики паролей по умолчанию:
dn: ou=System,dc=mycompany,dc=ruobjectClass: organizationalUnitou: Systemdn: cn=PPolicy Default,ou=System,dc=mycompany,dc=ruobjectClass: applicationProcessobjectClass: pwdPolicycn: PPolicy DefaultpwdAttribute: 2.5.4.35pwdInHistory: 3
В данном LDIF определяются две записи. Первая из них — контейнер для "системных" записей, введена просто для удобства, чтобы не засорять корневую запись каталога всевозможными "нужными" записями.
Вторая запись — дочерняя по отношению к первой запись политики паролей, основанная на объектном классе pwdPolicy. Поскольку pwdPolicy — вспомогательный объектный класс, поэтому для образования записи мы используем простой структурный объектный класс applicationProcess (обязательный атрбут cn). В обязательном атрибуте объектного класса pwdPolicy pwdAttribute указывается OID парольного атрибута, в данном случае это OID атрибута userPassword. Наконец, то, ради чего мы определяли данную политику — атрибут pwdInHistory со значением 3, то есть для каждой записи пользователя будет поддерживаться история изменения паролей, где будут храниться 3 последних пароля, определённых для этой записи. Соответственно, при очередном изменении пароля для записи новый пароль применится лишь в том случае, если он не совпадает ни с одним из хранящихся в истории паролей. Подробности можно посмотреть в учебнике LFRS.
Поместив наш LDIF с политикой паролей по умолчанию в файл /tmp/ldifs/102-ppolicy_add_default.ldif добавим его в пользовательский DIT:
# ldapadd -x -D 'cn=manager,ou=System,dc=mycompany,dc=ru' -W -f /tmp/ldifs/102-ppolicy_add_default.ldif Enter LDAP Password: adding new entry "ou=System,dc=mycompany,dc=ru" adding new entry "cn=PPolicy Default,ou=System,dc=mycompany,dc=ru"
Убедимся, что наша запись добавлена:
# ldapsearch -x -LLL -b 'ou=System,dc=mycompany,dc=ru' '(cn=PPolicy Default)' dn: cn=PPolicy Default,ou=System,dc=mycompany,dc=ru objectClass: applicationProcess objectClass: pwdPolicy cn: PPolicy Default pwdAttribute: 2.5.4.35 pwdInHistory: 3
Теперь мы можем расширить наш LDIF для добавления наложения ppolicy, добавив туда DN нашей записи с политикой по умолчанию как значение атрибута olcPPolicyDefault:
dn: olcOverlay=ppolicy,olcDatabase={1}mdb,cn=configobjectClass: olcPPolicyConfigolcOverlay: ppolicyolcPPolicyDefault: cn=PPolicy Default,ou=System,dc=mycompany,dc=ru
Итак, сохранив данный LDIF в файл /tmp/ldifs/103-ppolicy_add_overlay_to_db.ldif, мы можем наконец добавить наложение ppolicy к нашей пользовательской базе данных:
# ldapadd -x -D 'cn=config' -W -f /tmp/ldifs/103-ppolicy_add_overlay_to_db.ldif
Enter LDAP Password:
adding new entry "olcOverlay=ppolicy,olcDatabase={1}mdb,cn=config"
Посмотрим, что получилось:
# ldapsearch -x -LLL -D 'cn=config' -W -b 'olcDatabase={1}mdb,cn=config' '(olcOverlay=*)'
Enter LDAP Password:
dn: olcOverlay={0}ppolicy,olcDatabase={1}mdb,cn=config
objectClass: olcPPolicyConfig
olcOverlay: {0}ppolicy
olcPPolicyDefault: cn=PPolicy Default,ou=System,dc=mycompany,dc=ru
Поскольку это наше первое наложение для базы данных, оно получило индекс {0}. Теперь попробуем расширить запись наложения ppolicy, добавив новую настройку в виде атрибута olcPPolicyHashCleartext. Создадим LDIF-файл /tmp/ldifs/104-ppolicy_modify_overlay.ldif такого содержания:
dn: olcOverlay={0}ppolicy,olcDatabase={1}mdb,cn=configchangetype: modifyadd: olcPPolicyHashCleartextolcPPolicyHashCleartext: TRUE
Применим наше изменение:
# ldapmodify -x -D 'cn=config' -W -f /tmp/ldifs/104-ppolicy_modify_overlay.ldif
Enter LDAP Password:
modifying entry "olcOverlay={0}ppolicy,olcDatabase={1}mdb,cn=config"
Посмотрим, что получилось:
# ldapsearch -x -LLL -D 'cn=config' -W -b 'olcDatabase={1}mdb,cn=config' '(olcOverlay=*)'
Enter LDAP Password:
dn: olcOverlay={0}ppolicy,olcDatabase={1}mdb,cn=config
objectClass: olcPPolicyConfig
olcOverlay: {0}ppolicy
olcPPolicyDefault: cn=PPolicy Default,ou=System,dc=mycompany,dc=ru
olcPPolicyHashCleartext: TRUE
Таким образом, мы прошли полный цикл добавления наложения: от добавления модуля и набора схемы данных до определения и модификации записи наложения, попутно расширив необходимыми записями пользовательское DIT.
В итоге у нас есть вполне работоспособный каталог. Чем заняться дальше?