Trong LDAP, chính xác thì một DN ràng buộc là gì?


19

Tôi đã viết nhiều đoạn mã kết nối với máy chủ LDAP và chạy các truy vấn, nhưng nó luôn luôn tốt với tôi. Một điều tôi không thực sự hiểu là khái niệm về một DN ràng buộc. Đây là một ví dụ sử dụng ldapsearchcông cụ dòng lệnh có sẵn từ openldap. (Bỏ qua việc thiếu xác thực.)

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

Mục đích và chức năng của -D dc=example,dc=commột phần của việc này là gì? Tại sao chúng ta cần liên kết với một vị trí cụ thể trong hệ thống phân cấp thư mục? Có phải là để thiết lập phần nào của thư mục mà các truy vấn của tôi sẽ áp dụng cho? Ví dụ: nếu nút gốc của thư mục là dc=comvà nó có hai con ( dc=foodc=bar), có lẽ tôi muốn các truy vấn của mình chống lại dc=foo,dc=comcây con và không phải là dc=bar,dc=comcây con?

Câu trả lời:


18

Một ràng buộc DN là một đối tượng mà bạn liên kết với bên trong LDAP để cung cấp cho bạn quyền để làm bất cứ điều gì bạn đang cố gắng làm. Một số (nhiều?) Các trường hợp LDAP không cho phép các liên kết ẩn danh hoặc không cho phép các hoạt động nhất định được thực hiện với các liên kết ẩn danh, vì vậy bạn phải chỉ định một bindDN để có được danh tính để thực hiện thao tác đó.

Theo một cách phi kỹ thuật tương tự - và vâng, đây là một sự kéo dài - một ngân hàng sẽ cho phép bạn bước vào và xem xét lãi suất của họ mà không cần cung cấp cho họ bất kỳ loại ID nào, nhưng để mở tài khoản hoặc rút tiền, bạn có để có một danh tính mà họ biết - danh tính đó là bindDN.


Có phải bindDN luôn tương ứng với một nút trong thư mục không? Hoặc nó có thể là một chuỗi tùy ý?
dirtside

Đúng. Nó phải tương ứng với một nút có khả năng mang thuộc tính mật khẩu hoặc được xác thực bằng cách khác.
Giăng

Tomayto, tomahto. Tên người dùng, ràng buộc DN. 🤷🏻♂️
emallove

31

Đừng nhầm lẫn giữa baseDNbindDN .

Các BaseDN của một tìm kiếm là điểm khởi đầu. Nơi nó sẽ bắt đầu tìm kiếm. Khá tự giải thích.

Các binddn DN về cơ bản là chứng chỉ bạn đang sử dụng để xác thực chống lại một LDAP. Khi sử dụng một bindDN, nó thường đi kèm với một mật khẩu được liên kết với nó.

Nói cách khác, khi bạn chỉ định một bindDN, bạn đang sử dụng quyền truy cập bảo mật đối tượng đó để đi qua cây LDAP.

Bây giờ, chuỗi dc = ví dụ, dc = com không phải là ví dụ tốt nhất cho bindDN vì đây là "miền" cho cây LDAP. dc là viết tắt của thành phần miền và mỗi cây LDAP xác định gốc của nó bằng một chuỗi ở dạng dc = chuỗi, dc = chuỗi, ... Nhưng các chuỗi này không phải là "đường dẫn" như phần còn lại của cây.

Ví dụ hợp lệ là:

  • dc = ví dụ, dc = com
  • dc = tên miền của tôi
  • dc = avery, dc = long, dc = list, dc = of, dc = domain

Nhưng, những yếu tố gốc là không thể chia cắt. Chúng trông giống như một số yếu tố đại diện cho một con đường giống như phần còn lại của cây, nhưng thực tế không phải vậy . Chẳng hạn, trong ví dụ trước, một đối tượng dc = of, dc = domain không tồn tại.

Hãy tưởng tượng việc đặt tên ổ C: của bạn như "D: \ my \ thư mục \". Mọi đường dẫn trong đó sẽ trông giống như "D: \ my \ thư mục \ my \ real \ path" sẽ gây nhầm lẫn vì đường dẫn tệp thực sẽ là \ my \ real \ path phải không? Chà, đó là cách cơ sở (gốc) của LDAP trông như thế nào, với một tập hợp các phần tử dc =.

Liên kết có liên quan: http://docs.oracle.com/cd/E19199-01/816-6400-10/lsearch.html


7
Điều đó có vẻ như một thiết kế khó hiểu không cần thiết, nhưng lời giải thích của bạn có ý nghĩa.
dirtside

1
Vâng tôi đồng ý. Đặt tên gốc của bạn trông giống như một con đường không phải là lựa chọn tốt nhất nhưng tôi đoán nó phải có lý do của nó. Bây giờ bạn biết tại sao tất cả các DN kết thúc với một loạt các thành phần dc =. =)
Marcelo
Khi sử dụng trang web của chúng tôi, bạn xác nhận rằng bạn đã đọc và hiểu Chính sách cookieChính sách bảo mật của chúng tôi.
Licensed under cc by-sa 3.0 with attribution required.