Что именно в LDAP является DN связывания?

Я написал различные фрагменты кода, которые подключаются к серверам LDAP и запускают запросы, но для меня это всегда было вуду. Одна вещь, которую я не очень понимаю, это концепция связующего DN. Вот пример использования ldapsearchинструмента командной строки, доступного из openldap. (Игнорировать отсутствие аутентификации.)

ldapsearch -h 1.2.3.4 -D dc=example,dc=com [query]

Какова цель и функция этой -D dc=example,dc=comчасти? Почему мы должны привязываться к определенному месту в иерархии каталогов? Чтобы определить, к какой части каталога должны применяться мои запросы? Например, если корневым узлом каталога является dc=comи у него есть два дочерних элемента ( dc=fooи dc=bar), может быть, я хочу, чтобы мои запросы относились к dc=foo,dc=comподдереву, а не к dc=bar,dc=comподдереву?

DN привязки - это объект, к которому вы привязываетесь внутри LDAP, чтобы дать вам разрешение делать то, что вы пытаетесь сделать. Некоторые (многие?) Экземпляры LDAP не разрешают анонимные привязки или не позволяют выполнять определенные операции с анонимными привязками, поэтому вы должны указать bindDN, чтобы получить идентификатор для выполнения этой операции.

Подобным нетехническим способом - и да, это растянуто - банк позволит вам войти и посмотреть на их процентные ставки без какого-либо удостоверения личности, но для того, чтобы открыть счет или снять деньги, у вас есть иметь личность, о которой они знают - эта личность - это bindDN.

Не путайте между baseDN и bindDN .

ОкнеРазличающееся_имя_базыполе обыска является отправной точкой. Где он начнет искать. Довольно понятно.

BindDN DN в основном учетные данные используются для проверки подлинности против LDAP. При использовании bindDN он обычно поставляется с паролем, связанным с ним.

Другими словами, когда вы указываете bindDN, вы используете безопасный доступ к этому объекту для прохождения дерева LDAP.

Теперь строка dc = example, dc = com - не лучший пример для bindDN, поскольку это «домен» для дерева LDAP. dc обозначает компонент домена, и каждое дерево LDAP определяет его корень со строкой в ​​виде dc = string, dc = string, ... Но эти строки не являются "путем", как остальная часть дерева.

Допустимые примеры:

• DC = пример, DC = ком
• DC = MYDOMAIN
• DC = Эйвери, dc = длинный, dc = список, dc = о, dc = домены

Но эти корневые элементы неделимы. Они выглядят так, будто представляют собой несколько элементов, представляющих путь, подобный остальной части дерева, но это не так . Например, в последнем примере объект dc = of, dc = domains не существует.

Представьте себе имя вашего диска C: как "D: \ my \ folder \". Каждый путь там будет выглядеть примерно так: «D: \ my \ folder \ my \ real \ path», что может привести к путанице, поскольку реальный путь к файлу будет \ my \ real \ path, верно? Вот так выглядит база (корень) LDAP с набором элементов dc =.

Соответствующая ссылка: http://docs.oracle.com/cd/E19199-01/816-6400-10/lsearch.html