รับข้อมูลจากเซิร์ฟเวอร์ ldap การตั้งค่าการเชื่อมต่อในไฟล์ .properties กำลังเชื่อมต่อกับเซิร์ฟเวอร์ LDAP

LDAP และโดยเฉพาะอย่างยิ่ง OpenLDAP มีคุณลักษณะด้านความปลอดภัยจำนวนหนึ่งที่อาจดูซับซ้อนเล็กน้อยเมื่อดูครั้งแรก (และครั้งที่สองและสาม) รูปที่ 15-1 แสดงภาพรวมของปัญหาก่อนลงรายละเอียด ต่อไปนี้สาธิต วิธีการต่างๆการเข้าถึงและการเชื่อมต่อกับระบบ LDAP จากนั้นอธิบายข้อกังวลด้านความปลอดภัยและเทคนิคการจัดการความเสี่ยงที่มีอยู่ เป้าหมายของแบบฝึกหัดนี้คือเพื่อกำหนดชุดนโยบายความปลอดภัยหรือจัดลำดับความสำคัญของการนำไปปฏิบัติ

รูปที่ 15-1. ภาพทั่วไปของปัญหาด้านความปลอดภัย

ตัวเลขทั้งหมดที่ปรากฏในคำอธิบายด้านล่างอ้างอิงถึงรูปที่ 15-1

    การโต้ตอบกับสมาชิกระยะไกล (1):การรับรองความปลอดภัยเมื่อโต้ตอบกับสมาชิกระยะไกลอาจเป็นปัญหาหรือไม่ก็ได้ เมื่อให้การเข้าถึงข้อมูล LDAP ที่ไม่เป็นความลับได้อย่างไม่จำกัด (ไม่ระบุชื่อ) ปัญหาด้านความปลอดภัยจะไม่เกิดขึ้น ความสนใจ:ภายใต้เงื่อนไขเหล่านี้ เซิร์ฟเวอร์ของคุณยังคงเป็นเป้าหมายของการโจมตี DoS/DDoS โดยการโหลดเซิร์ฟเวอร์ด้วยคำขอ LDAP ที่เป็นอันตราย ดังนั้นแม้การดำเนินการที่ดูเหมือนเล็กน้อยอาจต้องมีการออกแบบอย่างระมัดระวัง

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

    เมื่อโต้ตอบกับ LDAP บนเครือข่ายที่ไม่น่าเชื่อถือ บุคคลที่ทำลายล้างบนเครือข่ายจะต้องทำบางอย่างทันที: เตรียมพร้อมสำหรับการสกัดกั้น การสอดแนม การโจมตีแบบแทรกกลาง ฯลฯ ย่อมมีเกิดขึ้นอย่างต่อเนื่อง. โปรดทราบว่าการใช้การกำหนดค่าออนไลน์ของ OLC (cn=config) และฟังก์ชันการตรวจสอบ (cn=จอภาพ) อาจส่งผลให้เบราว์เซอร์ LDAP กลายเป็นเครื่องมือทั่วไปสำหรับ การดูแลระบบระยะไกลและการจัดการเซิร์ฟเวอร์ LDAP และโดยธรรมชาติแล้วการรับส่งข้อมูลนี้เป็นความลับอย่างไม่น่าเชื่อ

    หากตัดสินใจว่ายังคงจำเป็นต้องมีการรักษาความปลอดภัยระดับหนึ่ง คำถามแรกที่เกิดขึ้นในกรณีนี้คือ: เราจำเป็นต้องป้องกันเฉพาะรหัสผ่าน (1-1) หรือเราจำเป็นต้องปกป้องทั้งสองข้อมูล (1-2) และรหัสผ่าน (1-1 )? ขั้นตอนต่อไปของเราจะได้รับการพิจารณาขึ้นอยู่กับคำตอบของคำถามนี้

    รหัสผ่าน (1-1):ไม่ควรสับสนระหว่างการป้องกันรหัสผ่านระหว่างการส่งข้อมูลผ่านเครือข่ายกับการป้องกันในไฟล์การกำหนดค่าหรือใน DIT แม้ว่าคุณจะป้องกันรหัสผ่านทั้งหมดในไฟล์การกำหนดค่าหรือ DIT โดยใช้วิธีการแฮชเช่น (SSHA) เมื่อไคลเอนต์ส่งรหัสผ่านไปยังเซิร์ฟเวอร์เพื่อตรวจสอบความถูกต้อง รหัสผ่านจะถูกส่งในรูปแบบข้อความที่ชัดเจน แฮชบนเซิร์ฟเวอร์ และเปรียบเทียบกับที่เก็บไว้ ค่า. หากไม่มีมาตรการเพิ่มเติม ก็สามารถดักจับ (หรือติดตามได้ ขึ้นอยู่กับความต้องการของคุณสำหรับข้อกำหนดดังกล่าว) บันทึก:เมื่อลูกค้าร้องขอบันทึกที่มีแอตทริบิวต์ดังกล่าว รหัสผ่านผู้ใช้ค่าที่ถูกแฮชพูดโดยใช้อัลกอริทึม (CRYPT) จากนั้นรหัสผ่านนี้จะไม่ถูกส่งในรูปแบบข้อความที่ชัดเจน แต่อยู่ในรูปแบบแฮช (นั่นคือในรูปแบบที่เก็บไว้) อย่างไรก็ตาม เมื่อมีการเข้าถึงในนามของบัญชีเดียวกันนี้ ลูกค้าจะส่งรหัสผ่าน (ซึ่งมีการตรวจสอบสิทธิ์) ในรูปแบบข้อความที่ชัดเจน และแน่นอน หากการตรวจสอบสิทธิ์สำเร็จ ผู้ดักฟังจะถือว่ารหัสผ่านที่ส่งไปนั้นสมเหตุสมผล ในข้อความที่ชัดเจนถูกต้อง

    เมื่อรหัสผ่านที่แฮชถูกส่งไปในสตรีมข้อมูลที่สามารถดักจับได้ รหัสผ่านเหล่านั้นจะเสี่ยงต่อการถูกโจมตีจากพจนานุกรม — เมื่อมีรหัสผ่านที่แฮชแล้ว ผู้โจมตีจะเรียกใช้รายการรหัสผ่าน (เรียกว่าพจนานุกรม) ผ่านอัลกอริธึมการแฮชจนกระทั่งพบรหัสผ่านที่ตรงกัน การใช้งาน เกลือ(หนึ่งไบต์หรือมากกว่านั้น — ขึ้นอยู่กับการใช้งาน — ต่อท้ายรหัสผ่านก่อนที่จะแฮชและละทิ้งก่อนการเปรียบเทียบ) ช่วยปรับปรุงความปลอดภัยของรหัสผ่านที่ถูกแฮชอย่างมาก และเว้นแต่คุณจะมีเหตุผลที่น่าสนใจในทางตรงกันข้าม คุณควรใช้รูปแบบใดรูปแบบหนึ่งเสมอ อัลกอริธึมการแฮชด้วย เกลือ- คุณควรใช้ เอซีแอลเพื่อให้สามารถเข้าถึงรหัสผ่านเฉพาะบางแวดวงเท่านั้น ผู้ใช้ที่ได้รับอนุญาต- ตัวอย่างเช่น สมมติว่ารหัสผ่านถูกเก็บไว้ในแอตทริบิวต์ รหัสผ่านผู้ใช้ ACL ต่อไปนี้จะอนุญาตให้เข้าถึงแอ็ตทริบิวต์นี้เฉพาะกับเจ้าของรายการและกลุ่มผู้ใช้เฉพาะ (ผู้ดูแลระบบ):

    # แบบฟอร์ม OLC (cn=config) olcAccess: ถึง attrs=userpassword โดยเขียนด้วยตนเองโดยการรับรองความถูกต้องแบบไม่ระบุชื่อโดย group.exact="cn=admin,ou=groups,dc=example,dc=com" เขียนโดย * none # รูปแบบ Slapd conf เข้าถึง attrs=userpassword โดยเขียนด้วยตนเองโดย auth ที่ไม่ระบุชื่อโดย group.exact="cn=admin,ou=groups,dc=example,dc=com" เขียนโดย * ไม่มี

    หากคุณต้องการปกป้องรหัสผ่านเท่านั้น วิธีแก้ไขอาจเป็นการใช้ SASL กับอัลกอริธึมบางอย่าง (เช่น CRAM-MD5) เพื่อให้แน่ใจว่ากล่องโต้ตอบการเชื่อมต่อที่ปลอดภัย (โดยใช้ลำดับความลับที่ใช้ร่วมกัน) ในระหว่างที่รหัสผ่านจะไม่ถูกส่งในรูปแบบข้อความที่ชัดเจน ( ). อีกทางเลือกหนึ่งคือใช้ TLS/SSL (มีหรือไม่มี SASL) หรือ Kerberos 5 ในกรณีนี้ สามารถใช้กลไกรหัสผ่านแบบง่ายได้ เนื่องจากการสื่อสารเครือข่ายทั้งหมดได้รับการเข้ารหัส จึงไม่สามารถดักฟังได้

    จนถึงตอนนี้เราได้พูดคุยกันเพียงประเด็นของการเข้าถึงข้อมูลเท่านั้น แล้วการเปลี่ยนแปลงหรือแก้ไขข้อมูลนี้ล่ะ? OpenLDAP มีสองตัวเลือกสำหรับการตรวจสอบ: การซ้อนทับ บันทึกการตรวจสอบ(เพื่อรับ ข้อมูลเพิ่มเติมดูหน้าคน slapo-auditlog) และโอเวอร์เลย์ accesslog ทั้งสองมีคุณสมบัติสำหรับการบันทึกการเปลี่ยนแปลงที่ทำกับ DIT ที่ใช้งานจริง และ accesslog ยังมีความสามารถในการบันทึกข้อมูลเกี่ยวกับการเชื่อมต่อ การเข้าถึงการอ่าน/ค้นหา และเนื้อหาก่อนหน้าของบันทึกหรือคุณลักษณะ

    การเข้าถึงในท้องถิ่น (2):การเข้าถึงภายในหมายถึงเหตุการณ์ใดๆ ที่เกิดขึ้นโดยตรงบนเซิร์ฟเวอร์ LDAP หรือคลัสเตอร์เซิร์ฟเวอร์ (หรือผ่านการเข้าถึงเซิร์ฟเวอร์ระยะไกลอย่างปลอดภัยโดยใช้ เช่น ssh) เห็นได้ชัดว่าการจัดการไฟล์/ไดเร็กทอรีการกำหนดค่า (2-1) และคำสั่งที่ดำเนินการในเครื่อง (2-2) อยู่ในหมวดหมู่นี้

    ไฟล์การกำหนดค่า (2-1):ที่นี่เราต้องพิจารณาสององค์ประกอบ:

    1. เจ้าของและสิทธิ์:โดยค่าเริ่มต้น ระบบที่ทันสมัย LDAP ทำงานในนามของบัญชีผู้ใช้/กลุ่มที่มีสิทธิ์จำกัด (โดยปกติคือ ldap:ldap) OpenLDAP ถูกโหลดจาก สิทธิ์รูท(เพื่อเปิดพอร์ตสิทธิพิเศษ) จากนั้นไปทำงานอย่างรวดเร็วด้วยสิทธิ์การทำงานปกติ (ต่ำ) เมื่อใช้ OLC (cn=config) OpenLDAP กำหนดให้เนื้อหาของไดเร็กทอรีการกำหนดค่ามีสิทธิ์อย่างน้อย 0750 สำหรับบัญชีที่จะใช้งาน (โดยปกติคือ ldap:ldap) แต่ไม่ได้ตั้งค่าสิทธิ์ที่เกี่ยวข้องโดยอิสระ ลักษณะการทำงานนี้แตกต่างจากการทำงานกับไฟล์คอนฟิกูเรชัน slapd.conf ซึ่งได้รับการกำหนดสิทธิ์ 0600 โดยอัตโนมัติ

      รหัสผ่าน:รหัสผ่านที่พบในไดเรกทอรี slapd.d (เมื่อใช้ OLC (cn=config)) และไฟล์การกำหนดค่า (slapd.conf) เช่น olcRootPw/rootpw ถือว่ามีความละเอียดอ่อนสูง เป็นการดีกว่าที่จะลบทั้ง olcRootDn/rootdn และ olcRootPw/rootpw ออกทั้งหมดหลังจากที่ DIT ถูกนำไปใช้จริง และแน่นอนว่ารหัสผ่านทั้งหมดควรถูกจัดเก็บในรูปแบบแฮชเพื่อป้องกันการประนีประนอมโดยไม่ตั้งใจ (ควรระบุในระดับนโยบายความปลอดภัย)

    ทีม (2-2):ในอดีต LDAP ได้รับการดูแลผ่านอินเทอร์เฟซภายในเครื่อง โดยส่วนใหญ่มาจากบรรทัดคำสั่ง สันนิษฐานว่าการรับส่งข้อมูลในพื้นที่ (ภายในเซิร์ฟเวอร์) ไม่ได้อยู่ภายใต้การติดตาม ดังนั้นแม้แต่การใช้รหัสผ่านเคลียร์เท็กซ์ธรรมดาก็ถือเป็นมาตรการรักษาความปลอดภัยที่เพียงพอสำหรับบริการด้านการดูแลระบบส่วนใหญ่ อย่างไรก็ตาม ดังที่ระบุไว้ข้างต้น การใช้งานไดเรกทอรีที่เพิ่มขึ้นด้วยการกำหนดค่ารันไทม์ (OLC, cn=config) และการตรวจสอบ (cn=monitor) อาจหมายความว่าเบราว์เซอร์ LDAP ระยะไกลกำลังกลายเป็นบรรทัดฐานในการดูแลระบบ LDAP ในกรณีนี้ การเข้าถึงบริการเหล่านี้ทำให้เกิดการส่งข้อมูลที่มีความละเอียดอ่อนสูงผ่านเครือข่าย ซึ่งจะต้องได้รับการปกป้องโดยใช้ เทคโนโลยีพิเศษมั่นใจในความปลอดภัยของข้อมูล เช่น TLS/SSL

    สุดท้ายนี้ เนื่องจากการกำหนดค่ารันไทม์เก็บการตั้งค่าทั้งหมดไว้ใน DIT (cn=config) จึงคุ้มค่าที่จะพิจารณาใช้ ความสามารถอันทรงพลัง overlay accesslog — เครื่องมือสร้างบันทึกเพื่อตรวจสอบการเปลี่ยนแปลงที่ทำกับ DIT ที่กำหนด

    ดิท(3):ความปลอดภัยของ DIT ถูกกำหนดโดยโมเดลความปลอดภัยของ LDAP และใช้งานโดยใช้ olc เท่านั้น การเข้าถึง/การเข้าถึงสิทธิ์ควรถูกจำกัดอย่างเคร่งครัดที่สุดเท่าที่จะเป็นไปได้ และ ACL ควรได้รับการทดสอบโดยใช้ slapacl หลังจากการเปลี่ยนแปลงแต่ละครั้ง

    การจำลองแบบ (1-3):แม้ว่าการเข้าถึงไคลเอ็นต์ปกติไปยังระบบ LDAP จะไม่จำเป็นต้องมีมาตรการรักษาความปลอดภัยที่ร้ายแรง แต่สถานการณ์อาจแตกต่างกันเมื่อจำลอง DIT เดียวกัน ในระหว่างรอบการจำลอง ณ จุดใดจุดหนึ่ง ข้อมูลทั้งหมดใน DIT (คุณลักษณะผู้ใช้และการดำเนินการ) จะถูกถ่ายโอนผ่านเครือข่าย มีแนวโน้มว่าข้อมูลบางส่วนนี้จะค่อนข้างสำคัญ การโต้ตอบกับเครือข่ายระหว่างการจำลองแบบสมควรได้รับการพิจารณาเป็นพิเศษ คุณสามารถกำหนดค่าการเชื่อมต่อแบบผสมของ TLS/SSL และประเภทที่ปลอดภัยอื่น (หรือแม้แต่ที่ไม่ปลอดภัย) ไปยังเซิร์ฟเวอร์เดียวกันได้ (ดูตัวอย่างการกำหนดค่าการเข้าถึง TLS/SSL และ SASL แบบผสม)

