การยืนยันตัวตน LDAP ของ OpenVPN ทำงาน แต่การตรวจสอบกลุ่มล้มเหลว: ควรดูตรงไหน

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

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

มองการปฏิเสธว่าเป็นคำตอบเรื่องการอนุญาต

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

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

ตัดสินว่าสมาชิกภาพอยู่ในตัวกรองหรือในบล็อกกลุ่ม

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

<Authorization>
    BaseDN       "OU=People,DC=example,DC=org"
    SearchFilter "(&(sAMAccountName=%u)(memberOf=CN=VPN Access,OU=Groups,DC=example,DC=org))"
    RequireGroup false
</Authorization>

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

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

<Authorization>
    BaseDN       "OU=People,DC=example,DC=org"
    SearchFilter "(sAMAccountName=%u)"
    RequireGroup true
    Group        "CN=VPN Access,OU=Groups,DC=example,DC=org"
</Authorization>

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

เลือกปลายทางที่มีออบเจ็กต์กลุ่ม

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

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

เก็บสถานะบัญชีและขอบเขตการค้นหาไว้ในฟิลด์ของตัวเอง

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

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

พิสูจน์ผลด้วยสามบัญชี

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

อ่านสามคำตอบเดียวกันจากไดเรกทอรีโดยตรงก่อนโทษปลั๊กอิน คำค้นหาแรกแสดงแอตทริบิวต์กลุ่มที่ตัวกรองพึ่งพา และคำที่สองแสดงค่าการควบคุมบัญชี แทนที่ด้วย DN ฐาน บัญชี และปลายทางของคุณเอง:

ldapsearch -H ldap://dc01.example.org:3268 -x -D "[email protected]" -W -b "DC=example,DC=org" "(sAMAccountName=alice)" memberOf
ldapsearch -H ldap://dc01.example.org:3268 -x -D "[email protected]" -W -b "DC=example,DC=org" "(sAMAccountName=bob)" userAccountControl

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

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