Приложение A — LDAP: DN и RDN

DN (Distinguished Name, уникальное имя) должно быть уникальным (или хотя бы приблизительно уникальным, смотрите комментарии ниже) в пределах дерева (DIT). В DN описывается содержимое атрибутов в дереве (так называемый путь навигации), требуемое для доступа к конкретной записи ИЛИ базовой (стартовой) записи поиска.

DN состоит из серии RDN (Relative Distinguished Names, относительных уникальных имён), определяемых путём перемещения ВВЕРХ по дереву (DIT) в направлении его корневой записи (суффикса или базовой записи), и записываемых СЛЕВА НАПРАВО, в отличие, например, от файловой системы, где пути записываются СПРАВА НАЛЕВО. Если проводить аналогии, то это больше напоминает полностью определённые доменные имена (fully qualified domain name, FQDN). Если Вы не знаете, что такое полностью определённые доменные имена — забудьте об аналогиях!

DN записывается СЛЕВА НАПРАВО.

Прежде чем двигаться дальше стоит потратить несколько минут, чтобы определиться с тем, что мы пытаемся делать при получении доступа к DIT, и что может означать термин "уникальный".

1. Если мы производим поиск, термин "уникальный" может означать не совсем то, что нам требуется — нам может понадобиться лишь приблизительно уникальный DN.

2. Если мы производим запись (модификацию), тогда DN должен быть уникальным — ведь мы хотим изменять только конкретную запись.

DN состоит из серии RDN (Relative Distinguished Names, относительных уникальных имён), которые представляют собой уникальные (или хотя бы приблизительно уникальные) атрибуты на каждом уровне иерархии DIT.

На рисунке показано построение DN из RDN:

В этом примере в качестве нашего RDN мы выбрали атрибут cn (commonName), поскольку он уникален на данном уровне иерархии в каталоге. Это дало такой полный DN:

DN: cn=Robert Smith,ou=people,dc=example,dc=com

НО мы с тем же успехом могли выбрать в качестве нашего RDN атрибут uid (userID), поскольку он также уникален (смотрите ниже). В обоих случаях в результате получаются вполне допустимые DN.

В атрибутах, используемых в качестве RDN нет ничего особенного, за исключением того, что их значения уникальны (для записи), и должны всегда оставаться уникальными. Но останется ли уникальным наш атрибут cn, когда на работу в организацию устроится второй Robert Smith? Если он не будет уникальным, то эта ситуация останется приемлемой для поиска (чтения), но не для записи — в этом случае нужно будет использовать какой-то другой атрибут или комбинацию атрибутов.

Примечание: Когда запись добавляется (или создаётся), ей всегда назначается DN и, как правило, именно этот DN чаще всего используется для получения доступа к записи. Если данная запись будет использоваться в целях прохождения аутентификации, то на неё накладываются некоторые специальные условия.

Наконец, существует возможность объединить два или более атрибута и сформировать многозначный RDN, который затем будет использоваться в DN. В нашем примере можно сформировать RDN, объединив cn+uid, для создания такого DN:

DN: cn=Robert Smith+uid=rsmith,ou=people,dc=example,dc=com

Примечание: Как правило, если Вы будете часто производить поиск по какому-либо атрибуту, он должен быть проиндексирован.