Я написал различные фрагменты кода, которые подключаются к серверам 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
поддерево?
Не запутайтесь между baseDN и bindDN.
В baseDN поиска является отправной точкой. Где начнут поиски. Довольно понятно.
В bindDN DN - это в основном учетные данные, которые вы используете для аутентификации по LDAP. При использовании bindDN обычно используется связанный с ним пароль.
Другими словами, когда вы указываете bindDN, вы используете доступ к этому объекту для прохождения через дерево LDAP.
Теперь строка dc = example, dc = com не лучшая пример для bindDN, поскольку это «домен» для дерева LDAP. Округ Колумбия означает компонент домена и каждое дерево LDAP определяет свой корень строкой в форме dc = string, dc = string, ... Но эти строки не являются «путем», как остальная часть дерева.
Допустимые примеры:
Но эти корневые элементы неделимы. Они выглядят так, как будто представляют собой несколько элементов, представляющих путь, как и остальная часть дерева, но они не. Например, в последнем примере объект dc = of, dc = домены не существует.
Представьте, что вы назвали свой диск 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
DN привязки - это объект, который вы привязываете к LDAP, чтобы дать вам разрешения делать все, что вы пытаетесь сделать. Некоторые (многие?) Экземпляры LDAP не разрешают анонимные привязки или не позволяют выполнять определенные операции с анонимными привязками, поэтому вы должны указать bindDN, чтобы получить идентификатор для выполнения этой операции.
Аналогичным нетехническим способом - и да, это с большой натяжкой - банк позволит вам войти и посмотреть их процентные ставки, не давая им никакого удостоверения личности, но для открытия счета или снятия денег у вас есть чтобы иметь известную личность - это имя bindDN.