Outlook и адресная книга в OpenLDAP
Dec. 7th, 2012 01:49 pmВ адресной книге Outlook (не Express) есть такая фича, как просмотр адресов (LDAP address-list-browsing). В русском Outlook в свойствах адресной книги это называется "Включить просмотр (требуется серверная поддержка)". Это когда вызываешь адресную книгу и в ней сразу показывается список всех адресов. Это по умолчанию работает с Exchange Server (duh!) и Communigate Pro (кто бы сомневался).
Чтобы получить эту функциональность с OpenLDAP в качестве LDAP сервера, последний должен уметь две вещи.
1. Поддерживать VLV. Для этого в описании базы в slapd.conf надо включить "overlay sssvlv".
2. Уметь отсортировать выдаваемый результат по аттрибуту cn. И вот это OpenLDAP делать отказывается с ошибкой "LDAPMessage searchResDone(11) inappropriateMatching (serverSort control: No ordering rule)". Потому что атрибут name и унаследованные от него атрибуты (cn, sn и др.) не поддерживают ORDERING. А всего-то надо добавить атрибуту name свойство "ORDERING caseIgnoreOrderingMatch".
В конфиге это сделать нельзя, т.к. свойства атрибута name зашиты в исходниках. Поэтому патч, после которого адресная книга начинает браузиться:
Ссылка на обсуждение: http://www.openldap.org/lists/openldap-technical/201212/threads.html#00002
Outlook по умолчанию делает запрос, который можно представить как
Если бы Outlook в запросе сообщал желаемое правило сортировки, по аналогии с
Чтобы получить эту функциональность с OpenLDAP в качестве LDAP сервера, последний должен уметь две вещи.
1. Поддерживать VLV. Для этого в описании базы в slapd.conf надо включить "overlay sssvlv".
2. Уметь отсортировать выдаваемый результат по аттрибуту cn. И вот это OpenLDAP делать отказывается с ошибкой "LDAPMessage searchResDone(11) inappropriateMatching (serverSort control: No ordering rule)". Потому что атрибут name и унаследованные от него атрибуты (cn, sn и др.) не поддерживают ORDERING. А всего-то надо добавить атрибуту name свойство "ORDERING caseIgnoreOrderingMatch".
В конфиге это сделать нельзя, т.к. свойства атрибута name зашиты в исходниках. Поэтому патч, после которого адресная книга начинает браузиться:
--- ./openldap-2.4.33/servers/slapd/schema_prep.c.orig 2012-12-07 09:54:56.000000000 +0700 +++ ./openldap-2.4.33/servers/slapd/schema_prep.c 2012-12-07 09:58:10.000000000 +0700 @@ -908,6 +908,7 @@ "DESC 'RFC4519: common supertype of name attributes' " "EQUALITY caseIgnoreMatch " "SUBSTR caseIgnoreSubstringsMatch " + "ORDERING caseIgnoreOrderingMatch " "SYNTAX 1.3.6.1.4.1.1466.115.121.1.15{32768} )", NULL, SLAP_AT_ABSTRACT, NULL, NULL,
Ссылка на обсуждение: http://www.openldap.org/lists/openldap-technical/201212/threads.html#00002
Outlook по умолчанию делает запрос, который можно представить как
ldapsearch -E sss=cn '(cn=*)' cnчто означает: "отсортируй мне выдачу согласно правилу сортировки, которое определено на сервере для атрибута cn". А на сервере для cn никакого правила сортировки не определено, потому что не предусмотрено в описании атрибута в RFC4519, и возникает ошибка.
Если бы Outlook в запросе сообщал желаемое правило сортировки, по аналогии с
ldapsearch -E sss=cn:caseIgnoreOrderingMatch '(cn=*)' cnто всё работало бы из коробки без модификации стандартной схемы.