У 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 = com
• dc = мідомен
• dc = avery, dc = long, dc = список, dc = of, dc = домени

Але ці кореневі елементи неподільні. Вони схожі на те, що вони є декількома елементами, що представляють шлях, як і решта дерева, але це не так . Наприклад, в останньому прикладі об'єкт dc = of, dc = домени не існує.

Уявіть, як назвати свій C: диск на зразок "D: \ my \ folder \". Кожен шлях там буде виглядати приблизно як "D: \ мій \ папка \ мій \ реальний \ шлях", який був би заплутаним, оскільки реальний шлях до файлу буде \ мій \ реальний \ шлях правильно? Ну, так виглядає база (корінь) LDAP із набором елементів dc =.

Відповідне посилання: http://docs.oracle.com/cd/E19199-01/816-6400-10/lsearch.html