การกำหนดค่า SASL ใน OpenLDAP

เราจะจบส่วนนี้ในเร็วๆ นี้ ( วันหนึ่งเร็วๆ นี้™)

การกำหนดค่า SASL TLS/SSL ใน OpenLDAP

คู่มือผู้ดูแลระบบ OpenLDAP ระบุว่าเมื่อใช้ TLS กับกลไก EXTERNAL SASL ทั้งไคลเอนต์และเซิร์ฟเวอร์จะต้องมีใบรับรอง X.509 ที่ถูกต้อง หากสิ่งนี้เป็นจริง เราจะจบลงด้วยการกำหนดค่าที่ซับซ้อนโดยไม่จำเป็นและมีการปรับปรุงความปลอดภัยเพียงเล็กน้อย ซึ่งทำให้การใช้งานเป็นเรื่องที่น่าสงสัยในกรณีส่วนใหญ่ (แต่มีข้อยกเว้นที่น่าสังเกต เช่น การจำลอง) เราจะไม่พูดคุยเรื่องนี้โดยละเอียดในเวลานี้

การกำหนดค่า TLS/SSL ใน OpenLDAP

ทบทวน

TLS (Transport Level Security) เป็นเพียงชื่อของ Secure Sockets Layer (SSL) เวอร์ชันมาตรฐาน IETF ของ Netscape แทบไม่มีความแตกต่างระหว่าง SSL(v3) และ TLS(v1) และในเอกสารนี้ข้อกำหนดเหล่านี้ถือว่ามีความหมายเหมือนกัน OpenLDAP รองรับ TLS/SSL ตั้งแต่เวอร์ชัน 2.1

โดยทั่วไป TLS/SSL ต้องใช้ใบรับรอง X.509 (รู้จักกันดีในชื่อ ใบรับรอง SSL) ซึ่งสามารถซื้อได้จากผู้ออกใบรับรองเชิงพาณิชย์ (CA) หรืออาจเป็นใบรับรองที่ลงนามด้วยตนเองก็ได้ เอกสารนี้ให้คำแนะนำทีละขั้นตอนสำหรับการสร้างใบรับรองที่ลงนามด้วยตนเอง และยังให้ข้อควรพิจารณาเพิ่มเติมสำหรับการใช้ใบรับรองเชิงพาณิชย์หากจำเป็น

# slapd.conf # ส่วน การตั้งค่าส่วนกลาง... # ความปลอดภัย - ส่วน TLS TLSCertificateFile /certs/ldapscert.pem TLSCertificateKeyFile /certs/keys/ldapskey.pem TLSCipherSuite TLSv1+RSA:!NULL # ค่าของคำสั่งต่อไปนี้ถูกตั้งค่าเป็นค่าเริ่มต้น # อย่างไรก็ตาม เรานำเสนอมัน เพื่อความชัดเจน TLSVerifyClient ไม่เคย # ความปลอดภัย - คำสั่งอื่น ๆ # ป้องกันการเชื่อมต่อที่ไม่ระบุชื่อในการเชื่อมต่อประเภทใด ๆ ไม่อนุญาต bind_anon # จำเป็นต้องมีการดำเนินการผูกก่อนที่จะเข้าถึง DIT ต้องใช้การผูก # รอการเชื่อมต่อเฉพาะบนพอร์ต ldaps เท่านั้น ต้องใช้ TLS/SSL, # แต่ไม่ได้กำหนดข้อกำหนดความยาวคีย์ขั้นต่ำ # ข้อกำหนดความยาวคีย์ขั้นต่ำถูกกำหนดโดยคำสั่งต่อไปนี้: ความปลอดภัย simple_bind=128 # DIT ฐานข้อมูล bdb ต่อท้าย "d=example,dc=com" ... # ผู้ให้บริการแบบจำลองซ้อนทับ syncprov # cn=config ฐานข้อมูล DIT config rootdn="cn =ผู้ดูแลระบบ, cn=config" rootpw .... # cn=monitor การตรวจสอบฐานข้อมูล DIT rootdn="cn=admin,cn=monitor" rootpw ....

หมายเหตุ:

  1. cn=การกำหนดค่า:เร็วๆ นี้.

    2. เรากำลังรอการเชื่อมต่อสำหรับ LDAPS URL เท่านั้น:อาร์กิวเมนต์ -h เมื่อเริ่มตบ ค่าเริ่มต้น มูลค่าที่กำหนดไม่ได้ระบุสิ่งที่ (ปกติ) สอดคล้องกับ -h ldap:/// การกำหนดค่านี้กำหนดให้เราอนุญาตเฉพาะการดำเนินการ ldaps เท่านั้น ดังนั้นเมื่อเริ่มต้น slapd ต้องใช้คำสั่ง:

    ตบ -h ldaps:/// -u ldap -g ldap

    slapd_flags="ldaps:///".

    หากคุณกังวลเกี่ยวกับการกำหนดค่าไฟร์วอลล์ คุณสามารถกำหนดค่า LDAPS ให้ใช้พอร์ต 389 ได้ (LDAPS เป็นรูปแบบ URL ที่ระบุว่าจะใช้ TLS ไม่ใช่พอร์ตที่จะใช้) ในกรณีนี้ คำสั่ง launch จะเป็นดังนี้:

    Slapd -h ldaps://:389/ -u ldap -g ldap # เมื่อเชื่อมต่อ ldaps URL ควรอยู่ในรูปแบบ: ldaps://ldap.server.name:389

  2. ไม่อนุญาต ต้องการ และคำสั่งด้านความปลอดภัย:การรอการเชื่อมต่อเฉพาะบนพอร์ต LDAPS จะส่งผลให้เกิด บังคับใช้ TLS/SSL บนการเชื่อมต่อทั้งหมด ไม่ยอมรับการเชื่อมต่อประเภทอื่นในการกำหนดค่าเซิร์ฟเวอร์นี้ หากต้องการบังคับให้ผู้ใช้เข้ารับการตรวจสอบสิทธิ์ LDAP ให้ใช้คำสั่ง ต้องมีการผูกมัดและเพื่อป้องกันการเชื่อมต่อแบบไม่ระบุชื่อ จึงมีการใช้คำสั่ง ไม่อนุญาติbind_anon- ดังนั้น เพื่อให้สามารถเข้าถึง DIT ได้ การเชื่อมต่อใดๆ จะต้องดำเนินการผูก และการเชื่อมต่อจะต้องไม่เปิดเผยชื่อ หากคุณระบุเฉพาะคำสั่ง ความปลอดภัย simple_bind=128ซึ่งไม่ได้ให้ระดับการป้องกันที่ต้องการ คำสั่งนี้บอกเพียงว่า: หากมีการดำเนินการผูกแบบธรรมดา จะต้องใช้งาน TLS/SSL ไม่จำเป็นต้องทำการเชื่อมต่อ วัตถุประสงค์การใช้งานเท่านั้น ความปลอดภัย simple_bind=128ในการกำหนดค่าที่กำหนด — define ค่าต่ำสุดสสส. หากไม่จำเป็น คำสั่งนี้ไม่อาจระบุได้
  3. การเข้าถึง rootDSE:ผลข้างเคียงของนโยบายนี้คือการห้ามไม่ให้เข้าถึงโดยไม่ระบุชื่อ rootDSEซึ่งตามที่ระบุไว้แล้วอาจค่อนข้างเหมาะสมสำหรับเซิร์ฟเวอร์ที่ปลอดภัย
  4. คำสั่ง ACL:การกำหนดค่านี้ไม่ได้ให้มาตรการรักษาความปลอดภัยเพิ่มเติมตามการใช้ ACLs — ความปลอดภัยของเซิร์ฟเวอร์จะได้รับการรับประกันอย่างเต็มที่โดยคำสั่งการกำหนดค่าส่วนกลาง และการจำกัดการเชื่อมต่อไปยังพอร์ต LDAPS เท่านั้น ACL สามารถใช้เพื่อสร้างข้อจำกัดการเข้าถึงที่จำเป็นตามข้อมูลประจำตัวของผู้ใช้

