โครงสร้าง LDAP: dc = example, dc = com vs o = ตัวอย่าง

ฉันค่อนข้างใหม่กับ LDAP และได้เห็นตัวอย่างสองประเภทของวิธีการตั้งค่าโครงสร้างของคุณ

วิธีหนึ่งคือการมีฐานเป็นอยู่: dc=example,dc=comในขณะที่ตัวอย่างอื่นมีฐานเป็นo=Exampleอยู่ คุณสามารถมีกลุ่มที่มีลักษณะดังนี้:

    dn: cn = team, ou = Group, dc = example, dc = com
    cn: ทีม
    objectClass: posixGroup
    memberUid: user1
    memberUid: user2

... หรือใช้สไตล์ "O":

    dn: cn = ทีม, o = ตัวอย่าง
    objectClass: posixGroup
    memberUid: user1
    memberUid: user2

คำถามของฉันคือ:

1. มีวิธีปฏิบัติที่ดีที่สุดที่กำหนดโดยใช้วิธีหนึ่งเหนือวิธีอื่นหรือไม่?
2. มันเป็นเรื่องของการตั้งค่าที่คุณใช้สไตล์หรือไม่?
3. มีข้อได้เปรียบใด ๆ หรือไม่ในการใช้อันใดอันหนึ่ง?
4. เป็นวิธีหนึ่งในแบบเก่าและรุ่นใหม่และที่ปรับปรุงแล้วหรือไม่

จนถึงตอนนี้ฉันได้ไปกับdc=example,dc=comสไตล์ คำแนะนำใด ๆ ที่ชุมชนสามารถให้ในเรื่องนี้จะได้รับการชื่นชมอย่างมาก

dcสไตล์ทั่วไปบ่งชี้ต้นไม้ LDAP DNS-based ของบางชนิด นี่คือรูปแบบการใช้งาน Active Directory (AD) หากคุณไม่สนใจทรี LDAP ที่ใช้ dns แล้วก็สามารถใช้ประเภทอื่นได้ดี eDirectory ของ Novell เป็นOต้นไม้ที่มีพื้นฐาน คำเตือนบางอย่าง:

• DC-style เป็นสิ่งที่โฆษณาใช้ ผลิตภัณฑ์ของบุคคลที่สามจำนวนมากที่สนับสนุนแหล่งข้อมูล AD LDAP เช่นต้นไม้ลักษณะนี้ดีกว่าโครงสร้างแบบOอิงมาก ฉันมีปัญหาในการทำให้ไคลเอนต์เหล่านี้พูดคุยกับแผนผัง LDAP ของ O-style
• โฆษณาไม่ได้ใช้Oเลยดังนั้นไคลเอ็นต์ / ตัวแยกวิเคราะห์ LDAP บางรายอาจไม่รองรับผลลัพธ์ดังกล่าว เช่นเดียวกับL(ตำแหน่ง)
• หากคุณไม่ได้ฝังรากต้นไม้ของคุณ DNS สไตล์เป็นสิ่งสำคัญน้อยกว่ามาก
• สไตล์ไฮบริดนั้นใช้ได้ ราก LDAP ของคุณคือdc=example,dc=comและคุณใช้แผนผัง O-style ใต้ต้นไม้นั้น DN เป็นอย่างดีcn=bobs,ou=users,o=company,dc=example,dc=com

โดยทั่วไปความต้องการของคุณที่จะเข้ากันได้กับไคลเอนต์ LDAP บุคคลที่สามคือสิ่งที่ควรขับเคลื่อนโครงสร้างของคุณ หากจำเป็นต้องใช้ภาษาถิ่นมันอาจจะต้องดูเป็น active-directory อย่างที่สุด หากพวกเขาเป็นไคลเอนต์ LDAP ที่บริสุทธิ์เพราะพวกเขาสนับสนุนข้อมูลจำเพาะทั้งหมดจริง ๆ แล้วโครงสร้างไม่ควรสำคัญ

ฉันไม่รู้มาตรฐานโครงสร้างต้นไม้ ldap ใด ๆ แต่ฉันแน่ใจว่าคนอื่นจะไปป์ไลน์หากมี