OpenVPN username-as-common-name: ทำไมการตรวจสอบ CN ของคุณจึงว่างเปล่า
สคริปต์ client-connect ที่เปรียบเทียบ common_name กับ username อาจเปรียบเทียบชื่อกับตัวมันเอง ผูกใบรับรองกับบัญชีก่อนที่การแทนที่จะทำงาน
คุณเพิ่มสคริปต์ client-connect ที่ปฏิเสธทุกการเชื่อมต่อซึ่ง common_name แตกต่างจาก username และดูเหมือนเป็นการผูกใบรับรองกับบัญชี บนเซิร์ฟเวอร์ที่รัน username-as-common-name การเปรียบเทียบนั้นได้สูญเสียความหมายไปแล้วเมื่อสคริปต์ทำงาน ค่าทั้งสองเป็นสตริงเดียวกัน การทดสอบจึงผ่านสำหรับใบรับรองที่ออกให้กับคนอื่นโดยสิ้นเชิง
การตรวจสอบไม่ได้ผิดเพราะสคริปต์เขียนไม่ดี แต่มันผิดเพราะค่าที่อ่านถูกแทนที่ไปแล้วก่อนหน้านี้ในการเชื่อมต่อเดียวกัน
สิ่งที่การเปรียบเทียบดูเหมือนจะพิสูจน์
การพิสูจน์ตัวตนด้วยใบรับรองและการพิสูจน์ตัวตนด้วยรหัสผ่านเป็นหลักฐานแยกกัน และเซิร์ฟเวอร์สามารถเรียกทั้งสองอย่างได้โดยไม่ต้องเรียกร้องว่าเป็นของคนเดียวกัน ช่องว่างนั้นมีจริง ใบรับรองอุปกรณ์ที่ถูกต้องบวกบัญชีใดๆ ที่ถูกต้องเป็นการกล่าวอ้างที่ต่างจากใบรับรองนั้นบวกบัญชีหนึ่งบัญชีที่ระบุชื่อ สคริปต์ที่เปรียบเทียบ common_name กับ username อ่านได้เหมือนข้อต่อที่หายไประหว่างสองสิ่งนั้น มันจะเป็นเช่นนั้นถ้า common_name ยังหมายถึงสิ่งที่ใบรับรองระบุ
ว่าเป็นเช่นนั้นหรือไม่ขึ้นอยู่กับตัวเลือกเซิร์ฟเวอร์หนึ่งตัว และตัวเลือกนั้นมักถูกเปิดด้วยเหตุผลที่ไม่เกี่ยวข้อง เช่น ทำให้ตั้งชื่อไฟล์กำหนดค่าของผู้ใช้แต่ละคนได้ง่ายขึ้น
username-as-common-name ทำอะไรกับชื่อ
เมื่อเปิด username-as-common-name OpenVPN จะแทนชื่อสามัญของใบรับรองด้วยชื่อผู้ใช้ที่ผ่านการพิสูจน์ตัวตนหลังจากตรวจสอบชื่อผู้ใช้และรหัสผ่านแล้ว ฮุกตรวจสอบที่ทำงานระหว่างการตรวจสอบนั้นยังคงได้รับชื่อสามัญของใบรับรอง เพราะการแทนที่ยังไม่เกิดขึ้น ทุกสิ่งหลังจากนั้นรวมถึง client-connect จะเห็นชื่อผู้ใช้ ดังนั้นการเรียกกลับภายหลังจึงได้รับตัวตนหนึ่งตัวสองครั้งและไม่สามารถเปรียบเทียบกับใบรับรองที่นำเสนอได้
| Stage | What common_name holds |
|---|---|
| Username and password verification hook | The certificate common name, for example bob-device |
| After the replacement | The authenticated account, alice |
| client-connect callback | The account again, alice |
ตามการเชื่อมต่อตัวอย่างหนึ่งรายการ ใบรับรองที่ออกให้ bob-device การเข้าสู่ระบบไดเรกทอรีสำเร็จในชื่อ alice และเปิดตัวเลือกไว้ ระยะตรวจสอบยังคงเห็นสตริงที่แตกต่างกันสองค่า ระยะเชื่อมต่อเห็น alice และ alice
ตัวอย่างนั้นแสดงว่าทำไมการเปรียบเทียบจึงว่างเปล่า มันไม่ได้แสดงว่าการเชื่อมต่อจะได้รับการยอมรับเป็นอย่างอื่น เพราะการตรวจสอบใบรับรองและการตรวจสอบรหัสผ่านยังคงทำงานด้วยตัวเอง
วางการผูกไว้ในขั้นตอนที่ทั้งสองตัวตนยังมีอยู่
กฎต้องถูกบังคับใช้ในขั้นตอนที่เห็นตัวตนของใบรับรองและบัญชีพร้อมกัน ซึ่งในทางปฏิบัติหมายถึงฮุกตรวจสอบชื่อผู้ใช้และรหัสผ่านหรือปลั๊กอินที่โหลดที่นั่น ปลั๊กอินที่รองรับซึ่งตรวจสอบรหัสผ่านอยู่แล้วมักเป็นที่ที่ถูกต้องในการเพิ่มกฎการจับคู่ เพราะการแทนที่ด้วยการเปรียบเทียบชื่อจะลบการตรวจสอบรหัสผ่านออกทั้งหมด
กำหนดการแมปก่อนเขียนโค้ด เพราะความเท่าเทียมไม่ค่อยเป็นนโยบายจริง ใบรับรองมักระบุอุปกรณ์ในขณะที่การเข้าสู่ระบบระบุบุคคล และอุปกรณ์หนึ่งเครื่องสามารถให้บริการหลายคนได้อย่างชอบธรรม เก็บความสัมพันธ์ในรูปแบบที่คุณควบคุมการออก และตัดสินใจว่าเกิดอะไรขึ้นเมื่อเปลี่ยนชื่อ เมื่อออกใหม่ และกับชื่อที่ระบุโดเมน การแปลงเป็นตัวพิมพ์เล็กหรือตัดคำนำหน้าโดเมนออกโดยไม่เข้าใจไดเรกทอรีอาจรวมสองบัญชีที่ควรแยกจากกัน
อย่าลืมว่าตัวเลือกยังเปลี่ยนว่าการกำหนดค่าต่อไคลเอนต์ใดมีผล เพราะ client-config-dir ถูกกำหนดด้วยชื่อสามัญ
ทดสอบการจับคู่ด้วยข้อมูลรับรองที่ถูกต้องสองชุด
เริ่มจากคู่ที่โยบายของคุณอนุญาตและยืนยันว่ามันเชื่อมต่อได้ จากนั้นนำเสนอใบรับรองที่ถูกต้องเดียวกันกับบัญชีอื่นที่ยังถูกต้อง ความพยายามนั้นต้องล้มเหลว และต้องล้มเหลวเพราะกฎการจับคู่ไม่ใช่เพราะพิมพ์รหัสผ่านผิด รหัสผ่านผิดพิสูจน์ว่าการตรวจสอบรหัสผ่านทำงานและไม่ได้บอกอะไรเกี่ยวกับกฎระหว่างใบรับรองกับบัญชี
ตรวจสอบเส้นทางที่ไม่มีใบรับรองและใบรับรองไม่ถูกต้องด้วย และยืนยันว่าเซิร์ฟเวอร์ใช้ตัวตนใดสำหรับการตั้งค่าต่อไคลเอนต์ หากวิธีเดียวที่ทำให้การเปรียบเทียบทำงานคือปิด username-as-common-name ให้ประเมินต้นทุนของการเปลี่ยนแปลงนั้นก่อน เพราะมันย้ายการค้นหาการกำหนดค่าของทุกไคลเอนต์กลับไปที่ชื่อของใบรับรอง