การตั้งค่าไคลเอ็นต์:ข้อกำหนดที่ว่าเซิร์ฟเวอร์ LDAP จะให้บริการเฉพาะการเชื่อมต่อ TLS หมายความว่าไคลเอ็นต์ทั้งหมดต้องใช้ URL ของ LDAPS เมื่อเชื่อมต่อ และต้องตรวจสอบใบรับรอง X.509 ของเซิร์ฟเวอร์ ซึ่งต้องมีการเข้าถึงใบรับรอง CA (รูท) ในบริบทของเรา ไคลเอนต์อ้างถึงยูทิลิตี้และเครื่องมือ ldap รวมถึงเซิร์ฟเวอร์ LDAP ที่ใช้บริการการจำลองแบบโดยใช้ syncrepl แน่นอนว่า เนื่องจากยูทิลิตี้และเครื่องมือ ldap เป็นไคลเอนต์ จึงได้รับการตั้งค่าจากไฟล์ ldap.conf บางทีสิ่งที่ชัดเจนน้อยกว่าก็คือเซิร์ฟเวอร์ LDAP ที่ใช้บริการการจำลองแบบนั้นเป็นไคลเอนต์ TLS เช่นกัน ดังนั้นจึงได้รับข้อมูลใบรับรอง CA (รูท) จาก ldap.conf การกำหนดค่า ldap.conf:

# คัดลอกใบรับรองที่สร้างในขั้นตอนที่ 1 # ไปยังตำแหน่งที่เหมาะสมบนระบบไคลเอ็นต์ # โดยนัย: /certs/ldapscert.pem # เพิ่ม TLS_CACERT ไปที่ ldap.conf /certs/ldapscert.pem

การกำหนดค่าเซิร์ฟเวอร์ LDAP ที่เรพลิกากำลังทำงานอยู่:

# slapd.conf # ส่วนการตั้งค่าส่วนกลาง... # ความปลอดภัย - ส่วน TLS # ไม่มีการตั้งค่า # ฐานข้อมูล DIT ที่จำลองแบบแล้ว ส่วนต่อท้าย bdb "d=example,dc=com" ... # การตั้งค่าผู้บริโภคการจำลองแบบ syncrepl kill=000 type=RefreshandPersist provider = ldaps://ldap-master.example.com bindmethod=simple searchbase="dc=example,dc=com" retry="5 3 300 +" attrs="*,+" binddn="...." ข้อมูลประจำตัว = .... ...

