ใน LDAP การผูก DN คืออะไร


19

ฉันได้เขียนโค้ดหลายชิ้นที่เชื่อมต่อกับเซิร์ฟเวอร์ 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ทรีย่อยหรือไม่

คำตอบ:


18

bind DN เป็นวัตถุที่คุณผูกไว้ใน LDAP เพื่อให้สิทธิ์ในการทำสิ่งที่คุณพยายามทำ อินสแตนซ์ของ LDAP (มาก?) บางตัวไม่อนุญาตการผูกแบบไม่ระบุชื่อหรือไม่อนุญาตให้ดำเนินการบางอย่างด้วยการผูกแบบไม่ระบุชื่อดังนั้นคุณต้องระบุ bindDN เพื่อรับข้อมูลประจำตัวเพื่อดำเนินการนั้น

ด้วยวิธีที่ไม่ใช่ทางเทคนิคที่คล้ายคลึงกันและใช่แล้วนี่เป็นเรื่องที่ยืดเยื้อ - ธนาคารจะอนุญาตให้คุณเดินเข้าไปดูอัตราดอกเบี้ยของพวกเขาโดยไม่ให้ ID ใด ๆ กับพวกเขา แต่เพื่อเปิดบัญชีหรือถอนเงินคุณมี มีตัวตนที่พวกเขารู้ - ตัวตนนั้นเป็น bindDN


bindDN นั้นสอดคล้องกับโหนดในไดเรกทอรีเสมอหรือไม่? หรือจะเป็นสตริงเองก็ได้?
dirtside

ใช่. มันจะต้องสอดคล้องกับโหนดที่มีความสามารถในการดำเนินการแอตทริบิวต์รหัสผ่านหรือมิฉะนั้นจะถูกรับรองความถูกต้องกับ
John

Tomayto, Tomahto 🍅ชื่อผู้ใช้ผูก DN 🤷🏻‍♂️
emallove

31

อย่าสับสนระหว่างBaseDNและbinddn

BaseDNของการค้นหาเป็นจุดเริ่มต้น มันจะเริ่มค้นหาที่ไหน สวยอธิบายตนเอง

binddn DN เป็นพื้นข้อมูลประจำตัวที่คุณใช้ในการตรวจสอบกับ LDAP เมื่อใช้ bindDN มักจะมาพร้อมกับรหัสผ่านที่เกี่ยวข้อง

กล่าวอีกนัยหนึ่งเมื่อคุณระบุ bindDN คุณกำลังใช้การเข้าถึงความปลอดภัยของวัตถุนั้นเพื่อผ่านทรี LDAP

ตอนนี้สตริง dc = example, dc = com ไม่ใช่ตัวอย่างที่ดีที่สุดสำหรับ bindDN เนื่องจากเป็น "โดเมน" สำหรับทรี LDAP dcย่อมาจากส่วนประกอบของโดเมนและทรี LDAP ทุกตัวกำหนดรูทของมันด้วยสตริงในรูปแบบของ dc = string, dc = string, ... แต่สตริงเหล่านี้ไม่ใช่ "พา ธ " เหมือนกับส่วนที่เหลือของทรี

ตัวอย่างที่ถูกต้องคือ:

  • dc = ตัวอย่าง DC = com
  • dc = mydomain
  • dc = เอเวอรี่, dc = ยาว dc = รายการ dc = ของ DC = โดเมน

แต่องค์ประกอบรากเหล่านี้จะแบ่งแยกไม่ได้ พวกเขามีลักษณะเหมือนพวกเขาเป็นตัวแทนขององค์ประกอบหลายเส้นทางเช่นที่เหลือของต้นไม้ แต่พวกเขาจะไม่ได้ ยกตัวอย่างเช่นในตัวอย่างสุดท้ายวัตถุdc = ของ 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


7
ดูเหมือนว่าจะเป็นการออกแบบที่สับสนโดยไม่จำเป็น แต่คำอธิบายของคุณเหมาะสมแล้ว
dirtside

1
ใช่ฉันเห็นด้วย การตั้งชื่อรูทของคุณดูเหมือนกับเส้นทางไม่ใช่ทางเลือกที่ดีที่สุด แต่ฉันคิดว่ามันต้องมีเหตุผล ตอนนี้คุณรู้แล้วว่าทำไม DN ทั้งหมดจึงลงท้ายด้วยชุดของส่วนประกอบ dc = =)
Marcelo
โดยการใช้ไซต์ของเรา หมายความว่าคุณได้อ่านและทำความเข้าใจนโยบายคุกกี้และนโยบายความเป็นส่วนตัวของเราแล้ว
Licensed under cc by-sa 3.0 with attribution required.