Network Working Group Request for Comments: 3088 Категория: Experimental K. Zeilenga, OpenLDAP Foundation Апрель 2001 г.
В этом документе определяется экспериментальный протокол для сообщества Интернет. В нём не даётся спецификация какого-либо рода стандарта Интернет. Принимаются обсуждения и предложения по улучшению протокола. Ограничений на распространение этого документа не накладывается.
Copyright (C) The Internet Society (2001). Все права защищены.
В рамках проекта OpenLDAP функционирует экспериментальный сервис отсылок LDAP (Lightweight Directory Access Protocol), известный как "Корневой сервис OpenLDAP". Эта автоматизированная система генерирует отсылки на основе информации о местоположении службы каталогов, опубликованной в ресурсных записях DNS SRV (ресурсные записи указания местоположения сервисов в системе доменных имён DNS). Данная система описана в этом документе.
Каталоги LDAP [RFC2251] используют унаследованную от X.500 [X500] иерархическую схему именования. Традиционно в системах каталогов X.500 использовалась геополитическая схема именования (например, CN=Jane Doe,OU=Engineering,O=Example,ST=CA,C=US). Тем не менее, инфраструктура регистрации и сервисы определения местонахождения службы каталога по имени для многих составных частей такого иерархического именования неадекватны или вообще отсутствуют.
Для построения глобального каталога требуется надежная инфраструктура регистрации и сервис определения местонахождения служб каталогов. Использование схемы именования на основе Интернет-доменов [RFC2247] (например, UID=jdoe,DC=eng,DC=example,DC=net) позволяет службам каталогов LDAP эффективно использовать существующую инфраструктуру регистрации DNS [RFC1034], при этом для определения местонахождения служб каталогов [LOCATE] могут быть использованы ресурсные записи DNS SRV [RFC2782].
Большинство существующих реализаций LDAP не поддерживает определение местонахождения служб каталогов с помощью ресурсных записей DNS SRV. Однако, большинство серверов поддерживает генерацию отсылок на "вышестоящий" сервер (серверы). Описываемый сервис обеспечивает "корневой" сервис LDAP, который может использоваться серверами в качестве вышестоящей службы в отсылках.
Этот сервис также может использоваться напрямую клиентами для определения местонахождения служб каталогов, связанных с уникальным именем [RFC2253] произвольного объекта каталога, если это уникальное имя принадлежит иерархии, основанной на доменах.
Предупреждение: Используемые в данном сервисе механизмы являются экспериментальными. Представленные в этом документе описания не являются дефинитивными. Дефинитивные механизмы должны быть опубликованы в документе (документах), определяющем стандарты (Standard Track).
Данный сервис возвращает отсылки, сгенерированные из ресурсных записей DNS SRV [RFC2782].
Данный сервис отображает DN [RFC2253] в полное доменное имя с использованием следующего алгоритма:
domain = null;
foreach RDN left-to-right // [1]
{
if not multi-valued RDN and
RDN.type == domainComponent
{
if ( domain == null || domain == "." )
{ // начало формирования доменного имени
domain = "";
}
else
{ // присоединить разделитель
domain .= ".";
}
if ( RDN.value == "." )
{ // корневой уровень
domain = ".";
}
else
{ // присоединить domainComponent
domain .= RDN.value;
}
continue;
}
domain = null;
}
Примеры:
Уникальное имя Домен ----------------------------- ------------ DC=example,DC=net example.net UID=jdoe,DC=example,DC=net example.net DC=. . [2] DC=example,DC=net,DC=. . [3] DC=example,DC=.,DC=net net [4] DC=example.net example.net [5] CN=Jane Doe,O=example,C=US null UID=jdoe,DC=example,C=US null DC=example,O=example,DC=net net DC=example+O=example,DC=net net DC=example,C=US+DC=net null
Примечания:
Если полученный в результате домен представляет собой null или ".", сервис прекращает дальнейшую обработку и возвращает noSuchObject. В дальнейших реализациях данного сервиса обработка может прекращаться, если полученный в результате домен представляет собой домен верхнего уровня.
Описываемый корневой сервис определяет местонахождение служб каталогов, связанных с полученным полным доменным именем, путём запроса ресурсных записей LDAP SRV в системе доменных имён DNS. Для домена example.net сервис будет выполнять запрос SRV для доменного имени "_ldap._tcp.example.net". Успешный запрос вернёт одну или несколько ресурсных записей в форме:
_ldap._tcp.example.net. IN SRV 0 0 389 ldap.example.net.
Если никаких ресурсных записей LDAP SRV не было возвращено, или при возникновении какой-либо ошибки DNS, сервис прекращает дальнейшую обработку и возвращает noSuchObject. В дальнейших реализациях данного сервиса будет улучшена обработка временно возникающих ошибок.
Для каждой ресурсной записи DNS SRV, которые были возвращены по запросу для конкретного домена, составляется LDAP URL [RFC2255]. Для приведённой выше ресурсной записи будет составлен следующий URL:
ldap://ldap.example.net:389/
Эти URL затем возвращаются в отсылке. В настоящее время эти URL возвращаются в том порядке, в каком были распознаны. То есть, сам сервер не использует информацию о приоритете и весе хоста, указываемую в ресурсных записях SRV. В дальнейших реализациях данного сервиса эта информация может учитываться.
В этом разделе описывается, как данный сервис выполняет основные операции LDAP. Сервис поддерживает операции, расширенные посредством некоторых элементов управления, как описано в следующем разделе.
Основные операции (добавление, сравнение, удаление, модификация, переименование, поиск) возвращают в качестве результата отсылку, если целевое (или базовое) DN может быть отображено в набор LDAP URL, как описано выше. В противном случае возвращается noSuchObject или другой подходящий ответ.
Описываемый сервис принимает "анонимные" подсоединения с указанием версии 2 или версии 3 данного протокола. В ответ на все остальные запросы Bind будет возвращён ответ с неуспешным результирующим кодом в поле resultCode. В частности, клиентам, отправляющим удостоверяющие данные в открытом виде, будет отправлен ответ с результирующим кодом unwillingToPerform и текстом, содержащим предостережение относительно возможного раскрытия паролей посторонним лицам.
Поскольку данный сервис доступен только для чтения, аутентификация LDAPv3 [RFC2829] не поддерживается.
При получении запроса Unbind сервер прекращает обработку всех незавершённых запросов, сделанных данным клиентом, и закрывает соединение.
В настоящее время данный сервис распознаёт любые расширенные операции. В дальнейших реализациях данного сервиса может поддерживаться операция Start TLS [RFC2830] и другие операции.
В дальнейших реализациях данного сервиса для всех операций обновления может возвращаться ответ с результирующим кодом unwillingToPerform, поскольку этот сервис не поддерживает проверку подлинности.
Данный сервис поддерживает элемент управления ManageDSAit. Неподдерживаемые элементы управления обслуживаются в соответствии с требованиями RFC 2251.
Сервер распознает и соблюдает предоставляемый с операциями элемент управления ManageDSAit [NAMEDREF].
Если DNS-сведения о местонахождении службы каталогов доступны для базового DN, то для операций, отличных от операции поиска, сервис будет возвращать сообщение с результирующим кодом unwillingToPerform. Для операций поиска сервис будет возвращать запись в том случае, если она попадает в диапазон поиска и удовлетворяет заданному поисковому фильтру. Например:
клиент: searchRequest {
base="DC=example,DC=net"
scope=base
filter=(objectClass=*)
ManageDSAit
}
сервер: searchEntry {
dn: DC=example,DC=net
objectClass: referral
objectClass: extensibleObject
dc: example
ref: ldap://ldap.example.net:389/
associatedDomain: example.net
}
сервер: searchResult {
success
}
Если DNS-сведения о местонахождении службы каталогов доступны для DC-части подчиненной записи, сервис будет возвращать сообщение с результирующим кодом noSuchObject и полем matchedDN, в котором указана DC-часть базовой записи для операций поиска и обновления.
клиент: searchRequest {
base="CN=subordinate,DC=example,DC=net"
scope=base
filter=(objectClass=*)
ManageDSAit
}
сервер: searchResult {
noSuchObject
matchedDN="DC=example,DC=net"
}
Серверы могут быть настроены таким образом, чтобы запросы на обработку вышестоящих записей перенаправлялись на <ldap://root.openldap.org:389>.
Несмотря на то, что клиенты могут использовать данный сервис напрямую, это не рекомендуется. Клиентам следует использовать локальную службу каталогов и обращаться к описываемому сервису только при перенаправлении к нему.
Сервис поддерживает клиентов LDAPv3 и LDAPv2+ [LDAPv2+], работающих по протоколу TCP/IPv4. В дальнейших реализациях данного сервиса может поддерживаться TCP/IPv6 или другие протоколы транспортного/сетевого уровней.
В настоящее время данный сервис работает на одном хосте. Этот хост и связанные с ними сетевые ресурсы еще не исчерпаны. Если же они будут исчерпаны, мы считаем, что сможем довольно просто масштабировать сервис до необходимого уровня за счёт общих методов распределенной балансировки нагрузки. Также данный сервис может быть легко продублирован локально.
Данный сервис способен обходить известные проблемы совместимости в поддержке различных вариантов протокола LDAP.
Развёрнутый сервер реализует все возможности LDAPv3 [RFC2251], необходимые для предоставления данного сервиса.
LDAPv2 [RFC1777] не поддерживает возвращение отсылок и, следовательно, не может работать с этим сервисом. Хотя клиент LDAPv2 может соединиться с данным сервисом и выполнить запрос, он будет интерпретировать возвращаемую отсылку как неизвестную ошибку.
В LDAPv2+ [LDAPv2+] предствлено несколько расширений для LDAPv2, в том числе отсылки. В LDAPv2+, как и в LDAPv3, не требуется выполнять операции подсоединения Bind перед тем, как запрашивать другие операции. Представление отсылок в LDAPv2+ и LDAPv3 отличается, и, поскольку без выполнения операции Bind определить версию протокола невозможно, в этом случае сервис возвращает отсылки LDAPv3. Однако, в связи с тем, что большинство клиентов LDAPv2+ по умолчанию выполняет запросы Bind (для совместимости с серверами LDAPv2), до сих пор это не вызывало каких-либо проблем совместимости.
В дальнейших реализациях данного сервиса может быть прекращена поддержка LDAPv2+ (и LDAPv2).
CLDAP [RFC1798] не поддерживает возвращение отсылок и потому не поддерживается.
Данный сервис предоставляет информацию "анонимным" клиентам. Эта информация получена из открытых источников, а именно из системы доменных имен (DNS).
При использовании аутентификации потребовалось бы, чтобы клиенты раскрывали данному сервису некоторую конфиденциальную информацию. Это было бы излишним вмешательством в частные интересы.
Отсутствие шифрования позволяет перехватывать запросы клиентов и ответы на них. В дальнейших реализациях данного сервиса может быть реализована поддержка шифрования (например, посредством операции Start TLS [RFC2830]).
Данный сервис не предоставляет защиты целостности данных. Он может быть подвержен различным формам DNS-спуфинга и атак. Даже при условии обеспечения целостности сеанса и операций LDAP, невозможно поручиться за целостность информации DNS. В дальнейших реализациях данного сервиса может быть реализована поддержка DNSSEC и обеспечиваться защита целостности (посредством SASL, TLS или IPSEC).
Данный сервис может быть подвержен различным атакам типа "отказ от обслуживания". Сервис имеет возможность осуществлять блокирование доступа по результатам контроля ряда факторов. Планируется и далее использовать данную возможность, хотя она, вероятно, будет неэффективна в предотвращении сложных атак. В дальнейших реализациях данного сервиса, скорее всего, потребуется более совершенная защита от подобных атак.
DNS — хороший связующий элемент. При целенаправленном использовании системы доменных имён можно строить глобальные каталоги LDAP без необходимости организации специфичной для протокола инфраструктуры регистрации.
Кроме того, использование DNS для определения местонахождения служб каталогов позволяет строить глобальные каталоги "по мере необходимости". То есть, участником может стать любое заинтересованное лицо, у которого имеется доменное имя. При этом участия в системе вышестоящего доменного имени не требуется.
Дополнительную информацию о проекте OpenLDAP и корневом сервисе OpenLDAP можно найти по адресу <http://www.openldap.org/>.
Kurt Zeilenga
OpenLDAP Foundation
EMail: kurt@openldap.org
Интернет-хостинг для данного эксперимента был предоставлен Internet Software Consortium <http://www.isc.org/>. Вычислительные ресурсы были предоставлены Net Boolean Incorporated <http://www.boolean.net/>. Данный эксперимент был бы невозможен без содействия многочисленных добровольцев из Open Sourse-сообщества. Описанный в данном документе механизм основан на механизмах, представленных в [RFC2247] и [LOCATE].
[RFC1034] Mockapetris, P., "Domain Names - Concepts and Facilities", STD 13, RFC 1034, ноябрь 1987 г.
[RFC1777] Yeong, W., Howes, T. and S. Kille, "LDAP", RFC 1777, март 1995 г.
[RFC1798] Young, A., "Connection-less Lightweight Directory Access Protocol", RFC 1798, июнь 1995 г.
[RFC2119] Bradner, S., "Ключевые слова для обозначения уровня требований в RFC", BCP 14, RFC 2119, март 1997 г.
[RFC2247] Kille, S., Wahl, M., Grimstad, A., Huber, R. and S. Sataluri, "Using Domains in LDAP/X.500 Distinguished Names", RFC 2247, январь 1998 г.
[RFC2251] Wahl, M., Howes, T. and S. Kille, "LDAP (v3)", RFC 2251, декабрь 1997 г.
[RFC2253] Wahl, M., Kille, S. and T. Howes, "LDAP (v3): UTF-8 String Representation of Distinguished Names", RFC 2253, декабрь 1997 г.
[RFC2255] Howes, T. and M. Smith, "The LDAP URL Format", RFC 2255, декабрь 1997 г.
[RFC2782] Gulbrandsen, A., Vixie, P. and L. Esibov, "A DNS RR for specifying the location of services (DNS SRV)", RFC 2782, февраль 2000 г.
[RFC2829] Wahl, M., Alvestrand, H., Hodges, J. and R. Morgan, "Authentication Methods for LDAP", RFC 2829, май 2000 г.
[RFC2830] Hodges, J., Morgan, R. and M. Wahl, "LDAP (v3): Extension for Transport Layer Security", RFC 2830, май 2000 г.
[LOCATE] IETF LDAPext WG, "Discovering LDAP Services with DNS", работы продолжаются.
[LDAPv2+] University of Michigan LDAP Team, "Referrals within the LDAPv2 Protocol", август 1996 г.
[NAMEDREF] Под редакцией Zeilenga, K., "Named Subordinate References in LDAP Directories", работы продолжаются.
[X500] ITU-T Rec. X.500, "The Directory: Overview of Concepts, Models and Service", 1993 г.
Copyright (C) Internet Society (2001). Все права защищены.
Этот документ и его переводы могут быть скопированы и переработаны в другие документы. Производные работы, комментирующие или иным способом поясняющие данный документ, либо оказывающие помощь в его реализации, могут быть подготовлены, скопированы, опубликованы и распространены, целиком или частями, без каких-либо ограничений, при условии, что указанное выше уведомление об авторском праве и этот параграф будут включены во все такие копии и производные работы. Однако, в этот документ как таковой не может быть внесено каких-либо изменений, таких как удаление уведомления об авторских правах или ссылок на Internet Society или другие организации Интернет, за исключением случаев, когда это требуется для разработки стандартов Интернет (при этом должны быть пройдены процедуры получения авторских прав, определённые в стандартах Интернет), либо когда это требуется при переводе на языки, отличные от английского.
Предоставляемые выше ограниченные права являются бессрочными и не подлежат отзыву Internet Society, его наследниками или правопреемниками.
Этот документ и содержащаяся в нём информация распространяются "КАК ЕСТЬ" и INTERNET SOCIETY И INTERNET ENGINEERING TASK FORCE ОТКАЗЫВАЮТСЯ ОТ ВСЕХ ГАРАНТИЙ, ЯВНЫХ ИЛИ ПОДРАЗУМЕВАЕМЫХ, ВКЛЮЧАЯ, ПОМИМО ПРОЧЕГО, ЛЮБЫЕ ГАРАНТИИ ТОГО, ЧТО ИСПОЛЬЗОВАНИЕ ПРИВЕДЁННОЙ ЗДЕСЬ ИНФОРМАЦИИ НЕ НАРУШАЕТ КАКИХ-ЛИБО ПРАВ ИЛИ ЛЮБЫЕ ПОДРАЗУМЕВАЕМЫЕ ГАРАНТИИ ПРИГОДНОСТИ ДЛЯ КОНКРЕТНЫХ ЦЕЛЕЙ.
Финансирование функций RFC Editor в настоящий момент обеспечивается Internet Society.