หมายเหตุ:

  1. ใบรับรอง CA (รูท) ที่ใช้ในผู้บริโภคตัวอย่าง ซิงค์เครป(และกำหนดโดยคำสั่ง TLS_CACERT ใน ldap.conf) จะเหมือนกับที่ใช้เป็นใบรับรองเซิร์ฟเวอร์โดยผู้ออก DIT หลัก นี่เป็นผลมาจากวิธีการออกใบรับรองเดียวที่เราใช้ในการสร้างใบรับรองนี้: โดยทำหน้าที่เป็นทั้งใบรับรองเซิร์ฟเวอร์และใบรับรอง CA เมื่อใช้วิธีการอื่นในการสร้างใบรับรองที่ลงนามด้วยตนเอง ใบรับรองเซิร์ฟเวอร์และใบรับรอง CA อาจแตกต่างกัน และแน่นอนว่าจะแตกต่างกันเสมอเมื่อใช้ใบรับรองเชิงพาณิชย์

    ตามที่กล่าวไว้ข้างต้น หากบริการ ldaps ให้บริการบนพอร์ต 389 (เช่น เพื่อแก้ไขปัญหาการบล็อกการรับส่งข้อมูลด้วยไฟร์วอลล์) คำจำกัดความของ syncrepl จะใช้รูปแบบ URL แบบขยายที่ระบุพอร์ต:

    Syncrepl ... ผู้ให้บริการ = ldaps://ldap-master.example.com:389 ...

    เซิร์ฟเวอร์ LDAP เป็นไคลเอนต์ TLS:เมื่อเซิร์ฟเวอร์ LDAP ทำหน้าที่เป็นผู้บริโภคการจำลองแบบ syncrepl เซิร์ฟเวอร์จะทำหน้าที่เป็นไคลเอ็นต์ TLS ดังนั้นจึงจำเป็นต้องตรวจสอบใบรับรองเซิร์ฟเวอร์กับใบรับรอง CA (รูท) ที่มีการลงนาม เนื่องจากเซิร์ฟเวอร์นี้ทำหน้าที่เป็นไคลเอ็นต์ TLS จึงจะใช้คำสั่ง TLS (และไฟล์ใบรับรอง TLS) ที่กำหนดไว้สำหรับไคลเอ็นต์ LDAP — โดยเฉพาะ จะใช้คำสั่ง TLS_CACERT ใน ldap.conf ไคลเอ็นต์ TLS จำเป็นต้องสร้างข้อความแลกเปลี่ยนคีย์ที่เข้ารหัสด้วย กุญแจสาธารณะ(กุญแจสาธารณะ)เซิร์ฟเวอร์ซึ่งแยกมาจากใบรับรอง X.509 ที่เซิร์ฟเวอร์ส่งมา ยังเป็นไคลเอนต์ TLS เมื่อเริ่มต้นสร้างการเชื่อมต่อ TLS ที่ ลูกค้าสวัสดีส่งรายการชุดการเข้ารหัสที่อนุญาตซึ่งควบคุมโดยคำสั่งการกำหนดค่าไคลเอนต์ TLS TLS_CIPHER_SUITE (โดยค่าเริ่มต้น ชุดการเข้ารหัสที่เป็นไปได้ทั้งหมด (ALL) จะถูกส่งไป ซึ่งเทียบเท่ากับคำสั่ง ยันต์ openssl -v ทั้งหมด- ก่อนจะอ่านประโยคถัดไป ให้หายใจลึกๆ ก่อน หากเซิร์ฟเวอร์ LDAP ที่เป็นผู้บริโภคการจำลองแบบ syncrepl และไคลเอ็นต์ TLS ยังให้การเข้าถึง DIT อื่นด้วย (เช่น cn=config) และถือว่าการสนับสนุน TLS จำเป็นต่อการควบคุมการเข้าถึงนั้นด้วย พร้อมกันจะเป็นเซิร์ฟเวอร์ TLS และกำหนดให้ระบุคำสั่งเซิร์ฟเวอร์ TLS ทั้งหมดที่กำหนดไว้ข้างต้นในขั้นตอนที่ 2 และ 3

การกำหนดค่าการเข้าถึง TLS/SSL แบบผสมใน OpenLDAP

หากคุณข้ามไปยังส่วนนี้โดยตรงโดยไม่มีคำอธิบายเกี่ยวกับการกำหนดค่า TLS ปกติ โปรดสละเวลาอ่านอย่างน้อย และควรอ่านให้ครบทุกส่วน ไม่เช่นนั้นคุณอาจสับสนได้อย่างรวดเร็ว (แม้ว่าหลังจากอ่านข้อความนี้แล้ว คุณอาจสับสนเร็วขึ้นอีก ). อย่างไรก็ตาม เราหวังว่าการรู้แจ้งบางอย่างจะเกิดขึ้น

การกำหนดค่า—บางอันใช้ TLS แต่บางอันไม่ได้ใช้

ในกรณีนี้ ข้อกำหนดก็คือผู้ใช้บางรายจะใช้ TLS และคนอื่นๆ จะใช้ไม่ได้ ตัวอย่างเช่น นโยบายอาจเป็น:

  1. อนุญาตการเข้าถึงแบบไม่ระบุชื่อ (และการสื่อสารที่ไม่ปลอดภัย) ไปยังชุดบันทึก LDAP สาธารณะแบบจำกัด
  2. ผู้ใช้ที่ผ่านการรับรองความถูกต้องของ LDAP (การเชื่อมต่ออย่างง่ายกับการสื่อสารที่ไม่ปลอดภัย) จะได้รับอนุญาตให้เข้าถึงบันทึก LDAP สาธารณะแบบอ่าน รวมถึง สิทธิอันจำกัดเพื่ออัปเดตเฉพาะบันทึกที่เป็นของผู้ใช้รายนี้
  3. ผู้ใช้ที่มีสิทธิ์ในการอัปเดตบันทึกของตนเองมากกว่าหนึ่งรายการต้องใช้ TLS และได้รับการรับรองความถูกต้อง (สมมติว่าพวกเขาเป็นสมาชิกทั้งหมดของกลุ่มผู้ดูแลระบบ)
  4. ผู้ใช้การจำลองข้อมูลทั้งหมดต้องใช้ TLS/SSL
  5. เมื่อเข้าถึง cn=config จากระยะไกล จะต้องใช้ TLS/SSL

โซลูชันนี้จำเป็นต้องใช้ ACL และคำสั่งการกำหนดค่าเซิร์ฟเวอร์ ดังที่แสดงด้านล่าง:

    การสร้างเซิร์ฟเวอร์ LDAP และใบรับรอง CA:บน ในขั้นตอนนี้ใบรับรองที่ลงนามด้วยตนเองจะถูกสร้างขึ้น — หากใช้ใบรับรอง X.509 (SSL) เชิงพาณิชย์ กระบวนการนี้ไม่จำเป็นและสามารถข้ามได้ทั้งหมด วิธีการคำสั่งเดียวแบบง่ายๆ ใช้เพื่อสร้างใบรับรอง X.509 เดียวที่สามารถใช้สำหรับการรับรองความถูกต้องของเซิร์ฟเวอร์และเป็นใบรับรอง CA (รูท) สำหรับไคลเอนต์ วิธีการนี้เอกสารโดยละเอียด (พร้อมบทสนทนาทั้งหมด) ลำดับคำสั่ง:

    # สร้างไดเร็กทอรีใหม่ (เป็นทางเลือก) mkdir /certs mkdir /certs/keys cd /certs # สร้างเซิร์ฟเวอร์/ใบรับรอง CA และ รหัสส่วนตัวไม่มีข้อความรหัสผ่าน # ใช้ได้ 10 ปี โดยใช้คำแนะนำขนาดคีย์ RSA ปัจจุบัน # RSA ใช้เป็นโปรโตคอลการแลกเปลี่ยนคีย์ openssl req -x509 -nodes -days 3650 -newkey rsa:2048 -keyout Keys/ldapskey.pem -out ldapscert # ใบรับรองสามารถใช้เป็นใบรับรองเซิร์ฟเวอร์หรือใบรับรอง CA # วางใบรับรองใน: /certs/ldapscert.pem # วางคีย์ส่วนตัวใน: /certs/keys/ldapskey.pem # ตั้งค่าการอนุญาต chown -R ldap:ldap / ใบรับรอง/ * chmod 0400 คีย์/ldapskey.pem

    หมายเหตุ:

    1. สำหรับคำอธิบายโดยละเอียดเกี่ยวกับตัวเลือกคำสั่ง openssl โปรดดูที่

      ไฟล์คีย์มักจะมีข้อความรหัสผ่าน (รหัสผ่าน) เพื่อปกป้องข้อมูลที่ละเอียดอ่อน หากใบรับรองถูกสร้างขึ้นสำหรับเซิร์ฟเวอร์ ข้อความรหัสผ่านดังกล่าวจะไม่ถูกนำมาใช้ (การสร้างใบรับรองจะถูกระงับโดยอาร์กิวเมนต์ -nodes)

      ขึ้นอยู่กับข้อกำหนดสำหรับใบรับรอง อาจใช้วิธีการอื่นในการสร้างใบรับรองที่ลงนามด้วยตนเองตามที่อธิบายไว้

    การเพิ่มคำสั่ง TLS และ ACL ไปที่ slapd.conf:(ดูส่วนท้ายของส่วนสำหรับหมายเหตุเกี่ยวกับ cn=config) คำสั่ง TLS ที่จำเป็นจะถูกเพิ่มในส่วนการตั้งค่าส่วนกลาง:

    # slapd.conf # ส่วนการตั้งค่าส่วนกลาง... # ความปลอดภัย - ส่วน TLS TLSCertificateFile /certs/ldapscert.pem TLSCertificateKeyFile /certs/keys/ldapskey.pem TLSCipherSuite TLSv1+RSA:!NULL # ค่าของคำสั่งต่อไปนี้ถูกตั้งค่าเป็นสิ่งนี้ โดยค่าเริ่มต้น # อย่างไรก็ตาม เรานำเสนอที่นี่เพื่อความชัดเจน TLSVerifyClient ไม่เคย ... # ฐานข้อมูล DIT ที่กำหนดเอง ส่วนต่อท้าย bdb "d=example,dc=com" # ไม่มีคำสั่ง rootdn และ rootpw # ดูหมายเหตุเกี่ยวกับการรักษาความปลอดภัยการเข้าถึงในฐานะ rootdn ... # ACL # ACL1 - การเข้าถึงสำหรับผู้ใช้การจำลองแบบ # (สมมติว่ามีการเชื่อมต่อในนามของ cn=replica,dc=example,dc=com) # ผู้บริโภคที่ใช้ TLS ได้รับอนุญาตให้เข้าถึงแบบอ่านไปยัง DIT ทั้งหมด # คนอื่นๆ ไปที่ ACL2 (หยุด) เข้าถึง * โดย dn.exact="cn=replica,dc=example,dc=com" tls_ssf=128 อ่านโดย * break # ACL2 - การเข้าถึงแอตทริบิวต์รหัสผ่านผู้ใช้ # ผู้ใช้ที่ไม่ระบุตัวตนสามารถรับรองความถูกต้องได้เท่านั้น ผู้ใช้ที่ได้รับการรับรองความถูกต้องเท่านั้นที่สามารถแก้ไขได้ รหัสผ่านของตัวเอง(ตนเอง) # สมาชิกของกลุ่มผู้ดูแลระบบที่ใช้ TLS สามารถแก้ไขรหัสผ่านการเข้าถึง attrs=userPassword โดยการเขียนด้วยตนเองโดยการรับรองความถูกต้องแบบไม่ระบุชื่อโดย group.exact "cn=admins,ou=groups,dc=example,dc=com" tls_ssf=128 write # ACL3 # การเข้าถึงแบบอ่านอย่างเดียวแบบจำกัดแบบไม่ระบุตัวตนในทรีย่อยสาธารณะ # ผู้ใช้ที่ได้รับการตรวจสอบความถูกต้องสามารถแก้ไข # รายการตนเองภายในทรีย่อย # สมาชิกของกลุ่มผู้ดูแลระบบที่ใช้ TLS มีสิทธิ์ในการเขียนไปยังทรีย่อยทั้งหมด การเข้าถึงสาธารณะไปยัง dn .subtree="ou =public,dc=example,dc=com" โดย group.exact "cn=admins,ou=groups,dc=example,dc=com" tls_ssf=128 เขียนด้วยตนเอง เขียนโดย anonymous อ่านโดยผู้ใช้ อ่าน # ACL4 # สมาชิกของ กลุ่มผู้ดูแลระบบที่ใช้ TLS มีสิทธิ์ในการเขียน มิฉะนั้นการเข้าถึง DIT ไปยัง * โดย group.exact "cn=admins,ou=groups,dc=example,dc=com" tls_ssf=128 write # สุดท้าย ACL4 ก็ตรงไปตรงมาเช่นกัน - หากมีกฎเพิ่มเติม จำเป็น # ควรแทนที่ด้วยอันด้านล่าง ซึ่งจะกรองผู้ใช้ทั้งหมด # ที่ไม่ได้ใช้ TLS ในกรณีนี้ ตัวแบ่งหมายความว่าหากผู้ใช้ใช้ TLS # มันจะย้ายไปยัง ACL ถัดไป ไม่เช่นนั้นการประมวลผลจะหยุดลง # ACL4 เข้าถึง * โดย group.exact "cn=admins,ou=groups,dc=example,dc=com" tls_ssf=128 break # ACL5 เป็นต้น เข้าถึง .... # ผู้ให้บริการการจำลองแบบซ้อนทับ syncprov # cn=config การกำหนดค่าฐานข้อมูล DIT rootdn "cn=admin,cn=config" rootpw (SSHA) hfkhfhfldkhlkhh # SSF มากกว่าหรือเท่ากับ 128 ถูกใช้เพื่อให้การเข้าถึงที่ปลอดภัยไปยัง cn=config ความปลอดภัย simple_bind= 128

    หมายเหตุ:

    1. ข้อมูลเพิ่มเติมเกี่ยวกับ TLSCipherSuite พารามิเตอร์ที่ใช้ไม่รวมการใช้การเข้ารหัส NULL (ไม่มีการเข้ารหัส) TLSv1 ครอบคลุม SSLv3 อนุญาตให้ใช้รหัสส่งออก — อนุญาต การเชื่อมต่อระหว่างประเทศ- หากปัญหาด้านประสิทธิภาพและโหลดมีความสำคัญ ควรระบุรายการการเข้ารหัสที่มีประสิทธิภาพและคุณลักษณะโหลดของระบบให้ชัดเจน ดีกว่าปล่อยให้ความสามารถในการเลือกการเข้ารหัสโดยพลการในระหว่างการเจรจา TLS/SSL

      การกำหนดค่า DSA:เร็วๆ นี้.

      cn=การกำหนดค่า:เร็วๆ นี้.

      หมายเหตุ ACL:

      1. ACL1: ACL นี้ ซึ่งสามารถวางในส่วนการตั้งค่าส่วนกลางได้อย่างง่ายดายพอๆ กัน ได้รับการออกแบบมาเพื่อแยกผู้ใช้การจำลองแบบตั้งแต่เริ่มต้นของการเชื่อมต่อ (DN cn=replica,dc=example,dc=com ต้องมีอยู่ใน DIT ด้วยค่าที่สอดคล้องกัน รหัสผ่าน). โดย dn.exact="cn=replica,dc=example,dc=com" tls_ssf=128 อ่านมีสองเงื่อนไขที่ใช้งานได้ (แม้ว่าจะไม่ได้ระบุไว้อย่างชัดเจน) และจะถูกจับคู่หากผู้บริโภคได้รับการรับรองความถูกต้องสำเร็จ และใช้ SSF (TLS) อย่างน้อย 128 เพื่อให้ผู้บริโภคการจำลองแบบ (และทุกคน) สามารถตรวจสอบสิทธิ์ได้ (หรือเพียงเข้าถึง DIT) ต้องมีเงื่อนไข โดย * ทำลายซึ่งช่วยให้คุณไปที่ ACL2 และวิเคราะห์การเชื่อมต่อต่อไปได้

        ACL2:อนุญาตให้ผู้ใช้ที่ได้รับการรับรองความถูกต้องสามารถแก้ไขรหัสผ่านของตนได้ การเข้าถึงแบบไม่ระบุชื่อจัดทำขึ้นเพื่อวัตถุประสงค์ในการรับรองความถูกต้อง ( รับรองความถูกต้อง- สมาชิกของกลุ่ม cn=admins,ou=groups,dc=example,dc=com ที่ใช้ TLS ในการเชื่อมต่อสามารถเปลี่ยนรหัสผ่านใดก็ได้

        ACL3:ในลำดับนี้ สมาชิกของกลุ่ม cn=admins,ou=groups,dc=example,dc=com โดยใช้ TLS เมื่อเชื่อมต่อ จะได้รับอนุญาตให้เขียนไปยังคุณลักษณะใดๆ ของรายการใดๆ ในทรีย่อยสาธารณะของฐานข้อมูล สำหรับผู้ใช้ที่ไม่ระบุชื่ออนุญาตให้เข้าถึงแผนผังย่อยเพื่ออ่าน สาธารณะ DIT (ยกเว้นแอตทริบิวต์ userPassword) ผู้ใช้ที่ได้รับการรับรองความถูกต้องจะได้รับอนุญาตให้เปลี่ยนแปลงส่วนใดส่วนหนึ่งของบันทึกของตนได้ ในที่สุด ผู้ใช้ที่ได้รับการรับรองความถูกต้อง (เชื่อมต่อโดยมีหรือไม่มี TLS) จะได้รับอนุญาตให้เข้าถึงแผนผังย่อยสาธารณะแบบอ่านอย่างเดียว ยกเว้นแอตทริบิวต์ userPassword (และยังไม่รวมของพวกเขาด้วย บันทึกของตัวเองการควบคุมการเข้าถึงที่ระบุไว้ในเงื่อนไขของตนเอง)

        ACL4:เฉพาะสมาชิกของกลุ่ม cn=admins,ou=groups,dc=example,dc=com ที่ใช้ TLS เพื่อเชื่อมต่อเท่านั้นที่ได้รับอนุญาตให้เข้าถึงการเขียนไปยังส่วนอื่นๆ ทั้งหมดของ DIT ผู้ใช้รายอื่นทั้งหมดถูกปฏิเสธการเข้าถึงใดๆ (เงื่อนไขโดยนัย โดย * ไม่มี).

      2. เรากำลังรอการเชื่อมต่อสำหรับ LDAPS และ LDAP URL:พอร์ตที่ใช้เชื่อมต่อจะถูกควบคุมโดยใช้อาร์กิวเมนต์ -h เมื่อเริ่มต้น slapd โดยค่าเริ่มต้น ค่านี้ไม่ได้ตั้งค่าไว้ ซึ่ง (โดยปกติ) จะสอดคล้องกับ -h ldap:/// ตามข้อกำหนดของการกำหนดค่านี้ เราต้องอนุญาตการดำเนินการทั้งสองอย่าง ลาป, ดังนั้น ลาปส์ดังนั้นเมื่อเริ่ม slapd ควรใช้คำสั่ง:

      ตบ -h "ldap:/// ldaps:///" -u ldap -g ldap

      เพื่อให้สิ่งนี้เกิดขึ้นโดยอัตโนมัติ คุณต้องแก้ไขสคริปต์เริ่มต้นใน Linux (/etc/rc.d/init.d/slapd) และใน BSD /etc/rc.conf ควรมีบรรทัดต่อไปนี้: slapd_flags="ldap:/// ldaps:///".

      การเข้าถึงความปลอดภัยในฐานะ rootdn:หลังจากที่ DIT ถูกโหลดครั้งแรกแล้ว มันทำหน้าที่อะไรบ้าง? rootdn- สิทธิพิเศษทุกกรณี พิมพ์ rootdnสำหรับ DIT สามารถมอบให้กับใครก็ได้ ผู้ใช้เฉพาะ(ลองโทรหาเขาสิ หลอก superuser) โดยใช้ ACL และดังนั้นจึงเป็นคำสั่ง rootdnคุณสามารถลบมันได้อย่างปลอดภัย ในระบบควบคุมที่ออกแบบมาอย่างดีคุณสามารถจัดหาสิ่งใหม่ได้ หลอก superuserสิทธิ์ที่จำเป็นโดยใช้ ACL มาตรฐาน — อันที่จริง นั่นคือสิ่งที่มีไว้สำหรับ ข้อผิดพลาดประการเดียวของแนวทางนี้คือ ข้อผิดพลาดใน ACL สามารถนำไปสู่การจำกัดสิทธิ์ที่จำเป็นได้ อย่างเลวร้ายที่สุด rootdnสามารถกู้คืนได้ชั่วคราวแล้วลบอีกครั้งเมื่อปัญหาได้รับการแก้ไข ทางออกที่ดีที่สุดการรักษาความปลอดภัยการเข้าถึงในนามของ rootdnถึง DIT ปกติจะมีการลบตัวเองออก rootdn- และระยะ. เช่นเดียวกับในการกำหนดค่าข้างต้น

      ในกรณีที่ rootdnเป็นวิธีการเข้าถึงวิธีเดียว เช่น cn=config ในตัวอย่างข้างต้น คำสั่งความปลอดภัย simple_bind=128 ใช้เพื่อบังคับให้เปิดใช้งานกลไกความปลอดภัยในส่วนฐานข้อมูลเฉพาะ

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

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

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

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

กำลังเชื่อมต่อกับเซิร์ฟเวอร์ LDAP

วิธีการผูกเซิร์ฟเวอร์ LDAP

พารามิเตอร์ วิธีการผูกเซิร์ฟเวอร์ LDAPกำหนดวิธีที่อุปกรณ์จะเชื่อมต่อกับเซิร์ฟเวอร์ LDAP ติดต่อผู้ดูแลระบบเซิร์ฟเวอร์ LDAP ของคุณเพื่อพิจารณาว่าวิธีใดดีที่สุดสำหรับคุณ

  • เรียบง่าย- เซิร์ฟเวอร์ LDAP ที่เลือกไม่รองรับการเข้ารหัส โปรดทราบว่ารหัสผ่าน (ถ้ามี) จะถูกส่งผ่านเครือข่ายในรูปแบบข้อความที่ชัดเจน
  • ง่าย ๆ ผ่าน SSL- เซิร์ฟเวอร์ LDAP ที่เลือกรองรับการเข้ารหัส SSL ข้อมูลทั้งหมดรวมทั้งชื่อผู้ใช้และรหัสผ่านจะถูกเข้ารหัส ต้องกำหนดค่าเซิร์ฟเวอร์ LDAP ให้รองรับ SSL รวมถึงการตั้งค่าใบรับรองเพื่อระบุเซิร์ฟเวอร์ นอกจากนี้ อินเทอร์เฟซเครือข่ายของอุปกรณ์จะต้องได้รับการกำหนดค่าด้วยใบรับรองผู้ออกใบรับรอง (CA) เพื่อตรวจสอบความถูกต้องของเซิร์ฟเวอร์ LDAP ใบรับรอง CA ได้รับการกำหนดค่าบนแท็บ สุทธิเว็บอินเตอร์เฟส ในการกำหนดค่าเซิร์ฟเวอร์ LDAP บางอย่าง คุณยังต้องสร้างใบรับรองไคลเอ็นต์ด้วย ซึ่งกำหนดค่าไว้ในแท็บเดียวกัน สุทธิ.

เซิร์ฟเวอร์ LDAP

พารามิเตอร์ เซิร์ฟเวอร์ LDAPหมายถึงชื่อโฮสต์หรือที่อยู่ IP ของเซิร์ฟเวอร์ LDAP ที่จะใช้ในการตรวจสอบสิทธิ์ผู้ใช้อุปกรณ์ หากคุณใช้ SSL ชื่อหรือที่อยู่ที่ป้อนที่นี่จะต้องตรงกับชื่อบนใบรับรองที่เซิร์ฟเวอร์ส่งมา

ในฟิลด์นี้ คุณสามารถระบุเซิร์ฟเวอร์ได้หลายเครื่อง โดยแยกที่อยู่ด้วยเครื่องหมาย แถบแนวตั้ง("|", ASCII 0x7c) ตัวอย่างเช่น ฟังก์ชันนี้สามารถใช้เพื่อระบุเซิร์ฟเวอร์หลักและเซิร์ฟเวอร์สำรองได้ อินเตอร์เฟซเครือข่ายรองรับใบรับรอง CA เดียวเท่านั้น ดังนั้นเซิร์ฟเวอร์ LDAP ทั้งหมดในรายการนี้ต้องใช้ใบรับรอง CA เดียวกัน

ท่าเรือ

พารามิเตอร์ ท่าเรือระบุหมายเลขพอร์ต TCP/IP ที่เซิร์ฟเวอร์ประมวลผลคำขอ LDAP โดยปกติจะเป็นพอร์ต 389 สำหรับ เรียบง่ายการผูกหรือ 636 สำหรับการผูก ง่าย ๆ ผ่าน SSL.

ค้นหาชื่อผู้ใช้และรหัสผ่าน

การตรวจสอบสิทธิ์ LDAP ใช้สองวิธีในการตรวจสอบสิทธิ์ผู้ใช้

วิธีแรกเรียกว่า- มันเกี่ยวข้องกับการ "สร้าง" DN ของผู้ใช้ (ชื่อเฉพาะ) สำหรับการรับรองความถูกต้อง ("การเชื่อมโยง") ในไดเร็กทอรี LDAP ต่อท้ายข้อมูลที่ผู้ใช้ป้อนบนแผงควบคุมคำนำหน้า DN , และ เส้นที่กำหนดต่อท้ายบรรทัดการผูกมัดและเริ่มการค้นหา- ตัวอย่างเช่น คำนำหน้า DN “CN” ร่วมกับสตริงที่ผู้ใช้ป้อน[ป้องกันอีเมล] และสตริงการผูกและการค้นหา OU=Engineering,DC=NASA,DC=GOV จะกำหนด DN ของผู้ใช้: [ป้องกันอีเมล],OU=วิศวกรรม,ดีซี=นาซ่า,ดีซี=GOV

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

ทาง ชื่อผู้ใช้และรหัสผ่านของอุปกรณ์ควรใช้เมื่อผู้ใช้ทั้งหมดอยู่ในคอนเทนเนอร์ไดเรกทอรี LDAP เดียวกัน และคำแรกคือคำศัพท์ DN ที่ปกติผู้ใช้จะใช้ในการตรวจสอบสิทธิ์ โปรดทราบว่าสามารถป้อนสตริงเริ่มต้นและการเชื่อมโยงหลายรายการได้ตราบใดที่คั่นด้วยเครื่องหมาย “|” และอุปกรณ์จะพยายามตรวจสอบสิทธิ์ผู้ใช้สำหรับการค้นหาและค่าเริ่มต้นการค้นหาแต่ละรายการตามลำดับ สามารถใช้วิธีนี้ได้หากผู้ใช้อยู่ในคอนเทนเนอร์ไดเรกทอรี LDAP หลายรายการ

ทาง ควรใช้หากผู้ใช้อยู่ในหลายคอนเทนเนอร์ หรือหากโดยทั่วไปผู้ใช้บางรายไม่รู้จักคำแรกของ DN หรือไม่ได้ใช้สำหรับการตรวจสอบสิทธิ์บนระบบอื่น เมื่อใช้วิธีการนี้ ผู้ใช้อาจได้รับแจ้งให้ป้อนแอตทริบิวต์ LDAP เฉพาะ เช่น SAMAccountName หรือแม้แต่หมายเลขโทรศัพท์ของผู้ใช้ - คุณลักษณะ TelephoneNumber

ชื่อผู้ใช้และรหัสผ่านของอุปกรณ์

วิธีการนี้ใช้คำนำหน้าการเชื่อมโยง สตริงที่ผู้ใช้ป้อนบนแผงควบคุมอุปกรณ์ และสตริงการค้นหาการเชื่อมโยงและเริ่มเพื่อสร้าง DN ของผู้ใช้ใหม่ DN ที่สร้างขึ้นใหม่จะใช้เพื่อตรวจสอบสิทธิ์ผู้ใช้

คำนำหน้าการผูก

พารามิเตอร์ คำนำหน้าการผูกเป็นแอตทริบิวต์ LDAP ที่ใช้สร้าง DN ของผู้ใช้เพื่อการตรวจสอบสิทธิ์ คำนำหน้านี้จะรวมกับชื่อผู้ใช้ที่ป้อนในแผงควบคุมเพื่อสร้างชื่อที่แตกต่างแบบสัมพันธ์ (RDN) โดยทั่วไปจะใช้คำนำหน้า "CN" (for ชื่อสามัญ) หรือ "UID" (สำหรับ ID ผู้ใช้)

การใช้ชื่อผู้ใช้และรหัสผ่านของผู้ดูแลระบบ

ผู้ดูแลระบบ DN

นี่คือ DN (ชื่อเฉพาะ) ของผู้ใช้ที่มีสิทธิ์อ่านไดเร็กทอรี LDAP บัญชีที่ป้อนที่นี่อาจไม่มีสิทธิ์การเข้าถึงระดับผู้ดูแลระบบในไดเรกทอรี สิทธิ์ในการอ่านก็เพียงพอแล้ว

รหัสผ่านผู้ดูแลระบบ

รหัสผ่านของผู้ใช้ที่ป้อน DN ในช่อง "Administrator DN"

ค้นหาฐานข้อมูล LDAP

การผูกมัดและเริ่มการค้นหา

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

เมื่อเลือกวิธีการ การใช้ชื่อผู้ใช้และรหัสผ่านของผู้ดูแลระบบเส้น การผูกมัดและเริ่มการค้นหาใช้เป็นจุดเริ่มต้นของการค้นหาเท่านั้น การค้นหาฐานไดเรกทอรี LDAP สามารถเริ่มต้นได้ และอุปกรณ์จะค้นหาแผนผัง LDAP ทั้งหมดเพื่อหาอ็อบเจ็กต์ผู้ใช้ที่ตรงกับชื่อผู้ใช้ที่ป้อน

สตริงประกอบด้วยคู่แอตทริบิวต์=ค่าคั่นด้วยเครื่องหมายจุลภาค ตัวอย่างเช่น:

ou=วิศวกรรม,o=ฮิวเลตต์แพ็กการ์ด,c=US

ou=การตลาด,o=ฮิวเลตต์แพ็กการ์ด,c=US

ou=วิศวกรรม,cn=ผู้ใช้,dc=hp,dc=com

หากคุณเลือกวิธีชื่อผู้ใช้อุปกรณ์และรหัสผ่าน คุณสามารถป้อนสตริงการผูกหลายสตริงในฟิลด์นี้ โดยคั่นด้วยอักขระไปป์ ("|", ASCII 0x7c) ซึ่งสามารถใช้เพื่อระบุโดเมน LDAP อื่นได้ อุปกรณ์จะพยายามเชื่อมโยงกับเซิร์ฟเวอร์ LDAP โดยใช้แต่ละสตริงทีละรายการตามลำดับที่ระบุ เมื่อการเชื่อมโยงสำเร็จ ระบบจะใช้ออบเจ็กต์รูทเดียวกันเพื่อค้นหาข้อมูลผู้ใช้อุปกรณ์

แอตทริบิวต์ LDAP ที่สอดคล้องกับชื่อผู้ใช้

เมื่อค้นหาข้อมูลผู้ใช้ในฐานข้อมูล LDAP ค่าของคุณลักษณะที่ระบุในช่องนี้จะถูกเปรียบเทียบกับชื่อผู้ใช้ที่ป้อนระหว่างการตรวจสอบสิทธิ์ โดยทั่วไปแล้วแอตทริบิวต์นี้จะเหมือนกับ คำนำหน้าการผูก.

ใบเสร็จ

ที่อยู่อีเมลโดยใช้แอตทริบิวต์

เมื่อพบผู้ใช้อุปกรณ์ในฐานข้อมูล LDAP แล้ว จะพบที่อยู่อีเมลของพวกเขาในฐานข้อมูลโดยใช้แอตทริบิวต์ LDAP ที่ระบุใน ที่อยู่อีเมลโดยใช้แอตทริบิวต์.

และชื่อโดยใช้แอตทริบิวต์

ชื่อหน้าจอของผู้ใช้ได้มาจากแอตทริบิวต์ LDAP ที่ระบุในช่อง ชื่อโดยใช้แอตทริบิวต์.

การทดสอบ

การทำงาน การทดสอบใช้เพื่อตรวจสอบว่าพารามิเตอร์ถูกต้องก่อนนำไปใช้ เมื่อคุณคลิกปุ่มนี้ คุณจะได้รับแจ้งให้ป้อนชื่อผู้ใช้และรหัสผ่าน เหมือนกับว่าคุณลงชื่อเข้าใช้แผงควบคุมอุปกรณ์ หากข้อมูลรับรองที่ป้อนได้รับการตรวจสอบสิทธิ์และพบข้อมูลผู้ใช้ในฐานข้อมูล LDAP ข้อความยืนยันความสำเร็จจะปรากฏขึ้น มิฉะนั้น ข้อความแสดงข้อผิดพลาดจะปรากฏขึ้นเพื่อระบุว่าการตรวจสอบสิทธิ์ล้มเหลว

  1. เข้าสู่ระบบ ไมโครซอฟต์ วินโดวส์ยังไง ผู้ดูแลระบบ
  2. ส่งออกบริบท LDAP ไปยังไฟล์โดยการรันคำสั่งในคอนโซล
ldifde –f ldap.txt
  1. เปิดไฟล์ที่ได้รับ
    ldap.txt- บรรทัดแรกจะมี DN ของเซิร์ฟเวอร์ของคุณ ตัวอย่างเช่น:
dn: DC=เซิร์ฟเวอร์ ldap,DC=บริษัทของฉัน,DC=com

Dn:DC=localhost

คุณสามารถกำหนดค่าพารามิเตอร์การเชื่อมต่อ LDAP ได้ในยูทิลิตี้ TrackStudio ผู้จัดการเซิร์ฟเวอร์หรือหากไม่มีในโปรแกรมแก้ไขข้อความใดๆ

การกำหนดค่าผ่านตัวจัดการเซิร์ฟเวอร์

  1. เลือกตัวเลือกการให้สิทธิ์ผู้ใช้: ช่องใดที่จะใช้เพื่อค้นหารายการที่ตรงกันใน TrackStudio และช่องใดที่จะใช้ใน LDAP
  2. คลิก ตรวจสอบการเชื่อมต่อเพื่อตรวจสอบการเชื่อมต่อ LDAP

การตั้งค่าการเชื่อมต่อในไฟล์ .properties

หากคุณไม่สามารถเรียกใช้ Server Manager ได้ คุณสามารถกำหนดค่าการรวม LDAP ในไฟล์ได้ trackstudio.security.properties

  1. เปิดใช้งานการสนับสนุน LDAP ใน trackstudio.security.properties:
trackstudio.useLDAP ใช่
  1. หากจำเป็น ให้เปิดใช้งานตัวเลือก " ใช้ LDAP ผ่าน SSL"
ldap.useSSL ใช่
  1. ระบุที่อยู่เซิร์ฟเวอร์ LDAP และพอร์ต
ldap.host 127.0.0.1 ldap.พอร์ต 389
  1. ตั้งค่า DN ฐานเป็น cn=ผู้ใช้สำหรับชื่อโดเมนของคุณ คุณสามารถระบุ Base DN ได้หลายรายการ
    การตั้งค่า LDAP ใช้อัฒภาคเป็นตัวคั่น
ldap.baseDN = dc=ตัวอย่าง,dc=com
  1. ระบุบัญชีผู้ใช้ที่คุณจะเข้าสู่ระบบ ไดเรกทอรีที่ใช้งานอยู่:
ldap.userDN = cn=admin,dc=example,dc=com
  1. ป้อนรหัสผ่านสำหรับรายการนี้:
ldap.userDNpass ผ่าน

เพื่อให้ผู้ใช้ที่ลงทะเบียนใน LDAP สามารถเข้าถึง TrackStudio ได้ จะต้องสร้างบัญชีให้พวกเขา บัญชีเหล่านี้จะต้องตรงกับรายการ LDAP ตามชื่อบัญชีหรือชื่อผู้ใช้

  1. หากต้องการเข้าสู่ระบบด้วยชื่อและนามสกุลของผู้ใช้ ให้ตั้งค่า:
ldap.loginAttrLDAP=displayName ชื่อ ldap.loginAttrTS
  1. วิธีเข้าสู่ระบบด้วยชื่อบัญชี:
เข้าสู่ระบบ ldap.loginAttrTS ldap.loginAttrLDAP=sAMAccountName

หลักการทำงาน

ถ้าติดตั้ง trackstudio.useLDAP ใช่ TrackStudio จะเชื่อมต่อกับเซิร์ฟเวอร์ LDAP ที่ระบุเมื่อผู้ใช้พยายามเข้าสู่ระบบและดำเนินการให้สิทธิ์ LDAP โดยใช้บัญชีที่ระบุใน ldap.userDNและ ldap.userDNpass- TrackStudio จะทำการค้นหาในท้องถิ่นในฐานข้อมูลสำหรับผู้ใช้ที่ตรงกับการเข้าสู่ระบบที่ระบุ หลังจากนี้ TrackStudio จะค้นหาเซิร์ฟเวอร์ LDAP เพื่อหารายการของผู้ใช้ ldap.loginAttrLDAPซึ่งสอดคล้องกัน ชื่อหรือ เข้าสู่ระบบ(ขึ้นอยู่กับ ldap.loginAttrTS) พบผู้ใช้ ผู้ใช้รายนี้จะได้รับอนุญาตด้วยรหัสผ่านที่ให้ไว้ในหน้าต่างเข้าสู่ระบบ
TrackStudio รองรับการทำงานกับตัวกรอง LDAP คุณสามารถป้อนตัวกรองของคุณลงใน "ช่องค้นหา LDAP" ดังนั้น TrackStudio จะใช้งานได้เฉพาะกับผู้ใช้ที่มีคุณสมบัติตรงตามเงื่อนไขของตัวกรองที่ระบุเท่านั้น คุณสามารถอ่านเพิ่มเติมเกี่ยวกับตัวกรองได้ในบทความนี้

บันทึก

  • หากต้องการเข้าสู่ TrackStudio ในหน้าต่างเข้าสู่ระบบคุณต้องใช้ทุกประการ เข้าสู่ระบบ
  • ไม่ว่าในกรณีใด ผู้ใช้ที่เกี่ยวข้องจะต้องมีบัญชีใน TrackStudio
  • เมื่อคุณเปลี่ยนรหัสผ่านโดยใช้ TrackStudio จะไม่เปลี่ยนบนเซิร์ฟเวอร์ LDAP
  • ผู้ใช้สามารถเข้าสู่ระบบได้หากรหัสผ่านตรงกับรหัสผ่านใน LDAP หรือรหัสผ่านในฐานข้อมูล TrackStudio ในเครื่อง หากต้องการปิดใช้งานการอนุญาตในตัว ให้ลบออก com.trackstudio.app.adapter.auth.SimpleAuthAdapterจากลูกโซ่ในไฟล์ trackstudio.adapter คุณสมบัติ.

บทความนี้เขียนขึ้นเพื่อคนหนึ่ง นิตยสารคอมพิวเตอร์ค่อนข้างนานมาแล้ว ตั้งแต่นั้นมาพวกเขาไม่ได้ติดต่อฉันเกี่ยวกับชะตากรรมในอนาคต ฉันจึงสรุปว่ามันไม่มีประโยชน์และกำลังโพสต์ต่อสาธารณะ

นี่ไม่ใช่แนวทางในการติดตั้งและใช้งาน LDAP เป็นเพียงภาพรวมสำหรับคนที่ยังไม่รู้ว่านี่คือสัตว์ชนิดไหน...

ความคิดเห็นยินดีต้อนรับ

บริการไดเรกทอรี พวกเขาคืออะไรและมีไว้เพื่ออะไร?

และไม่ว่าผู้คนจะพูดอะไรที่นั่น -
ฉันจะมีชีวิตอยู่ ฉันจะผ่านดวงดาว
ฉันจะนับพวกมันจากแค็ตตาล็อก
ฉันจะอ่านซ้ำจากหนังสือตอนกลางคืน

เครือข่ายกำลังเติบโต เครือข่ายท้องถิ่นก็ไม่มีข้อยกเว้น บ่อยครั้งที่เครือข่ายที่เชื่อมต่อคอมพิวเตอร์สามเครื่องเมื่อวานนี้ได้เติบโตขึ้น สมบูรณ์ และรกไปด้วยทรัพยากร จะไม่หลงทางได้อย่างไร? จะไม่สับสนกับการเข้าสู่ระบบและรหัสผ่านได้อย่างไร? จะค้นหาข้อมูลที่คุณต้องการได้อย่างรวดเร็วได้อย่างไร? ไม่ช้าก็เร็วคำถามเหล่านี้ก็เกิดขึ้นต่อหน้าผู้ดูแลระบบเกือบทุกคน

หลายๆ คนใช้สคริปต์ที่เขียนเอง เหล่านี้เป็นซามูไรที่แท้จริง ความตั้งใจของพวกเขาก็เหมือนกับดาบคาทาน่า และเวลาที่ใช้ไปนั้นสามารถชดเชยได้อย่างง่ายดายด้วยประสบการณ์ที่ได้รับ อื่นๆ ที่มีความซับซ้อนในกระบวนการโอนเคสและตำแหน่งในกรณีที่มีการเปลี่ยนแปลงงานหรือลาพักร้อน ให้ใช้โซลูชันที่ได้มาตรฐาน ชื่อของโซลูชันเหล่านี้คือบริการไดเร็กทอรี

ใน รีวิวนี้ฉันจะแนะนำคุณเกี่ยวกับสถานการณ์โดยย่อ บริการไดเร็กทอรีคืออะไร?

สั้นมากและเรียบง่ายมาก - เป็นฐานข้อมูลประเภทหนึ่งที่เก็บข้อมูลเกี่ยวกับผู้ใช้โหนดและออบเจ็กต์เครือข่าย จุดประสงค์ของการสร้างคือเพื่อทำให้การบริหารง่ายขึ้น

คำถามเกิดขึ้น: ทำไมไม่ใช้ฐานข้อมูล? ความจริงก็คือมีความแตกต่างอย่างมีนัยสำคัญระหว่างบริการไดเร็กทอรีและฐานข้อมูลเชิงสัมพันธ์:

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

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

ทุกอย่างเริ่มต้นง่ายๆ เครือข่ายมีขนาดเล็กและคอมพิวเตอร์มีขนาดใหญ่ และมีไม่มากนัก ในช่วงเวลาแห่งการลืมเลือนไปครึ่งหนึ่งหรือเกือบจะเป็นมหากาพย์ เราก็ผ่านไปได้ การคัดลอกอย่างง่ายไฟล์การกำหนดค่าจากคอมพิวเตอร์เครื่องหนึ่งไปยังอีกเครื่องหนึ่ง

แต่เวลาผ่านไป เครือข่ายเติบโตและเติบโตเต็มที่ เป็นที่ชัดเจนมากขึ้นว่าจำเป็นต้องมีวิธีแก้ปัญหาบางอย่าง สิ่งที่จะทำให้ชีวิตที่ยากลำบากของผู้ดูแลระบบและเครือข่ายง่ายขึ้น

หนึ่งในการใช้บริการประเภทนี้ครั้งแรกคือการพัฒนาของบริษัท Sun Microsystems ซึ่งเดิมเรียกว่าสมุดหน้าเหลือง ต่อจากนั้นเนื่องจากความตึงเครียดทางกฎหมาย ชื่อจึงถูกแทนที่ด้วย Network Information Service (NIS) ซึ่งยังคงเป็นที่รู้จักอย่างกว้างขวาง (ในวงแคบ)

การพัฒนามีพื้นฐานอยู่บนแนวคิดง่ายๆ นั่นคือ คอมพิวเตอร์ที่ทำงานบนเครือข่ายมีไฟล์การกำหนดค่าเดียวกันหลายไฟล์ ดังนั้นทำไมไม่ตรวจสอบให้แน่ใจว่าคอมพิวเตอร์นำไฟล์เหล่านี้มาจากเซิร์ฟเวอร์เดียว สิ่งนี้ไม่เพียงช่วยประหยัดพื้นที่ดิสก์ (NIS ได้รับการพัฒนามานานแล้วและปัจจัยนี้ค่อนข้างเกี่ยวข้อง) แต่ยังประหยัดเวลาในการซิงโครไนซ์ไฟล์เหล่านี้ด้วย

เป็นการยากที่จะเรียกมันว่าบริการไดเร็กทอรี แต่ได้ดำเนินการขั้นตอนแรกในทิศทางที่ถูกต้องแล้ว

เนื่องจากแนวคิดนี้เป็นที่ต้องการ CCITT และ ISO จึงเดินหน้าต่อไปและพัฒนาชุดมาตรฐาน X.500 ซึ่งรวมถึงโปรโตคอลต่อไปนี้: DAP (Directory โปรโตคอลการเข้าถึง), DSP (Directory System Protocol), DISP (Directory Information Shadowing Protocol) และ DOP (Directory Operational Bindings Management Protocol) อย่างไรก็ตาม ภายหลังพบว่าโปรโตคอลเหล่านี้มีความซับซ้อนมากเกินไป และได้มีการดำเนินการเพื่อพัฒนาโปรโตคอลทดแทน กลายเป็นโปรโตคอล LDAP (Lightweight Directory Access Protocol) ซึ่งทำหน้าที่เป็นพื้นฐานสำหรับโซลูชันที่ประสบความสำเร็จมากมาย

ประวัติความเป็นมาของผลิตภัณฑ์ที่ใช้ LDAP ที่มีชื่อเสียงที่สุดย้อนกลับไปในปี 1995 เมื่อพนักงานของมหาวิทยาลัยมิชิแกนเขียนเซิร์ฟเวอร์ LDAP เครื่องแรก - slapd ในปี 1996 Netscape ได้จ้างพวกเขา ในปี 1999 AOL กลายเป็นเจ้าของ Netscape เพื่อสานต่อการทำงานเกี่ยวกับผลิตภัณฑ์เซิร์ฟเวอร์ ได้มีการสรุปความเป็นพันธมิตรเชิงกลยุทธ์กับ Sun พวกเขาเรียกมันว่า iPlanet Alliance ตั้งแต่ปี 1999 ถึง 2001 ทีมงาน Netscape Directory Server ทำงานร่วมกับทีมงาน Sun Directory Server และต่อมากับผู้พัฒนา Innosoft Directory Server (IDDS) งานได้ดำเนินการทั้งบน Directory Server และในโครงการที่เกี่ยวข้อง เช่น Meta Directory และ Directory Access Router ในเดือนตุลาคม พ.ศ. 2544 iPlanet Alliance ยุบวง และสมาชิก Sun และ Netscape เริ่มพัฒนาผลิตภัณฑ์ของตนอย่างเป็นอิสระ ตั้งแต่ปี 2544 ถึง 2547 นักพัฒนา Netscape Directory Server ได้ทำงานอย่างหนักในโครงการนี้ ในเดือนธันวาคม พ.ศ. 2547 Netscape Directory Server ได้กลายเป็นทรัพย์สินของบริษัท หมวกแดง.

ดังนั้น เพื่อไม่ให้เรื่องราวนี้เกิดขึ้น เรามาดูกันว่าบริการไดเร็กทอรีใดบ้างที่พร้อมใช้งาน และเหตุใดจึงดี

NIS (แม้ว่าจะพูดอย่างเคร่งครัด แต่ก็ไม่ใช่บริการไดเร็กทอรี)

การพัฒนาโดย Sun Microsystems นี้มีความคงทนมากและยังคงใช้อยู่ในปัจจุบัน ข้อดีของมันคือความเรียบง่ายของแนวคิดและการนำไปปฏิบัติ ข้อเสีย - สามารถใช้ได้เฉพาะกับระบบปฏิบัติการที่เข้ากันได้กับ UNIX ที่มีไฟล์การกำหนดค่าที่ตรงกันเท่านั้น ร่วมแสดงความเคารพต่อเธอและก้าวไปสู่ผลิตภัณฑ์ LDAP ที่ครบครัน ในบทความนี้ฉันจะไม่อยู่ต่อไป รายละเอียดทางเทคนิคฉันจะบอกว่าฟังก์ชันพื้นฐานแตกต่างกันเล็กน้อย ความแตกต่างเริ่มต้นที่ระดับเอกสารและซอฟต์แวร์ประยุกต์ที่อำนวยความสะดวกในการบริหารจัดการ

เรามาเริ่มด้วยแบบเปิดและแบบฟรีกันดีกว่า มีไม่มาก จริงๆแล้วมีแค่สองคนเท่านั้น

เซิร์ฟเวอร์ไดเรกทอรี Red Hat และเซิร์ฟเวอร์ไดเรกทอรี Fedora

เดิม Red Hat Directory Server ถูกซื้อจาก Netscape Security Solutions ในฐานะผลิตภัณฑ์เชิงพาณิชย์สำหรับ Red Hat Enterprise Linux และขณะนี้ได้เปิดตัวโดย Red Hat เองภายใต้ชื่อ Red Hat Directory Server ตามนโยบาย Red Hat ยังออกเวอร์ชันสำหรับ Fedora Core อีกด้วย ชื่อของมันคือ Fedora Directory Server Red Hat Directory Server รัน Red Hat Enterprise Linux (x86, เวอร์ชัน 3 และ 4), Solaris 9 (SPARC ทั้ง 32 บิตและ 64 บิต), HP-UX 11i สำหรับ HP-9000 และเซิร์ฟเวอร์ HP Integrity บรรทัด 64 บิต . Fedora Directory Server นั้นพิถีพิถันน้อยกว่าและตกลงที่จะทำงานทั้งภายใต้ Fedora Core (x86, เวอร์ชัน 3 และ 4) และ Red Hat Enterprise Linux และภายใต้อื่นๆ เวอร์ชันลินุกซ์- gentoo, เดเบียน ฯลฯ รองรับ Solaris, Windows 2000 และ HP/UX 11i (pa-risc) บทสรุป: ทางเลือกที่ดีสำหรับการแจกแจงตาม RedHat ได้รับการบันทึกไว้อย่างดีว่าเปรียบเทียบได้ดีกับ OpenLDAP อย่างไร รหัสของโครงการเหล่านี้ส่วนใหญ่จะเหมือนกัน (เนื่องจากมีบรรพบุรุษร่วมกัน)

OpenLDAP

OpenLDAP เป็นการพัฒนาเพิ่มเติมของ slapd ดั้งเดิม แพร่หลาย. ใช้บนหลายแพลตฟอร์ม เช่น Linux, FreeBSD, Windows และ MacOS X เอกสารประกอบบนเว็บไซต์เป็นแบบเรียบง่าย อย่างไรก็ตามผู้มีปัญญานั่งและ คำแนะนำทีละขั้นตอนมีมากมายในเน็ต หากคุณรู้สึกไม่สบายใจที่จะใช้ผลิตภัณฑ์ RedHat ด้วยเหตุผลบางประการ OpenLDAP ก็เป็นตัวเลือกที่ยอดเยี่ยมและผ่านการทดสอบตามเวลา ฟังก์ชันการทำงานของทั้งสองโครงการเกือบจะเหมือนกัน

นี่คือจุดเริ่มต้นของเซิร์ฟเวอร์ LDAP แบบเปิดและฟรีและโซลูชันระดับองค์กร น่าเสียดายที่รายละเอียดของที่มาและฟังก์ชันการทำงานของพวกเขาถูกซ่อนไว้เบื้องหลังข่าวประชาสัมพันธ์ด้านการตลาด ดังนั้นผมจะสรุปสั้นๆ

ไดเร็กทอรีอิเล็กทรอนิกส์ของโนเวลล์

ก่อนอื่นขอพูดถึงนโยบายการออกใบอนุญาตก่อน เนื่องจากค่อนข้างน่าสนใจ ประการแรก ผลิตภัณฑ์ทั้งหมดฟรีสำหรับมหาวิทยาลัย ประการที่สอง คุณสามารถติดตั้งผลิตภัณฑ์นี้และใช้งานได้โดยไม่เสียค่าใช้จ่ายใดๆ (ใบอนุญาตรายปีสำหรับผู้ใช้ 100,000 ราย ไม่มีการสนับสนุนทางเทคนิค คุณสามารถรับได้โดยขอรหัสทดลองใช้งานปีละครั้ง) ประการที่สามคุณสามารถซื้อได้ ราคา - $2 ต่อใบอนุญาตผู้ใช้โดยไม่มีการจำกัดเวลา ทำงานภายใต้ดังต่อไปนี้ ระบบปฏิบัติการ: Novell Netware, Windows (สาขา NT), Linux (SUSE Enterprise หรือ RedHat), Solaris, AIX, HP-UX สรุป: โซลูชันแบบครบวงจร - โปรแกรมที่จำเป็นทั้งหมดจะถูกส่งทันที การติดตั้งและการกำหนดค่าทำได้อย่างสะดวกที่สุด ราคาต่ำ. เอกสารที่ยอดเยี่ยม สำหรับผู้ใช้ที่ลงทะเบียน - เทคโนโลยี สนับสนุน. ข้ามแพลตฟอร์ม ลบ - แหล่งปิด

ไมโครซอฟต์ ActiveDirectory

รวมไว้ใน วินโดวส์เซิร์ฟเวอร์ 200x. โซลูชั่นที่สมบูรณ์แบบสำหรับเครือข่าย MS หากคุณวางแผนที่จะใช้กลุ่มผลิตภัณฑ์จาก MS เท่านั้น ก็คุ้มค่าที่จะพิจารณา หากคุณใช้เซิร์ฟเวอร์อื่นนอกเหนือจาก Windows 200x ฉันขอแนะนำให้ใส่ใจกับผลิตภัณฑ์ข้างต้นอย่างใกล้ชิด สรุป: บูรณาการเข้ากับระบบได้อย่างยอดเยี่ยม เอกสารคุณภาพสูง ข้อเสียคือราคาค่อนข้างสูง

เซิร์ฟเวอร์ไดเรกทอรีระบบ Sun Java

ในช่วงต้นทศวรรษ 2000 Sun ได้รวมกิจการกับ iPlanet และใช้การพัฒนา (โดยเฉพาะ iPlanet Directory Server) ได้สร้างผลิตภัณฑ์ของตัวเอง - Sun ONE ซึ่งต่อมาเปลี่ยนชื่อเป็น Sun Java System Directory Server นี่ไม่ใช่ผลิตภัณฑ์อิสระ แต่เป็นเพียงส่วนหนึ่งของ Java Enterprise System ความต้องการของระบบ: Solaris 10, Solaris 9, Solaris 8 (SPARC เท่านั้น), Red Hat Enterprise Linux 2.1 และ 3.1, HP-UX 11i, Microsoft Windows 2000, XP (Developer), 2003 ไม่จำหน่ายแยกต่างหากจาก Java Enterprise System บทสรุป - หากคุณตัดสินใจใช้โซลูชันที่ครอบคลุมจาก Sun คุณจะไม่มีปัญหาพิเศษใด ๆ อย่างชัดเจน วิศวกรของ Sun จะช่วยคุณติดตั้งและกำหนดค่าให้เหมาะกับความต้องการของคุณ เพื่อเงินแน่นอน

เซิร์ฟเวอร์ไดเร็กทอรี IBM Tivoli

โซลูชัน LDAP จาก IBM ทำงานภายใต้ระบบปฏิบัติการต่อไปนี้: AIX, Solaris, Microsoft Windows 2000, HP-UX รวมถึง Linux สำหรับ Intel และ IBM eServer iSeries, pSeries และ zSeries ราคาเริ่มต้นที่ 10,000 ดอลลาร์ วิธีแก้ปัญหานี้ไม่ได้มีไว้สำหรับทุกคนอย่างชัดเจน อย่างไรก็ตาม เป็นที่น่าสังเกตว่าทุกคนสามารถเข้าถึงเอกสารนี้ได้ ฉันขอแนะนำเป็นอย่างยิ่งให้กับทุกคนที่สนใจใน LDAP หนังสือจากชุด IBM Red Books การทำความเข้าใจ LDAP - การออกแบบและการนำไปใช้ แม้ว่าเนื้อหาจะครอบคลุม IBM Tivoli Directory Server เป็นหลัก แต่ก็มีเนื้อหาทางทฤษฎีคุณภาพสูงมากมายเกี่ยวกับ LDAP และ วางแผนแค็ตตาล็อกของคุณให้ดียิ่งขึ้นได้อย่างไร

นี่เป็นการสรุปเรื่องราวที่ยาวเล็กน้อยของฉัน ฉันหวังว่าฉันจะสามารถสนใจคุณได้ ในที่สุดฉันจะพูดต่อไปนี้ LDAP คือก้าวต่อไปนอกเหนือจากการนำ DHCP ไปใช้ ความสะดวกสบายที่ได้รับจากการใช้งานมีมากกว่าค่าแรงในการแนะนำ หากมีคอมพิวเตอร์มากกว่า 10 เครื่องบนเครือข่ายท้องถิ่นของคุณ ให้คิดถึง LDAP

ฐานข้อมูลไดเรกทอรี - DIB) ข้อมูลประกอบด้วยชื่อของออบเจ็กต์ ตลอดจนคุณลักษณะต่างๆ ที่แสดงลักษณะของออบเจ็กต์นั้น คำแนะนำเหล่านี้เรียกว่ามาตรฐาน X.500

เพื่อเข้าถึงอ็อบเจ็กต์ในฐานข้อมูลแบบกระจายนี้ Directory Access Protocol (DAP) ได้รับการพัฒนา

แอลดีเอพี ( โปรโตคอลการเข้าถึงไดเรกทอรีแบบ Lightweight) มอบความสามารถส่วนใหญ่ของ DAP โดยมีต้นทุนการดำเนินการที่ต่ำกว่ามาก ตัวอย่างเช่น การดำเนินการที่ซ้ำซ้อนและไม่ค่อยได้ใช้ได้ถูกลบออกไป LDAP ต่างจาก X.500 ตรงที่ใช้สแต็ก TCP ไม่ใช่ OSI

อย่างไรก็ตาม ไม่มีการโต้ตอบแบบหนึ่งต่อหนึ่งระหว่างการทำงานของโปรโตคอล LDAP และการทำงานของโปรโตคอล X.500 DAP

LDAP เป็นโปรโตคอลที่ใช้ในการเข้าถึงข้อมูลที่จัดเก็บไว้ในเซิร์ฟเวอร์ที่กระจายผ่านเครือข่าย

ข้อมูลนี้เป็นข้อมูลที่จัดเก็บไว้ในแอตทริบิวต์ สันนิษฐานว่ามีการอ่านข้อมูลดังกล่าวบ่อยกว่าการแก้ไข LDAP ขึ้นอยู่กับโมเดลการสื่อสารไคลเอ็นต์-เซิร์ฟเวอร์

รูปแบบทั่วไปของโปรโตคอลนี้คือเซิร์ฟเวอร์ดำเนินการตามที่ลูกค้าต้องการ ไคลเอนต์ส่งคำขอที่อธิบายการดำเนินการที่เซิร์ฟเวอร์จะดำเนินการ เซิร์ฟเวอร์ดำเนินการที่จำเป็นในไดเรกทอรี หลังจากเสร็จสิ้นการดำเนินการหรือการดำเนินการหลายอย่าง เซิร์ฟเวอร์จะตอบกลับไปยังไคลเอนต์ที่มีผลลัพธ์หรือรหัสข้อผิดพลาด

โปรดทราบว่าแม้ว่าเซิร์ฟเวอร์จำเป็นต้องส่งคืนการตอบกลับเมื่อใดก็ตามที่มีการระบุการตอบกลับดังกล่าวในโปรโตคอล แต่ก็ไม่มีข้อกำหนดที่ไคลเอ็นต์หรือเซิร์ฟเวอร์จะต้องทำงานพร้อมกัน คำขอและการตอบกลับสำหรับการดำเนินการหลายอย่างสามารถส่งระหว่างไคลเอนต์และเซิร์ฟเวอร์ในลำดับใดก็ได้ แต่ไคลเอนต์จะต้องได้รับการตอบกลับสำหรับคำขอแต่ละรายการ

ข้อมูลบนเซิร์ฟเวอร์ LDAP คือชุดของบันทึกที่มีชุดคุณลักษณะและจัดกลุ่มเป็นโครงสร้างแบบลำดับชั้นแบบต้นไม้

บันทึกจะถูกระบุด้วยชื่อที่ไม่ซ้ำกันทั่วโลก (ชื่อเฉพาะ - DN) - คล้ายกับชื่อโดเมนในโครงสร้าง DNS

แคตตาล็อกเป็นฐานข้อมูลเฉพาะที่สามารถนำไปใช้ในชีวิตประจำวัน - สมุดโทรศัพท์, คู่มือโปรแกรม ฯลฯ สันนิษฐานว่าข้อมูลแคตตาล็อกค่อนข้างคงที่ ตัวอย่างคลาสสิกของฐานข้อมูลพิเศษดังกล่าวคือ บริการดีเอ็นเอส.

ประโยชน์ของแอลดีเอพี

สาเหตุหลักที่ทำให้ LDAP ได้รับความนิยมเพิ่มขึ้นเนื่องมาจากข้อเท็จจริงที่ว่า:

  • LDAP มีรูปแบบการจัดเก็บข้อมูลมาตรฐานสำหรับข้อมูล ซึ่งแตกต่างจากฐานข้อมูลเชิงสัมพันธ์ ซึ่งแต่ละรูปแบบมีรูปแบบการจัดเก็บข้อมูลของตัวเองที่กำหนดไว้ในแง่ของตารางและคอลัมน์ และความสัมพันธ์ระหว่างตาราง ดังนั้น LDAP ไม่มีการจัดการต่อไดเรกทอรีและต่อแอปพลิเคชัน จึงไม่เรียกว่า "ปัญหาไดเรกทอรี N+1" เซิร์ฟเวอร์ LDAP ทั้งหมดใช้รูปแบบการจัดเก็บข้อมูลเดียว วิธีหนึ่งการตั้งชื่อวัตถุที่เก็บไว้และโปรโตคอลการเข้าถึงแบบครบวงจร
  • LDAP ช่วยให้คุณค้นหาข้อมูลที่จำเป็นได้อย่างรวดเร็ว เนื่องจากเน้นไปที่การอ่านและค้นหาข้อมูลมากกว่าการแก้ไข
  • LDAP ไม่จำเป็นต้องจำกัดอยู่เพียงเซิร์ฟเวอร์เดียว คุณสามารถจัดระเบียบระบบแบบกระจายจากหลายเซิร์ฟเวอร์ได้ คุณสามารถสร้างการเชื่อมโยงระหว่าง เซิร์ฟเวอร์ต่างๆ LDAP ซึ่งให้ความสามารถในการค้นหาเซิร์ฟเวอร์ LDAP หลายเครื่องพร้อมกัน
  • ทั้งโปรโตคอล LDAP และโครงสร้างไดเรกทอรี LDAP ได้รับการจัดระเบียบตามมาตรฐาน เพื่อให้สามารถใช้งาน LDAP ของผู้จำหน่ายที่แตกต่างกันได้อย่างสม่ำเสมอ

การเปรียบเทียบ LDAP และฐานข้อมูล

ลองเปรียบเทียบสองวิธีที่ได้รับความนิยมมากที่สุดในการจัดเก็บข้อมูลในปัจจุบัน ฐานข้อมูลเชิงสัมพันธ์ และเซิร์ฟเวอร์ LDAP ตามคุณลักษณะต่อไปนี้:

  • อัตราส่วนการอ่าน-เขียน– LDAP ต่างจากฐานข้อมูลเชิงสัมพันธ์ตรงที่ได้รับการปรับให้เหมาะสมในการอ่าน
  • ความสามารถในการขยาย– สคีมา LDAP ง่ายต่อการเปลี่ยนแปลงระหว่างการดำเนินการมากกว่าสคีมาฐานข้อมูล
  • การกระจาย– ข้อมูล LDAP สามารถอยู่บนเซิร์ฟเวอร์หลายเครื่อง ซึ่งสามารถค้นหาได้โดยใช้คำสั่งเดียว ด้วยเหตุนี้ คุณสามารถสร้างการกำหนดค่าเซิร์ฟเวอร์ LDAP ในตำแหน่งที่เหมาะสมที่สุดตามตำแหน่งที่ต้องการข้อมูล ขณะเดียวกันก็ตรวจสอบให้แน่ใจว่าสามารถค้นหาข้อมูลทั้งหมดที่จัดเก็บไว้ในเซิร์ฟเวอร์ LDAP ทั้งหมดได้ สิ่งนี้ประสบความสำเร็จมากขึ้น ระดับสูงการกระจายเมื่อเทียบกับฐานข้อมูลเชิงสัมพันธ์
  • การจำลองแบบ– ข้อมูล LDAP สามารถจัดเก็บไว้ในเซิร์ฟเวอร์หลายเครื่อง และสามารถใช้วิธีการต่างๆ ในการซิงโครไนซ์ข้อมูลได้
  • การประยุกต์ใช้ข้อมูล– LDAP ได้รับการออกแบบมาเพื่อ การใช้งานที่มีประสิทธิภาพข้อมูลที่จัดเก็บไว้ในแค็ตตาล็อก การใช้งานที่แตกต่างกันฐานข้อมูลได้รับการพัฒนาสำหรับแอปพลิเคชันเดียว
  • ความซับซ้อนของความสัมพันธ์ระหว่างวัตถุ– ออบเจ็กต์ฐานข้อมูลมีความสัมพันธ์ที่ซับซ้อนมากกว่าบันทึก LDAP
  • การทำธุรกรรม– ในธุรกรรม LDAP นั้นง่ายกว่า โดยปกติแล้วหนึ่งระเบียนจะมีการเปลี่ยนแปลง ธุรกรรมในฐานข้อมูลมีความซับซ้อนมากขึ้น
  • ประเภทของข้อมูลที่จัดเก็บ– LDAP เก็บข้อมูลไว้ในแอตทริบิวต์
  • วิธีการตั้งชื่อ– LDAP เป็นโครงสร้างข้อมูลแบบลำดับชั้น ชื่อของอ็อบเจ็กต์คือพาธไปยังอ็อบเจ็กต์นั้นในแผนผังลำดับชั้น คล้ายกับพาธของไฟล์ในระบบไฟล์ปกติ
  • แบบแผน– สกีมาฐานข้อมูลเชิงสัมพันธ์ถูกกำหนดโดยสมบูรณ์โดยผู้พัฒนาฐานข้อมูลที่เกี่ยวข้อง LDAP มีสกีมามาตรฐาน รวมถึงสกีมาหลักที่ใช้ร่วมกันกับไดเร็กทอรีใด ๆ สิ่งนี้ทำให้สามารถทำงานร่วมกันได้มากขึ้นเมื่อเปรียบเทียบกับฐานข้อมูล
  • มาตรฐาน– การใช้แผนการจัดเก็บข้อมูลมาตรฐานและโปรโตคอลการเข้าถึงมาตรฐานเป็นข้อได้เปรียบของ LDAP เหนือฐานข้อมูล เนื่องจากในกรณีนี้ ไคลเอนต์ LDAP สามารถสื่อสารกับเซิร์ฟเวอร์ LDAP ใดก็ได้ และไคลเอนต์ฐานข้อมูลสามารถโต้ตอบกับฐานข้อมูลที่ได้รับการออกแบบเท่านั้น
  • ความเป็นไปได้ของการย้อนกลับ การดำเนินงานที่ไม่ประสบความสำเร็จ – ฐานข้อมูลเชิงสัมพันธ์มีความสามารถในการย้อนกลับที่ยืดหยุ่นมากกว่า ดังนั้นจึงเหมาะสำหรับการแก้ไขข้อมูลมากกว่า LDAP สำหรับออบเจ็กต์ไดนามิก ความสามารถของ LDAP อาจไม่เพียงพอ

หลักการปรับใช้เซิร์ฟเวอร์ LDAP

เมื่อปรับใช้เซิร์ฟเวอร์ LDAP คุณต้องดำเนินการงานต่อไปนี้:

  • ตัดสินใจว่าควรเก็บสิ่งใดไว้ในไดเร็กทอรี จำเป็นต้องเข้าใจอย่างชัดเจนว่าแอปพลิเคชันใดจะทำงานกับข้อมูลได้
  • กำหนดโครงสร้างข้อมูลในแค็ตตาล็อกและสร้างความสัมพันธ์
  • กำหนดชุด วงจรที่จำเป็นแคตตาล็อกที่ปรับให้เหมาะกับข้อกำหนดการใช้งาน
  • กำหนดเนมสเปซ
  • กำหนดโทโพโลยีของตำแหน่งเซิร์ฟเวอร์
  • กำหนดการจำลองที่จำเป็น เพื่อให้มั่นใจว่าข้อมูลจะพร้อมใช้งานทุกที่ที่จำเป็น
  • กำหนดระดับความปลอดภัยที่เหมาะสมโดยคำนึงถึงข้อกำหนดด้านความปลอดภัยเฉพาะ


บทความที่เกี่ยวข้อง