W LDAP, czym dokładnie jest nazwa wyróżniająca powiązania?


19

Napisałem różne fragmenty kodu, które łączą się z serwerami LDAP i uruchamiają zapytania, ale zawsze było to dla mnie voodoo. Jedną rzeczą, której tak naprawdę nie rozumiem, jest koncepcja wiążącej nazwy wyróżniającej. Oto przykład użycia ldapsearchnarzędzia wiersza polecenia dostępnego w openldap. (Zignoruj ​​brak uwierzytelnienia).

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

Jaki jest cel i funkcja tej -D dc=example,dc=comczęści? Dlaczego musimy powiązać z określoną lokalizacją w hierarchii katalogów? Czy ma to ustalić, do której części katalogu powinny mieć zastosowanie moje zapytania? Np. Jeśli węzłem głównym katalogu jest dc=comi ma dwoje dzieci ( dc=fooi dc=bar), może chcę, aby moje zapytania dc=foo,dc=comdotyczyły poddrzewa, a nie dc=bar,dc=compoddrzewa?

Odpowiedzi:


18

Nazwa wyróżniająca powiązania jest obiektem, z którym łączysz się wewnątrz LDAP, aby dać ci uprawnienia do robienia wszystkiego, co próbujesz zrobić. Niektóre (wiele?) Instancji LDAP nie zezwalają na anonimowe powiązania lub nie zezwalają na przeprowadzanie niektórych operacji z anonimowymi powiązaniami, dlatego należy określić nazwę bindDN, aby uzyskać tożsamość w celu wykonania tej operacji.

W podobny nietechniczny sposób - i tak, to jest odcinek - bank pozwoli ci wejść i sprawdzić ich stopy procentowe bez podawania im jakiegokolwiek dowodu tożsamości, ale aby otworzyć konto lub wypłacić pieniądze, musisz mieć tożsamość, o której wiedzą - ta tożsamość to bindDN.


Czy bindDN zawsze odpowiada węzłowi w katalogu? Czy może to być dowolny ciąg?
dirtside

Tak. Musi odpowiadać węzłowi, który ma możliwość przenoszenia atrybutu hasła lub uwierzytelnienia w inny sposób.
John

Tomayto, tomahto. 🍅 Nazwa użytkownika, wiąż DN. 🤷🏻‍♂️
emallove

31

Nie daj się pomylić między baseDN a bindDN .

The nazwa wyszukiwania jest punktem początkowym. Gdzie rozpocznie wyszukiwanie. Dość oczywiste.

The DN bindDN jest w zasadzie poświadczeniem używanym do uwierzytelniania na podstawie LDAP. Kiedy używasz bindDN, zwykle towarzyszy mu hasło.

Innymi słowy, gdy określisz bindDN, używasz dostępu do zabezpieczeń tego obiektu, aby przejść przez drzewo LDAP.

Teraz ciąg dc = przykład, dc = com nie jest najlepszym przykładem dla bindDN, ponieważ jest „domeną” dla drzewa LDAP. dc oznacza komponent domeny i każde drzewo LDAP definiuje swój katalog główny ciągiem w postaci dc = ciąg, dc = ciąg, ... Ale te ciągi nie są „ścieżką” jak reszta drzewa.

Prawidłowe przykłady to:

  • dc = przykład, dc = com
  • dc = mojadomena
  • dc = avery, dc = długi, dc = lista, dc = z, dc = domeny

Ale te podstawowe elementy są niepodzielne. Wyglądają jak są one kilka elementów stanowiących ścieżkę jak reszta drzewa, ale są one nie . Na przykład w ostatnim przykładzie obiekt dc = z, dc = domeny nie istnieje.

Wyobraź sobie, że nazywasz swój dysk C: „D: \ my \ folder \”. Każda ścieżka tam będzie wyglądać jak „D: \ mój \ folder \ mój \ prawdziwy \ ścieżka”, co byłoby mylące, ponieważ prawdziwa ścieżka do pliku to \ moja \ prawdziwa \ ścieżka, prawda? Tak właśnie wygląda podstawa (root) LDAP z zestawem elementów dc =.

Odpowiedni link: http://docs.oracle.com/cd/E19199-01/816-6400-10/lsearch.html


7
Wygląda to na niepotrzebnie mylący projekt, ale twoje wyjaśnienie ma sens.
dirtside

1
Tak! Zgadzam się. Nazwanie katalogu głównego również wygląda na ścieżkę, nie jest najlepszym wyborem, ale myślę, że musi mieć swoje powody. Teraz już wiesz, dlaczego wszystkie nazwy wyróżniające kończą się serią składników dc =. =)
Marcelo
Korzystając z naszej strony potwierdzasz, że przeczytałeś(-aś) i rozumiesz nasze zasady używania plików cookie i zasady ochrony prywatności.
Licensed under cc by-sa 3.0 with attribution required.