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