В DN описывается содержимое атрибутов в дереве (так называемый путь навигации), требуемое для доступа к конкретной записи ИЛИ базовой (стартовой) записи поиска.
DN состоит из серии RDN (Relative Distinguished Names, относительных уникальных имён), определяемых путём перемещения ВВЕРХ по дереву (DIT) в направлении его корневой записи (суффикса или базовой записи), и записываемых СЛЕВА НАПРАВО, в отличие, например, от файловой системы, где пути записываются СПРАВА НАЛЕВО.
DN записывается СЛЕВА НАПРАВО.
При добавлении в DIT новой записи с помощью DN серверу сообщается, каким образом структурировать (или разместить) данную запись. Пример добавления новых записей с использованием файла LDIF (точно также их можно добавить с помощью LDAP-браузера или специализированного клиентского инструмента LDAP).
version: 1 ## нет строгого требования указывать версию (version), ## но это является хорошим тоном для совместимости с будущими версиями ## ОПРЕДЕЛЯЕМ DIT ROOT/BASE/SUFFIX #### ## используется формат RFC 2377 ## dcObject - это ВСПОМОГАТЕЛЬНЫЙ объектный класс и, кроме него, запись ## ДОЛЖНА иметь СТРУКТУРНЫЙ объектный класс (в данном случае, organization) # это последовательность ЗАПИСИ и ей предшествует ПУСТАЯ СТРОКА dn: dc=example,dc=com dc: example description: The best company in the whole world objectClass: dcObject objectClass: organization o: Example, Inc. ## ПЕРВЫЙ уровень иерархии - люди (people) # это последовательность ЗАПИСИ, она должна предваряться ПУСТОЙ строкой dn: ou=people, dc=example,dc=com ou: people description: All people in organisation objectClass: organizationalUnit ## ВТОРОЙ уровень иерархии - записи людей # это последовательность ЗАПИСИ, она должна предваряться ПУСТОЙ строкой dn: cn=Joe Schmo,ou=people,dc=example,dc=com objectclass: inetOrgPerson cn: Joe Schmo sn: Schmo uid: jschmo mail: joe@example.com mail: j.schmo@example.com ou: sales
Этот LDIF создаёт следующую структуру каталога:
Как правило, нет разницы, значение какого атрибута используется при добавлении записи, лишь бы соблюдалось условие уникальности 'dn:'. В последней записи приведённого примера для этой цели было решено использовать cn=Joe Schmo. Точно также можно было бы использовать uid=jschmo. В процессе поиска LDAP может быть использован любой атрибут или комбинация атрибутов, так что записи могут быть найдены независимо от того, какое значение 'dn:' использовалось при их создании. Во избежание излишних операций поиска, в большинстве случаев имеет смысл использовать значение 'dn:', представляющее собой тот DN, который чаще всего будет использоваться для доступа к записи. Таким образом, в предыдущем примере подразумевается, что чаще всего при обращении к каталогу будет использоваться атрибут cn=.
Однако, если какую-то запись планируется использовать для аутентификации пользователя, значение её 'dn:' создания становится чрезвычайно важным и определяет единственно возможный DN входа в систему. Причина этого в том, что проверка подлинности осуществляется с помощью LDAP-операции Bind, которая требует предоставления DN подключения (Bind DN) и, опционально, пароля, при этом никакие операции поиска НЕ разрешены. Таким образом, данный DN подключения МОЖЕТ БЫТЬ ТОЛЬКО тем DN, который использовался при добавлении (создании) записи. Следующий LDIF-файл создаёт dn с использованием атрибута uid, более соответствующего системам аутентификации LDAP:
version: 1 ## нет строгого требования указывать версию (version), ## но это является хорошим тоном для совместимости с будущими версиями ## ОПРЕДЕЛЯЕМ DIT ROOT/BASE/SUFFIX #### ## используется формат RFC 2377 ## dcObject - это ВСПОМОГАТЕЛЬНЫЙ объектный класс и, кроме него, запись ## ДОЛЖНА иметь СТРУКТУРНЫЙ объектный класс (в данном случае, organization) # это последовательность ЗАПИСИ и ей предшествует ПУСТАЯ СТРОКА dn: dc=example,dc=com dc: example description: The best company in the whole world objectClass: dcObject objectClass: organization o: Example, Inc. ## ПЕРВЫЙ уровень иерархии - люди (people) # это последовательность ЗАПИСИ, она должна предваряться ПУСТОЙ строкой dn: ou=people, dc=example,dc=com ou: people description: All people in organisation objectClass: organizationalUnit ## ВТОРОЙ уровень иерархии - записи людей # это последовательность ЗАПИСИ, она должна предваряться ПУСТОЙ строкой dn: uid=jschmo,ou=people,dc=example,dc=com objectclass: inetOrgPerson cn: Joe Schmo sn: Schmo uid: jschmo mail: joe@example.com mail: j.schmo@example.com ou: sales
Этот LDIF создаёт следующую структуру каталога:
В стандартах LDAP нет специального термина, указывающего на DN, используемый при первоначальном создании записи. Однако иногда, особенно в контексте LDAP, применяемого в Microsoft AD, данный DN 'создания' называется DN принципала (Principal DN), главным образом вследствие использования его в качестве принципала (принципала безопасности) в Kerberos.
Проблемы, комментарии, предположения, исправления (включая битые ссылки) или есть что добавить? Пожалуйста, выкроите время в потоке занятой жизни, чтобы написать нам, вебмастеру или в службу поддержки. Оставшийся день Вы проведёте с чувством удовлетворения.
Нашли ошибку в переводе? Сообщите переводчикам!
Copyright © 1994-2017 ZyTrax, Inc. Все права защищены. Последнее изменение страницы: 21 октября 2015 г.
Переведено участниками проекта Pro-LDAP.ru в 2012 г.